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

classic Classic list List threaded Threaded
35 messages Options
12
mottelet mottelet
Reply | Threaded
Open this post in threaded view
|

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

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.00000000000000000D+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.0000i

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

 >> -sin(x0)
ans =
    -0.7071


--

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
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
Antoine ELIAS-2 Antoine ELIAS-2
Reply | Threaded
Open this post in threaded view
|

Re: display of complex/not real numbers, again

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.00000000000000000D+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.0000i
>
> >> imag(cos(x0+i*h))/h
> ans =
>    -0.7071
>
> >> -sin(x0)
> ans =
>    -0.7071
>
>

_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
mottelet mottelet
Reply | Threaded
Open this post in threaded view
|

Re: display of complex/not real numbers, again


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.0000i


> 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.00000000000000000D+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.0000i
>>
>> >> imag(cos(x0+i*h))/h
>> ans =
>>    -0.7071
>>
>> >> -sin(x0)
>> ans =
>>    -0.7071
>>
>>
>
> _______________________________________________
> users mailing list
> [hidden email]
> 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
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
Christophe Dang Ngoc Chan Christophe Dang Ngoc Chan
Reply | Threaded
Open this post in threaded view
|

Re: {EXT} display of complex/not real numbers, again

In reply to this post by mottelet
Hello,

> De la part de Stéphane Mottelet
> Envoyé : jeudi 12 septembre 2019 10:26
>
> I now have a real rationale to promote a change in
> the way complex numbers with small imaginary part are displayed.

I agree with you.

I would add another advantage:
the user is not always aware that the result of a function is a complex;
the typical case is the use of roots() when the expected result is real.
It sometimes causes problems as some other function
do not accept complex numbers as patrameters.

Regards

--
Christophe Dang Ngoc Chan
Mechanical calculation engineer

General
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error), please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
mottelet mottelet
Reply | Threaded
Open this post in threaded view
|

Re: {EXT} display of complex/not real numbers, again


Le 12/09/2019 à 14:19, Dang Ngoc Chan, Christophe a écrit :

> Hello,
>
>> De la part de Stéphane Mottelet
>> Envoyé : jeudi 12 septembre 2019 10:26
>>
>> I now have a real rationale to promote a change in
>> the way complex numbers with small imaginary part are displayed.
> I agree with you.
>
> I would add another advantage:
> the user is not always aware that the result of a function is a complex;
> the typical case is the use of roots() when the expected result is real.
> It sometimes causes problems as some other function
> do not accept complex numbers as patrameters.

You are right.

This basic rationale (compared to the over-sophisticated I proposed...) 
has been invoked many times and should have been enough to change
things. There is already a proposal here:

https://codereview.scilab.org/#/c/20981/


>
> Regards
>
> --
> Christophe Dang Ngoc Chan
> Mechanical calculation engineer
>
> General
> This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error), please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
> _______________________________________________
> users mailing list
> [hidden email]
> 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
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
mottelet mottelet
Reply | Threaded
Open this post in threaded view
|

Re: display of complex/not real numbers, again

In reply to this post by 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.0000000

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.0000i
>
>
>> 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.00000000000000000D+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.0000i
>>>
>>> >> imag(cos(x0+i*h))/h
>>> ans =
>>>    -0.7071
>>>
>>> >> -sin(x0)
>>> ans =
>>>    -0.7071
>>>
>>>
>>
>> _______________________________________________
>> users mailing list
>> [hidden email]
>> 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
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
mottelet mottelet
Reply | Threaded
Open this post in threaded view
|

Re: display of complex/not real numbers, again

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.0000000
>
> 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.0000i
>>
>>
>>> 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.00000000000000000D+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.0000i
>>>>
>>>> >> imag(cos(x0+i*h))/h
>>>> ans =
>>>>    -0.7071
>>>>
>>>> >> -sin(x0)
>>>> ans =
>>>>    -0.7071
>>>>
>>>>
>>>
>>> _______________________________________________
>>> users mailing list
>>> [hidden email]
>>> 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 Compiègne
CS 60319, 60203 Compiègne cedex
Tel : +33(0)344234688
http://www.utc.fr/~mottelet

_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
Samuel GOUGEON Samuel GOUGEON
Reply | Threaded
Open this post in threaded view
|

Re: display of complex/not real numbers, again

In reply to this post by mottelet
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.00000000000000000D+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.0000i

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

>> -sin(x0)
ans =
   -0.7071




_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
mottelet mottelet
Reply | Threaded
Open this post in threaded view
|

Re: display of complex/not real numbers, again


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.00000000000000000D+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.0000i

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

>> -sin(x0)
ans =
   -0.7071




_______________________________________________
users mailing list
[hidden email]
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
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
Samuel GOUGEON Samuel GOUGEON
Reply | Threaded
Open this post in threaded view
|

Re: display of complex/not real numbers, again

In reply to this post by mottelet
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.000012), 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
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
mottelet mottelet
Reply | Threaded
Open this post in threaded view
|

Re: display of complex/not real numbers, again


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.000012), 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
[hidden email]
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
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
mottelet mottelet
Reply | Threaded
Open this post in threaded view
|

Re: display of complex/not real numbers, again

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.7000000   1.8   1.9   2.

--> x(7)
 ans  =

   1.6

--> x(7)-1.6
 ans  =

   0.

--> x(8)

 ans  =

   1.7000000

--> 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.0000000   1.1000000   1.2000000   1.3000000   1.4000000   1.0000005   1.6000000   1.7000000   1.8000000   1.9000000   2.0000000

--> x(7)
 ans  =

   1.6

--> x(8)
 ans  =

   1.7000000

--> 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.000012), 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
[hidden email]
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
[hidden email]
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
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
Christophe Dang Ngoc Chan Christophe Dang Ngoc Chan
Reply | Threaded
Open this post in threaded view
|

Re: {EXT} Re: display of complex/not real numbers, again

Hello,

> De : Stéphane Mottelet
> Envoyé : vendredi 13 septembre 2019 14:23
>
> I think that we do agree about the fact that the actual Scilab display
> [...]
> --> x(8)
> ans  =
>
>   1.7
> --> x(8)-1.7
> ans  =
>
>   2.220D-16
> is pretty but not correct/homogeneous/honest

I don't agree about this.
The decimal number can only rarely be represented exactly in binary according to IEEE 754.

This means that there should always be trailing zeros to highlight the fact that there is a 10^-16 discrepancy between the stored value and the displayed value?
I don't find this convenient.

The fact that some people are not aware of this discrepancy can be a problem but it is the general problem of underflow or subtractive cancellation or round-off error etc.

The problem is not less important than ignoring a number is complex with a zero imaginary part, but I'm not sure it can be handled in the same way.

--
Christophe Dang Ngoc Chan
Mechanical calculation engineer

General
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error), please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
mottelet mottelet
Reply | Threaded
Open this post in threaded view
|

Re: {EXT} Re: display of complex/not real numbers, again


Le 13/09/2019 à 15:13, Dang Ngoc Chan, Christophe a écrit :

> Hello,
>
>> De : Stéphane Mottelet
>> Envoyé : vendredi 13 septembre 2019 14:23
>>
>> I think that we do agree about the fact that the actual Scilab display
>> [...]
>> --> x(8)
>> ans  =
>>
>>    1.7
>> --> x(8)-1.7
>> ans  =
>>
>>    2.220D-16
>> is pretty but not correct/homogeneous/honest

Maybe I was not clear enough.

1.7 cannot be stored exactly in IEEE754 encoding so it should always be
displayed with trailing zeros.

So

--> x(8)-1.7
ans  =

   2.220D-16

is OK and should always be displayed like this,  but the previous display

--> x(8)
ans  =

   1.7

is not OK. What is not correct/homogeneous/honest is the fact that we have this both displays in the current version of Scilab.


> I don't agree about this.
> The decimal number can only rarely be represented exactly in binary according to IEEE 754.
>
> This means that there should always be trailing zeros to highlight the fact that there is a 10^-16 discrepancy between the stored value and the displayed value?
> I don't find this convenient.
>
> The fact that some people are not aware of this discrepancy can be a problem but it is the general problem of underflow or subtractive cancellation or round-off error etc.
>
> The problem is not less important than ignoring a number is complex with a zero imaginary part, but I'm not sure it can be handled in the same way.
>
> --
> Christophe Dang Ngoc Chan
> Mechanical calculation engineer
>
> General
> This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error), please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
> _______________________________________________
> users mailing list
> [hidden email]
> 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
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
Christophe Dang Ngoc Chan Christophe Dang Ngoc Chan
Reply | Threaded
Open this post in threaded view
|

Re: {EXT} Re: display of complex/not real numbers, again

Hello,

> De : Stéphane Mottelet
> Envoyé : vendredi 13 septembre 2019 15:22
>
> 1.7 cannot be stored exactly in IEEE754

Yes, but there is an "infinite" amount of decimal numbers
that cannot be stored exactly in IEEE754.

--
Christophe Dang Ngoc Chan
Mechanical calculation engineer

General
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error), please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
mottelet mottelet
Reply | Threaded
Open this post in threaded view
|

Re: {EXT} Re: display of complex/not real numbers, again


Le 13/09/2019 à 15:28, Dang Ngoc Chan, Christophe a écrit :
> Hello,
>
>> De : Stéphane Mottelet
>> Envoyé : vendredi 13 septembre 2019 15:22
>>
>> 1.7 cannot be stored exactly in IEEE754
> Yes, but there is an "infinite" amount of decimal numbers
> that cannot be stored exactly in IEEE754.
I know... so what ? Upon reflection I don't think that systematically
adding trailing zeros (even when a number is stored exactly) is a good
idea. What we could aim at, in order to keep a compact display, is to
remove all trailing zeros when displaying non-scalar matrices, and
display them when displaying a scalar alone. Even this small step
(together with the display of small real real parts, small imaginary
parts, zero imaginary parts) would be an improvement for Scilab users.

S.

>
> --
> Christophe Dang Ngoc Chan
> Mechanical calculation engineer
>
> General
> This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error), please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
> _______________________________________________
> users mailing list
> [hidden email]
> 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
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
Samuel GOUGEON Samuel GOUGEON
Reply | Threaded
Open this post in threaded view
|

Re: display of complex/not real numbers, again

In reply to this post by mottelet
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.7000000   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.7000000 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
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
mottelet mottelet
Reply | Threaded
Open this post in threaded view
|

Re: display of complex/not real numbers, again


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.7000000   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  =

!0011111111110000000000000000000000000000000000000000000000000000  !
!                                                                  !
!0011111111110001100110011001100110011001100110011001100110011010  !
!                                                                  !
!0011111111110011001100110011001100110011001100110011001100110011  !
!                                                                  !
!0011111111110100110011001100110011001100110011001100110011001101  !
!                                                                  !
!0011111111110110011001100110011001100110011001100110011001100110  !
!                                                                  !
!0011111111111000000000000000000000000000000000000000000000000000  !
!                                                                  !
!0011111111111001100110011001100110011001100110011001100110011010  !
!                                                                  !
!0011111111111011001100110011001100110011001100110011001100110100  !
!                                                                  !
!0011111111111100110011001100110011001100110011001100110011001101  !
!                                                                  !
!0011111111111110011001100110011001100110011001100110011001100110  !
!                                                                  !
!0100000000000000000000000000000000000000000000000000000000000000  !


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.7000000 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
[hidden email]
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
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
Samuel GOUGEON Samuel GOUGEON
Reply | Threaded
Open this post in threaded view
|

Re: display of complex/not real numbers, again

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.7000000 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
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
mottelet mottelet
Reply | Threaded
Open this post in threaded view
|

Re: display of complex/not real numbers, again


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.7000000 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.100000000000000088818
    1.199999999999999955591
    1.300000000000000044409
    1.399999999999999911182
    1.5
    1.600000000000000088818
    1.700000000000000177636
    1.8
    1.9
    2.

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


>
>
> _______________________________________________
> users mailing list
> [hidden email]
> 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
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
12