$SPAD/src/input knownbugs.input

The Axiom Team December 3, 2016

Abstract

Contents

2

1 bugs

1.1 bug1: round

20030618000 by Bill Page <bill.page1@sympatico.ca>
version: Tuesday June 17, 2003 at 18:27:07
status: open

This returns -5.0 but should return -4.0 — bug1 —

round(-3.77623)

———-

1.2 bug2: truncate

20030618001 by Bill Page <bill.page1@sympatico.ca>
version: Tuesday June 17, 2003 at 18:27:07
status: open

This returns -10.0 but should return -9.0 — bug2 —

truncate(-9.654)

———-

1.3 bug3 fractionPart

20030618002 by Bill Page <bill.page1@sympatico.ca>
version: Tuesday June 17, 2003 at 18:27:07
status: open

This returns 0.22377 but should return -0.77623 — bug3 —

fractionPart(-3.77623)

———-

1.4 bug4: Using local database

20030619000 by Bill Page <bill.page1@sympatico.ca>
version: Tuesday June 17, 2003 at 18:27:07
status: closed

Create a file called axiom.input in your home directory. Add a line that reads:

)set message autoload off

Next time you start axiom and type a+1 you should no longer get algebra load messages. — bug4 —

--20030619000 by Bill Page <bill.page1@sympatico.ca>
-- Using local database msg is missing a newline

———-

1.5 bug5: axiom issues 2 prompts

20030619001 by Bill Page <bill.page1@sympatico.ca>
version: Tuesday June 17, 2003 at 18:27:07
status: open

— bug5 —

--20030619001 by Bill Page <bill.page1@sympatico.ca>
-- axiom issues 2 prompts on startup

———-

1.6 bug6: turn off loading messages

20030619002 by Bill Page <bill.page1@sympatico.ca>
version: Tuesday June 17, 2003 at 18:27:07
status: closed

— bug6 —

--20030619002 by Bill Page <bill.page1@sympatico.ca>
)set message autoload off

———-

1.7 bug7: axiom.input should have a period prefix

20030619003 by Bill Page <bill.page1@sympatico.ca>
version: Tuesday June 17, 2003 at 18:27:07
status: closed

— bug6 —

--20030619002 by Bill Page <bill.page1@sympatico.ca>
)set message autoload off

———-

1.8 bug8: 325 Severe bug in normalize$EFSTRUC

There is a severe bug in normalize$EFSTRUC. This affects summation (’innersum$SUMFS), maybe also integration.

sub$SUMFS uses this method to check whether a function is rational for Gosper, and thus returns completely false results, which are difficult to detect.

This is listed as bug #325 on IssueTracker

To: Francois Maltey <fmaltey@nerim.fr>
Subject: Re: [Axiom-developer] severe (!) bug in normalize
From: Martin Rubey <martin.rubey@univie.ac.at>
Date: 05 Dec 2006 22:59:30 +0100
Francois Maltey <fmaltey@nerim.fr> writes:
> I'm testing some patchs in expr.spad.
> On my today-version I get :
>
> (64) -> T := t^(n^2)*sqrt(1+t)^n
>            2
>           n   +-----+n
>    (64)  t   \|t + 1
>                                            Type: Expression Integer
> (65) -> T/subst (T, n=n-1)
>           2n - 1 +-----+
>    (65)  t      \|t + 1
>                                            Type: Expression Integer
> (68) -> normalize (T/eval (T, n=n-1))
>           +-----+  (2n - 1)log(t)
>    (68)  \|t + 1 %e
>                                            Type: Expression Integer
Although this is very nice (I tried it!), it only steps around the bug
in rischNormalize, since the latter is not called with the same
arguments: your patches make axiom simplify T/eval(T, n=n-1) right
away. Although this is a very good thing, I suspect that the bug in
rischNormalize will surface under other circumstances, too.
I will comment on your patches in a separate email tomorrow, but I'd
like to express my joy about your work on EXPR and friends. I do have
some - hopefully constructive - critisism, though.
Meanwhile I did a bit of tracing. It seems likely that the bug occurs
in expeval, possibly in goodCoef. Here is the relevant bit of the
trace:
  1<enter ElementaryFunctionStructurePackage.expeval,119 :
                            +-----+
           n log(t)  n log(\|t + 1 )
         %e        %e

   arg1= ---------------------------
                          +-----+
              (n - 1)log(\|t + 1 )
            %e
                                                                 +-----+
                  +-----+   n log(t)      +-----+    (n - 1)log(\|t + 1 )
   arg2= [log(t),\|t + 1 ,%e        ,log(\|t + 1 ),%e                    ]
                  +-----+
           n log(\|t + 1 )
   arg3= %e
   arg4= [0,0,1,1]
   1<enter ElementaryFunctionStructurePackage.goodCoef,142 :
    arg1= [0,0,1,1]
                                                                  +-----+
                   +-----+   n log(t)      +-----+    (n - 1)log(\|t + 1 )
    arg2= [log(t),\|t + 1 ,%e        ,log(\|t + 1 ),%e                    ]
    arg3= exp
   1>exit  ElementaryFunctionStructurePackage.goodCoef,142 :
                     n log(t)
    [index= 3,ker= %e        ]
  1>exit  ElementaryFunctionStructurePackage.expeval,119 :
                       +-----+  2
                n log(\|t + 1 )
             (%e               )              n log(t)
   [func= -------------------------, kers= [%e        ],
                         +-----+  2
             (n - 1)log(\|t + 1 )
          (%e                    )
                       +-----+
                n log(\|t + 1 )
              %e
    vals= [----------------------]]
                         +-----+
             (n - 1)log(\|t + 1 )
           %e
Note that the expeval replaces the elements of "kers" with the
elements of "vals", but here, these are clearly not equivalent: kers
contains t^n, vals however sqrt(t+1).
Maybe this is simply an index mismatch: The length of the fourth
argument to expeval and goodCoef is four, but I have the feeling that
it is meant to refer to the elements of the second argument which are
of the form exp... or log..., and thus sqrt(t+1) should not be
counted. In other words, maybe goodCoef should rather return [index=
4, ker= log(sqrt(t+1))] or so.

A later email on the same bug

To: Waldek Hebisch <hebisch@math.uni.wroc.pl>

From: Martin Rubey <martin.rubey@univie.ac.at>
Date: 07 Dec 2006 12:52:09 +0100
Subject: [Axiom-developer] Re: severe (!) bug in normalize
Dear Waldek,
thanks for your explanations.
Waldek Hebisch <hebisch@math.uni.wroc.pl> writes:
> Martin Rubey wrote:
> > Waldek Hebisch <hebisch@math.uni.wroc.pl> writes:
> > I guess that the main problem with EXPR and friends is, that it is
> > not clear what the variables are. Do you know the assumptions
> > needed for RischNormalize?
> I do not know what problems with variables you see here
I meant that it is not clear what the coefficient field for
rischNormalize is: rischNormalize works over F, which is a
"FunctionSpace R".
To fix things, suppose that F is EXPR INT and the expression we
consider contains only one variable. I guess the field of constants is
the field of "numeric" elements from EXPR INT, i.e., expressions that
do not contain a variable.
Of course, this is still not a computable coefficient field. However,
in this case it is at least clear mathematically what
sqrt(2)*sqrt(3)-sqrt(6) is supposed to be.
Now, if we switch to a field of constants containing some variables,
what about sqrt(x)*sqrt(y)-sqrt(x*y)?
> But rischNormalize uses operations implemented by other domains to
> perform actual computuations, so there are extra assumptions.  One
> is that if an expression does not depend on a kernel (which is
> checked using derivatives) simplifier should eliminate this kernel
> from the expression.  For example representing 'y' as 'x - x + y' is
> legal for computable fields,
There are some related axioms defined in attreg.spad (namely
canonicalUnitNormal, unitsKnown and canonical). In any case, I think
that there should be a way to check whether equality is "mathematical"
or only heuristic.
> but rischNormalize would not tolerate such representation.  Of
> course, since expressions are represented as rational functions of
> kernels such simple problem can not happen in Axiom. But

> (sqrt(2)*sqrt(3)-sqrt(6))*exp(x) already hints towards possible
> problems.

By the way, are there any interesting computable coefficient fields
for rischNormalize?
> (I am aware of tread about Polynomial Expression Integer, but I
> think it is a separate problem).
Yes. In fact, I meanwhile think that it is not a problem, apart from
the fact that axiom lacks domains UnivariateExpression and
MultivariateExpression analogous to the polynomial domains.
Martin

Yet another followup:

To: Waldek Hebisch <hebisch@math.uni.wroc.pl>
From: Martin Rubey <martin.rubey@univie.ac.at>
Date: 09 Dec 2006 15:27:29 +0100
Subject: [Axiom-developer] Re: severe (!) bug in normalize
Dear Waldek,
Waldek Hebisch <hebisch@math.uni.wroc.pl> writes:
> Martin Rubey wrote:
> > Now, if we switch to a field of constants containing some
> > variables, what about sqrt(x)*sqrt(y)-sqrt(x*y)?
> At least in theory extra variable cause no difficulty.  Difficulties
> are due to extra operations (like elliptic functions).  Risch
> structure theorem also works for multivariate functions, so for
> example you can reduce zero test for elementary functions to zero
> test for elementary constants.
So, does that mean that it doesn't matter what
sqrt(x)*sqrt(y)-sqrt(x*y) is, as long as it is consistent? I guess
there are two different cases, namely, one where we normalize with
respect to, say, x, i.e., y is a constant but x isn't, the other
casebeing when both x and y are constants.

> > By the way, are there any interesting computable coefficient
> > fields for rischNormalize?
> Algebraic numbers are computable, assuming Schanuel conjecture
> elementary numbers are computable (so also elementary functions
> are computable).

Of course, Axiom doesn't have a domain for elementary
functions... Would it be difficult to implement such a domain?
> My point of view is that main task of rischNormalize is to build
> computable representation for elementary functions, so it has to
> accept somewhat unstuctured input and I do not expect that type of
> argument can alone guarantee computability.
What do you mean with "somewhat unstructured input"? I also do not
understand "I do not expect that the type of the argument alone can
guarantee computability". Computability of what? I'd guess that if the
argument type is computable, then rischNormalize should return a
normal form. Is this correct?
> Looking now at 'normalize' I think that 'normalize' is wrong.
> Namely, expressions are rational functions of kernels.  If kernels
> are algebraically dependent we risk divion by zero.  Some kernels
> (like roots) involve explicit algebraic dependence and simplifier
> should be smart enough to reduce then to normal form.
Do you mean that EXPR INT should store it's things rischNormalized? I
guess that this would make sense, however only if we keep the
unnormalized form as well, if it is "shorter". But I guess, I
misunderstood.
By the way, I stumbled over an old paper by Karl Aberer who presents a
normal form for expressions built using 1, 0, +, -, *, id and
composition. It may not be so surprising, but I think it might be
useful at some point. Furthermore, the procedure that normalizes is
absolutely simple. Notice the absence of division, though.
> But if there is dependence between transcendental kernels we have to
> 'normalize' first. rischNormalize is carefull to use a variable
> kernel in computations only after it is normalized.  But 'normalize'
> normalizes separately in each variable, so if we have function of x
> and y and we normalize first in x we use parts depending on y before
> they are normalized.  AFAICS correct version would normalize
> simultaneously in all variables.
Is this possible?
Martin

— bug8 —

T := t^(n^2)*(sqrt(1+t))^n
S := T/eval(T,n=n-1)
normalize S

———-

— * —

\getchunk{bug1}
\getchunk{bug2}
\getchunk{bug3}
\getchunk{bug4}
\getchunk{bug5}
\getchunk{bug6}
\getchunk{bug8}

———-

References^{[1] nothing}

11