[Os-project-managers] Question about OSxLParserdata, OSInstance, OSOption

[Jun Ma]

Gus,
Here is one major point not to be missed that I want to make after reading 
all the previous emails on this:
OSInstance is necessary to have a correspondingly binding structure to OSiL 
Schema, because all along we have TWO big sides to balance
a) as a standard datastructure that can serve as a good candidate to further 
interface with any solver and that is robust enough to be an extensible 
design
b) given that certain performance issue becomes extremely critical, the 
design doesn't need to be "clean" and "nice". e.g. we will think about using 
array

Our goal of "extensibility"  and "compatibility" is, if you think about it, 
is what's the original intent and our major and unique selling point.
If fact the goal is so big -- extensible to all optimization types and 
compatible (easily through drivers) with all the  solver -- that we HAVE to 
weigh mostly on a)
Originally we thought it was always a) but as we gained more experience, we 
do think giving our way to the b) side is necessary from time to time.

Given the above comment, I believe, there is no major flaw in OS Framework 
and Standards and the corresponding implementations.
Hope this helps.

Jun

--------------------------------------------------
From: "Kipp Martin" <kmartin at chicagobooth.edu>
Sent: Tuesday, December 21, 2010 12:53 PM
To: "Horand Gassmann" <Horand.Gassmann at dal.ca>
Cc: <os-project-managers at list.coin-or.org>
Subject: Re: [Os-project-managers] Question about OSxLParserdata, 
OSInstance, OSOption

> Hi Gus:
>
>
>>
>> Ah!!! I had not taken this point onboard. This is indeed significant.
>
> Well actually there still is a problem but I don't have time to write
> out a detailed email because I am taking off soon for the day. We can
> discuss next Wednesday. Right now, "in theory" one never ever modifies
> the "original" OSInstance object. Of course theory is different than
> practice and we can discuss.  The OSModification will be for modifying
> an OSInstance. I envision OSModification as storing a set of
> modification objects that can be applied to an OSInstance object. It
> would work much like a word processor where you can edit your document
> but then under the "edit" menu item hit "undo" multiple times to get
> back to where you were.
>>
>>>> Can I summarize the state of affairs as follows: The constitution
>>>> requires OSInstance, OSResult and OSOption, but for efficiency it may
>>>> be more expeditious to switch to a flat storage scheme. Is that fair?
>>> Yes, absolutely, Jun has made this point a number of times.
>>
>> OK. Hope I will remember this time...
>>
>>>> Can I also ask about set() methods? I noticed that OSParseosil.y
>>>> stores things into the OSInstance object directly; for example in line
>>>> 1109:
>>>>
>>>> osinstance->instanceHeader->name = pelementText;
>>>>
>>>> or in line 1440:
>>>> osinstance->instanceData->variables->var[varcount]->lb
>>>>          = atofmod1( osillineno,attText, attTextEnd);
>>>>
>>>> One of the things that is slowing me down is the endless writing and
>>>> invoking of set() methods to get the data into the OSOption object.
>>>> Was that even necessary? Should I have left in the old
>>> No it was not necessary.
>>>> osoption->general->serviceURI = $3;
>>>>
>>>> in place of
>>>>
>>>> if (osoption->setServiceURI($3) == false)
>>>>         osolError(...)
>>> Yes, probably so.  I even asked you about this specific point and we
>>> discussed it. I was surprised you wanted to use the set methods but did
>>> not object.
>>
>> I clearly misunderstood. I was under the impression that the set()
>> methods would be prefereable, and that`s what you wanted me to use. My
>> bad. Could have saved enormous amounts of time...
>
> I don't think it is a big deal for OSOption or OSResult.  That is why I
> did not object.
>>
>> But it`s too late now to switch. I will continue doing what I have
>> been doing so that we get something out of the door.
>
>
> I agree, do not change at this point.
>
>
> Sorry for all this confusion.
>
> Cheers
>>
>> Cheers
>>
>> gus
>>
>> _______________________________________________
>> Os-project-managers mailing list
>> Os-project-managers at list.coin-or.org
>> http://list.coin-or.org/mailman/listinfo/os-project-managers
>
>
> -- 
> Kipp Martin
> Professor of Operations Research
> and Computing Technology
> Booth School of Business
> University of Chicago
> 5807 South Woodlawn Avenue
> Chicago, IL 60637
> 773-702-7456
> kmartin at chicagobooth.edu
> http://www.chicagobooth.edu/faculty/bio.aspx?person_id=12825325568
> http://projects.coin-or.org/OS
>
> _______________________________________________
> Os-project-managers mailing list
> Os-project-managers at list.coin-or.org
> http://list.coin-or.org/mailman/listinfo/os-project-managers
>