[Os-project-managers] More schema issues

Kipp Martin kmartin at chicagobooth.edu
Wed Oct 3 05:07:46 EDT 2012


Hi Gus:

>>>
>>> I am not so sure. Remember, we are talking about an <other> result
>>> associated with the upper and lower bounds of a problem. This could
>>> equally well be a status of some kind, which could be an integer, or
>>> even an enumeration, that is, a string.
>>
>> What is an example of an upper bound on a string or enumeration? This
>> seems to be getting really far out there.
>
> Aaaahhaaa!! This is a completely new spin on things, and it shows that
> the very terms ubValue and lbValue are ambiguous. I had assumed that
> they referred to some characteristics associated with the upper and
> lower bounds of a variable, such as whether the upper bound is tight, or
> that it was tightened during the algorithm, or something along those
> lines. You seem to interpret ubValue and lbValue as a _range_ on a value
> associated with the variable, such as bounds on a reduced cost or
> something like that.
>
> In your interpretation I would agree; there is little sense in
> describing a range other than through a pair of real numbers. But in my
> interpretation I feel it is perfectly reasonable to expect the ubValue
> "tightened" to mean that the upper bound on the variable was tightened,
> while the ubValue "original" would say that the lower bound was
> unchanged. My memory is playing tricks on me occasionally, so I cannot
> be certain that my interpretation is what was originally intended, but I
> seem to recall Jun mentioning something very much along the lines of my
> interpretation.
>
> Having said that, however, I am left to wonder whether this ambiguity
> isn't one of our own making, and whether we wouldn't be better off just
> canning lbValue and ubValue altogether. For both interpretations we can
> get the desired effect through a pair of <other> elements. It's more
> wordy, but a lot easier to interpret.

Of course if can them then we are not backward compatible. This seems so 
minor, my vote is to just leave it be for now.

Cheers


>
> Cheers
>
> gus
>


-- 
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

Sent without Blackberry, Droid, iPhone, or any other
wireless device.
-- 


More information about the Os-project-managers mailing list