Le 2015-06-30 03:18, Clément David a écrit :
Hello Stéphane,

Sorry for the lag but I tried to investigate a little bit !

Did you try to reproduce on a reduced test case which does not depends
on fsqp ?

For the 5.5.2 release, I did not notice anything that might impact the
behavior of fsqp.

I might be slightly off topic, but floating point is sometimes unpredictable: scilab provides the function ieee to specify the behaviour of floating point operations. BUT, on my 5.5.1 under Ubuntu 14.04,

   -->ieee(0)
   -->exp(2000)
     ans  =
        Inf
   -->1/0
        !--error 27
   Division by zero...

   -->ieee(1)
   -->exp(2000)
     ans  =
        Inf
   -->1/0
     ans  =
        Inf

and according to the doc, ieee(1) : floating point exception produces a warning...

The first exp(2000) should have produced an error, the second a warning and if using ieee(2), Inf. 1/0 should produce a warning with ieee(1) and correctly produces an error with ieee(0)


Unfortunately, the correct treatement of IEEE 754 floating point operations is very often very messy, not only in scilab. Now, what if the external code is compiled using different assumptions with respect to the desired behavior when "exeptions" or Inf are produced? An increased messyness!

Just my 2 cents on this topic!

JPD





--
Clément

Le lundi 22 juin 2015 à 14:35 +0200, Stéphane Mottelet a écrit :
Hello Scilab devmasters !

I have noticed subtle (but real) differences between successive
versions
of Scilab, here's the whole story:

I use fsqp to solve an optimization problem where the computation of
the
cost function and its gradient uses a lot of sparse/full matrix
products, and I noticed different convergence behaviour of the same
code
depending on the Scilab version.

E.g. with Scilab 5.5.0 and 5.5.1 fsqp converges within the prescribed

tolerance (norm of the gradient), but with 5.5.2 fsqp stops its
iterations without reaching it. When relaxing the tolerance
successful
convergence is obtained but I got slightly different results at the
end.

I am wondering about which pathway I should follow to identify the
problem, so my questions are the following :

-is it possible that the scilab version which has been used to
compile
fsqp could produce such a behaviour ?
-did the sparse/sparse and sparse/full product routines change
recently ?

Best regards,

S.


_______________________________________________
dev mailing list
[email protected]
http://lists.scilab.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
[email protected]
http://lists.scilab.org/mailman/listinfo/dev

Reply via email to