[Scilab-users] update script to Scilab 6.00

[Hermes]

how to update this script to scilab 6.00. I really do not know where and how
to substitute ¨pixmap¨ for drawlater and drawnow and get the animation as
good as shown on the source website of the script

//http://www.ulb.ac.be/polytech/smana/TUTORIAL.htm
  
function dy=fon(t, y)
global g l 
dy(1) = y(2);
dy(2)=-g/l*sin(y(1)); 
endfunction
 
teta_init = 45;teta_init=teta_init/180*pi;dteta_init = 0;
g=9.81;l=1;
t=0:0.1:20;
y=ode([teta_init;dteta_init],0,[t],fon);
 
//Preparation du graphe
f = gcf(); // on recupere le handle de la fen^etre graphique
f.pixmap = "on"; // on met la fenetre en mode double buffer
f.background = color("white");
f.foreground = color("white");;
//FIN Preparation du graphe
 
i = 1;
while i<=length(y)  
  i = i+1;  
  
  clf(); // On efface l'image précédente - on évite le scintillement
  xtitle('', 'm', 'm');  
  a = gca(); // On récupère l'objet graphique axes pour modifier les
légendes
  a.isoview = "on"; a.data_bounds = [-2 2 -2 2];  a.title.text = "Le pendule
";
  a.title.font_size = 4; a.title.foreground = color("white");
  a.background = color("white");;
 
  xpoly([0  +l*sin(y(1,i))],[0 -l*cos(y(1,i))],"lines",0)
  ep = gce(); // On récupère l'objet graphique double-pendule atwood 
  // pour modifier son aspect cosmétique
  ep.thickness = 3;ep.foreground = color("blue");
  
 
plot([+l*sin(y(1,i))],[-l*cos(y(1,i))],'o','MarkSize',10,'MarkBackground','b')
  xgrid(12)
  show_pixmap() // basculement de la pixmap a l'ecran
end
f.pixmap = "off"; // on remet la fen^etre en mode usuel


Gracias



--
Sent from: 
http://mailinglists.scilab.org/Scilab-users-Mailing-Lists-Archives-f2602246.html
___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

Re: [Scilab-users] Strange floating point issue below %eps

[antoine monmayrant]

Thanks a lot Bruno!

I knew I had read something like that but could not remember what it was 
called.


Cheers,

Antoine

PS: Samuel, do you think you could close the bug by pointing to this 
"round to even" rule?



Le 19/09/2017 à 11:16, Pinçon Bruno a écrit :

Le 18/09/2017 à 20:54, Samuel Gougeon a écrit :


Now comes the issue:
In (A), the relative difference 1/2^53 is too small (< %eps) to be 
recorded and to change the number. OK.
Since 1 / (2^53 +2) is even smaller than 1 / (2^53), it should nor 
make a difference. Yet, it does:


--> (2^53 + 2^1) + 1 == (2^53 + 2^1)
 ans  =
  F

How is this possible ??!



Hi all,

   no issue here but simply the round to even rule. Every real number
  should be approximated by the nearest floating point number but in 
case of

  a number exactly between 2 successive floats the one with an even end
  digit win. You can see this rule as a mean to approximate those 
ambiguous cases,
  one in two down and one in two up, but has more subtle features in 
it such

  (it is explained in Knuth I).


  OK that2^53 + 2^1 is exactly represented
  (it is a double float number). When computing :

  x = (2^53 + 2^1) + 1

  it is not a float but is exactly at the same distance between the 
two floats :


2^53 + 2^1   and 2^53 + 2^2  but this last one ends with a even digit (0)
  so :
 fl( (2^53 + 2^1) + 1) = 2^53 + 2^2

  hth
 Bruno



___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users


___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

Re: [Scilab-users] Strange floating point issue below %eps

[Pinçon Bruno]

Le 18/09/2017 à 20:54, Samuel Gougeon a écrit :


Now comes the issue:
In (A), the relative difference 1/2^53 is too small (< %eps) to be 
recorded and to change the number. OK.
Since 1 / (2^53 +2) is even smaller than 1 / (2^53), it should nor 
make a difference. Yet, it does:


--> (2^53 + 2^1) + 1 == (2^53 + 2^1)
 ans  =
  F

How is this possible ??!



Hi all,

   no issue here but simply the round to even rule. Every real number
  should be approximated by the nearest floating point number but in 
case of

  a number exactly between 2 successive floats the one with an even end
  digit win. You can see this rule as a mean to approximate those 
ambiguous cases,
  one in two down and one in two up, but has more subtle features in it 
such

  (it is explained in Knuth I).


  OK that2^53 + 2^1 is exactly represented
  (it is a double float number). When computing :

  x = (2^53 + 2^1) + 1

  it is not a float but is exactly at the same distance between the two 
floats :


2^53 + 2^1   and 2^53 + 2^2  but this last one ends with a even digit (0)
  so :
 fl( (2^53 + 2^1) + 1) = 2^53 + 2^2

  hth
 Bruno

___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

Re: [Scilab-users] This version of Scilab will probably fail on this system (10.13)

[Paul Bignier]

Hello Heinz,


I don't know why version 10.13 is detected but you should have a "Try anyway" 
button is that message window, did you try it?

If it doesn't work, can you please try to run Scilab from a terminal (command 
'bin/scilab') and send me the return?

Which Scilab version are you running, and what MacOS version please?


Regards,

Paul


Paul BIGNIER
Development engineer
---
ESI Group - Scilab
99 rue des Solets - 94513 Rungis, France
Phone: +33.1.41.73.58.77
https://scilab.io
https://esi-group.com



From: users  on behalf of Heinz Nabielek 

Sent: Monday, September 18, 2017 11:45 PM
To: users@lists.scilab.org
Subject: [Scilab-users] This version of Scilab will probably fail on this 
system (10.13)

>>This version of Scilab will probably fail on this system (10.13): Scilab
requires 10.8.3 (Mountain Lion) or newer system.

It has failed. What can I do? I have not Mac OS X 10.13 in my iMac
Heinz



--
Sent from: 
http://mailinglists.scilab.org/Scilab-users-Mailing-Lists-Archives-f2602246.html
___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users
___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

Re: [Scilab-users] Strange floating point issue below %eps

[antoine monmayrant]

Just digging a bit further in julia:

println("2.0^53+2.0^1   : $(bits(2.0^53+2.0^1))")
println("2.0^53+2.0^1+1 : $(bits(2.0^53+2.0^1+1))")
println("")
println("2.0^53+2.0^2   : $(bits(2.0^53+2.0^2))")
println("2.0^53+2.0^2+1 : $(bits(2.0^53+2.0^2+1))")

gives:

2.0^53+2.0^1   : 
01110101
2.0^53+2.0^1+1 : 
01110110


2.0^53+2.0^2   : 
01110110
2.0^53+2.0^2+1 : 
01110110


So the first two are different while the last two are bit identical.

I anyone can point to the specific bit in IEEE spec for this, I'll be happy!


Antoine

Le 19/09/2017 à 08:58, antoine monmayrant a écrit :


Houps, my bad, julia does exactly the same when using Float64, not Int64:


println((2.0^53 + 2.0^2) + 1.0 == (2.0^53 + 2.0^2))

true

println((2.0^53 + 2.0^1) + 1.0 == (2.0^53 + 2.0^1))

false


It has to be some normal IEEE thing but I did not manage to find the 
proper reference for it.



Antoine


Le 18/09/2017 à 20:54, Samuel Gougeon a écrit :


Dear co-Scilabers,

I met a strange Scilab's bug this week-end. But today, i tried with 
Octave, Matlab2016 and R, and i found the same strange behavior. So, 
either i am missing something, or the bug affects all these languages 
in the same way. It is reported @ http://bugzilla.scilab.org/15276


In a few words, here it is:

The mantissa of any decimal number is recorded on 53 bits (numbered 
#0 to #52) + 1 bit for the sign.

This relative absolute accuracy sets the value of the epsilon-machine :
--> %eps == 2^0 / 2^52
 ans  =
  T
From here, it comes, as expected:

--> 2^52 + 1 == 2^52
 ans  =
  F

--> 2^53 - 1 == 2^53
 ans  =
  F

--> 2^53 + 1 == 2^53   // (A)
 ans  =
  T

Now comes the issue:
In (A), the relative difference 1/2^53 is too small (< %eps) to be 
recorded and to change the number. OK.
Since 1 / (2^53 +2) is even smaller than 1 / (2^53), it should nor 
make a difference. Yet, it does:


--> (2^53 + 2^1) + 1 == (2^53 + 2^1)
 ans  =
  F

How is this possible ??!
But this occurs only when THIS bit #0 is set. For higher bits 
(hebelow the #1 one), we get back to the expected behavior:

--> (2^53 + 2^2) + 1 == (2^53 + 2^2)
 ans  =
  T

So, when the bit #0 is set and we add a value on the bit "#-1", the 
language somewhat behaves as if there was a "withholding" value on 
the bit #0, and seems to toogle it.
Is is a part of any IEEE floating point convention, or am i missing 
anything, or is it a true bug?

Again, R, Octave and Matlab behave exactly in the same way...

Looking forward to reading your thoughts,

Samuel






___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users




___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users


___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

Re: [Scilab-users] Strange floating point issue below %eps

[antoine monmayrant]

Houps, my bad, julia does exactly the same when using Float64, not Int64:


println((2.0^53 + 2.0^2) + 1.0 == (2.0^53 + 2.0^2))

true

println((2.0^53 + 2.0^1) + 1.0 == (2.0^53 + 2.0^1))

false


It has to be some normal IEEE thing but I did not manage to find the 
proper reference for it.



Antoine


Le 18/09/2017 à 20:54, Samuel Gougeon a écrit :


Dear co-Scilabers,

I met a strange Scilab's bug this week-end. But today, i tried with 
Octave, Matlab2016 and R, and i found the same strange behavior. So, 
either i am missing something, or the bug affects all these languages 
in the same way. It is reported @ http://bugzilla.scilab.org/15276


In a few words, here it is:

The mantissa of any decimal number is recorded on 53 bits (numbered #0 
to #52) + 1 bit for the sign.

This relative absolute accuracy sets the value of the epsilon-machine :
--> %eps == 2^0 / 2^52
 ans  =
  T
From here, it comes, as expected:

--> 2^52 + 1 == 2^52
 ans  =
  F

--> 2^53 - 1 == 2^53
 ans  =
  F

--> 2^53 + 1 == 2^53   // (A)
 ans  =
  T

Now comes the issue:
In (A), the relative difference 1/2^53 is too small (< %eps) to be 
recorded and to change the number. OK.
Since 1 / (2^53 +2) is even smaller than 1 / (2^53), it should nor 
make a difference. Yet, it does:


--> (2^53 + 2^1) + 1 == (2^53 + 2^1)
 ans  =
  F

How is this possible ??!
But this occurs only when THIS bit #0 is set. For higher bits (hebelow 
the #1 one), we get back to the expected behavior:

--> (2^53 + 2^2) + 1 == (2^53 + 2^2)
 ans  =
  T

So, when the bit #0 is set and we add a value on the bit "#-1", the 
language somewhat behaves as if there was a "withholding" value on the 
bit #0, and seems to toogle it.
Is is a part of any IEEE floating point convention, or am i missing 
anything, or is it a true bug?

Again, R, Octave and Matlab behave exactly in the same way...

Looking forward to reading your thoughts,

Samuel






___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users


___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

Re: [Scilab-users] Strange floating point issue below %eps

[antoine monmayrant]

Hello Samuel,

Is this some IEEE standard overflow wraparound?

For information, Julia (0.6) does not behave exactly in the same way.
Both 'print((2^53 + 2^2) + 1 == (2^53 + 2^2))' and  'print((2^53 + 2^1) 
+ 1 == (2^53 + 2^1))' return false.


Antoine
___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users