Re: [Scilab-users] lcm() output type: how to avoid overflowing and get an actual result?

2017-03-15 Thread Samuel Gougeon
Hello Tim, Le 15/03/2017 à 18:57, Tim Wescott a écrit : So, a quick test gives me: -->A = uint8([123 423]); A / lcm(A) ans = 2 2 This looks pretty "least common multiple" to me. Really? In which way? As long as integers are used, the result should not depend on their encoding. So

Re: [Scilab-users] A tool for creating formated tables

2017-03-15 Thread Claus Futtrup
Hi Pierre Wow! Today I did the opposite ... I exported a LaTeX table to Scilab (as a matrix of strings). Best regards, Claus On 15-03-2017 18:56, Pierre Vuillemin wrote: Hi all, I've made a little tool for creating formated tables in Scilab. In particular, it enables to: * display p

Re: [Scilab-users] A tool for creating formated tables

2017-03-15 Thread Samuel Gougeon
Hello Pierre, Le 15/03/2017 à 18:56, Pierre Vuillemin a écrit : Hi all, I've made a little tool for creating formated tables in Scilab. In particular, it enables to: * display pretty tables in the console, * create github-markdown tables, * create latex tables. Source code (the file

[Scilab-users] A tool for creating formated tables

2017-03-15 Thread Pierre Vuillemin
Hi all, I've made a little tool for creating formated tables in Scilab. In particular, it enables to: * display pretty tables in the console, * create github-markdown tables, * create latex tables. Source code (the file tabular.sci) and some examples are provided here

Re: [Scilab-users] lcm() output type: how to avoid overflowing and get an actual result?

2017-03-15 Thread Tim Wescott
So, a quick test gives me: -->A = uint8([123 423]); A / lcm(A)  ans  =     2  2   This looks pretty "least common multiple" to me.  If I want a least common multiple over decimal numbers or floats or bigger integers or whatever, then it's my responsibility to tell the function that's what I want

Re: [Scilab-users] lcm() output type: how to avoid overflowing and get an actual result?

2017-03-15 Thread Samuel Gougeon
Le 15/03/2017 à 17:04, Samuel Gougeon a écrit : Hello, Processing the bughttp://bugzilla.scilab.org/15017 for the lcm() function deserves an open discussion about the datatype of the result when the operand is a matrix of encoded integers. Presently, the result of lcm(A) has the type of A: -->

Re: [Scilab-users] {EXT} lcm() output type: how to avoid overflowing and get an actual result?

2017-03-15 Thread Samuel Gougeon
Hello Christophe, Thanks for your contribution: Le 15/03/2017 à 17:29, Dang Ngoc Chan, Christophe a écrit : My (slight) preference would be to cast the result always into the decimal class This sounds reasonable. But the result could also be converted to the format that is the "closest and s

Re: [Scilab-users] {EXT} lcm() output type: how to avoid overflowing and get an actual result?

2017-03-15 Thread Dang Ngoc Chan, Christophe
Hello, > De : users [mailto:users-boun...@lists.scilab.org] De la part de Samuel > Gougeon > Envoyé : mercredi 15 mars 2017 17:05 > > My (slight) preference would be to cast the result always into the decimal > class This sounds reasonable. But the result could also be converted to the format

[Scilab-users] lcm() output type: how to avoid overflowing and get an actual result?

2017-03-15 Thread Samuel Gougeon
Hello, Processing the bug http://bugzilla.scilab.org/15017 for the lcm() function deserves an open discussion about the datatype of the result when the operand is a matrix of encoded integers. Presently, the result of lcm(A) has the type of A: --> r = lcm(int16([123 423])), typeof(r) r = 173

Re: [Scilab-users] Once and for all curing input() : a good target for Scilab 6.0.1 <== Re: Bug in input statement

2017-03-15 Thread Samuel Gougeon
Once more user report about input(): http://bugzilla.scilab.org/15069 SG Le 03/03/2017 à 21:06, Samuel Gougeon a écrit : Hello Osvaldo, Yes, there are awful sticky bugs on input(). Despite it is a "basic" function, it has never ever worked in a completely right way. It is a quite nasty situat