[Scilab-users] Strange behaviour of prod on rationals

[Samuel Gougeon]

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 <http://bugzilla.scilab.org/show_bug.cgi?id=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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/users/attachments/20200724/a2704256/attachment.htm>