No subject
Wed Sep 26 11:31:34 EDT 2012
gestion.On > But if name=3D"xxx.yyy" and name=3D"yyy" category=3D"xxx" are =
treated as=20
> synonymous (as in the Couenne case)=2C we are inviting confusion. And if=
=20
> they are not=2C then that is even worse.category shouldn't be by default =
automatically be concatenated with name. The two cases are NOT synonymous. =
It's up to the solver driver to separately feed category/name (in Lindo's c=
ase?) or concatenate them with . or : or whatever. The solver driver can ma=
p the "category" to any concept in the solver. The solver can ignore the ca=
tegory. This is all because solver driver understands best both OS and solv=
er. It's an implementation bridge between the two that does the matching as=
close as possible.=20
Jun
> Date: Sat=2C 13 Oct 2012 13:23:40 -0300
> From: Horand.Gassmann at Dal.Ca
> To: majxuh at hotmail.com
> CC: kmartin at chicagobooth.edu=3B os-project-managers at list.coin-or.org
> Subject: RE: Bonmin etc. options passed through Couenne
>=20
> Jun Ma <majxuh at hotmail.com> wrote:
>=20
> > The reasons for "category"
> > 1. It's not just for solver=2C i.e. it can be used to categorize other
> > aspects.
>=20
> To make clear my intention: I do *not* suggest to get rid of the =20
> "category" attribute. However=2C a Couenne user must specify in the =20
> Couenne.opt option file
>=20
> bonmin.xxx
> couenne.xxx
>=20
> and apparently
>=20
> cbc.xxx
>=20
> although I have not seen a working example of this.
>=20
> That is=2C the "name" the user sees has the dot built in. It is =20
> therefore a bit confusing for us to require
>=20
> name=3D"xxx" category=3D"couenne"
>=20
> just to get a couenne option processed (and it requires quite a bit of =20
> code to deal with category=3D"ipopt"=2C because apparently the loader doe=
s =20
> not accept that). It seems so much easier to implement =20
> name=3D"couenne.xxx". More importantly=2C I do not want to mislead the =20
> user as to the purpose of "category" in the write-up of the =20
> option/result paper.
>=20
> > 2. It' a grouping mechanism. Having it separate provides structured inf=
o.
> > 3. Bh mixing it into the name=2C we lose the structure=2C thus the info=
. =20
> > (xxx.yyy could mean anything)
>=20
> I certainly agree=2C but couenne.xxx is what the Couenne manual calls =20
> the option. For us to advocate a *different* name *and* requiring =20
> additional info in the "category" attribute seems wrong.
>=20
> > 4. Category in a sense is just like "package" or "namespace" in any =20
> > language that is used to make sure the name is unique.
> > 5. If xxx.yyy is a tight name=2C i.e. xxx and yyy are treated as a =20
> > whole=2C then you always can choose not to add a category=2C say zzz. =
=20
> > The name will just be xxx.yyy=2C NOT zzz.xxx.yyy
>=20
> But if name=3D"xxx.yyy" and name=3D"yyy" category=3D"xxx" are treated as =
=20
> synonymous (as in the Couenne case)=2C we are inviting confusion. And if =
=20
> they are not=2C then that is even worse.
>=20
> I still think the easiest solution would be to take that paragraph out =20
> ot the paper.
>=20
> Cheers
>=20
> gus
>=20
>=20
> >> Hi guys=2C
> >>
> >> 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=2C 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.=2C "bonmin.warmstart". Wouldn't i=
t
> >> be a lot easier and clearer(!) so simply put "bonmin.warmstart" as the
> >> *name* of the option right away? After all=2C this is the name you wou=
ld
> >> use when calling Couenne in stand-alone fashion=2C and this is what th=
e
> >> Couenne user's manual says you should do. It would also simplify our
> >> code considerably=2C and it would avoid the contortion of treating
> >> category "ipopt" special=2C since the loader does not prepend the
> >> 'ipopt' to the option name. That is
> >>
> >> name=3D"print_level" value=3D"6" category=3D"ipopt"
> >>
> >> must be sent to the option loader *without* the 'ipopt.' prepended. I
> >> say=2C 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
>=20
> -------------------------------------------------------
>=20
> Horand I. Gassmann=2C Professor
>=20
> School of Business Administration=2C Dalhousie University
> 6100 University Avenue=2C PO Box 15000
> Halifax=2C Nova Scotia=2C Canada=2C B3H 4R2
> ph. (902) 494-1844
> fax (902) 494-1107
>=20
> http://myweb.dal.ca/gassmann/
>=20
=
--_04127591-7c3d-4f01-83af-76bd5992a659_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<style><!--
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 12pt=3B
font-family:Calibri
}
--></style></head>
<body class=3D'hmmessage'><div dir=3D'ltr'>From the perspective point of vi=
ew in the paper=2C I would go with your suggestion.<div>On =3B<div>>=
=3B But if name=3D"xxx.yyy" and name=3D"yyy" category=3D"xxx" are treated a=
s =3B<br>>=3B synonymous (as in the Couenne case)=2C we are inviting =
confusion. And if =3B<br>>=3B they are not=2C then that is even worse=
.</div><div>category shouldn't be by default automatically be concatenated =
with name. =3B<div></div></div><div>The two cases are NOT =3B<span =
style=3D"font-size: 12pt=3B ">synonymous. =3B</span></div><div><span st=
yle=3D"font-size: 12pt=3B ">It's up to the solver driver to separately feed=
category/name (in Lindo's case?) or concatenate them with . or : or whatev=
er. =3B</span></div><div><span style=3D"font-size: 12pt=3B ">The solver=
driver can map the "category" to any concept in the solver. =3B</span>=
</div><div><span style=3D"font-size: 12pt=3B ">The solver can ignore the ca=
tegory. =3B</span></div><div><span style=3D"font-size: 12pt=3B ">This i=
s all because solver driver understands best both OS and solver. It's an im=
plementation bridge between the two that does the matching as close as poss=
ible. =3B</span></div><div><span style=3D"font-size: 12pt=3B "><br></sp=
an></div><div><span style=3D"font-size: 12pt=3B ">Jun</span></div><div><spa=
n style=3D"font-size: 12pt=3B "><br></span></div><div><br></div><div><br><d=
iv><div id=3D"SkyDrivePlaceholder"></div>>=3B Date: Sat=2C 13 Oct 2012 13=
:23:40 -0300<br>>=3B From: Horand.Gassmann at Dal.Ca<br>>=3B To: majxuh at ho=
tmail.com<br>>=3B CC: kmartin at chicagobooth.edu=3B os-project-managers at lis=
t.coin-or.org<br>>=3B Subject: RE: Bonmin etc. options passed through Cou=
enne<br>>=3B <br>>=3B Jun Ma <=3Bmajxuh at hotmail.com>=3B wrote:<br>&=
gt=3B <br>>=3B >=3B The reasons for "category"<br>>=3B >=3B 1. It's=
not just for solver=2C i.e. it can be used to categorize other<br>>=3B &=
gt=3B aspects.<br>>=3B <br>>=3B To make clear my intention: I do *not* =
suggest to get rid of the <br>>=3B "category" attribute. However=2C a Co=
uenne user must specify in the <br>>=3B Couenne.opt option file<br>>=
=3B <br>>=3B bonmin.xxx<br>>=3B couenne.xxx<br>>=3B <br>>=3B and ap=
parently<br>>=3B <br>>=3B cbc.xxx<br>>=3B <br>>=3B although I have =
not seen a working example of this.<br>>=3B <br>>=3B That is=2C the "na=
me" the user sees has the dot built in. It is <br>>=3B therefore a bit c=
onfusing for us to require<br>>=3B <br>>=3B name=3D"xxx" category=3D"co=
uenne"<br>>=3B <br>>=3B just to get a couenne option processed (and it =
requires quite a bit of <br>>=3B code to deal with category=3D"ipopt"=2C=
because apparently the loader does <br>>=3B not accept that). It seems =
so much easier to implement <br>>=3B name=3D"couenne.xxx". More importan=
tly=2C I do not want to mislead the <br>>=3B user as to the purpose of "=
category" in the write-up of the <br>>=3B option/result paper.<br>>=3B=
<br>>=3B >=3B 2. It' a grouping mechanism. Having it separate provides=
structured info.<br>>=3B >=3B 3. Bh mixing it into the name=2C we lose=
the structure=2C thus the info. <br>>=3B >=3B (xxx.yyy could mean any=
thing)<br>>=3B <br>>=3B I certainly agree=2C but couenne.xxx is what th=
e Couenne manual calls <br>>=3B the option. For us to advocate a *differ=
ent* name *and* requiring <br>>=3B additional info in the "category" att=
ribute seems wrong.<br>>=3B <br>>=3B >=3B 4. Category in a sense is j=
ust like "package" or "namespace" in any <br>>=3B >=3B language that i=
s used to make sure the name is unique.<br>>=3B >=3B 5. If xxx.yyy is a=
tight name=2C i.e. xxx and yyy are treated as a <br>>=3B >=3B whole=
=2C then you always can choose not to add a category=2C say zzz. <br>>=
=3B >=3B The name will just be xxx.yyy=2C NOT zzz.xxx.yyy<br>>=3B <br>&=
gt=3B But if name=3D"xxx.yyy" and name=3D"yyy" category=3D"xxx" are treated=
as <br>>=3B synonymous (as in the Couenne case)=2C we are inviting conf=
usion. And if <br>>=3B they are not=2C then that is even worse.<br>>=
=3B <br>>=3B I still think the easiest solution would be to take that par=
agraph out <br>>=3B ot the paper.<br>>=3B <br>>=3B Cheers<br>>=3B =
<br>>=3B gus<br>>=3B <br>>=3B <br>>=3B >=3B>=3B Hi guys=2C<br>&=
gt=3B >=3B>=3B<br>>=3B >=3B>=3B In our options paper we say "Anot=
her use of the {\tt category}<br>>=3B >=3B>=3B attribute is to allow=
a solver to pass options on to external pieces<br>>=3B >=3B>=3B of s=
oftware that are used by the solver. For instance=2C Couenne..."<br>>=3B =
>=3B>=3B<br>>=3B >=3B>=3B In the OSCouenneSolver we then go throu=
gh contortions to build the<br>>=3B >=3B>=3B option name out of the "=
name" and "category" attributes and pass it to<br>>=3B >=3B>=3B the o=
ption loader in Couenne as e.g.=2C "bonmin.warmstart". Wouldn't it<br>>=
=3B >=3B>=3B be a lot easier and clearer(!) so simply put "bonmin.warms=
tart" as the<br>>=3B >=3B>=3B *name* of the option right away? After =
all=2C this is the name you would<br>>=3B >=3B>=3B use when calling C=
ouenne in stand-alone fashion=2C and this is what the<br>>=3B >=3B>=
=3B Couenne user's manual says you should do. It would also simplify our<br=
>>=3B >=3B>=3B code considerably=2C and it would avoid the contortion=
of treating<br>>=3B >=3B>=3B category "ipopt" special=2C since the l=
oader does not prepend the<br>>=3B >=3B>=3B 'ipopt' to the option nam=
e. That is<br>>=3B >=3B>=3B<br>>=3B >=3B>=3B name=3D"print_leve=
l" value=3D"6" category=3D"ipopt"<br>>=3B >=3B>=3B<br>>=3B >=3B&g=
t=3B must be sent to the option loader *without* the 'ipopt.' prepended. I<=
br>>=3B >=3B>=3B say=2C using the "category" attribute in the way we =
are advocating in<br>>=3B >=3B>=3B the paper is confusing and can do =
more harm than good. My preference<br>>=3B >=3B>=3B would be to simpl=
y take that paragraph out of the paper.<br>>=3B >=3B>=3B<br>>=3B &g=
t=3B>=3B Cheers<br>>=3B >=3B>=3B<br>>=3B >=3B>=3B gus<br>>=
=3B <br>>=3B -------------------------------------------------------<br>&=
gt=3B <br>>=3B Horand I. Gassmann=2C Professor<br>>=3B <br>>=3B Schoo=
l of Business Administration=2C Dalhousie University<br>>=3B 6100 Univers=
ity Avenue=2C PO Box 15000<br>>=3B Halifax=2C Nova Scotia=2C Canada=2C B3=
H 4R2<br>>=3B ph. (902) 494-1844<br>>=3B fax (902) 494-1107<br>>=3B <=
br>>=3B http://myweb.dal.ca/gassmann/<br>>=3B <br></div></div></div> =
</div></body>
</html>=
--_04127591-7c3d-4f01-83af-76bd5992a659_--
More information about the Os-project-managers
mailing list