<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Le 2015-06-30 03:18, Clément David a
écrit :<br>
</div>
<blockquote
cite="mid:1435648681.11353.18.camel@scilab-enterprises.com"
type="cite">
<pre wrap="">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.</pre>
</blockquote>
<br>
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,<br>
<blockquote>-->ieee(0)<br>
-->exp(2000)<br>
ans =<br>
Inf <br>
-->1/0<br>
!--error 27 <br>
Division by zero...<br>
<br>
-->ieee(1)<br>
-->exp(2000)<br>
ans =<br>
Inf <br>
-->1/0<br>
ans =<br>
Inf <br>
</blockquote>
and according to the doc, ieee(1) : floating point exception
produces a warning...<br>
<br>
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)<br>
<br>
<br>
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!<br>
<br>
Just my 2 cents on this topic! <br>
<br>
JPD<br>
<br>
<br>
<br>
<br>
<blockquote
cite="mid:1435648681.11353.18.camel@scilab-enterprises.com"
type="cite">
<pre wrap="">
--
Clément
Le lundi 22 juin 2015 à 14:35 +0200, Stéphane Mottelet a écrit :
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">_______________________________________________
dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:dev@lists.scilab.org">dev@lists.scilab.org</a>
<a class="moz-txt-link-freetext" href="http://lists.scilab.org/mailman/listinfo/dev">http://lists.scilab.org/mailman/listinfo/dev</a>
</pre>
</blockquote>
<br>
</body>
</html>