Fix %r_simp() about preliminary cleaning 43/21743/6
authorSamuel GOUGEON <sgougeon@free.fr>
Tue, 27 Apr 2021 08:59:27 +0000 (10:59 +0200)
committerClement DAVID <clement.david@esi-group.com>
Thu, 29 Apr 2021 09:31:48 +0000 (11:31 +0200)
commit3b3f272ee6e0d85b2f3000a3648e12cd2785bed8
treeca2abfededc3ec97d8194633afcc5fef48e70a14
parentf59d6de9f6eef9ec149b9c26dbd86e43b13913a9
Fix %r_simp() about preliminary cleaning

 Discussion @ http://mailinglists.scilab.org/Scilab-users-Strange-behaviour-of-prod-on-rationals-tt4040527.html

 1) clean(n) and clean(d) formerly introduced (by me) are not correct
    because they implicitly apply some default absolute threshold.
    Such an absolute threshold is not relevant and even erroneous.
    Indeed, a numerator with all coefficients very small like
    1e-100 + 1e-110*%z  *can* be meaningful. By the way, in a rational,
    (1e-100 + 1e-110*%z)/%z and (1+1e-10*%z)/(1e100*%z) are equivalent.
    So if clean() is used, it should be so with a 0 absolute threshold.

 2) Now for the considered aim, here clean(n,0,reltol) would be useless:
    At least one non-zero coefficient will always survive to it,
    with no way to yield a constant null polynomial.

  This is why these clean() must be removed.
  This does not cancel the fix against the bug 13893, but makes the fix stricter.

  If we want to go forward about simplification with some relevant cleaning,
  this should be done *when operating* (+,-,.*,./) rationals, while
  operands are still known, *not after* based only on the result.
  Indeed, cleaning needs to be based on the order of magnitude of
  *operands coefficients*, compared to the result ones.

  On this respect, https://codereview.scilab.org/21742 is a good preliminary
  that could avoid later implementing N times the same improvements.

Change-Id: I6fef298bc41b6dd1da45dac3aeaa80dda0b798ef
scilab/modules/overloading/macros/%r_simp.sci