[Os-project-managers] Bonmin etc. options passed through Couenne

Horand Gassmann Horand.Gassmann at DAL.CA
Sat Oct 13 12:23:40 EDT 2012


Jun Ma <majxuh at hotmail.com> wrote:

> The reasons for "category"
> 1. It's not just for solver, i.e. it can be used to categorize other
> aspects.

To make clear my intention: I do *not* suggest to get rid of the  
"category" attribute. However, a Couenne user must specify in the  
Couenne.opt option file

bonmin.xxx
couenne.xxx

and apparently

cbc.xxx

although I have not seen a working example of this.

That is, the "name" the user sees has the dot built in. It is  
therefore a bit confusing for us to require

name="xxx" category="couenne"

just to get a couenne option processed (and it requires quite a bit of  
code to deal with category="ipopt", because apparently the loader does  
not accept that). It seems so much easier to implement  
name="couenne.xxx". More importantly, I do not want to mislead the  
user as to the purpose of "category" in the write-up of the  
option/result paper.

> 2. It' a grouping mechanism. Having it separate provides structured info.
> 3. Bh mixing it into the name, we lose the structure, thus the info.  
> (xxx.yyy could mean anything)

I certainly agree, but couenne.xxx is what the Couenne manual calls  
the option. For us to advocate a *different* name *and* requiring  
additional info in the "category" attribute seems wrong.

> 4. Category in a sense is just like "package" or "namespace" in any  
> language that is used to make sure the name is unique.
> 5. If xxx.yyy is a tight name, i.e. xxx and yyy are treated as a  
> whole, then you always can choose not to add a category, say zzz.  
> The name will just be xxx.yyy, NOT zzz.xxx.yyy

But if name="xxx.yyy" and name="yyy" category="xxx" are treated as  
synonymous (as in the Couenne case), we are inviting confusion. And if  
they are not, then that is even worse.

I still think the easiest solution would be to take that paragraph out  
ot the paper.

Cheers

gus


>> Hi guys,
>>
>> In our options paper we say "Another use of the {\tt  category}
>> attribute is to allow a solver to pass options on to external pieces
>> of software that are used by the solver. For instance, Couenne..."
>>
>> In the OSCouenneSolver we then go through contortions to build the
>> option name out of the "name" and "category" attributes and pass it to
>> the option loader in Couenne as e.g., "bonmin.warmstart". Wouldn't it
>> be a lot easier and clearer(!) so simply put "bonmin.warmstart" as the
>> *name* of the option right away? After all, this is the name you would
>> use when calling Couenne in stand-alone fashion, and this is what the
>> Couenne user's manual says you should do. It would also simplify our
>> code considerably, and it would avoid the contortion of treating
>> category "ipopt" special, since the loader does not prepend the
>> 'ipopt' to the option name. That is
>>
>> name="print_level" value="6" category="ipopt"
>>
>> must be sent to the option loader *without* the 'ipopt.' prepended. I
>> say, using the "category" attribute in the way we are advocating in
>> the paper is confusing and can do more harm than good. My preference
>> would be to simply take that paragraph out of the paper.
>>
>> Cheers
>>
>> gus

-------------------------------------------------------

Horand I. Gassmann, Professor

School of Business Administration, Dalhousie University
6100 University Avenue, PO Box 15000
Halifax, Nova Scotia, Canada, B3H 4R2
ph. (902) 494-1844
fax (902) 494-1107

http://myweb.dal.ca/gassmann/



More information about the Os-project-managers mailing list