Re: [Scilab-users] display of complex/not real numbers, again

2019-09-18 Thread Stéphane Mottelet 

Hello,

Le 13/09/2019 à 12:51, Stéphane Mottelet a écrit :



Le 13/09/2019 à 12:45, Samuel Gougeon a écrit :

Hello,

To me, as already claimed there 
, 
it's clear that, for a complex-encoded number, not displaying its 
null imaginary part is a bug, and the proposed patch is clearly 
welcome as well.


Another regression very close to this one, but with real numbers 
display, would deserve the same care :

Scilab 5:
-->[1e30 1e-30]
 ans  =
    1.000D+30    1.000D-30

Scilab 6:
--> [1e30 1e-30]
 ans  =
   1.000D+30   0.

The patch also fixes this.


So, very small numbers are reduced to strict 0...



Samuel,  do you know if a bug was reported for this particular point ?

Thanks,

S.


This is a bad implementation of the variable format mode. The Scilab 
5 one was correct, at least on this point.


Best regards
Samuel


Le 12/09/2019 à 10:26, Stéphane Mottelet a écrit :

Hello all,

The subject has been already discussed a lot but I would like it to 
be discussed again because I now have a real rationale to promote a 
change in the way complex numbers with small imaginary part are 
displayed.


I don't know if some of you were aware of the clever technique of 
complex-step derivative approximation, but until yesterday I was not 
(see e.g. 
http://mdolab.engin.umich.edu/sites/default/files/Martins2003CSD.pdf). 
Roughly speaking, using the extension of a real function x->f(x) to 
the complex plane allows to compute an approximation of the 
derivative f'(x0) at a real x0 without using a substraction, like in 
the central difference formula (f(x0+h)-f(x0-h))/2/h which is 
subject to substractive cancelation when h is small. In Scilab most 
operators and elementary functions are already complex-aware so this 
is easy to illustrate the technique. For example let us approximate 
the derivative of x->cos(x) at x=%pi/4, first with the central 
difference formula, then with the complex step technique:


--> format("e",24)

--> h=%eps/128, x0=%pi/4
 h  =

   1.73472347597680709D-18

 x0  =

   7.85398163397448279D-01


--> (cos(x0+h)-cos(x0-h))/2/h
 ans  =

   0.0D+00


--> imag(cos(x0+%i*h))/h
 ans  =

  -7.07106781186547462D-01


--> -sin(x0)
 ans  =

  -7.07106781186547462D-01

You can see the pathological approximation with central difference 
formula and the perfect (up to relative machine precision) 
approximation of complex-step formula.


However, the following is a pity:


--> cos(x0+%i*h)
 ans  =

   7.07106781186547573D-01

We cannot see the imaginary part although seeing the latter is 
fundamental in the complex-step technique. We have to force the 
display like this, and frankly I don't like having to do that with 
my students:


--> imag(cos(x0+%i*h))
 ans  =

  -1.22663473334669916D-18

I hope that you will find that this example is a good rationale to 
change the default display of Scilab. To feed the discussion, here 
is how Matlab displays things, without having to change the default 
settings:



>> h=eps/128, x0=pi/4
h =
   1.7347e-18
x0 =
    0.7854

>> (cos(x0+h)-cos(x0-h))/2/h
ans =
 0

>> cos(x0+i*h)
ans =
   0.7071 - 0.i

>> imag(cos(x0+i*h))/h
ans =
   -0.7071

>> -sin(x0)
ans =
   -0.7071





___
users mailing list
users@lists.scilab.org
https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users

--
Stéphane Mottelet
Ingénieur de recherche
EA 4297 Transformations Intégrées de la Matière Renouvelable
Département Génie des Procédés Industriels
Sorbonne Universités - Université de Technologie de Compiègne
CS 60319, 60203 Compiègne cedex
Tel : +33(0)344234688
http://www.utc.fr/~mottelet


--
Stéphane Mottelet
Ingénieur de recherche
EA 4297 Transformations Intégrées de la Matière Renouvelable
Département Génie des Procédés Industriels
Sorbonne Universités - Université de Technologie de Compiègne
CS 60319, 60203 Compiègne cedex
Tel : +33(0)344234688
http://www.utc.fr/~mottelet

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

Re: [Scilab-users] display of complex/not real numbers, again

2019-09-17 Thread Stéphane Mottelet 


Le 17/09/2019 à 15:19, Federico Miyara a écrit :


Stéphane,


--> x=1:0.1:2
 x  =

   1.   1.1   1.2   1.3   1.4   1.5   1.6   1.700   1.8 1.9   2.



nothing triggers it in actual Scilab version. This was just an example 
of what could be displayed after the patch I propose (in its last week 
version). But the discussion has been fruitfull and I will propose 
something that will satisfy (I hope so) everyone.


S.



However I get this:

  > x=1:0.1:2
 x  =

   1.   1.1   1.2   1.3   1.4   1.5   1.6   1.7   1.8   1.9   2.

But it is true that x(7) - 1.7 yields 2.220D-16. Here there are two 
problems, an arithmetic one and a display one. Formatting to a 
sufficiently large number of digits the arithmetic problem (or 
limitation, probably unsurmountable, originated in the incompatibility 
of binary and decimal systems) is evident:


  > format(20)

  > x=1:0.1:2
 x  =

 column 1 to 6

   1.   1.10009   1.19996 
1.30004   1.39991   1.5


 column 7 to 11

   1.60009   1.70018   1.8 
1.89991   2.



Why this triggers showing several zeros I don't understand, probably a 
bug, but it can be seen that it happens when the numeric error affects 
te 16th decimal digit.





Regards,

Federico Miyara







--> x(7)
 ans  =

   1.6

--> x(7)-1.6
 ans  =

   0.

--> x(8)

 ans  =

   1.700

--> x(8)-1.7
 ans  =

   2.220D-16

I think that we do agree about the fact that the actual Scilab display

--> x=1:0.1:2
 x  =

   1.   1.1   1.2   1.3   1.4   1.5   1.6   1.7  1.8   1.9 2.

--> x(7)
 ans  =

   1.6

--> x(7)-1.6
 ans  =

   0.

--> x(8)
 ans  =

   1.7

--> x(8)-1.7
 ans  =

   2.220D-16

is pretty but not correct/homogeneous/honest. The display that is 
obtained with the patch (first lines of this email) is correct+honest 
but not homogeneous. A pretty + mathematically correct display would be:


--> x=1:0.1:2
 x  =

   1.000   1.100   1.200   1.300   1.400 
1.005   1.600   1.700   1.800   1.900 2.000


--> x(7)
 ans  =

   1.6

--> x(8)
 ans  =

   1.700

--> x(8)-1.7

 ans  =

   2.220D-16

i.e. when the matrix to display is not a scalar, add always trailing 
zeros for homogeneity, BUT when it is a scalar, add trailing zeros 
only when the actual stored value is different from the displayed value.


The first thing that you can see is that the default format(10) would 
be very verbose, but this is tunable. A value of 7 would be ok, but 
quite low for format("e").


S.

Le 13/09/2019 à 13:37, Stéphane Mottelet a écrit :



Le 13/09/2019 à 13:07, Samuel Gougeon a écrit :

Le 12/09/2019 à 18:55, Stéphane Mottelet a écrit :
I prefer the display after applying 
https://codereview.scilab.org/#/c/20981/:


--> x0=%pi/4;h=%eps/2
 h  =

   1.110D-16

--> cos(x0+%i*h)
 ans  =

   0.7071068 - 7.850D-17i

However, we could discuss if the arbitrary switch to "e" mode is 
desirable or not, but since Scilab 6.0 we have got used to this 
display mixing "v" and "e" mode...



... and IMO it's very suitable. The only rule should be that, */for 
a given format's width/*, */the more the number of significant 
displayed figures the better./* When the exponent format is used, 
it takes 4 or 5 digits (D+12, D+123). As a consequence, in v mode, 
small (absolute) values should be displayed in normal mode down to 
4 non-significant 0 (e.g. 0.12), and switched to "e" mode beyond.


In v mode, forcing the display of 0.0123456  in "e" mode on the 
(bad) reason that some other huge or tiny numbers in the matrix are 
displayed in this mode, would print 1.234D-02, and so make 
invisible 2 significant figures.
I do not see any reason that would impose the display mode to be 
homogeneous over all elements of a matrix, possibly canceling the 
display of significant figures in the given format's width.



I agree Samuel.


Regards

Samuel



___
users mailing list
users@lists.scilab.org
https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users

--
Stéphane Mottelet
Ingénieur de recherche
EA 4297 Transformations Intégrées de la Matière Renouvelable
Département Génie des Procédés Industriels
Sorbonne Universités - Université de Technologie de Compiègne
CS 60319, 60203 Compiègne cedex
Tel : +33(0)344234688
http://www.utc.fr/~mottelet

___
users mailing list
users@lists.scilab.org
https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users

--
Stéphane Mottelet
Ingénieur de recherche
EA 4297 Transformations Intégrées de la Matière Renouvelable
Département Génie des Procédés Industriels
Sorbonne Universités - Université de Technologie de Compiègne
CS 60319, 60203 Compiègne cedex
Tel : +33(0)344234688
http://www.utc.fr/~mottelet

___
users mailing list
users@lists.scilab.o

Re: [Scilab-users] display of complex/not real numbers, again

2019-09-17 Thread Federico Miyara 


Stéphane,


--> x=1:0.1:2
 x  =

   1.   1.1   1.2   1.3   1.4   1.5   1.6   1.700   1.8 1.9   2.



However I get this:

  > x=1:0.1:2
 x  =

   1.   1.1   1.2   1.3   1.4   1.5   1.6   1.7   1.8   1.9   2.

But it is true that x(7) - 1.7 yields 2.220D-16. Here there are two 
problems, an arithmetic one and a display one. Formatting to a 
sufficiently large number of digits the arithmetic problem (or 
limitation, probably unsurmountable, originated in the incompatibility 
of binary and decimal systems) is evident:


  > format(20)

  > x=1:0.1:2
 x  =

 column 1 to 6

   1.   1.10009   1.19996 1.30004   
1.39991   1.5


 column 7 to 11

   1.60009   1.70018   1.8 1.89991   2.


Why this triggers showing several zeros I don't understand, probably a 
bug, but it can be seen that it happens when the numeric error affects 
te 16th decimal digit.


Regards,

Federico Miyara







--> x(7)
 ans  =

   1.6

--> x(7)-1.6
 ans  =

   0.

--> x(8)

 ans  =

   1.700

--> x(8)-1.7
 ans  =

   2.220D-16

I think that we do agree about the fact that the actual Scilab display

--> x=1:0.1:2
 x  =

   1.   1.1   1.2   1.3   1.4   1.5   1.6   1.7  1.8   1.9   2.

--> x(7)
 ans  =

   1.6

--> x(7)-1.6
 ans  =

   0.

--> x(8)
 ans  =

   1.7

--> x(8)-1.7
 ans  =

   2.220D-16

is pretty but not correct/homogeneous/honest. The display that is 
obtained with the patch (first lines of this email) is correct+honest 
but not homogeneous. A pretty + mathematically correct display would be:


--> x=1:0.1:2
 x  =

   1.000   1.100   1.200   1.300   1.400 
1.005   1.600   1.700   1.800   1.900 2.000


--> x(7)
 ans  =

   1.6

--> x(8)
 ans  =

   1.700

--> x(8)-1.7

 ans  =

   2.220D-16

i.e. when the matrix to display is not a scalar, add always trailing 
zeros for homogeneity, BUT when it is a scalar, add trailing zeros 
only when the actual stored value is different from the displayed value.


The first thing that you can see is that the default format(10) would 
be very verbose, but this is tunable. A value of 7 would be ok, but 
quite low for format("e").


S.

Le 13/09/2019 à 13:37, Stéphane Mottelet a écrit :



Le 13/09/2019 à 13:07, Samuel Gougeon a écrit :

Le 12/09/2019 à 18:55, Stéphane Mottelet a écrit :
I prefer the display after applying 
https://codereview.scilab.org/#/c/20981/:


--> x0=%pi/4;h=%eps/2
 h  =

   1.110D-16

--> cos(x0+%i*h)
 ans  =

   0.7071068 - 7.850D-17i

However, we could discuss if the arbitrary switch to "e" mode is 
desirable or not, but since Scilab 6.0 we have got used to this 
display mixing "v" and "e" mode...



... and IMO it's very suitable. The only rule should be that, */for 
a given format's width/*, */the more the number of significant 
displayed figures the better./* When the exponent format is used, it 
takes 4 or 5 digits (D+12, D+123). As a consequence, in v mode, 
small (absolute) values should be displayed in normal mode down to 4 
non-significant 0 (e.g. 0.12), and switched to "e" mode beyond.


In v mode, forcing the display of 0.0123456  in "e" mode on the 
(bad) reason that some other huge or tiny numbers in the matrix are 
displayed in this mode, would print 1.234D-02, and so make invisible 
2 significant figures.
I do not see any reason that would impose the display mode to be 
homogeneous over all elements of a matrix, possibly canceling the 
display of significant figures in the given format's width.



I agree Samuel.


Regards

Samuel



___
users mailing list
users@lists.scilab.org
https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users

--
Stéphane Mottelet
Ingénieur de recherche
EA 4297 Transformations Intégrées de la Matière Renouvelable
Département Génie des Procédés Industriels
Sorbonne Universités - Université de Technologie de Compiègne
CS 60319, 60203 Compiègne cedex
Tel : +33(0)344234688
http://www.utc.fr/~mottelet

___
users mailing list
users@lists.scilab.org
https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users

--
Stéphane Mottelet
Ingénieur de recherche
EA 4297 Transformations Intégrées de la Matière Renouvelable
Département Génie des Procédés Industriels
Sorbonne Universités - Université de Technologie de Compiègne
CS 60319, 60203 Compiègne cedex
Tel : +33(0)344234688
http://www.utc.fr/~mottelet

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




---
El software de antivirus Avast ha analizado este correo electrónico en busca de 
virus.
https://www.avast.com/antivirus
___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

Re: [Scilab-users] display of complex/not real numbers, again

2019-09-13 Thread Stéphane Mottelet 


Le 13/09/2019 à 17:38, Stéphane Mottelet a écrit :


Le 13/09/2019 à 17:32, Samuel Gougeon a écrit :

Le 13/09/2019 à 17:20, Stéphane Mottelet a écrit :


Le 13/09/2019 à 17:13, Samuel Gougeon a écrit :

Le 13/09/2019 à 16:59, Stéphane Mottelet a écrit :



Le 13/09/2019 à 16:52, Samuel Gougeon a écrit :

Le 13/09/2019 à 14:22, Stéphane Mottelet a écrit :


However, as I already said it elsewhere, some glitches such as 
the following  one do occur (see the display of whole x)


--> x=1:0.1:2
 x  =
   1.   1.1   1.2   1.3   1.4   1.5   1.6   1.700 1.8 1.9   2.



I agree with Christophe. This output is OK for me. Aestheticism 
must be encouraged provided that it does not truncate or 
downgrade the information.


About padding every number: Not OK. This would kill one of the 
assets of the "v" format: its compacity.


About the fact that 1.7 can't be exactly encoded: It is very 
surprising for a so limited decimal number. But OK. I am also 
quite surprised that, in this series, only 1.7 can't be exactly 
encoded.



bitstring allows to see that only 1, 1.5 and 2 are exactly encoded



So, question: Why 1.1 1.2 1.3 1.4 1.6 1.8 and 1.9 are displayed 
without trailing 0, while 1.7 is?
The argument/explanation according to which 1.7 can't be exactly 
encoded does not tell all...


By using format(24) in current Scilab version you will have the 
explanation :


--> (1:0.1:2)'
 ans  =

   1.
   1.100088818
   1.199955591
   1.300044409
   1.399911182
   1.5
   1.600088818
   1.700177636
   1.8
   1.9
   2.

You have (1.700177636-1.7) >= %eps but for the others 
the difference is lower



This is an excellent piece of news. This means that the 1.7 
"glitch" is meaningful,

yes

and the 0-removing algo is OK. Doesn't it?

also yes


The only issue is that (1.700177636-1.7) should not be >= 
%eps.

But this issue is not related to the display.


yeah, we actually got :

--> x=(1:0.1:2); bitstring(x(8)), bitstring(1.7)
 ans  =

 00111011001100110011001100110011001100110011001100110100

 ans  =

 00111011001100110011001100110011001100110011001100110011

the one bit difference  is due to the way implicit vectors are computed.

sorry it is more than one bit, the last 3 bits differ





___
users mailing list
users@lists.scilab.org
https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users 




--
Stéphane Mottelet
Ingénieur de recherche
EA 4297 Transformations Intégrées de la Matière Renouvelable
Département Génie des Procédés Industriels
Sorbonne Universités - Université de Technologie de Compiègne
CS 60319, 60203 Compiègne cedex
Tel : +33(0)344234688
http://www.utc.fr/~mottelet

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

Re: [Scilab-users] display of complex/not real numbers, again

2019-09-13 Thread Stéphane Mottelet 


Le 13/09/2019 à 17:20, Stéphane Mottelet a écrit :


Le 13/09/2019 à 17:13, Samuel Gougeon a écrit :

Le 13/09/2019 à 16:59, Stéphane Mottelet a écrit :



Le 13/09/2019 à 16:52, Samuel Gougeon a écrit :

Le 13/09/2019 à 14:22, Stéphane Mottelet a écrit :


However, as I already said it elsewhere, some glitches such as the 
following  one do occur (see the display of whole x)


--> x=1:0.1:2
 x  =
   1.   1.1   1.2   1.3   1.4   1.5   1.6   1.700 1.8 1.9   2.



I agree with Christophe. This output is OK for me. Aestheticism 
must be encouraged provided that it does not truncate or downgrade 
the information.


About padding every number: Not OK. This would kill one of the 
assets of the "v" format: its compacity.


About the fact that 1.7 can't be exactly encoded: It is very 
surprising for a so limited decimal number. But OK. I am also quite 
surprised that, in this series, only 1.7 can't be exactly encoded.



bitstring allows to see that only 1, 1.5 and 2 are exactly encoded



So, question: Why 1.1 1.2 1.3 1.4 1.6 1.8 and 1.9 are displayed 
without trailing 0, while 1.7 is?
The actual algorithm in addDoubleValue() in tostring_common.cpp is quite 
simple. The decimal representation of the number x to display is first 
determined up to the current format settings. The obtained string is 
then converted back to a double y with atof(). If x and y differ, then 
trailing zeros can eventually be displayed if the settings allow it.
The argument/explanation according to which 1.7 can't be exactly 
encoded does not tell all...


By using format(24) in current Scilab version you will have the 
explanation :


--> (1:0.1:2)'
 ans  =

   1.
   1.100088818
   1.199955591
   1.300044409
   1.399911182
   1.5
   1.600088818
   1.700177636
   1.8
   1.9
   2.

You have (1.700177636-1.7) >= %eps but for the others the 
difference is lower






___
users mailing list
users@lists.scilab.org
https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users 




--
Stéphane Mottelet
Ingénieur de recherche
EA 4297 Transformations Intégrées de la Matière Renouvelable
Département Génie des Procédés Industriels
Sorbonne Universités - Université de Technologie de Compiègne
CS 60319, 60203 Compiègne cedex
Tel : +33(0)344234688
http://www.utc.fr/~mottelet

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

Re: [Scilab-users] display of complex/not real numbers, again

2019-09-13 Thread Stéphane Mottelet 


Le 13/09/2019 à 17:32, Samuel Gougeon a écrit :

Le 13/09/2019 à 17:20, Stéphane Mottelet a écrit :


Le 13/09/2019 à 17:13, Samuel Gougeon a écrit :

Le 13/09/2019 à 16:59, Stéphane Mottelet a écrit :



Le 13/09/2019 à 16:52, Samuel Gougeon a écrit :

Le 13/09/2019 à 14:22, Stéphane Mottelet a écrit :


However, as I already said it elsewhere, some glitches such as 
the following  one do occur (see the display of whole x)


--> x=1:0.1:2
 x  =
   1.   1.1   1.2   1.3   1.4   1.5   1.6   1.700 1.8 1.9   2.



I agree with Christophe. This output is OK for me. Aestheticism 
must be encouraged provided that it does not truncate or downgrade 
the information.


About padding every number: Not OK. This would kill one of the 
assets of the "v" format: its compacity.


About the fact that 1.7 can't be exactly encoded: It is very 
surprising for a so limited decimal number. But OK. I am also 
quite surprised that, in this series, only 1.7 can't be exactly 
encoded.



bitstring allows to see that only 1, 1.5 and 2 are exactly encoded



So, question: Why 1.1 1.2 1.3 1.4 1.6 1.8 and 1.9 are displayed 
without trailing 0, while 1.7 is?
The argument/explanation according to which 1.7 can't be exactly 
encoded does not tell all...


By using format(24) in current Scilab version you will have the 
explanation :


--> (1:0.1:2)'
 ans  =

   1.
   1.100088818
   1.199955591
   1.300044409
   1.399911182
   1.5
   1.600088818
   1.700177636
   1.8
   1.9
   2.

You have (1.700177636-1.7) >= %eps but for the others the 
difference is lower



This is an excellent piece of news. This means that the 1.7 
"glitch" is meaningful,

yes

and the 0-removing algo is OK. Doesn't it?

also yes


The only issue is that (1.700177636-1.7) should not be >= 
%eps.

But this issue is not related to the display.


yeah, we actually got :

--> x=(1:0.1:2); bitstring(x(8)), bitstring(1.7)
 ans  =

 00111011001100110011001100110011001100110011001100110100

 ans  =

 00111011001100110011001100110011001100110011001100110011

the one bit difference  is due to the way implicit vectors are computed.




___
users mailing list
users@lists.scilab.org
https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users 



--
Stéphane Mottelet
Ingénieur de recherche
EA 4297 Transformations Intégrées de la Matière Renouvelable
Département Génie des Procédés Industriels
Sorbonne Universités - Université de Technologie de Compiègne
CS 60319, 60203 Compiègne cedex
Tel : +33(0)344234688
http://www.utc.fr/~mottelet

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

Re: [Scilab-users] display of complex/not real numbers, again

2019-09-13 Thread Samuel Gougeon 

Le 13/09/2019 à 17:20, Stéphane Mottelet a écrit :


Le 13/09/2019 à 17:13, Samuel Gougeon a écrit :

Le 13/09/2019 à 16:59, Stéphane Mottelet a écrit :



Le 13/09/2019 à 16:52, Samuel Gougeon a écrit :

Le 13/09/2019 à 14:22, Stéphane Mottelet a écrit :


However, as I already said it elsewhere, some glitches such as the 
following  one do occur (see the display of whole x)


--> x=1:0.1:2
 x  =
   1.   1.1   1.2   1.3   1.4   1.5   1.6   1.700 1.8 1.9   2.



I agree with Christophe. This output is OK for me. Aestheticism 
must be encouraged provided that it does not truncate or downgrade 
the information.


About padding every number: Not OK. This would kill one of the 
assets of the "v" format: its compacity.


About the fact that 1.7 can't be exactly encoded: It is very 
surprising for a so limited decimal number. But OK. I am also quite 
surprised that, in this series, only 1.7 can't be exactly encoded.



bitstring allows to see that only 1, 1.5 and 2 are exactly encoded



So, question: Why 1.1 1.2 1.3 1.4 1.6 1.8 and 1.9 are displayed 
without trailing 0, while 1.7 is?
The argument/explanation according to which 1.7 can't be exactly 
encoded does not tell all...


By using format(24) in current Scilab version you will have the 
explanation :


--> (1:0.1:2)'
 ans  =

   1.
   1.100088818
   1.199955591
   1.300044409
   1.399911182
   1.5
   1.600088818
   1.700177636
   1.8
   1.9
   2.

You have (1.700177636-1.7) >= %eps but for the others the 
difference is lower



This is an excellent piece of news. This means that the 1.7 
"glitch" is meaningful,

and the 0-removing algo is OK. Doesn't it?

The only issue is that (1.700177636-1.7) should not be >= %eps.
But this issue is not related to the display.


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

Re: [Scilab-users] display of complex/not real numbers, again

2019-09-13 Thread Stéphane Mottelet 


Le 13/09/2019 à 17:13, Samuel Gougeon a écrit :

Le 13/09/2019 à 16:59, Stéphane Mottelet a écrit :



Le 13/09/2019 à 16:52, Samuel Gougeon a écrit :

Le 13/09/2019 à 14:22, Stéphane Mottelet a écrit :


However, as I already said it elsewhere, some glitches such as the 
following  one do occur (see the display of whole x)


--> x=1:0.1:2
 x  =
   1.   1.1   1.2   1.3   1.4   1.5   1.6   1.700 1.8 1.9   2.



I agree with Christophe. This output is OK for me. Aestheticism must 
be encouraged provided that it does not truncate or downgrade the 
information.


About padding every number: Not OK. This would kill one of the 
assets of the "v" format: its compacity.


About the fact that 1.7 can't be exactly encoded: It is very 
surprising for a so limited decimal number. But OK. I am also quite 
surprised that, in this series, only 1.7 can't be exactly encoded.



bitstring allows to see that only 1, 1.5 and 2 are exactly encoded



So, question: Why 1.1 1.2 1.3 1.4 1.6 1.8 and 1.9 are displayed 
without trailing 0, while 1.7 is?
The argument/explanation according to which 1.7 can't be exactly 
encoded does not tell all...


By using format(24) in current Scilab version you will have the 
explanation :


--> (1:0.1:2)'
 ans  =

   1.
   1.100088818
   1.199955591
   1.300044409
   1.399911182
   1.5
   1.600088818
   1.700177636
   1.8
   1.9
   2.

You have (1.700177636-1.7) >= %eps but for the others the 
difference is lower






___
users mailing list
users@lists.scilab.org
https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users 



--
Stéphane Mottelet
Ingénieur de recherche
EA 4297 Transformations Intégrées de la Matière Renouvelable
Département Génie des Procédés Industriels
Sorbonne Universités - Université de Technologie de Compiègne
CS 60319, 60203 Compiègne cedex
Tel : +33(0)344234688
http://www.utc.fr/~mottelet

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

Re: [Scilab-users] display of complex/not real numbers, again

2019-09-13 Thread Samuel Gougeon 

Le 13/09/2019 à 16:59, Stéphane Mottelet a écrit :



Le 13/09/2019 à 16:52, Samuel Gougeon a écrit :

Le 13/09/2019 à 14:22, Stéphane Mottelet a écrit :


However, as I already said it elsewhere, some glitches such as the 
following  one do occur (see the display of whole x)


--> x=1:0.1:2
 x  =
   1.   1.1   1.2   1.3   1.4   1.5   1.6   1.700 1.8   1.9   2.



I agree with Christophe. This output is OK for me. Aestheticism must 
be encouraged provided that it does not truncate or downgrade the 
information.


About padding every number: Not OK. This would kill one of the assets 
of the "v" format: its compacity.


About the fact that 1.7 can't be exactly encoded: It is very 
surprising for a so limited decimal number. But OK. I am also quite 
surprised that, in this series, only 1.7 can't be exactly encoded.



bitstring allows to see that only 1, 1.5 and 2 are exactly encoded



So, question: Why 1.1 1.2 1.3 1.4 1.6 1.8 and 1.9 are displayed without 
trailing 0, while 1.7 is?
The argument/explanation according to which 1.7 can't be exactly encoded 
does not tell all...



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

Re: [Scilab-users] display of complex/not real numbers, again

2019-09-13 Thread Stéphane Mottelet 


Le 13/09/2019 à 16:52, Samuel Gougeon a écrit :

Le 13/09/2019 à 14:22, Stéphane Mottelet a écrit :


However, as I already said it elsewhere, some glitches such as the 
following  one do occur (see the display of whole x)


--> x=1:0.1:2
 x  =
   1.   1.1   1.2   1.3   1.4   1.5   1.6   1.700   1.8 1.9   2.



I agree with Christophe. This output is OK for me. Aestheticism must 
be encouraged provided that it does not truncate or downgrade the 
information.


About padding every number: Not OK. This would kill one of the assets 
of the "v" format: its compacity.


About the fact that 1.7 can't be exactly encoded: It is very 
surprising for a so limited decimal number. But OK. I am also quite 
surprised that, in this series, only 1.7 can't be exactly encoded.



bitstring allows to see that only 1, 1.5 and 2 are exactly encoded

--> bitstring(1:0.1:2)'
 ans  =

!0011 !
! !
!00110001100110011001100110011001100110011001100110011010 !
! !
!00110011001100110011001100110011001100110011001100110011 !
! !
!00110100110011001100110011001100110011001100110011001101 !
! !
!00110110011001100110011001100110011001100110011001100110 !
! !
!00111000 !
! !
!00111001100110011001100110011001100110011001100110011010 !
! !
!00111011001100110011001100110011001100110011001100110100 !
! !
!0000110011001100110011001100110011001100110011001101 !
! !
!0010011001100110011001100110011001100110011001100110 !
! !
!0100 !



So, the discussion holds on the criterion according to which trailing 
zeros must be displayed or not.


 1. I am wondering about the following, clearly without definitive
opinion. Just a thought:

After format(10), 1.700 is displayed if the NEXT figure is not
0, and 1.7 is displayed otherwise.
In other words, this would no longer refer to %eps but to the
format's length.
The issue with this proposal is that we don't have the current
format in mind. If all numbers are displayed in a compact form, we
don't see the display accuracy..

The choice to refer either to %eps or to format() could be
proposed through the preferences.

 2. Instead, the discussion could also be about the IEEE rounding
mode. In some occasion, the IEEE rounding mode below %eps has
visible effects on results (there is something about this in
Bugzilla on mailing lists...). Now, i guess that testing with a
hardcoded equivalent of nearfloat() would be too time-consuming.



___
users mailing list
users@lists.scilab.org
https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users


--
Stéphane Mottelet
Ingénieur de recherche
EA 4297 Transformations Intégrées de la Matière Renouvelable
Département Génie des Procédés Industriels
Sorbonne Universités - Université de Technologie de Compiègne
CS 60319, 60203 Compiègne cedex
Tel : +33(0)344234688
http://www.utc.fr/~mottelet

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

Re: [Scilab-users] display of complex/not real numbers, again

2019-09-13 Thread Samuel Gougeon 

Le 13/09/2019 à 14:22, Stéphane Mottelet a écrit :


However, as I already said it elsewhere, some glitches such as the 
following  one do occur (see the display of whole x)


--> x=1:0.1:2
 x  =
   1.   1.1   1.2   1.3   1.4   1.5   1.6   1.700   1.8 1.9   2.



I agree with Christophe. This output is OK for me. Aestheticism must be 
encouraged provided that it does not truncate or downgrade the information.


About padding every number: Not OK. This would kill one of the assets of 
the "v" format: its compacity.


About the fact that 1.7 can't be exactly encoded: It is very surprising 
for a so limited decimal number. But OK. I am also quite surprised that, 
in this series, only 1.7 can't be exactly encoded.


So, the discussion holds on the criterion according to which trailing 
zeros must be displayed or not.


1. I am wondering about the following, clearly without definitive
   opinion. Just a thought:

   After format(10), 1.700 is displayed if the NEXT figure is not
   0, and 1.7 is displayed otherwise.
   In other words, this would no longer refer to %eps but to the
   format's length.
   The issue with this proposal is that we don't have the current
   format in mind. If all numbers are displayed in a compact form, we
   don't see the display accuracy..

   The choice to refer either to %eps or to format() could be proposed
   through the preferences.

2. Instead, the discussion could also be about the IEEE rounding mode.
   In some occasion, the IEEE rounding mode below %eps has visible
   effects on results (there is something about this in Bugzilla on
   mailing lists...). Now, i guess that testing with a hardcoded
   equivalent of nearfloat() would be too time-consuming.


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

Re: [Scilab-users] display of complex/not real numbers, again

2019-09-13 Thread Stéphane Mottelet 
However, as I already said it elsewhere, some glitches such as the 
following  one do occur (see the display of whole x)


--> x=1:0.1:2
 x  =

   1.   1.1   1.2   1.3   1.4   1.5   1.6   1.700   1.8 1.9   2.

--> x(7)
 ans  =

   1.6

--> x(7)-1.6
 ans  =

   0.

--> x(8)

 ans  =

   1.700

--> x(8)-1.7
 ans  =

   2.220D-16

I think that we do agree about the fact that the actual Scilab display

--> x=1:0.1:2
 x  =

   1.   1.1   1.2   1.3   1.4   1.5   1.6   1.7  1.8   1.9   2.

--> x(7)
 ans  =

   1.6

--> x(7)-1.6
 ans  =

   0.

--> x(8)
 ans  =

   1.7

--> x(8)-1.7
 ans  =

   2.220D-16

is pretty but not correct/homogeneous/honest. The display that is 
obtained with the patch (first lines of this email) is correct+honest 
but not homogeneous. A pretty + mathematically correct display would be:


--> x=1:0.1:2
 x  =

   1.000   1.100   1.200   1.300   1.400 
1.005   1.600   1.700   1.800   1.900 2.000


--> x(7)
 ans  =

   1.6

--> x(8)
 ans  =

   1.700

--> x(8)-1.7

 ans  =

   2.220D-16

i.e. when the matrix to display is not a scalar, add always trailing 
zeros for homogeneity, BUT when it is a scalar, add trailing zeros only 
when the actual stored value is different from the displayed value.


The first thing that you can see is that the default format(10) would be 
very verbose, but this is tunable. A value of 7 would be ok, but quite 
low for format("e").


S.

Le 13/09/2019 à 13:37, Stéphane Mottelet a écrit :



Le 13/09/2019 à 13:07, Samuel Gougeon a écrit :

Le 12/09/2019 à 18:55, Stéphane Mottelet a écrit :
I prefer the display after applying 
https://codereview.scilab.org/#/c/20981/:


--> x0=%pi/4;h=%eps/2
 h  =

   1.110D-16

--> cos(x0+%i*h)
 ans  =

   0.7071068 - 7.850D-17i

However, we could discuss if the arbitrary switch to "e" mode is 
desirable or not, but since Scilab 6.0 we have got used to this 
display mixing "v" and "e" mode...



... and IMO it's very suitable. The only rule should be that, */for a 
given format's width/*, */the more the number of significant 
displayed figures the better./* When the exponent format is used, it 
takes 4 or 5 digits (D+12, D+123). As a consequence, in v mode, small 
(absolute) values should be displayed in normal mode down to 4 
non-significant 0 (e.g. 0.12), and switched to "e" mode beyond.


In v mode, forcing the display of 0.0123456  in "e" mode on the (bad) 
reason that some other huge or tiny numbers in the matrix are 
displayed in this mode, would print 1.234D-02, and so make invisible 
2 significant figures.
I do not see any reason that would impose the display mode to be 
homogeneous over all elements of a matrix, possibly canceling the 
display of significant figures in the given format's width.



I agree Samuel.


Regards

Samuel



___
users mailing list
users@lists.scilab.org
https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users

--
Stéphane Mottelet
Ingénieur de recherche
EA 4297 Transformations Intégrées de la Matière Renouvelable
Département Génie des Procédés Industriels
Sorbonne Universités - Université de Technologie de Compiègne
CS 60319, 60203 Compiègne cedex
Tel : +33(0)344234688
http://www.utc.fr/~mottelet

___
users mailing list
users@lists.scilab.org
https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users


--
Stéphane Mottelet
Ingénieur de recherche
EA 4297 Transformations Intégrées de la Matière Renouvelable
Département Génie des Procédés Industriels
Sorbonne Universités - Université de Technologie de Compiègne
CS 60319, 60203 Compiègne cedex
Tel : +33(0)344234688
http://www.utc.fr/~mottelet

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

Re: [Scilab-users] display of complex/not real numbers, again

2019-09-13 Thread Stéphane Mottelet 


Le 13/09/2019 à 13:07, Samuel Gougeon a écrit :

Le 12/09/2019 à 18:55, Stéphane Mottelet a écrit :
I prefer the display after applying 
https://codereview.scilab.org/#/c/20981/:


--> x0=%pi/4;h=%eps/2
 h  =

   1.110D-16

--> cos(x0+%i*h)
 ans  =

   0.7071068 - 7.850D-17i

However, we could discuss if the arbitrary switch to "e" mode is 
desirable or not, but since Scilab 6.0 we have got used to this 
display mixing "v" and "e" mode...



... and IMO it's very suitable. The only rule should be that, */for a 
given format's width/*, */the more the number of significant displayed 
figures the better./* When the exponent format is used, it takes 4 or 
5 digits (D+12, D+123). As a consequence, in v mode, small (absolute) 
values should be displayed in normal mode down to 4 non-significant 0 
(e.g. 0.12), and switched to "e" mode beyond.


In v mode, forcing the display of 0.0123456  in "e" mode on the (bad) 
reason that some other huge or tiny numbers in the matrix are 
displayed in this mode, would print 1.234D-02, and so make invisible 2 
significant figures.
I do not see any reason that would impose the display mode to be 
homogeneous over all elements of a matrix, possibly canceling the 
display of significant figures in the given format's width.



I agree Samuel.


Regards

Samuel



___
users mailing list
users@lists.scilab.org
https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users


--
Stéphane Mottelet
Ingénieur de recherche
EA 4297 Transformations Intégrées de la Matière Renouvelable
Département Génie des Procédés Industriels
Sorbonne Universités - Université de Technologie de Compiègne
CS 60319, 60203 Compiègne cedex
Tel : +33(0)344234688
http://www.utc.fr/~mottelet

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

Re: [Scilab-users] display of complex/not real numbers, again

2019-09-13 Thread Samuel Gougeon 

Le 12/09/2019 à 18:55, Stéphane Mottelet a écrit :
I prefer the display after applying 
https://codereview.scilab.org/#/c/20981/:


--> x0=%pi/4;h=%eps/2
 h  =

   1.110D-16

--> cos(x0+%i*h)
 ans  =

   0.7071068 - 7.850D-17i

However, we could discuss if the arbitrary switch to "e" mode is 
desirable or not, but since Scilab 6.0 we have got used to this 
display mixing "v" and "e" mode...



... and IMO it's very suitable. The only rule should be that, */for a 
given format's width/*, */the more the number of significant displayed 
figures the better./* When the exponent format is used, it takes 4 or 5 
digits (D+12, D+123). As a consequence, in v mode, small (absolute) 
values should be displayed in normal mode down to 4 non-significant 0 
(e.g. 0.12), and switched to "e" mode beyond.


In v mode, forcing the display of 0.0123456  in "e" mode on the (bad) 
reason that some other huge or tiny numbers in the matrix are displayed 
in this mode, would print 1.234D-02, and so make invisible 2 significant 
figures.
I do not see any reason that would impose the display mode to be 
homogeneous over all elements of a matrix, possibly canceling the 
display of significant figures in the given format's width.


Regards

Samuel


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

Re: [Scilab-users] display of complex/not real numbers, again

2019-09-13 Thread Stéphane Mottelet 


Le 13/09/2019 à 12:45, Samuel Gougeon a écrit :

Hello,

To me, as already claimed there 
, 
it's clear that, for a complex-encoded number, not displaying its null 
imaginary part is a bug, and the proposed patch is clearly welcome as 
well.


Another regression very close to this one, but with real numbers 
display, would deserve the same care :

Scilab 5:
-->[1e30 1e-30]
 ans  =
    1.000D+30    1.000D-30

Scilab 6:
--> [1e30 1e-30]
 ans  =
   1.000D+30   0.

The patch also fixes this.


So, very small numbers are reduced to strict 0...
This is a bad implementation of the variable format mode. The Scilab 5 
one was correct, at least on this point.


Best regards
Samuel


Le 12/09/2019 à 10:26, Stéphane Mottelet a écrit :

Hello all,

The subject has been already discussed a lot but I would like it to 
be discussed again because I now have a real rationale to promote a 
change in the way complex numbers with small imaginary part are 
displayed.


I don't know if some of you were aware of the clever technique of 
complex-step derivative approximation, but until yesterday I was not 
(see e.g. 
http://mdolab.engin.umich.edu/sites/default/files/Martins2003CSD.pdf). 
Roughly speaking, using the extension of a real function x->f(x) to 
the complex plane allows to compute an approximation of the 
derivative f'(x0) at a real x0 without using a substraction, like in 
the central difference formula (f(x0+h)-f(x0-h))/2/h which is subject 
to substractive cancelation when h is small. In Scilab most operators 
and elementary functions are already complex-aware so this is easy to 
illustrate the technique. For example let us approximate the 
derivative of x->cos(x) at x=%pi/4, first with the central difference 
formula, then with the complex step technique:


--> format("e",24)

--> h=%eps/128, x0=%pi/4
 h  =

   1.73472347597680709D-18

 x0  =

   7.85398163397448279D-01


--> (cos(x0+h)-cos(x0-h))/2/h
 ans  =

   0.0D+00


--> imag(cos(x0+%i*h))/h
 ans  =

  -7.07106781186547462D-01


--> -sin(x0)
 ans  =

  -7.07106781186547462D-01

You can see the pathological approximation with central difference 
formula and the perfect (up to relative machine precision) 
approximation of complex-step formula.


However, the following is a pity:


--> cos(x0+%i*h)
 ans  =

   7.07106781186547573D-01

We cannot see the imaginary part although seeing the latter is 
fundamental in the complex-step technique. We have to force the 
display like this, and frankly I don't like having to do that with my 
students:


--> imag(cos(x0+%i*h))
 ans  =

  -1.22663473334669916D-18

I hope that you will find that this example is a good rationale to 
change the default display of Scilab. To feed the discussion, here is 
how Matlab displays things, without having to change the default 
settings:



>> h=eps/128, x0=pi/4
h =
   1.7347e-18
x0 =
    0.7854

>> (cos(x0+h)-cos(x0-h))/2/h
ans =
 0

>> cos(x0+i*h)
ans =
   0.7071 - 0.i

>> imag(cos(x0+i*h))/h
ans =
   -0.7071

>> -sin(x0)
ans =
   -0.7071





___
users mailing list
users@lists.scilab.org
https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users


--
Stéphane Mottelet
Ingénieur de recherche
EA 4297 Transformations Intégrées de la Matière Renouvelable
Département Génie des Procédés Industriels
Sorbonne Universités - Université de Technologie de Compiègne
CS 60319, 60203 Compiègne cedex
Tel : +33(0)344234688
http://www.utc.fr/~mottelet

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

Re: [Scilab-users] display of complex/not real numbers, again

2019-09-13 Thread Samuel Gougeon 

Hello,

To me, as already claimed there 
, it's clear that, 
for a complex-encoded number, not displaying its null imaginary part is 
a bug, and the proposed patch is clearly welcome as well.


Another regression very close to this one, but with real numbers 
display, would deserve the same care :

Scilab 5:
-->[1e30 1e-30]
 ans  =
    1.000D+30    1.000D-30

Scilab 6:
--> [1e30 1e-30]
 ans  =
   1.000D+30   0.

So, very small numbers are reduced to strict 0...
This is a bad implementation of the variable format mode. The Scilab 5 
one was correct, at least on this point.


Best regards
Samuel


Le 12/09/2019 à 10:26, Stéphane Mottelet a écrit :

Hello all,

The subject has been already discussed a lot but I would like it to be 
discussed again because I now have a real rationale to promote a 
change in the way complex numbers with small imaginary part are 
displayed.


I don't know if some of you were aware of the clever technique of 
complex-step derivative approximation, but until yesterday I was not 
(see e.g. 
http://mdolab.engin.umich.edu/sites/default/files/Martins2003CSD.pdf). 
Roughly speaking, using the extension of a real function x->f(x) to 
the complex plane allows to compute an approximation of the derivative 
f'(x0) at a real x0 without using a substraction, like in the central 
difference formula (f(x0+h)-f(x0-h))/2/h which is subject to 
substractive cancelation when h is small. In Scilab most operators and 
elementary functions are already complex-aware so this is easy to 
illustrate the technique. For example let us approximate the 
derivative of x->cos(x) at x=%pi/4, first with the central difference 
formula, then with the complex step technique:


--> format("e",24)

--> h=%eps/128, x0=%pi/4
 h  =

   1.73472347597680709D-18

 x0  =

   7.85398163397448279D-01


--> (cos(x0+h)-cos(x0-h))/2/h
 ans  =

   0.0D+00


--> imag(cos(x0+%i*h))/h
 ans  =

  -7.07106781186547462D-01


--> -sin(x0)
 ans  =

  -7.07106781186547462D-01

You can see the pathological approximation with central difference 
formula and the perfect (up to relative machine precision) 
approximation of complex-step formula.


However, the following is a pity:


--> cos(x0+%i*h)
 ans  =

   7.07106781186547573D-01

We cannot see the imaginary part although seeing the latter is 
fundamental in the complex-step technique. We have to force the 
display like this, and frankly I don't like having to do that with my 
students:


--> imag(cos(x0+%i*h))
 ans  =

  -1.22663473334669916D-18

I hope that you will find that this example is a good rationale to 
change the default display of Scilab. To feed the discussion, here is 
how Matlab displays things, without having to change the default 
settings:



>> h=eps/128, x0=pi/4
h =
   1.7347e-18
x0 =
    0.7854

>> (cos(x0+h)-cos(x0-h))/2/h
ans =
 0

>> cos(x0+i*h)
ans =
   0.7071 - 0.i

>> imag(cos(x0+i*h))/h
ans =
   -0.7071

>> -sin(x0)
ans =
   -0.7071




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

Re: [Scilab-users] display of complex/not real numbers, again

2019-09-13 Thread Stéphane Mottelet 
If Windows users want to test the patch, I have prepared a Windows build 
of patched Scilab at the folowing URL :


http://www.utc.fr/~mottelet/scilab/download/master/scilab-branch-master-6cdd3ce0d62c632cd428b71440b0371a7731dbae_x64.exe

S.

Le 12/09/2019 à 18:55, Stéphane Mottelet a écrit :
I prefer the display after applying 
https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/codereview.scilab.org/#/c/20981/:


--> x0=%pi/4;h=%eps/2
 h  =

   1.110D-16

--> cos(x0+%i*h)
 ans  =

   0.7071068 - 7.850D-17i

However, we could discuss if the arbitrary switch to "e" mode is 
desirable or not, but since Scilab 6.0 we have got used to this 
display mixing "v" and "e" mode...


BTW, this patch also fixes the more general problem of ambiguous 
display of quantities like (below is the display after the patch)


--> 1+%eps
 ans  =

   1.000

Currently Scilab makes users believe that a complex/non real number is 
real by hiding small non-zero real parts, and makes users believe that 
a non-integer number is integer by hiding zeros in the fractional 
part. Each year I have to warn my students, and I am really getting 
upset about this. The aforementionned patch also fixes that.


S.


Le 12/09/2019 à 11:59, Stéphane Mottelet a écrit :


Le 12/09/2019 à 11:55, Antoine ELIAS a écrit :

Hello Stéphane,

In Scilab 6.0.2 without format("e", 24)

--> h = %eps/128, x0=%pi/4
 h  =
   1.735D-18

 x0  =
   0.7853982

--> (cos(x0+h)-cos(x0-h))/2/h
 ans  =
   0.

--> cos(x0+%i*h)
 ans  =
   0.7071068

--> imag(cos(x0+%i*h))/h
 ans  =
  -0.7071068

--> -sin(x0)
 ans  =
  -0.7071068

It seems to be close of Matlab's outputs, no ?


No, Scilab display is singularly different:

--> cos(x0+%i*h)
 ans  =
   0.7071068

the above has an imaginary part, which is quite small, but essential 
in the computation. Matlab is quite explicit here:


>> cos(x0+i*h)
ans =
   0.7071 - 0.i



I probably not understand your problem ...

Antoine
Le 12/09/2019 à 10:26, Stéphane Mottelet a écrit :

Hello all,

The subject has been already discussed a lot but I would like it to 
be discussed again because I now have a real rationale to promote a 
change in the way complex numbers with small imaginary part are 
displayed.


I don't know if some of you were aware of the clever technique of 
complex-step derivative approximation, but until yesterday I was 
not (see e.g. 
https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/mdolab.engin.umich.edu/sites/default/files/Martins2003CSD.pdf). 
Roughly speaking, using the extension of a real function x->f(x) to 
the complex plane allows to compute an approximation of the 
derivative f'(x0) at a real x0 without using a substraction, like 
in the central difference formula (f(x0+h)-f(x0-h))/2/h which is 
subject to substractive cancelation when h is small. In Scilab most 
operators and elementary functions are already complex-aware so 
this is easy to illustrate the technique. For example let us 
approximate the derivative of x->cos(x) at x=%pi/4, first with the 
central difference formula, then with the complex step technique:


--> format("e",24)

--> h=%eps/128, x0=%pi/4
 h  =

   1.73472347597680709D-18

 x0  =

   7.85398163397448279D-01


--> (cos(x0+h)-cos(x0-h))/2/h
 ans  =

   0.0D+00


--> imag(cos(x0+%i*h))/h
 ans  =

  -7.07106781186547462D-01


--> -sin(x0)
 ans  =

  -7.07106781186547462D-01

You can see the pathological approximation with central difference 
formula and the perfect (up to relative machine precision) 
approximation of complex-step formula.


However, the following is a pity:


--> cos(x0+%i*h)
 ans  =

   7.07106781186547573D-01

We cannot see the imaginary part although seeing the latter is 
fundamental in the complex-step technique. We have to force the 
display like this, and frankly I don't like having to do that with 
my students:


--> imag(cos(x0+%i*h))
 ans  =

  -1.22663473334669916D-18

I hope that you will find that this example is a good rationale to 
change the default display of Scilab. To feed the discussion, here 
is how Matlab displays things, without having to change the default 
settings:



>> h=eps/128, x0=pi/4
h =
   1.7347e-18
x0 =
    0.7854

>> (cos(x0+h)-cos(x0-h))/2/h
ans =
 0

>> cos(x0+i*h)
ans =
   0.7071 - 0.i

>> imag(cos(x0+i*h))/h
ans =
   -0.7071

>> -sin(x0)
ans =
   -0.7071




___
users mailing list
users@lists.scilab.org
https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users 




--
Stéphane Mottelet
Ingénieur de recherche
EA 4297 Transformations Intégrées de la Matière Renouvelable
Département Génie des Procédés Industriels
Sorbonne Universités - Université de Technologie de

Re: [Scilab-users] display of complex/not real numbers, again

2019-09-12 Thread Stéphane Mottelet 
I prefer the display after applying 
https://codereview.scilab.org/#/c/20981/:


--> x0=%pi/4;h=%eps/2
 h  =

   1.110D-16

--> cos(x0+%i*h)
 ans  =

   0.7071068 - 7.850D-17i

However, we could discuss if the arbitrary switch to "e" mode is 
desirable or not, but since Scilab 6.0 we have got used to this display 
mixing "v" and "e" mode...


BTW, this patch also fixes the more general problem of ambiguous display 
of quantities like (below is the display after the patch)


--> 1+%eps
 ans  =

   1.000

Currently Scilab makes users believe that a complex/non real number is 
real by hiding small non-zero real parts, and makes users believe that a 
non-integer number is integer by hiding zeros in the fractional part. 
Each year I have to warn my students, and I am really getting upset 
about this. The aforementionned patch also fixes that.


S.


Le 12/09/2019 à 11:59, Stéphane Mottelet a écrit :


Le 12/09/2019 à 11:55, Antoine ELIAS a écrit :

Hello Stéphane,

In Scilab 6.0.2 without format("e", 24)

--> h = %eps/128, x0=%pi/4
 h  =
   1.735D-18

 x0  =
   0.7853982

--> (cos(x0+h)-cos(x0-h))/2/h
 ans  =
   0.

--> cos(x0+%i*h)
 ans  =
   0.7071068

--> imag(cos(x0+%i*h))/h
 ans  =
  -0.7071068

--> -sin(x0)
 ans  =
  -0.7071068

It seems to be close of Matlab's outputs, no ?


No, Scilab display is singularly different:

--> cos(x0+%i*h)
 ans  =
   0.7071068

the above has an imaginary part, which is quite small, but essential 
in the computation. Matlab is quite explicit here:


>> cos(x0+i*h)
ans =
   0.7071 - 0.i



I probably not understand your problem ...

Antoine
Le 12/09/2019 à 10:26, Stéphane Mottelet a écrit :

Hello all,

The subject has been already discussed a lot but I would like it to 
be discussed again because I now have a real rationale to promote a 
change in the way complex numbers with small imaginary part are 
displayed.


I don't know if some of you were aware of the clever technique of 
complex-step derivative approximation, but until yesterday I was not 
(see e.g. 
https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/mdolab.engin.umich.edu/sites/default/files/Martins2003CSD.pdf). 
Roughly speaking, using the extension of a real function x->f(x) to 
the complex plane allows to compute an approximation of the 
derivative f'(x0) at a real x0 without using a substraction, like in 
the central difference formula (f(x0+h)-f(x0-h))/2/h which is 
subject to substractive cancelation when h is small. In Scilab most 
operators and elementary functions are already complex-aware so this 
is easy to illustrate the technique. For example let us approximate 
the derivative of x->cos(x) at x=%pi/4, first with the central 
difference formula, then with the complex step technique:


--> format("e",24)

--> h=%eps/128, x0=%pi/4
 h  =

   1.73472347597680709D-18

 x0  =

   7.85398163397448279D-01


--> (cos(x0+h)-cos(x0-h))/2/h
 ans  =

   0.0D+00


--> imag(cos(x0+%i*h))/h
 ans  =

  -7.07106781186547462D-01


--> -sin(x0)
 ans  =

  -7.07106781186547462D-01

You can see the pathological approximation with central difference 
formula and the perfect (up to relative machine precision) 
approximation of complex-step formula.


However, the following is a pity:


--> cos(x0+%i*h)
 ans  =

   7.07106781186547573D-01

We cannot see the imaginary part although seeing the latter is 
fundamental in the complex-step technique. We have to force the 
display like this, and frankly I don't like having to do that with 
my students:


--> imag(cos(x0+%i*h))
 ans  =

  -1.22663473334669916D-18

I hope that you will find that this example is a good rationale to 
change the default display of Scilab. To feed the discussion, here 
is how Matlab displays things, without having to change the default 
settings:



>> h=eps/128, x0=pi/4
h =
   1.7347e-18
x0 =
    0.7854

>> (cos(x0+h)-cos(x0-h))/2/h
ans =
 0

>> cos(x0+i*h)
ans =
   0.7071 - 0.i

>> imag(cos(x0+i*h))/h
ans =
   -0.7071

>> -sin(x0)
ans =
   -0.7071




___
users mailing list
users@lists.scilab.org
https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users 




--
Stéphane Mottelet
Ingénieur de recherche
EA 4297 Transformations Intégrées de la Matière Renouvelable
Département Génie des Procédés Industriels
Sorbonne Universités - Université de Technologie de Compiègne
CS 60319, 60203 Compiègne cedex
Tel : +33(0)344234688
http://www.utc.fr/~mottelet

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

Re: [Scilab-users] display of complex/not real numbers, again

2019-09-12 Thread Stéphane Mottelet 


Le 12/09/2019 à 11:55, Antoine ELIAS a écrit :

Hello Stéphane,

In Scilab 6.0.2 without format("e", 24)

--> h = %eps/128, x0=%pi/4
 h  =
   1.735D-18

 x0  =
   0.7853982

--> (cos(x0+h)-cos(x0-h))/2/h
 ans  =
   0.

--> cos(x0+%i*h)
 ans  =
   0.7071068

--> imag(cos(x0+%i*h))/h
 ans  =
  -0.7071068

--> -sin(x0)
 ans  =
  -0.7071068

It seems to be close of Matlab's outputs, no ?


No, Scilab display is singularly different:

--> cos(x0+%i*h)
 ans  =
   0.7071068

the above has an imaginary part, which is quite small, but essential in 
the computation. Matlab is quite explicit here:


>> cos(x0+i*h)
ans =
   0.7071 - 0.i



I probably not understand your problem ...

Antoine
Le 12/09/2019 à 10:26, Stéphane Mottelet a écrit :

Hello all,

The subject has been already discussed a lot but I would like it to 
be discussed again because I now have a real rationale to promote a 
change in the way complex numbers with small imaginary part are 
displayed.


I don't know if some of you were aware of the clever technique of 
complex-step derivative approximation, but until yesterday I was not 
(see e.g. 
https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/mdolab.engin.umich.edu/sites/default/files/Martins2003CSD.pdf). 
Roughly speaking, using the extension of a real function x->f(x) to 
the complex plane allows to compute an approximation of the 
derivative f'(x0) at a real x0 without using a substraction, like in 
the central difference formula (f(x0+h)-f(x0-h))/2/h which is subject 
to substractive cancelation when h is small. In Scilab most operators 
and elementary functions are already complex-aware so this is easy to 
illustrate the technique. For example let us approximate the 
derivative of x->cos(x) at x=%pi/4, first with the central difference 
formula, then with the complex step technique:


--> format("e",24)

--> h=%eps/128, x0=%pi/4
 h  =

   1.73472347597680709D-18

 x0  =

   7.85398163397448279D-01


--> (cos(x0+h)-cos(x0-h))/2/h
 ans  =

   0.0D+00


--> imag(cos(x0+%i*h))/h
 ans  =

  -7.07106781186547462D-01


--> -sin(x0)
 ans  =

  -7.07106781186547462D-01

You can see the pathological approximation with central difference 
formula and the perfect (up to relative machine precision) 
approximation of complex-step formula.


However, the following is a pity:


--> cos(x0+%i*h)
 ans  =

   7.07106781186547573D-01

We cannot see the imaginary part although seeing the latter is 
fundamental in the complex-step technique. We have to force the 
display like this, and frankly I don't like having to do that with my 
students:


--> imag(cos(x0+%i*h))
 ans  =

  -1.22663473334669916D-18

I hope that you will find that this example is a good rationale to 
change the default display of Scilab. To feed the discussion, here is 
how Matlab displays things, without having to change the default 
settings:



>> h=eps/128, x0=pi/4
h =
   1.7347e-18
x0 =
    0.7854

>> (cos(x0+h)-cos(x0-h))/2/h
ans =
 0

>> cos(x0+i*h)
ans =
   0.7071 - 0.i

>> imag(cos(x0+i*h))/h
ans =
   -0.7071

>> -sin(x0)
ans =
   -0.7071




___
users mailing list
users@lists.scilab.org
https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users 



--
Stéphane Mottelet
Ingénieur de recherche
EA 4297 Transformations Intégrées de la Matière Renouvelable
Département Génie des Procédés Industriels
Sorbonne Universités - Université de Technologie de Compiègne
CS 60319, 60203 Compiègne cedex
Tel : +33(0)344234688
http://www.utc.fr/~mottelet

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

Re: [Scilab-users] display of complex/not real numbers, again

2019-09-12 Thread Antoine ELIAS 

Hello Stéphane,

In Scilab 6.0.2 without format("e", 24)

--> h = %eps/128, x0=%pi/4
 h  =
   1.735D-18

 x0  =
   0.7853982

--> (cos(x0+h)-cos(x0-h))/2/h
 ans  =
   0.

--> cos(x0+%i*h)
 ans  =
   0.7071068

--> imag(cos(x0+%i*h))/h
 ans  =
  -0.7071068

--> -sin(x0)
 ans  =
  -0.7071068

It seems to be close of Matlab's outputs, no ?
I probably not understand your problem ...

Antoine
Le 12/09/2019 à 10:26, Stéphane Mottelet a écrit :

Hello all,

The subject has been already discussed a lot but I would like it to be 
discussed again because I now have a real rationale to promote a 
change in the way complex numbers with small imaginary part are 
displayed.


I don't know if some of you were aware of the clever technique of 
complex-step derivative approximation, but until yesterday I was not 
(see e.g. 
http://mdolab.engin.umich.edu/sites/default/files/Martins2003CSD.pdf). 
Roughly speaking, using the extension of a real function x->f(x) to 
the complex plane allows to compute an approximation of the derivative 
f'(x0) at a real x0 without using a substraction, like in the central 
difference formula (f(x0+h)-f(x0-h))/2/h which is subject to 
substractive cancelation when h is small. In Scilab most operators and 
elementary functions are already complex-aware so this is easy to 
illustrate the technique. For example let us approximate the 
derivative of x->cos(x) at x=%pi/4, first with the central difference 
formula, then with the complex step technique:


--> format("e",24)

--> h=%eps/128, x0=%pi/4
 h  =

   1.73472347597680709D-18

 x0  =

   7.85398163397448279D-01


--> (cos(x0+h)-cos(x0-h))/2/h
 ans  =

   0.0D+00


--> imag(cos(x0+%i*h))/h
 ans  =

  -7.07106781186547462D-01


--> -sin(x0)
 ans  =

  -7.07106781186547462D-01

You can see the pathological approximation with central difference 
formula and the perfect (up to relative machine precision) 
approximation of complex-step formula.


However, the following is a pity:


--> cos(x0+%i*h)
 ans  =

   7.07106781186547573D-01

We cannot see the imaginary part although seeing the latter is 
fundamental in the complex-step technique. We have to force the 
display like this, and frankly I don't like having to do that with my 
students:


--> imag(cos(x0+%i*h))
 ans  =

  -1.22663473334669916D-18

I hope that you will find that this example is a good rationale to 
change the default display of Scilab. To feed the discussion, here is 
how Matlab displays things, without having to change the default 
settings:



>> h=eps/128, x0=pi/4
h =
   1.7347e-18
x0 =
    0.7854

>> (cos(x0+h)-cos(x0-h))/2/h
ans =
 0

>> cos(x0+i*h)
ans =
   0.7071 - 0.i

>> imag(cos(x0+i*h))/h
ans =
   -0.7071

>> -sin(x0)
ans =
   -0.7071




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