[Os-project-managers] More schema issues

Horand Gassmann Horand.Gassmann at dal.ca
Tue Oct 2 13:08:44 EDT 2012


Kipp Martin <kmartin at chicagobooth.edu> wrote:

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

Cheers

gus



More information about the Os-project-managers mailing list