# [Maxima] erf(inf)

Richard Fateman fateman at eecs.berkeley.edu
Wed May 23 09:11:22 CDT 2012

```On 5/23/2012 6:48 AM, Stavros Macrakis wrote:
> I think we all agree that 0*inf, inf-inf, etc. should not simplify
> incorrectly.
>
> Why hasn't this been changed? Four reasons I can think of:
>
> 1) No one yet has modified the simplification functions to handle all
> these cases correctly and systematically.  I believe there are some
> partial implementations, though -- perhaps that would be a good start.
>
> 2) There is some concern that this might slow down simplification in
> the common cases too much. I doubt that this effect will be large
> enough to make a difference with current technology.

I believe the simplifier will simplify <A>*<B>*<C> * ....  to 0  as soon
as one factor simplifies to 0,  ignoring the others.
This "short circuit" technique saves time.  How much time, unknown.

>
> 3) Assuming 0/EXPR => 0 is valid 'works' most of the time. If we
> not zero, then 0/EXPR should not be simplified to 0; this would
> probably cause problems in many calculations, as it is not always
> possible to determine whether something is actually zero (or infinity)
> or not (see the recent thread "Puzzle with bfloat and radcan"),
> especially not in the general simplifier (which does not use
> 'expensive' techniques). For that matter, subst(0,x,0/x) shows that
> even a simple variable cannot be assumed to be non-zero; as Fateman
> has pointed out repeatedly, Maxima has no way of recording that the
> simplification 0/x was /predicated/ on the assumption that x <> 0.

If we carefully and expensively record all implicit assumptions, we can
do this (i.e. it has been programmed, sort of).

e.g.  0/x is simplified to    "if x=0 then undefined else 0"

then you usually have to to further arithmetic on the "if ...".

I think this is not an adequate solution unless the conditions in the
"if" can be condensed .

>
> 4) Maxima currently has exactly one INF value.  This means that
> inf-inf must be undefined, even if the inf's are actually correlated
> -- it is correct that limit(x-x,x,inf) => 0, though inf-inf in general
> is undefined.  I'd say this case is unimportant -- if you want the
> correct value, use limits rather than inf constants.

I have proposed a way around this, by making collections of special
items like this.
put an index on the infs when created....   also on intervals.

e.g.  inf[1], inf[2],  ....  then if someone computes with an infinity,
say inf[1],    it is true that inf[1]-inf[1] =0.  But inf[1]-inf[2] =
undefined.

Similarly,  [-1,1], an interval, can be subscripted.  [-1,1] _1  -
[-1,1]_1   = 0.  However, with different subscripts the
answer is either "unsimplified" or  [-2,2]_3.

>
> There are probably other reasons as well, but that said, if someone
> contributed solid code that handled the basic cases, that would seem
> like a step forward.

I think that what is first needed is an adequate mathematical defense of
computing with infinities,
real and complex, combined with  the real and complex field, and over
polynomials etc over those fields.
then extended to  log, exp,  (which, via complex exponentials gives us
sin, cos).

Perhaps a thesis topic for someone.

RJF

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.math.utexas.edu/pipermail/maxima/attachments/20120523/b0c55dec/attachment.html>
```