Re: [Scilab-users] xload mess ...

[Samuel Gougeon]

Le 16/09/2019 à 11:31, Antoine Monmayrant a écrit :



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

Hello Antoine,

Hello Samuel,


As discussed with you there 
, xload() has 
been restored and upgraded for Scilab 6.0.2.
However, its help page was updated only after the 6.0.2 release. Its 
update is pending
here , and visible in PDF there 
.


As it is not possible to reproduce the issue on win7 and on Fedora, 
it is clear that it depends
on the OS, is likely specific to Ubuntu, and very likely linked to 
HDF5 issues reported with Ubuntu.


However, after your recent report about the same issue on Windows 10, 
the confirmation
of the issue by any user working with 6.0.2 on Windows 10 would be 
welcome.

The test is :

  * Download the c.scg file

(http://bugzilla.scilab.org/16189)
  * Run : xload("c.scg")


No, that's not the test!
Just xload("c.scg") does not crash scilab.
As stated in the bug report ( http://bugzilla.scilab.org/16189 ) The 
test is the following:

// XLOAD Segfault bug
xdel(winsid())
xload('c.scg'); // from 5.5.2
h=gcf()
xsave('c2.scg',h);
xload('c2.scg'); //bye

That is you  have to xload, save a copy and xload again the copy to crash.
I confirm this bug under another Win10 box with a colleague.
Can you try again? 



Done. As reported on the Bugzilla thread, the instability more likely 
comes from xsave()

-- actually save() --, that changes Scilab and makes it instable.


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

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

[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] {EXT} Re: display of complex/not real numbers, again

[Federico Miyara]

Dear all,

I think that saying that

1.70018

should be represented as

1.700

and that representing it as

1.7

instead is dishonest seems a bit too much for me.

What about

1.712345649?

With the available decimal places you would represent it as

1.7123456

Wouldn't you?

However, there is no clue that the number is inaccurate by the next 
(8th) decimal digit, whereas 1.7 is inaccurate by the 16th decimal 
digit. So the clue would be given only if there are any places available 
after the last non-zero digit. If the trailing zeros serve the purpose 
of calling attention to the fact that the result is inaccurate then the 
same opportunity should be given to numbers such as 1.712345649, 
which is clearly impossible with the available decimal places.


I think no trailing zeros should be added except in rare cases when 
formatting for a table (outside Scilab), or when, as in experimental 
physics, the number of exact digits is important, but in such case 
1.700 would be as dishonest as 1.7, being 1.700 the only 
"honest" choice, again, impossible with 7 decimal places. At best, this 
could be acceptable as a non-default formatting option.


For me, the only change should be to prevent that 1.60009 be 
represented as 1.6 while 1.70018 is represented as 1.700.


Regards,

Federico Miyara



On 13/09/2019 10:21, Stéphane Mottelet wrote:


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
users@lists.scilab.org
https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/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

[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] Generating a boolean vector or matrix

[Federico Miyara]

Stéphane,

I hope no. These are typical -- IMO fake -- functions that i would 
not expect in Scilab (and in any other language). There are many 
trivial and fast ways to create a boolean array of given dimensions.




true(m,n) may be fake if, as in other message has been clarified, 
boolean takes 4 bytes, but I think this is definitely not right, it is 
way too inefficient as regards memory usage.


By the same token, ones(m,n) wouldn't be strictly necessary either, 
since zeros(m,n) + 1 does the job. But it is more inefficient, and I 
guess any of the ways to get a boolean matrix resorting to ones or zeros 
is more inefficient than would be a custom primitive.


For instance, these codes allow to measure the average time required by 
the indirect creation of a 1000x1000 boolean matrix by two methods:


for  k=1:20  
tic()

a  =  ones(1000,1000)  &  %t;
t(k)  =  toc()
clear  a
end
to  =  mean(t)  

for  k=1:20  
tic()

a  =  (ones(1000, 1000);
t(k)  =  toc()
clear  a
end
to  =  mean(t)

In my i7 laptop it is about 0.017 each, while

for  k=1:20  
tic()

a  =  ones(1,n);
t(k)  =  toc()
clear  a
end
to  =  mean(t)

takes about half the time. However, if ones is replaced by zeros + 1 it 
takes the same time as both methods for boolean


for k=1:20

tic()
a  =  zeros(1000,1000)  +  1;
t(k)  =  toc();
clear  a
end
to  =  mean(t)

That's why a primitive for booleans, whatever the syntax (such as the 
proposed ones(m,n,'boolean') would be welcome.


Regards,

Federico Miyara



To me, the only need is to document these trivial ways in the help 
pages of %F and %T.
Replacing a few lines of documentation with a lot of trivial 
duplicated codes, separate pages, separate tests always look a very 
bad idea to me.


But i can understand that, for some habit reason, former octavers 
would appreciate their usual functions.
This is why i don't clearly understand why this sub-community does 
not build /and maintain/ a "Matlabic" ATOMS package gathering this 
kind of "aliases", or do not invest time to contribute to the m2sci 
converter improvement.


Even when repmat() will be fastened by a factor 7 through its upgrade 
pending for 7 months now 
, 
it won't be the optimal way, noticeably due to its overhead.


I am neither very convinced by the ones(m,n,.,"boolean") and 
zeros(m,n,.. "boolean") proposal, for the same reason initially 
exposed by Alain. But why not.
In the same commit, Stéphane proposes to allow using the *"logical"* 
keyword as an equivalent of the "boolean" one. On this side, i 
definitively disagree with this. Indeed,


 1. it would be useless, adding strictly no value to scilab
 2. it would introduce a confusion for everyone, including for former
octavers, since in Octave an array of logical type is made of 0
and 1, not of %F and %T. While in Scilab we can also have arrays
of 0 and 1.

OK Samuel, I can forget this one. However, "double" should be kept as 
an equivalent of "constant", even if not the name of a scilab type 
returned by typeof(). We already have the macro "double()" (instead of 
"constant()") and the keyword "double" used everywhere in the API.


1.


About trivial ways, a preliminary note -- and answer to Federico :

2) How much memory does it take a boolean scalar? Does a boolean 
vector eploit the fact that a byte could theoretically host up to 8 
boolean components?


4 bytes / boolean. This big memory waste is reported since a while: 
http://bugzilla.scilab.org/12789


I think it was stored as 4 bytes for historical reasons (in Visual 
Studio up to version 4.2 C++ int was 4 bytes)


This means that, using an array of decimal numbers to create a 
boolean array uses an intermediate memory "only" ~twice bigger than 
the final result.


About some trivial efficient ways:

  * Array of %F :
  o zeros(m,n,..)==1
as Christophe does, the way i use when, for 99,5% of cases, a
factor 2 in intermediate memory is not critical
  o a(m,n,..) = %f;
or safer:
clear a, a(m,n,..) = %f;
  * Array of %T :
  o zeros(m,n,..)==0
  o a(m,n,..) = %f; ~a
  * Random boolean array :
  o rand(m,n,..) < 0.5

Personnaly, i don't need any option for getting all this. But 
documenting it would be useful.

In the same way, we can use

  * clear c, c =(5,4,7) = %i*0 // to initiate an array of 0+0i
complex-encoded array
  * clear p, p(5,4,7) = %z*0  // to initiate an array of 0z polynomials
  * etc

.. still without any specific functions or option.

Best 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 Pr

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

[Stéphane Mottelet]

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


Dear all,

I think that saying that

1.70018

should be represented as

1.700

and that representing it as

1.7

instead is dishonest seems a bit too much for me.

What about

1.712345649?

With the available decimal places you would represent it as

1.7123456

Wouldn't you?

However, there is no clue that the number is inaccurate by the next 
(8th) decimal digit, whereas 1.7 is inaccurate by the 16th decimal 
digit. So the clue would be given only if there are any places 
available after the last non-zero digit. If the trailing zeros serve 
the purpose of calling attention to the fact that the result is 
inaccurate then the same opportunity should be given to numbers such 
as 1.712345649, which is clearly impossible with the available 
decimal places.


I think no trailing zeros should be added except in rare cases when 
formatting for a table (outside Scilab), or when, as in experimental 
physics, the number of exact digits is important, but in such case 
1.700 would be as dishonest as 1.7, being 1.700 the 
only "honest" choice, again, impossible with 7 decimal places. At 
best, this could be acceptable as a non-default formatting option.


For me, the only change should be to prevent that 1.60009 
be represented as 1.6 while 1.70018 is represented as 
1.700.


Let me give the following rationale. When parsing with msscanf we get

--> msscanf("1.60009","%lf")==1.6
 ans  =

  T

but

--> msscanf("1.70018","%lf")==1.7
 ans  =

  F

The actual display algorithm does not use msscanf but a cross-platform 
code (msscanf give different results on Windows and Linux/OSX), but this 
was just a way to explain why the display of 1.7 could (not should) be 
different.


S.



Regards,

Federico Miyara



On 13/09/2019 10:21, Stéphane Mottelet wrote:


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
users@lists.scilab.org
https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users 







---
El software de antivirus Avast ha analizado este correo electrónico en 
busca de virus.
https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/www.avast.com/antivirus 



___
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] {EXT} Re: display of complex/not real numbers, again

[Stéphane Mottelet]

Le 17/09/2019 à 15:33, Stéphane Mottelet a écrit :


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


Dear all,

I think that saying that

1.70018

should be represented as

1.700

and that representing it as

1.7

instead is dishonest seems a bit too much for me.

What about

1.712345649?

With the available decimal places you would represent it as

1.7123456

Wouldn't you?

However, there is no clue that the number is inaccurate by the next 
(8th) decimal digit, whereas 1.7 is inaccurate by the 16th decimal 
digit. So the clue would be given only if there are any places 
available after the last non-zero digit. If the trailing zeros serve 
the purpose of calling attention to the fact that the result is 
inaccurate then the same opportunity should be given to numbers such 
as 1.712345649, which is clearly impossible with the 
available decimal places.


I think no trailing zeros should be added except in rare cases when 
formatting for a table (outside Scilab), or when, as in experimental 
physics, the number of exact digits is important, but in such case 
1.700 would be as dishonest as 1.7, being 1.700 the 
only "honest" choice, again, impossible with 7 decimal places. At 
best, this could be acceptable as a non-default formatting option.


For me, the only change should be to prevent that 1.60009 
be represented as 1.6 while 1.70018 is represented as 
1.700.


Let me give the following rationale. When parsing with msscanf we get

--> msscanf("1.60009","%lf")==1.6
 ans  =

  T

but

--> msscanf("1.70018","%lf")==1.7
 ans  =

  F

The actual display algorithm does not use msscanf but a cross-platform 
code (msscanf give different results on Windows and Linux/OSX), but 
this was just a way to explain why the display of 1.7 

I meant x(8) when x=1:0.1:2, i.e. 1.70018

could (not should) be different.

S.



Regards,

Federico Miyara



On 13/09/2019 10:21, Stéphane Mottelet wrote:


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
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 







---
El software de antivirus Avast ha analizado este correo electrónico 
en busca de virus.
https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/www.avast.com/antivirus 



___
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:/

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

[Federico Miyara]

Stéphane,


Let me give the following rationale. When parsing with msscanf we get

--> msscanf("1.60009","%lf")==1.6
 ans  =

  T

but

--> msscanf("1.70018","%lf")==1.7
 ans  =

  F

The actual display algorithm does not use msscanf but a 
cross-platform code (msscanf give different results on Windows and 
Linux/OSX), but this was just a way to explain why the display of 1.7 

I meant x(8) when x=1:0.1:2, i.e. 1.70018

could (not should) be different.


OK, I can now grasp what is the reason why I see 1.7 instead of 
1.700 on my system, but I cannot find a good rationale for trailing 
zeros.


Regards,

Federico Miyara





---
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