"Steven Lord" <slord@mathworks.com> wrote in message <h1o1bd$rk7$1@fred.mathworks.com>...
>
> "Erica B" <ebickford@wisc.edu> wrote in message
> news:h1nj2i$65d$1@fred.mathworks.com...
> > This is a followup to my earlier post on June 12 regarding lsqlin in the
> > optimization toolbox returning values outside of given bounds.
> >
> > Part of the problem appears to be lsqlin returning Nans when either the
> > starting value, the target value or the boundaries involve infinity (inf).
> >
> > This appears to be a bug in the lsqlin function, since it would seem that
> > if the starting value is inf, and the lower boundary is inf then lsqlin
> > should register the optimized value as inf, rather than nansnot to
> > mention an entire vector of nans rather than single vector elements.
>
> NaNs propagate. Once you get one NaN involved in a computation, it tends to
> spread, since all of these operations (among others) return NaN:
>
> % x is any arbitrary value
> NaN + x
> x + NaN
> NaN  x
> x  NaN
> x * NaN
> NaN * x
> x ^ NaN
> NaN ^ x
> sin(NaN)
> cos(NaN)
> 0 * Inf
> 0 * NaN
> Inf  Inf
> Inf  Inf
> Inf  (Inf)
> % etc.
>
> > For a little background, I am trying to optimize the following:
> >
> > Y=X1*X2*X3
> >
> > Take the log to solve as a linear system
> >
> > log(Y)=log(X1)+log(X2)+log(X3)
> >
> > This is where inf comes in because some of the Y values and starting X
> > values are 0.
>
> And you're calling LSQLIN on this? So C is [1 1 1], d is log(Y), and you're
> solving the leastsquares problem with x = [log(X1) log(X2) log(X3)]?
>
> In that case, when LSQLIN evaluates norm(C*xd), it performs the
> calculation inf  (inf). The result of that calculation is mathematically
> undefined, and as such results in NaN. As I said above, NaNs propagate so
> after a few iterations most or all of the elements of x will have become NaN
> as the initial NaN is used in the process of calculating the other elements.
> Therefore I claim this is Not A Bug in LSQLIN.
>
> > According to the Matlab documentation, use of inf or inf in boundaries is
> > not a problem and preferable to using arbitrary large or small numbers.
>
> Yes. Using +/ Inf in the lower and upper bounds is fine. Using +/ Inf in
> the equation that you're trying to solve is not fine.
>
> > However, I found that about a third fewer NAN values are returned if I
> > set inf to 1000 in starting values for X.
> >
> > Has anyone else ever encountered lsqlin returning NANs? Were you able to
> > find a way around it, or alternatively determine a single, direct cause?
> > Again, any help, insight or recommendations for alternative strategies
> > would be much appreciated.
>
> The way to avoid LSQLIN encountering NaNs is to have LSQLIN not be forced to
> evaluate the "objective function" at points where the result would be
> nonfinite.
>
> 
> Steve Lord
> slord@mathworks.com
>
Thanks for the reply. You are correct, when I set the target value to an arbitrary, large, negative number, lsqlin stops producing nans.
Erica B.
