[Scilab-users] Strange behaviour of prod on rationals

classic Classic list List threaded Threaded
9 messages Options
fmiyara fmiyara
Reply | Threaded
Open this post in threaded view
|

[Scilab-users] Strange behaviour of prod on rationals


Dear all,

Look at this code (the coefficients are actually the result of pevious calculations):

NUM = [5.858D-09 + 2.011D-08*%s + 4.884D-08*%s^2 ...
       5.858D-09 + 8.796D-10*%s + 7.028D-10*%s^2]
DEN
= [0.1199597 + 7.2765093*%s + %s^2 ...
       8.336136 +  7.0282601*%s + %s^2]
q = NUM
./DEN
 
Running it yields

   5.858D-09 +2.011D-08s +4.884D-08s²  5.858D-09 +8.796D-10s +7.028D-10s² 
   ----------------------------------  ---------------------------------- 
       0.1199597 +7.2765093s +s²            8.336136 +7.0282601s +s²      

This is, correctly, a two-component rational vector with the expected numerators and denominators.

Now let's evaluate

q = prod(NUM./DEN)

The prod documantation sys that the argument may be "an array of reals, complex, booleans, polynomials or rational fractions". It should provide the rational obtained by multiplying the twonumrators and the two denominators. However, we get

   3.432D-17 +1.230D-16s +3.079D-16s² +5.709D-17s³ +3.432D-17s⁴ 
   ------------------------------------------------------------ 
                                1                               

The numeratoris right, but the expected denominator has been just replaced by 1

However, rewriting the command as

prod(NUM)/prod(DEN)

we get the expected result:

   3.432D-17 +1.230D-16s +3.079D-16s² +5.709D-17s³ +3.432D-17s⁴ 
   ------------------------------------------------------------ 
       1.0000004 +61.501079s +59.597296s² +14.304769s³ +s⁴      

This is quite strange!

Now we repeat with simpler polynomials:

NUM = [1-%s 2-%s]
DEN = [1+%s 2+%s]
q = NUM./DEN

We get

   1 -s  2 -s 
   ----  ---- 
   1 +s  2 +s

Now evaluate

prod(NUM./DEN)

The result is the expected one!
             
   2 -3s +s² 
   --------- 
   2 +3s +s² 

The behavior seems to depend on the type of polynomials.

Is this a bug or there is something I'm not interpreting correctly?

Regards,

Federico Miyara

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

Re: Strange behaviour of prod on rationals

Hello Federico

 

I have met few months or years ago this problem when i was developping my  « OPTSIM Solution » software to fix parameters of a PID for turbines (30 mw to 2 gw) in Nyquist and Bode Plans with hydraulic parameters site

So I’ve seen instability of the denominator, witch damage calculus.

I don ‘t remember what I’ve done to get a cool solution, but it  has been a hard and severe problem with syslin, tf2ss and ss2tf instructions

 

Sincerely

 

Pierre P.

 

 

De : users <[hidden email]> De la part de Federico Miyara
Envoyé : mardi 17 mars 2020 10:31
À : Users mailing list for Scilab <[hidden email]>
Objet : [Scilab-users] Strange behaviour of prod on rationals

 


Dear all,

Look at this code (the coefficients are actually the result of pevious calculations):

NUM = [5.858D-09 + 2.011D-08*%s + 4.884D-08*%s^2 ...
       5.858D-09 + 8.796D-10*%s + 7.028D-10*%s^2]
DEN = [0.1199597 + 7.2765093*%s + %s^2 ...
       8.336136 +  7.0282601*%s + %s^2]
q = NUM./DEN
 
Running it yields

   5.858D-09 +2.011D-08s +4.884D-08s²  5.858D-09 +8.796D-10s +7.028D-10s² 
   ----------------------------------  ---------------------------------- 
       0.1199597 +7.2765093s +s²            8.336136 +7.0282601s +s²      

This is, correctly, a two-component rational vector with the expected numerators and denominators.

Now let's evaluate

q = prod(NUM./DEN)

The prod documantation sys that the argument may be "an array of reals, complex, booleans, polynomials or rational fractions". It should provide the rational obtained by multiplying the twonumrators and the two denominators. However, we get

   3.432D-17 +1.230D-16s +3.079D-16s² +5.709D-17s³ +3.432D-17s⁴ 
   ------------------------------------------------------------ 
                                1                               

The numeratoris right, but the expected denominator has been just replaced by 1

However, rewriting the command as

prod(NUM)/prod(DEN)

we get the expected result:

   3.432D-17 +1.230D-16s +3.079D-16s² +5.709D-17s³ +3.432D-17s⁴ 
   ------------------------------------------------------------ 
       1.0000004 +61.501079s +59.597296s² +14.304769s³ +s⁴      

This is quite strange!

Now we repeat with simpler polynomials:

NUM = [1-%s 2-%s]
DEN = [1+%s 2+%s]
q = NUM./DEN

We get

   1 -s  2 -s 
   ----  ---- 
   1 +s  2 +s

Now evaluate

prod(NUM./DEN)

The result is the expected one!
             
   2 -3s +s² 
   --------- 
   2 +3s +s² 

The behavior seems to depend on the type of polynomials.

Is this a bug or there is something I'm not interpreting correctly?

Regards,

Federico Miyara


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

Re: Strange behaviour of prod on rationals

In reply to this post by fmiyara

Here are examples of my process in Open loop (FTBO) or Close loop (FTBF)

Depending of managemat, D can have s14 …

 

 

 

De : Perrichon <[hidden email]>
Envoyé : mardi 17 mars 2020 10:49
À : 'Users mailing list for Scilab' <[hidden email]>
Objet : RE: [Scilab-users] Strange behaviour of prod on rationals

 

Hello Federico

 

I have met few months or years ago this problem when i was developping my  « OPTSIM Solution » software to fix parameters of a PID for turbines (30 mw to 2 gw) in Nyquist and Bode Plans with hydraulic parameters site

So I’ve seen instability of the denominator, witch damage calculus.

I don ‘t remember what I’ve done to get a cool solution, but it  has been a hard and severe problem with syslin, tf2ss and ss2tf instructions

 

Sincerely

 

Pierre P.

 

 

De : users <[hidden email]> De la part de Federico Miyara
Envoyé : mardi 17 mars 2020 10:31
À : Users mailing list for Scilab <[hidden email]>
Objet : [Scilab-users] Strange behaviour of prod on rationals

 


Dear all,

Look at this code (the coefficients are actually the result of pevious calculations):

NUM = [5.858D-09 + 2.011D-08*%s + 4.884D-08*%s^2 ...
       5.858D-09 + 8.796D-10*%s + 7.028D-10*%s^2]
DEN = [0.1199597 + 7.2765093*%s + %s^2 ...
       8.336136 +  7.0282601*%s + %s^2]
q = NUM./DEN
 
Running it yields

   5.858D-09 +2.011D-08s +4.884D-08s²  5.858D-09 +8.796D-10s +7.028D-10s² 
   ----------------------------------  ---------------------------------- 
       0.1199597 +7.2765093s +s²            8.336136 +7.0282601s +s²      

This is, correctly, a two-component rational vector with the expected numerators and denominators.

Now let's evaluate

q = prod(NUM./DEN)

The prod documantation sys that the argument may be "an array of reals, complex, booleans, polynomials or rational fractions". It should provide the rational obtained by multiplying the twonumrators and the two denominators. However, we get

   3.432D-17 +1.230D-16s +3.079D-16s² +5.709D-17s³ +3.432D-17s⁴ 
   ------------------------------------------------------------ 
                                1                               

The numeratoris right, but the expected denominator has been just replaced by 1

However, rewriting the command as

prod(NUM)/prod(DEN)

we get the expected result:

   3.432D-17 +1.230D-16s +3.079D-16s² +5.709D-17s³ +3.432D-17s⁴ 
   ------------------------------------------------------------ 
       1.0000004 +61.501079s +59.597296s² +14.304769s³ +s⁴      

This is quite strange!

Now we repeat with simpler polynomials:

NUM = [1-%s 2-%s]
DEN = [1+%s 2+%s]
q = NUM./DEN

We get

   1 -s  2 -s 
   ----  ---- 
   1 +s  2 +s

Now evaluate

prod(NUM./DEN)

The result is the expected one!
             
   2 -3s +s² 
   --------- 
   2 +3s +s² 

The behavior seems to depend on the type of polynomials.

Is this a bug or there is something I'm not interpreting correctly?

Regards,

Federico Miyara


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

Re: Strange behaviour of prod on rationals

In reply to this post by Perrichon

Pierre,

Thanks for your answer.

However, I believe no involved computatins are required to get the correct result. The multiplication of the two polynomials from the denominators is straightforward, no need to solve any system, no risk of ill-conditioned or badly-scaled matrices.

This must be another kind of problem.

Regards,

Federico Miyara

On 17/03/2020 06:48, Perrichon wrote:

Hello Federico

 

I have met few months or years ago this problem when i was developping my  « OPTSIM Solution » software to fix parameters of a PID for turbines (30 mw to 2 gw) in Nyquist and Bode Plans with hydraulic parameters site

So I’ve seen instability of the denominator, witch damage calculus.

I don ‘t remember what I’ve done to get a cool solution, but it  has been a hard and severe problem with syslin, tf2ss and ss2tf instructions

 

Sincerely

 

Pierre P.

 

 

De : users [hidden email] De la part de Federico Miyara
Envoyé : mardi 17 mars 2020 10:31
À : Users mailing list for Scilab [hidden email]
Objet : [Scilab-users] Strange behaviour of prod on rationals

 


Dear all,

Look at this code (the coefficients are actually the result of pevious calculations):

NUM = [5.858D-09 + 2.011D-08*%s + 4.884D-08*%s^2 ...
       5.858D-09 + 8.796D-10*%s + 7.028D-10*%s^2]
DEN = [0.1199597 + 7.2765093*%s + %s^2 ...
       8.336136 +  7.0282601*%s + %s^2]
q = NUM./DEN
 
Running it yields

   5.858D-09 +2.011D-08s +4.884D-08s²  5.858D-09 +8.796D-10s +7.028D-10s² 
   ----------------------------------  ---------------------------------- 
       0.1199597 +7.2765093s +s²            8.336136 +7.0282601s +s²      

This is, correctly, a two-component rational vector with the expected numerators and denominators.

Now let's evaluate

q = prod(NUM./DEN)

The prod documantation sys that the argument may be "an array of reals, complex, booleans, polynomials or rational fractions". It should provide the rational obtained by multiplying the twonumrators and the two denominators. However, we get

   3.432D-17 +1.230D-16s +3.079D-16s² +5.709D-17s³ +3.432D-17s⁴ 
   ------------------------------------------------------------ 
                                1                               

The numeratoris right, but the expected denominator has been just replaced by 1

However, rewriting the command as

prod(NUM)/prod(DEN)

we get the expected result:

   3.432D-17 +1.230D-16s +3.079D-16s² +5.709D-17s³ +3.432D-17s⁴ 
   ------------------------------------------------------------ 
       1.0000004 +61.501079s +59.597296s² +14.304769s³ +s⁴      

This is quite strange!

Now we repeat with simpler polynomials:

NUM = [1-%s 2-%s]
DEN = [1+%s 2+%s]
q = NUM./DEN

We get

   1 -s  2 -s 
   ----  ---- 
   1 +s  2 +s

Now evaluate

prod(NUM./DEN)

The result is the expected one!
             
   2 -3s +s² 
   --------- 
   2 +3s +s² 

The behavior seems to depend on the type of polynomials.

Is this a bug or there is something I'm not interpreting correctly?

Regards,

Federico Miyara


_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users


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

Re: Strange behaviour of prod on rationals

In reply to this post by fmiyara

Hello Frederico,

The problem is in simp() :

---> rlist(prod(a.num),prod(a.den),a.dt)
 ans  =

                                      2            3            4 
   3.432D-17 + 1.230D-16s + 3.079D-16s + 5.709D-17s + 3.432D-17s  
   -------------------------------------------------------------- 
                                          2            3   4      
       1.0000004 + 61.501079s + 59.597296s + 14.304769s + s       


---> simp(rlist(prod(a.num),prod(a.den),a.dt))
 ans  =

                                      2            3            4 
   3.432D-17 + 1.230D-16s + 3.079D-16s + 5.709D-17s + 3.432D-17s  
   -------------------------------------------------------------- 
                                                                  
                                 1         

S.

Le 17/03/2020 à 10:30, Federico Miyara a écrit :

Dear all,

Look at this code (the coefficients are actually the result of pevious calculations):

NUM = [5.858D-09 + 2.011D-08*%s + 4.884D-08*%s^2 ...
       5.858D-09 + 8.796D-10*%s + 7.028D-10*%s^2]
DEN
= [0.1199597 + 7.2765093*%s + %s^2 ...
       8.336136 +  7.0282601*%s + %s^2]
q = NUM
./DEN
 
Running it yields

   5.858D-09 +2.011D-08s +4.884D-08s²  5.858D-09 +8.796D-10s +7.028D-10s² 
   ----------------------------------  ---------------------------------- 
       0.1199597 +7.2765093s +s²            8.336136 +7.0282601s +s²      

This is, correctly, a two-component rational vector with the expected numerators and denominators.

Now let's evaluate

q = prod(NUM./DEN)

The prod documantation sys that the argument may be "an array of reals, complex, booleans, polynomials or rational fractions". It should provide the rational obtained by multiplying the twonumrators and the two denominators. However, we get

   3.432D-17 +1.230D-16s +3.079D-16s² +5.709D-17s³ +3.432D-17s⁴ 
   ------------------------------------------------------------ 
                                1                               

The numeratoris right, but the expected denominator has been just replaced by 1

However, rewriting the command as

prod(NUM)/prod(DEN)

we get the expected result:

   3.432D-17 +1.230D-16s +3.079D-16s² +5.709D-17s³ +3.432D-17s⁴ 
   ------------------------------------------------------------ 
       1.0000004 +61.501079s +59.597296s² +14.304769s³ +s⁴      

This is quite strange!

Now we repeat with simpler polynomials:

NUM = [1-%s 2-%s]
DEN = [1+%s 2+%s]
q = NUM./DEN

We get

   1 -s  2 -s 
   ----  ---- 
   1 +s  2 +s

Now evaluate

prod(NUM./DEN)

The result is the expected one!
             
   2 -3s +s² 
   --------- 
   2 +3s +s² 

The behavior seems to depend on the type of polynomials.

Is this a bug or there is something I'm not interpreting correctly?

Regards,

Federico Miyara

_______________________________________________
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: Strange behaviour of prod on rationals

(num,den) calling style seems to be OK:

--> [a,b]=simp(prod(q.num),prod(q.den))
 a  =

                                    2            3            4
   3.432D-17 +1.230D-16s +3.079D-16s  +5.709D-17s  +3.432D-17s

 b  =

                                    2            3   4
   1.0000004 +61.501079s +59.597296s  +14.304769s  +s

The problem is in %r_simp code, which does a cleaning, but not a complete one. If fact we should have the same result when the cleaning is done afterwards :

--> clean(a/b)
 ans  =

      
   0  
   -- 
      
   1 

which is OK to me when you see this:

--> w=10^(1:6); abs(horner(a/b,%i*w))
 ans  =

   2.224D-17   3.415D-17   3.432D-17   3.432D-17   3.432D-17   3.432D-17

S.


Le 20/03/2020 à 14:10, Stéphane Mottelet a écrit :

Hello Frederico,

The problem is in simp() :

---> rlist(prod(a.num),prod(a.den),a.dt)
 ans  =

                                      2            3            4 
   3.432D-17 + 1.230D-16s + 3.079D-16s + 5.709D-17s + 3.432D-17s  
   -------------------------------------------------------------- 
                                          2            3   4      
       1.0000004 + 61.501079s + 59.597296s + 14.304769s + s       


---> simp(rlist(prod(a.num),prod(a.den),a.dt))
 ans  =

                                      2            3            4 
   3.432D-17 + 1.230D-16s + 3.079D-16s + 5.709D-17s + 3.432D-17s  
   -------------------------------------------------------------- 
                                                                  
                                 1         

S.

Le 17/03/2020 à 10:30, Federico Miyara a écrit :

Dear all,

Look at this code (the coefficients are actually the result of pevious calculations):

NUM = [5.858D-09 + 2.011D-08*%s + 4.884D-08*%s^2 ...
       5.858D-09 + 8.796D-10*%s + 7.028D-10*%s^2]
DEN
= [0.1199597 + 7.2765093*%s + %s^2 ...
       8.336136 +  7.0282601*%s + %s^2]
q = NUM
./DEN
 
Running it yields

   5.858D-09 +2.011D-08s +4.884D-08s²  5.858D-09 +8.796D-10s +7.028D-10s² 
   ----------------------------------  ---------------------------------- 
       0.1199597 +7.2765093s +s²            8.336136 +7.0282601s +s²      

This is, correctly, a two-component rational vector with the expected numerators and denominators.

Now let's evaluate

q = prod(NUM./DEN)

The prod documantation sys that the argument may be "an array of reals, complex, booleans, polynomials or rational fractions". It should provide the rational obtained by multiplying the twonumrators and the two denominators. However, we get

   3.432D-17 +1.230D-16s +3.079D-16s² +5.709D-17s³ +3.432D-17s⁴ 
   ------------------------------------------------------------ 
                                1                               

The numeratoris right, but the expected denominator has been just replaced by 1

However, rewriting the command as

prod(NUM)/prod(DEN)

we get the expected result:

   3.432D-17 +1.230D-16s +3.079D-16s² +5.709D-17s³ +3.432D-17s⁴ 
   ------------------------------------------------------------ 
       1.0000004 +61.501079s +59.597296s² +14.304769s³ +s⁴      

This is quite strange!

Now we repeat with simpler polynomials:

NUM = [1-%s 2-%s]
DEN = [1+%s 2+%s]
q = NUM./DEN

We get

   1 -s  2 -s 
   ----  ---- 
   1 +s  2 +s

Now evaluate

prod(NUM./DEN)

The result is the expected one!
             
   2 -3s +s² 
   --------- 
   2 +3s +s² 

The behavior seems to depend on the type of polynomials.

Is this a bug or there is something I'm not interpreting correctly?

Regards,

Federico Miyara

_______________________________________________
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
fmiyara fmiyara
Reply | Threaded
Open this post in threaded view
|

Re: Strange behaviour of prod on rationals


Stéphane,

In the meantime, a workaround is to toggle simplification off:

simp_mode(%f).

This inhibits simplification.

Regards,

Federico Miyara


On 20/03/2020 10:42, Stéphane Mottelet wrote:

(num,den) calling style seems to be OK:

--> [a,b]=simp(prod(q.num),prod(q.den))
 a  =

                                    2            3            4
   3.432D-17 +1.230D-16s +3.079D-16s  +5.709D-17s  +3.432D-17s

 b  =

                                    2            3   4
   1.0000004 +61.501079s +59.597296s  +14.304769s  +s

The problem is in %r_simp code, which does a cleaning, but not a complete one. If fact we should have the same result when the cleaning is done afterwards :

--> clean(a/b)
 ans  =

      
   0  
   -- 
      
   1 

which is OK to me when you see this:

--> w=10^(1:6); abs(horner(a/b,%i*w))
 ans  =

   2.224D-17   3.415D-17   3.432D-17   3.432D-17   3.432D-17   3.432D-17

S.


Le 20/03/2020 à 14:10, Stéphane Mottelet a écrit :

Hello Frederico,

The problem is in simp() :

---> rlist(prod(a.num),prod(a.den),a.dt)
 ans  =

                                      2            3            4 
   3.432D-17 + 1.230D-16s + 3.079D-16s + 5.709D-17s + 3.432D-17s  
   -------------------------------------------------------------- 
                                          2            3   4      
       1.0000004 + 61.501079s + 59.597296s + 14.304769s + s       


---> simp(rlist(prod(a.num),prod(a.den),a.dt))
 ans  =

                                      2            3            4 
   3.432D-17 + 1.230D-16s + 3.079D-16s + 5.709D-17s + 3.432D-17s  
   -------------------------------------------------------------- 
                                                                  
                                 1         

S.

Le 17/03/2020 à 10:30, Federico Miyara a écrit :

Dear all,

Look at this code (the coefficients are actually the result of pevious calculations):

NUM = [5.858D-09 + 2.011D-08*%s + 4.884D-08*%s^2 ...
       5.858D-09 + 8.796D-10*%s + 7.028D-10*%s^2]
DEN
= [0.1199597 + 7.2765093*%s + %s^2 ...
       8.336136 +  7.0282601*%s + %s^2]
q = NUM
./DEN
 
Running it yields

   5.858D-09 +2.011D-08s +4.884D-08s²  5.858D-09 +8.796D-10s +7.028D-10s² 
   ----------------------------------  ---------------------------------- 
       0.1199597 +7.2765093s +s²            8.336136 +7.0282601s +s²      

This is, correctly, a two-component rational vector with the expected numerators and denominators.

Now let's evaluate

q = prod(NUM./DEN)

The prod documantation sys that the argument may be "an array of reals, complex, booleans, polynomials or rational fractions". It should provide the rational obtained by multiplying the twonumrators and the two denominators. However, we get

   3.432D-17 +1.230D-16s +3.079D-16s² +5.709D-17s³ +3.432D-17s⁴ 
   ------------------------------------------------------------ 
                                1                               

The numeratoris right, but the expected denominator has been just replaced by 1

However, rewriting the command as

prod(NUM)/prod(DEN)

we get the expected result:

   3.432D-17 +1.230D-16s +3.079D-16s² +5.709D-17s³ +3.432D-17s⁴ 
   ------------------------------------------------------------ 
       1.0000004 +61.501079s +59.597296s² +14.304769s³ +s⁴      

This is quite strange!

Now we repeat with simpler polynomials:

NUM = [1-%s 2-%s]
DEN = [1+%s 2+%s]
q = NUM./DEN

We get

   1 -s  2 -s 
   ----  ---- 
   1 +s  2 +s

Now evaluate

prod(NUM./DEN)

The result is the expected one!
             
   2 -3s +s² 
   --------- 
   2 +3s +s² 

The behavior seems to depend on the type of polynomials.

Is this a bug or there is something I'm not interpreting correctly?

Regards,

Federico Miyara

_______________________________________________
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


_______________________________________________
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: Strange behaviour of prod on rationals

In reply to this post by mottelet
Le 20/03/2020 à 14:42, Stéphane Mottelet a écrit :

(num,den) calling style seems to be OK:

--> [a,b]=simp(prod(q.num),prod(q.den))
 a  =
                                    2            3            4
   3.432D-17 +1.230D-16s +3.079D-16s  +5.709D-17s  +3.432D-17s

 b  =
                                    2            3   4
   1.0000004 +61.501079s +59.597296s  +14.304769s  +s

The problem is in %r_simp code, which does a cleaning, but not a complete one. If fact we should have the same result when the cleaning is done afterwards :

--> clean(a/b)
 ans  =
   0  
   -- 
   1 


My fault. When i introduced cleaning in %r_simp in order to manage the bugs 13893, i did not pay attention to the crude default clean() tolerances triggering the cleaning and used as is.
In addition, i do not remember if keeping the initial numerator was intentional or not, instead of actually setting it to 0. Still now, i am not sure neither that it should be set to 0, nor the opposite. Please see below.


which is OK to me when you see this:

--> w=10^(1:6); abs(horner(a/b,%i*w))
 ans  =

   2.224D-17   3.415D-17   3.432D-17   3.432D-17   3.432D-17   3.432D-17


IMHO, despite these low results, considering them as small enough to be cleaned is still quite questionable. We could have a numerator with all coefficients < %eps but still all meaningful.

I am wondering about the cleaning conditions used for rationals:
edit %r_clean
> a = simp(clean(a("num"), epsa, epsr) ./ clean(a("den"), epsa, epsr));

The numerators and the denominators are cleaned separately.
How to apply any absolute tolerance is quite clear (although unsafe). IMHO the absolute tolerance must be set to 0 (so not keeping the default one set to 1e-10), for the reason given hereabove.
How to use and apply  the relative tolerance is more debatable. Presently, for a given rational, no comparison is done between coefficients of its numerator and the corresponding ones of its denominator. We could consider doing things is this way.

Any other input is welcome.
Regards
Samuel



_______________________________________________
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: Strange behaviour of prod on rationals

Le 24/07/2020 à 13:11, Samuel Gougeon a écrit :

.../...
How to apply any absolute tolerance is quite clear (although unsafe). IMHO the absolute tolerance must be set to 0 (so not keeping the default one set to 1e-10), for the reason given hereabove.


I meant, in %r_simp(). In %r_clean(), taking the actual input absolute tolerance is obviously mandatory.

How to use and apply  the relative tolerance is more debatable. Presently, for a given rational, no comparison is done between coefficients of its numerator and the corresponding ones of its denominator. We could consider doing things is this way.


Either in both %r_clean() and %r_simp(), or only in %r_simp() to decide when simplifying. By the way, the comparison could be done either alone, or after applying clean() to the num and den separately.
A possible proposal:

  • keep %r_clean() as is: num and den are cleaned separately.

  • %r_simp(): to decide any denom=1 simplification for a given rational, do
    • apply clean(rational, 0, %eps).
      Then:
    • if degree(numer) <= degree(denom) and if for all numer(i) coefficients clean([numer(i) denom(i)], 0, %eps) sets numer(i) to 0
      • Then actually set numer=0 and denom=1
      • Otherwise: keep the rational as is.

We could illustrate with some critical examples of inputs and results

SG


_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users