[Os-project-managers] NaN in xs:double (OSrL)

[Horand Gassmann]

Kipp Martin <kmartin at chicagobooth.edu> wrote:

> Hi Gus:
>
> So I guess there are places were we instantiate an object and we set  
> data members equal to NaN. Is that correct?
>>> It seems to me that by definition of an optimal, indeed even feasible
>>> solution, cannot contain a NaN.  If the solver does return NaN my first
>>> inclination is in the <optimization> child <status> set type = "error"
>>> and under description say "solver returned a NaN."  In  such a case we
>>> would not print a <solution>. I would argue that having a NaN as a
>>> solution value is an oxymoron.
>>
>> But even then, I think, the diagnostics would be helped greatly if  
>> we provide tools to *pinpoint* where the NaN occurred. We allow NaN  
>> to be provided as a *starting value*, so why not as a terminating  
>> value? We seem to be breaking the symmetry here.
>
> But we DON'T provide the value to the solver correct? Don't we use  
> it as a  place holder so we can skip over that initial value? I see  
> this as quite different from reporting it in a solution.

That is not how I remember the discussion from last time (or maybe the  
time before that):

<initialVariableValues numberOfVar="2">
	<var idx="0" value="NaN"/>
	<var idx="1"/>

should set both x0 and x1 to NaN (this I am clear on) and should send  
those values to the solver (this is how I understood the discussion,  
but perhaps I misunderstood).

But even then, I maintain that diagnosing a solver error would be  
greatly helped if there were some mechanism that allows the user to  
pinpoint the variable or constraint or even objective that went awry.  
And the only way I see for that to happen is a way that allows the  
solver to return NaN to the user.

Another Can$ 0.02

Cheers

gus