Re: [Scilab-users] printf bug?
And the help page of printf_conversion states only decimal point: The number of digits to appear after the decimal point for e, E, and f conversions If the precision is zero, , no decimal point appears. A decimal point appears only if it is followed by a digit. Consequently, this is a bug. If the behaviour is indeed intended, there should be a warning (that you can turn off) if a decimal comma is used and some means to force a decimal point! Stefan On 2014-10-20 21:04, Stéphane Mottelet wrote: In the help page of string it is said that its output depends on display parameters which are defined with the format macro, i.e. you get the same output with --string(%pi) and --disp(%pi) So it is just a feature, not a bug :-D S. Le 20/10/2014 19:49, Stefan Du Rietz a écrit : But why the difference between msprintf() and string()? Stefan On 2014-10-20 18:19, Stéphane Mottelet wrote: Hello, I think that the decimal separator is controlled by the LC_NUMERIC or the LANG environment variable. With my local install (LANG=fr_FR.UTF-8) I get --msprintf(%0.1f,1.2345) ans = 1.2 S. Le 20/10/2014 17:48, Stefan Du Rietz a écrit : Hello, look here: --x = 1.2345 x = 1.2345 --msprintf(%0.1f, x) ans = 1,2 --string(0.1 * floor(10 * x)) ans = 1.2 This could cause disastrous results, e.g. when written to files ... Regards Stefan On 2014-08-02 22:35, Stefan Du Rietz wrote: With Scilab here, I mean Scilab 5.5.0. On 2014-08-02 22:30, Stefan Du Rietz wrote: Thank you, Leon, it confirms that Scilab 5.4.1 handles it correctly. But when I have LC_NUMERIC=en_DK.utf8 which means decimal comma, see below, Scilab is in error: --msprintf(%0.2f, %pi) ans = 3,14 --msprintf(%0.2f, 3.1416) ans = 3,14 Compare the correct handling in Python: Pi with two decimals is %0.2f % 3.1416 'Pi with two decimals is 3.14' Can any of the developers comment on this, or shall I report a bug? Regards Stefan stefan@Asus1:~$ uname -a Linux Asus1 3.13.0-32-generic #57-Ubuntu SMP Tue Jul 15 03:51:12 UTC 2014 i686 i686 i686 GNU/Linux stefan@Asus1:~$ locale LANG=en_GB.UTF-8 LANGUAGE=en_GB:en LC_CTYPE=en_DK.utf8 LC_NUMERIC=en_DK.utf8 LC_TIME=en_DK.utf8 LC_COLLATE=en_DK.utf8 LC_MONETARY=en_DK.utf8 LC_MESSAGES=en_DK.utf8 LC_PAPER=en_DK.utf8 LC_NAME=en_DK.utf8 LC_ADDRESS=en_DK.utf8 LC_TELEPHONE=en_DK.utf8 LC_MEASUREMENT=en_DK.utf8 LC_IDENTIFICATION=en_DK.utf8 LC_ALL=en_DK.utf8 On 2014-07-30 07:25, Leon Bevc wrote: Here is output from openSuse 13.1 and Scilab 5.4.1: --- lebevc@linux-xkf0:~ uname -a Linux linux-xkf0.site 3.15.3-1.g42bf625-desktop #1 SMP PREEMPT Wed Jul 2 09:23:08 UTC 2014 (42bf625) x86_64 x86_64 x86_64 GNU/Linux --- lebevc@linux-xkf0:~ locale LANG=sl_SI.UTF-8 LC_CTYPE=sl_SI.UTF-8 LC_NUMERIC=sl_SI.UTF-8 LC_TIME=sl_SI.UTF-8 LC_COLLATE=sl_SI.UTF-8 LC_MONETARY=sl_SI.UTF-8 LC_MESSAGES=sl_SI.UTF-8 LC_PAPER=sl_SI.UTF-8 LC_NAME=sl_SI.UTF-8 LC_ADDRESS=sl_SI.UTF-8 LC_TELEPHONE=sl_SI.UTF-8 LC_MEASUREMENT=sl_SI.UTF-8 LC_IDENTIFICATION=sl_SI.UTF-8 LC_ALL= --- lebevc@linux-xkf0:~ printf %0.2f\n 3.1416 bash: printf: 3.1416: invalid number 0,00 lebevc@linux-xkf0:~ printf %0.2f\n 3,1416 3,14 //-Scilab- --ver Scilab Version: 5.4.1.1364497457 --x = 0.12345 x = 0.12345 --xstr = msprintf(%0.2f, x) xstr = 0.12 2014-07-29 22:41 GMT+02:00 Stefan Du Rietz s...@durietz.se mailto:s...@durietz.se: Leon, Can you please try it with Scilab 5.4.1 under openSUSE? And can you show its Bash output from $ locale When I was running Scilab 5.4.1 under Xubuntu 12.04, printf worked OK, but also in Bash. So the question is: Why do you now get different results in Scilab and Bash? And *the important point*: Why should a mathematics program handle inputs differently from outputs? If one should handle decimal separators differently depending on the local language, it should be done consistently (as in Bash, even if I don't like it)! One could of course have special functions or arguments to present numbers in specific local formats. Stefan On 2014-07-29 19:41, Leon Bevc wrote: Strange... In this case I got the same result as you on Xubuntu and openSUSE: [ xUbuntu 14.04.1 - 32bit / Scilab 5.5.0 / LANG=sl_SI.UTF-8 ] lebevc@book-PC:~$ printf %0.2f\n 3.1416 bash: printf: 3.1416: neveljavno število 0,00 lebevc@book-PC:~$ printf %0.2f\n 3,1416 3,14 --__--__-- [ openSUSE 13.1-64bit ; Scilab 5.4.1] lebevc@linux-xkf0:~ printf %0.2f\n 3.1416 bash: printf: 3.1416: invalid number 0,00 lebevc@linux-xkf0:~ printf %0.2f\n 3,1416 3,14 --x = 0.6231166; --xstr = msprintf(%0.2f, x) xstr = 0.62 _
Re: [Scilab-users] printf bug?
Hello, look here: --x = 1.2345 x = 1.2345 --msprintf(%0.1f, x) ans = 1,2 --string(0.1 * floor(10 * x)) ans = 1.2 This could cause disastrous results, e.g. when written to files ... Regards Stefan On 2014-08-02 22:35, Stefan Du Rietz wrote: With Scilab here, I mean Scilab 5.5.0. On 2014-08-02 22:30, Stefan Du Rietz wrote: Thank you, Leon, it confirms that Scilab 5.4.1 handles it correctly. But when I have LC_NUMERIC=en_DK.utf8 which means decimal comma, see below, Scilab is in error: --msprintf(%0.2f, %pi) ans = 3,14 --msprintf(%0.2f, 3.1416) ans = 3,14 Compare the correct handling in Python: Pi with two decimals is %0.2f % 3.1416 'Pi with two decimals is 3.14' Can any of the developers comment on this, or shall I report a bug? Regards Stefan stefan@Asus1:~$ uname -a Linux Asus1 3.13.0-32-generic #57-Ubuntu SMP Tue Jul 15 03:51:12 UTC 2014 i686 i686 i686 GNU/Linux stefan@Asus1:~$ locale LANG=en_GB.UTF-8 LANGUAGE=en_GB:en LC_CTYPE=en_DK.utf8 LC_NUMERIC=en_DK.utf8 LC_TIME=en_DK.utf8 LC_COLLATE=en_DK.utf8 LC_MONETARY=en_DK.utf8 LC_MESSAGES=en_DK.utf8 LC_PAPER=en_DK.utf8 LC_NAME=en_DK.utf8 LC_ADDRESS=en_DK.utf8 LC_TELEPHONE=en_DK.utf8 LC_MEASUREMENT=en_DK.utf8 LC_IDENTIFICATION=en_DK.utf8 LC_ALL=en_DK.utf8 On 2014-07-30 07:25, Leon Bevc wrote: Here is output from openSuse 13.1 and Scilab 5.4.1: --- lebevc@linux-xkf0:~ uname -a Linux linux-xkf0.site 3.15.3-1.g42bf625-desktop #1 SMP PREEMPT Wed Jul 2 09:23:08 UTC 2014 (42bf625) x86_64 x86_64 x86_64 GNU/Linux --- lebevc@linux-xkf0:~ locale LANG=sl_SI.UTF-8 LC_CTYPE=sl_SI.UTF-8 LC_NUMERIC=sl_SI.UTF-8 LC_TIME=sl_SI.UTF-8 LC_COLLATE=sl_SI.UTF-8 LC_MONETARY=sl_SI.UTF-8 LC_MESSAGES=sl_SI.UTF-8 LC_PAPER=sl_SI.UTF-8 LC_NAME=sl_SI.UTF-8 LC_ADDRESS=sl_SI.UTF-8 LC_TELEPHONE=sl_SI.UTF-8 LC_MEASUREMENT=sl_SI.UTF-8 LC_IDENTIFICATION=sl_SI.UTF-8 LC_ALL= --- lebevc@linux-xkf0:~ printf %0.2f\n 3.1416 bash: printf: 3.1416: invalid number 0,00 lebevc@linux-xkf0:~ printf %0.2f\n 3,1416 3,14 //-Scilab- --ver Scilab Version: 5.4.1.1364497457 --x = 0.12345 x = 0.12345 --xstr = msprintf(%0.2f, x) xstr = 0.12 2014-07-29 22:41 GMT+02:00 Stefan Du Rietz s...@durietz.se mailto:s...@durietz.se: Leon, Can you please try it with Scilab 5.4.1 under openSUSE? And can you show its Bash output from $ locale When I was running Scilab 5.4.1 under Xubuntu 12.04, printf worked OK, but also in Bash. So the question is: Why do you now get different results in Scilab and Bash? And *the important point*: Why should a mathematics program handle inputs differently from outputs? If one should handle decimal separators differently depending on the local language, it should be done consistently (as in Bash, even if I don't like it)! One could of course have special functions or arguments to present numbers in specific local formats. Stefan On 2014-07-29 19:41, Leon Bevc wrote: Strange... In this case I got the same result as you on Xubuntu and openSUSE: [ xUbuntu 14.04.1 - 32bit / Scilab 5.5.0 / LANG=sl_SI.UTF-8 ] lebevc@book-PC:~$ printf %0.2f\n 3.1416 bash: printf: 3.1416: neveljavno število 0,00 lebevc@book-PC:~$ printf %0.2f\n 3,1416 3,14 --__--__-- [ openSUSE 13.1-64bit ; Scilab 5.4.1] lebevc@linux-xkf0:~ printf %0.2f\n 3.1416 bash: printf: 3.1416: invalid number 0,00 lebevc@linux-xkf0:~ printf %0.2f\n 3,1416 3,14 --x = 0.6231166; --xstr = msprintf(%0.2f, x) xstr = 0.62 _ users mailing list users@lists.scilab.org mailto:users@lists.scilab.org http://lists.scilab.org/__mailman/listinfo/users http://lists.scilab.org/mailman/listinfo/users _ users mailing list users@lists.scilab.org mailto:users@lists.scilab.org http://lists.scilab.org/__mailman/listinfo/users http://lists.scilab.org/mailman/listinfo/users ___ users mailing list users@lists.scilab.org http://lists.scilab.org/mailman/listinfo/users ___ users mailing list users@lists.scilab.org http://lists.scilab.org/mailman/listinfo/users ___ users mailing list users@lists.scilab.org http://lists.scilab.org/mailman/listinfo/users ___ users mailing list users@lists.scilab.org http://lists.scilab.org/mailman/listinfo/users
Re: [Scilab-users] printf bug?
Hello, I think that the decimal separator is controlled by the LC_NUMERIC or the LANG environment variable. With my local install (LANG=fr_FR.UTF-8) I get --msprintf(%0.1f,1.2345) ans = 1.2 S. Le 20/10/2014 17:48, Stefan Du Rietz a écrit : Hello, look here: --x = 1.2345 x = 1.2345 --msprintf(%0.1f, x) ans = 1,2 --string(0.1 * floor(10 * x)) ans = 1.2 This could cause disastrous results, e.g. when written to files ... Regards Stefan On 2014-08-02 22:35, Stefan Du Rietz wrote: With Scilab here, I mean Scilab 5.5.0. On 2014-08-02 22:30, Stefan Du Rietz wrote: Thank you, Leon, it confirms that Scilab 5.4.1 handles it correctly. But when I have LC_NUMERIC=en_DK.utf8 which means decimal comma, see below, Scilab is in error: --msprintf(%0.2f, %pi) ans = 3,14 --msprintf(%0.2f, 3.1416) ans = 3,14 Compare the correct handling in Python: Pi with two decimals is %0.2f % 3.1416 'Pi with two decimals is 3.14' Can any of the developers comment on this, or shall I report a bug? Regards Stefan stefan@Asus1:~$ uname -a Linux Asus1 3.13.0-32-generic #57-Ubuntu SMP Tue Jul 15 03:51:12 UTC 2014 i686 i686 i686 GNU/Linux stefan@Asus1:~$ locale LANG=en_GB.UTF-8 LANGUAGE=en_GB:en LC_CTYPE=en_DK.utf8 LC_NUMERIC=en_DK.utf8 LC_TIME=en_DK.utf8 LC_COLLATE=en_DK.utf8 LC_MONETARY=en_DK.utf8 LC_MESSAGES=en_DK.utf8 LC_PAPER=en_DK.utf8 LC_NAME=en_DK.utf8 LC_ADDRESS=en_DK.utf8 LC_TELEPHONE=en_DK.utf8 LC_MEASUREMENT=en_DK.utf8 LC_IDENTIFICATION=en_DK.utf8 LC_ALL=en_DK.utf8 On 2014-07-30 07:25, Leon Bevc wrote: Here is output from openSuse 13.1 and Scilab 5.4.1: --- lebevc@linux-xkf0:~ uname -a Linux linux-xkf0.site 3.15.3-1.g42bf625-desktop #1 SMP PREEMPT Wed Jul 2 09:23:08 UTC 2014 (42bf625) x86_64 x86_64 x86_64 GNU/Linux --- lebevc@linux-xkf0:~ locale LANG=sl_SI.UTF-8 LC_CTYPE=sl_SI.UTF-8 LC_NUMERIC=sl_SI.UTF-8 LC_TIME=sl_SI.UTF-8 LC_COLLATE=sl_SI.UTF-8 LC_MONETARY=sl_SI.UTF-8 LC_MESSAGES=sl_SI.UTF-8 LC_PAPER=sl_SI.UTF-8 LC_NAME=sl_SI.UTF-8 LC_ADDRESS=sl_SI.UTF-8 LC_TELEPHONE=sl_SI.UTF-8 LC_MEASUREMENT=sl_SI.UTF-8 LC_IDENTIFICATION=sl_SI.UTF-8 LC_ALL= --- lebevc@linux-xkf0:~ printf %0.2f\n 3.1416 bash: printf: 3.1416: invalid number 0,00 lebevc@linux-xkf0:~ printf %0.2f\n 3,1416 3,14 //-Scilab- --ver Scilab Version: 5.4.1.1364497457 --x = 0.12345 x = 0.12345 --xstr = msprintf(%0.2f, x) xstr = 0.12 2014-07-29 22:41 GMT+02:00 Stefan Du Rietz s...@durietz.se mailto:s...@durietz.se: Leon, Can you please try it with Scilab 5.4.1 under openSUSE? And can you show its Bash output from $ locale When I was running Scilab 5.4.1 under Xubuntu 12.04, printf worked OK, but also in Bash. So the question is: Why do you now get different results in Scilab and Bash? And *the important point*: Why should a mathematics program handle inputs differently from outputs? If one should handle decimal separators differently depending on the local language, it should be done consistently (as in Bash, even if I don't like it)! One could of course have special functions or arguments to present numbers in specific local formats. Stefan On 2014-07-29 19:41, Leon Bevc wrote: Strange... In this case I got the same result as you on Xubuntu and openSUSE: [ xUbuntu 14.04.1 - 32bit / Scilab 5.5.0 / LANG=sl_SI.UTF-8 ] lebevc@book-PC:~$ printf %0.2f\n 3.1416 bash: printf: 3.1416: neveljavno število 0,00 lebevc@book-PC:~$ printf %0.2f\n 3,1416 3,14 --__--__-- [ openSUSE 13.1-64bit ; Scilab 5.4.1] lebevc@linux-xkf0:~ printf %0.2f\n 3.1416 bash: printf: 3.1416: invalid number 0,00 lebevc@linux-xkf0:~ printf %0.2f\n 3,1416 3,14 --x = 0.6231166; --xstr = msprintf(%0.2f, x) xstr = 0.62 _ users mailing list users@lists.scilab.org mailto:users@lists.scilab.org http://lists.scilab.org/__mailman/listinfo/users http://lists.scilab.org/mailman/listinfo/users _ users mailing list users@lists.scilab.org mailto:users@lists.scilab.org http://lists.scilab.org/__mailman/listinfo/users http://lists.scilab.org/mailman/listinfo/users ___ users mailing list users@lists.scilab.org http://lists.scilab.org/mailman/listinfo/users ___ users mailing list users@lists.scilab.org http://lists.scilab.org/mailman/listinfo/users ___ users mailing list users@lists.scilab.org http://lists.scilab.org/mailman/listinfo/users
Re: [Scilab-users] printf bug?
But why the difference between msprintf() and string()? Stefan On 2014-10-20 18:19, Stéphane Mottelet wrote: Hello, I think that the decimal separator is controlled by the LC_NUMERIC or the LANG environment variable. With my local install (LANG=fr_FR.UTF-8) I get --msprintf(%0.1f,1.2345) ans = 1.2 S. Le 20/10/2014 17:48, Stefan Du Rietz a écrit : Hello, look here: --x = 1.2345 x = 1.2345 --msprintf(%0.1f, x) ans = 1,2 --string(0.1 * floor(10 * x)) ans = 1.2 This could cause disastrous results, e.g. when written to files ... Regards Stefan On 2014-08-02 22:35, Stefan Du Rietz wrote: With Scilab here, I mean Scilab 5.5.0. On 2014-08-02 22:30, Stefan Du Rietz wrote: Thank you, Leon, it confirms that Scilab 5.4.1 handles it correctly. But when I have LC_NUMERIC=en_DK.utf8 which means decimal comma, see below, Scilab is in error: --msprintf(%0.2f, %pi) ans = 3,14 --msprintf(%0.2f, 3.1416) ans = 3,14 Compare the correct handling in Python: Pi with two decimals is %0.2f % 3.1416 'Pi with two decimals is 3.14' Can any of the developers comment on this, or shall I report a bug? Regards Stefan stefan@Asus1:~$ uname -a Linux Asus1 3.13.0-32-generic #57-Ubuntu SMP Tue Jul 15 03:51:12 UTC 2014 i686 i686 i686 GNU/Linux stefan@Asus1:~$ locale LANG=en_GB.UTF-8 LANGUAGE=en_GB:en LC_CTYPE=en_DK.utf8 LC_NUMERIC=en_DK.utf8 LC_TIME=en_DK.utf8 LC_COLLATE=en_DK.utf8 LC_MONETARY=en_DK.utf8 LC_MESSAGES=en_DK.utf8 LC_PAPER=en_DK.utf8 LC_NAME=en_DK.utf8 LC_ADDRESS=en_DK.utf8 LC_TELEPHONE=en_DK.utf8 LC_MEASUREMENT=en_DK.utf8 LC_IDENTIFICATION=en_DK.utf8 LC_ALL=en_DK.utf8 On 2014-07-30 07:25, Leon Bevc wrote: Here is output from openSuse 13.1 and Scilab 5.4.1: --- lebevc@linux-xkf0:~ uname -a Linux linux-xkf0.site 3.15.3-1.g42bf625-desktop #1 SMP PREEMPT Wed Jul 2 09:23:08 UTC 2014 (42bf625) x86_64 x86_64 x86_64 GNU/Linux --- lebevc@linux-xkf0:~ locale LANG=sl_SI.UTF-8 LC_CTYPE=sl_SI.UTF-8 LC_NUMERIC=sl_SI.UTF-8 LC_TIME=sl_SI.UTF-8 LC_COLLATE=sl_SI.UTF-8 LC_MONETARY=sl_SI.UTF-8 LC_MESSAGES=sl_SI.UTF-8 LC_PAPER=sl_SI.UTF-8 LC_NAME=sl_SI.UTF-8 LC_ADDRESS=sl_SI.UTF-8 LC_TELEPHONE=sl_SI.UTF-8 LC_MEASUREMENT=sl_SI.UTF-8 LC_IDENTIFICATION=sl_SI.UTF-8 LC_ALL= --- lebevc@linux-xkf0:~ printf %0.2f\n 3.1416 bash: printf: 3.1416: invalid number 0,00 lebevc@linux-xkf0:~ printf %0.2f\n 3,1416 3,14 //-Scilab- --ver Scilab Version: 5.4.1.1364497457 --x = 0.12345 x = 0.12345 --xstr = msprintf(%0.2f, x) xstr = 0.12 2014-07-29 22:41 GMT+02:00 Stefan Du Rietz s...@durietz.se mailto:s...@durietz.se: Leon, Can you please try it with Scilab 5.4.1 under openSUSE? And can you show its Bash output from $ locale When I was running Scilab 5.4.1 under Xubuntu 12.04, printf worked OK, but also in Bash. So the question is: Why do you now get different results in Scilab and Bash? And *the important point*: Why should a mathematics program handle inputs differently from outputs? If one should handle decimal separators differently depending on the local language, it should be done consistently (as in Bash, even if I don't like it)! One could of course have special functions or arguments to present numbers in specific local formats. Stefan On 2014-07-29 19:41, Leon Bevc wrote: Strange... In this case I got the same result as you on Xubuntu and openSUSE: [ xUbuntu 14.04.1 - 32bit / Scilab 5.5.0 / LANG=sl_SI.UTF-8 ] lebevc@book-PC:~$ printf %0.2f\n 3.1416 bash: printf: 3.1416: neveljavno število 0,00 lebevc@book-PC:~$ printf %0.2f\n 3,1416 3,14 --__--__-- [ openSUSE 13.1-64bit ; Scilab 5.4.1] lebevc@linux-xkf0:~ printf %0.2f\n 3.1416 bash: printf: 3.1416: invalid number 0,00 lebevc@linux-xkf0:~ printf %0.2f\n 3,1416 3,14 --x = 0.6231166; --xstr = msprintf(%0.2f, x) xstr = 0.62 _ users mailing list users@lists.scilab.org mailto:users@lists.scilab.org http://lists.scilab.org/__mailman/listinfo/users http://lists.scilab.org/mailman/listinfo/users _ users mailing list users@lists.scilab.org mailto:users@lists.scilab.org http://lists.scilab.org/__mailman/listinfo/users http://lists.scilab.org/mailman/listinfo/users ___ users mailing list users@lists.scilab.org http://lists.scilab.org/mailman/listinfo/users ___ users mailing list users@lists.scilab.org http://lists.scilab.org/mailman/listinfo/users ___ users mailing list
Re: [Scilab-users] printf bug?
In the help page of string it is said that its output depends on display parameters which are defined with the format macro, i.e. you get the same output with --string(%pi) and --disp(%pi) So it is just a feature, not a bug :-D S. Le 20/10/2014 19:49, Stefan Du Rietz a écrit : But why the difference between msprintf() and string()? Stefan On 2014-10-20 18:19, Stéphane Mottelet wrote: Hello, I think that the decimal separator is controlled by the LC_NUMERIC or the LANG environment variable. With my local install (LANG=fr_FR.UTF-8) I get --msprintf(%0.1f,1.2345) ans = 1.2 S. Le 20/10/2014 17:48, Stefan Du Rietz a écrit : Hello, look here: --x = 1.2345 x = 1.2345 --msprintf(%0.1f, x) ans = 1,2 --string(0.1 * floor(10 * x)) ans = 1.2 This could cause disastrous results, e.g. when written to files ... Regards Stefan On 2014-08-02 22:35, Stefan Du Rietz wrote: With Scilab here, I mean Scilab 5.5.0. On 2014-08-02 22:30, Stefan Du Rietz wrote: Thank you, Leon, it confirms that Scilab 5.4.1 handles it correctly. But when I have LC_NUMERIC=en_DK.utf8 which means decimal comma, see below, Scilab is in error: --msprintf(%0.2f, %pi) ans = 3,14 --msprintf(%0.2f, 3.1416) ans = 3,14 Compare the correct handling in Python: Pi with two decimals is %0.2f % 3.1416 'Pi with two decimals is 3.14' Can any of the developers comment on this, or shall I report a bug? Regards Stefan stefan@Asus1:~$ uname -a Linux Asus1 3.13.0-32-generic #57-Ubuntu SMP Tue Jul 15 03:51:12 UTC 2014 i686 i686 i686 GNU/Linux stefan@Asus1:~$ locale LANG=en_GB.UTF-8 LANGUAGE=en_GB:en LC_CTYPE=en_DK.utf8 LC_NUMERIC=en_DK.utf8 LC_TIME=en_DK.utf8 LC_COLLATE=en_DK.utf8 LC_MONETARY=en_DK.utf8 LC_MESSAGES=en_DK.utf8 LC_PAPER=en_DK.utf8 LC_NAME=en_DK.utf8 LC_ADDRESS=en_DK.utf8 LC_TELEPHONE=en_DK.utf8 LC_MEASUREMENT=en_DK.utf8 LC_IDENTIFICATION=en_DK.utf8 LC_ALL=en_DK.utf8 On 2014-07-30 07:25, Leon Bevc wrote: Here is output from openSuse 13.1 and Scilab 5.4.1: --- lebevc@linux-xkf0:~ uname -a Linux linux-xkf0.site 3.15.3-1.g42bf625-desktop #1 SMP PREEMPT Wed Jul 2 09:23:08 UTC 2014 (42bf625) x86_64 x86_64 x86_64 GNU/Linux --- lebevc@linux-xkf0:~ locale LANG=sl_SI.UTF-8 LC_CTYPE=sl_SI.UTF-8 LC_NUMERIC=sl_SI.UTF-8 LC_TIME=sl_SI.UTF-8 LC_COLLATE=sl_SI.UTF-8 LC_MONETARY=sl_SI.UTF-8 LC_MESSAGES=sl_SI.UTF-8 LC_PAPER=sl_SI.UTF-8 LC_NAME=sl_SI.UTF-8 LC_ADDRESS=sl_SI.UTF-8 LC_TELEPHONE=sl_SI.UTF-8 LC_MEASUREMENT=sl_SI.UTF-8 LC_IDENTIFICATION=sl_SI.UTF-8 LC_ALL= --- lebevc@linux-xkf0:~ printf %0.2f\n 3.1416 bash: printf: 3.1416: invalid number 0,00 lebevc@linux-xkf0:~ printf %0.2f\n 3,1416 3,14 //-Scilab- --ver Scilab Version: 5.4.1.1364497457 --x = 0.12345 x = 0.12345 --xstr = msprintf(%0.2f, x) xstr = 0.12 2014-07-29 22:41 GMT+02:00 Stefan Du Rietz s...@durietz.se mailto:s...@durietz.se: Leon, Can you please try it with Scilab 5.4.1 under openSUSE? And can you show its Bash output from $ locale When I was running Scilab 5.4.1 under Xubuntu 12.04, printf worked OK, but also in Bash. So the question is: Why do you now get different results in Scilab and Bash? And *the important point*: Why should a mathematics program handle inputs differently from outputs? If one should handle decimal separators differently depending on the local language, it should be done consistently (as in Bash, even if I don't like it)! One could of course have special functions or arguments to present numbers in specific local formats. Stefan On 2014-07-29 19:41, Leon Bevc wrote: Strange... In this case I got the same result as you on Xubuntu and openSUSE: [ xUbuntu 14.04.1 - 32bit / Scilab 5.5.0 / LANG=sl_SI.UTF-8 ] lebevc@book-PC:~$ printf %0.2f\n 3.1416 bash: printf: 3.1416: neveljavno število 0,00 lebevc@book-PC:~$ printf %0.2f\n 3,1416 3,14 --__--__-- [ openSUSE 13.1-64bit ; Scilab 5.4.1] lebevc@linux-xkf0:~ printf %0.2f\n 3.1416 bash: printf: 3.1416: invalid number 0,00 lebevc@linux-xkf0:~ printf %0.2f\n 3,1416 3,14 --x = 0.6231166; --xstr = msprintf(%0.2f, x) xstr = 0.62 _ users mailing list users@lists.scilab.org mailto:users@lists.scilab.org http://lists.scilab.org/__mailman/listinfo/users http://lists.scilab.org/mailman/listinfo/users _ users mailing list users@lists.scilab.org mailto:users@lists.scilab.org http://lists.scilab.org/__mailman/listinfo/users http://lists.scilab.org/mailman/listinfo/users ___ users mailing list
Re: [Scilab-users] printf bug?
With Scilab here, I mean Scilab 5.5.0. On 2014-08-02 22:30, Stefan Du Rietz wrote: Thank you, Leon, it confirms that Scilab 5.4.1 handles it correctly. But when I have LC_NUMERIC=en_DK.utf8 which means decimal comma, see below, Scilab is in error: --msprintf(%0.2f, %pi) ans = 3,14 --msprintf(%0.2f, 3.1416) ans = 3,14 Compare the correct handling in Python: Pi with two decimals is %0.2f % 3.1416 'Pi with two decimals is 3.14' Can any of the developers comment on this, or shall I report a bug? Regards Stefan stefan@Asus1:~$ uname -a Linux Asus1 3.13.0-32-generic #57-Ubuntu SMP Tue Jul 15 03:51:12 UTC 2014 i686 i686 i686 GNU/Linux stefan@Asus1:~$ locale LANG=en_GB.UTF-8 LANGUAGE=en_GB:en LC_CTYPE=en_DK.utf8 LC_NUMERIC=en_DK.utf8 LC_TIME=en_DK.utf8 LC_COLLATE=en_DK.utf8 LC_MONETARY=en_DK.utf8 LC_MESSAGES=en_DK.utf8 LC_PAPER=en_DK.utf8 LC_NAME=en_DK.utf8 LC_ADDRESS=en_DK.utf8 LC_TELEPHONE=en_DK.utf8 LC_MEASUREMENT=en_DK.utf8 LC_IDENTIFICATION=en_DK.utf8 LC_ALL=en_DK.utf8 On 2014-07-30 07:25, Leon Bevc wrote: Here is output from openSuse 13.1 and Scilab 5.4.1: --- lebevc@linux-xkf0:~ uname -a Linux linux-xkf0.site 3.15.3-1.g42bf625-desktop #1 SMP PREEMPT Wed Jul 2 09:23:08 UTC 2014 (42bf625) x86_64 x86_64 x86_64 GNU/Linux --- lebevc@linux-xkf0:~ locale LANG=sl_SI.UTF-8 LC_CTYPE=sl_SI.UTF-8 LC_NUMERIC=sl_SI.UTF-8 LC_TIME=sl_SI.UTF-8 LC_COLLATE=sl_SI.UTF-8 LC_MONETARY=sl_SI.UTF-8 LC_MESSAGES=sl_SI.UTF-8 LC_PAPER=sl_SI.UTF-8 LC_NAME=sl_SI.UTF-8 LC_ADDRESS=sl_SI.UTF-8 LC_TELEPHONE=sl_SI.UTF-8 LC_MEASUREMENT=sl_SI.UTF-8 LC_IDENTIFICATION=sl_SI.UTF-8 LC_ALL= --- lebevc@linux-xkf0:~ printf %0.2f\n 3.1416 bash: printf: 3.1416: invalid number 0,00 lebevc@linux-xkf0:~ printf %0.2f\n 3,1416 3,14 //-Scilab- --ver Scilab Version: 5.4.1.1364497457 --x = 0.12345 x = 0.12345 --xstr = msprintf(%0.2f, x) xstr = 0.12 2014-07-29 22:41 GMT+02:00 Stefan Du Rietz s...@durietz.se mailto:s...@durietz.se: Leon, Can you please try it with Scilab 5.4.1 under openSUSE? And can you show its Bash output from $ locale When I was running Scilab 5.4.1 under Xubuntu 12.04, printf worked OK, but also in Bash. So the question is: Why do you now get different results in Scilab and Bash? And *the important point*: Why should a mathematics program handle inputs differently from outputs? If one should handle decimal separators differently depending on the local language, it should be done consistently (as in Bash, even if I don't like it)! One could of course have special functions or arguments to present numbers in specific local formats. Stefan On 2014-07-29 19:41, Leon Bevc wrote: Strange... In this case I got the same result as you on Xubuntu and openSUSE: [ xUbuntu 14.04.1 - 32bit / Scilab 5.5.0 / LANG=sl_SI.UTF-8 ] lebevc@book-PC:~$ printf %0.2f\n 3.1416 bash: printf: 3.1416: neveljavno število 0,00 lebevc@book-PC:~$ printf %0.2f\n 3,1416 3,14 --__--__-- [ openSUSE 13.1-64bit ; Scilab 5.4.1] lebevc@linux-xkf0:~ printf %0.2f\n 3.1416 bash: printf: 3.1416: invalid number 0,00 lebevc@linux-xkf0:~ printf %0.2f\n 3,1416 3,14 --x = 0.6231166; --xstr = msprintf(%0.2f, x) xstr = 0.62 _ users mailing list users@lists.scilab.org mailto:users@lists.scilab.org http://lists.scilab.org/__mailman/listinfo/users http://lists.scilab.org/mailman/listinfo/users _ users mailing list users@lists.scilab.org mailto:users@lists.scilab.org http://lists.scilab.org/__mailman/listinfo/users http://lists.scilab.org/mailman/listinfo/users ___ users mailing list users@lists.scilab.org http://lists.scilab.org/mailman/listinfo/users ___ users mailing list users@lists.scilab.org http://lists.scilab.org/mailman/listinfo/users ___ users mailing list users@lists.scilab.org http://lists.scilab.org/mailman/listinfo/users
Re: [Scilab-users] printf bug?
And I get the same error in Bash: $ printf %0.2f\n 3.1416 bash: printf: 3.1416: invalid number 0,00 lab-5.5.0/BG$ printf %0.2f\n 3,1416 3,14 So it has to do with the weird tries to simplify things ... Stefan On 2014-07-29 16:31, Leon Bevc wrote: xUbuntu 14.04.1 - 32bit / Scilab 5.5.0 / LANG=sl_SI.UTF-8 No problem here, printf functions outputs decimal point. 2014-07-29 16:06 GMT+02:00 Stefan Du Rietz s...@durietz.se mailto:s...@durietz.se: Hello, under Xubuntu 14.04 (Ubuntu Linux with XFCE) and locale en_DK.UTF-8 all Scilab printf functions output decimal commas instead of points: --x = 0.6231166; --xstr = msprintf(%0.2f, x) xstr = 0,62 which leads to --eval(xstr) ans = 0. and (worse) wrong numbers written to text files. I have not tried Scilab Scilab 5.5.0 in my earlier Xubuntu 12.04. Under Windows 7 I get the normal behaviour. Regards Stefan _ users mailing list users@lists.scilab.org mailto:users@lists.scilab.org http://lists.scilab.org/__mailman/listinfo/users http://lists.scilab.org/mailman/listinfo/users ___ users mailing list users@lists.scilab.org http://lists.scilab.org/mailman/listinfo/users ___ users mailing list users@lists.scilab.org http://lists.scilab.org/mailman/listinfo/users
Re: [Scilab-users] printf bug?
Strange... In this case I got the same result as you on Xubuntu and openSUSE: [ xUbuntu 14.04.1 - 32bit / Scilab 5.5.0 / LANG=sl_SI.UTF-8 ] lebevc@book-PC:~$ printf %0.2f\n 3.1416 bash: printf: 3.1416: neveljavno število 0,00 lebevc@book-PC:~$ printf %0.2f\n 3,1416 3,14 -- [ openSUSE 13.1-64bit ; Scilab 5.4.1] lebevc@linux-xkf0:~ printf %0.2f\n 3.1416 bash: printf: 3.1416: invalid number 0,00 lebevc@linux-xkf0:~ printf %0.2f\n 3,1416 3,14 --x = 0.6231166; --xstr = msprintf(%0.2f, x) xstr = 0.62 ___ users mailing list users@lists.scilab.org http://lists.scilab.org/mailman/listinfo/users
Re: [Scilab-users] printf bug?
Leon, Can you please try it with Scilab 5.4.1 under openSUSE? And can you show its Bash output from $ locale When I was running Scilab 5.4.1 under Xubuntu 12.04, printf worked OK, but also in Bash. So the question is: Why do you now get different results in Scilab and Bash? And *the important point*: Why should a mathematics program handle inputs differently from outputs? If one should handle decimal separators differently depending on the local language, it should be done consistently (as in Bash, even if I don't like it)! One could of course have special functions or arguments to present numbers in specific local formats. Stefan On 2014-07-29 19:41, Leon Bevc wrote: Strange... In this case I got the same result as you on Xubuntu and openSUSE: [ xUbuntu 14.04.1 - 32bit / Scilab 5.5.0 / LANG=sl_SI.UTF-8 ] lebevc@book-PC:~$ printf %0.2f\n 3.1416 bash: printf: 3.1416: neveljavno število 0,00 lebevc@book-PC:~$ printf %0.2f\n 3,1416 3,14 -- [ openSUSE 13.1-64bit ; Scilab 5.4.1] lebevc@linux-xkf0:~ printf %0.2f\n 3.1416 bash: printf: 3.1416: invalid number 0,00 lebevc@linux-xkf0:~ printf %0.2f\n 3,1416 3,14 --x = 0.6231166; --xstr = msprintf(%0.2f, x) xstr = 0.62 ___ users mailing list users@lists.scilab.org http://lists.scilab.org/mailman/listinfo/users ___ users mailing list users@lists.scilab.org http://lists.scilab.org/mailman/listinfo/users
Re: [Scilab-users] printf bug?
Here is output from openSuse 13.1 and Scilab 5.4.1: --- lebevc@linux-xkf0:~ uname -a Linux linux-xkf0.site 3.15.3-1.g42bf625-desktop #1 SMP PREEMPT Wed Jul 2 09:23:08 UTC 2014 (42bf625) x86_64 x86_64 x86_64 GNU/Linux --- lebevc@linux-xkf0:~ locale LANG=sl_SI.UTF-8 LC_CTYPE=sl_SI.UTF-8 LC_NUMERIC=sl_SI.UTF-8 LC_TIME=sl_SI.UTF-8 LC_COLLATE=sl_SI.UTF-8 LC_MONETARY=sl_SI.UTF-8 LC_MESSAGES=sl_SI.UTF-8 LC_PAPER=sl_SI.UTF-8 LC_NAME=sl_SI.UTF-8 LC_ADDRESS=sl_SI.UTF-8 LC_TELEPHONE=sl_SI.UTF-8 LC_MEASUREMENT=sl_SI.UTF-8 LC_IDENTIFICATION=sl_SI.UTF-8 LC_ALL= --- lebevc@linux-xkf0:~ printf %0.2f\n 3.1416 bash: printf: 3.1416: invalid number 0,00 lebevc@linux-xkf0:~ printf %0.2f\n 3,1416 3,14 //-Scilab- --ver Scilab Version: 5.4.1.1364497457 --x = 0.12345 x = 0.12345 --xstr = msprintf(%0.2f, x) xstr = 0.12 2014-07-29 22:41 GMT+02:00 Stefan Du Rietz s...@durietz.se: Leon, Can you please try it with Scilab 5.4.1 under openSUSE? And can you show its Bash output from $ locale When I was running Scilab 5.4.1 under Xubuntu 12.04, printf worked OK, but also in Bash. So the question is: Why do you now get different results in Scilab and Bash? And *the important point*: Why should a mathematics program handle inputs differently from outputs? If one should handle decimal separators differently depending on the local language, it should be done consistently (as in Bash, even if I don't like it)! One could of course have special functions or arguments to present numbers in specific local formats. Stefan On 2014-07-29 19:41, Leon Bevc wrote: Strange... In this case I got the same result as you on Xubuntu and openSUSE: [ xUbuntu 14.04.1 - 32bit / Scilab 5.5.0 / LANG=sl_SI.UTF-8 ] lebevc@book-PC:~$ printf %0.2f\n 3.1416 bash: printf: 3.1416: neveljavno število 0,00 lebevc@book-PC:~$ printf %0.2f\n 3,1416 3,14 -- [ openSUSE 13.1-64bit ; Scilab 5.4.1] lebevc@linux-xkf0:~ printf %0.2f\n 3.1416 bash: printf: 3.1416: invalid number 0,00 lebevc@linux-xkf0:~ printf %0.2f\n 3,1416 3,14 --x = 0.6231166; --xstr = msprintf(%0.2f, x) xstr = 0.62 ___ users mailing list users@lists.scilab.org http://lists.scilab.org/mailman/listinfo/users ___ users mailing list users@lists.scilab.org http://lists.scilab.org/mailman/listinfo/users ___ users mailing list users@lists.scilab.org http://lists.scilab.org/mailman/listinfo/users
