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.
3) Assuming 0/EXPR => 0 is valid 'works' most of the time. If we wanted to
be careful about this, unless Maxima can prove that EXPR is 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.
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.
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.
-s
On Wed, May 23, 2012 at 4:04 AM, Soegtrop, Michael <
michael.soegtrop at intel.com> wrote:
> I agree. I wouldn't expect that 0*inf is 0 or inf-inf is 0.
> Can someone explain what is the rationale behind this?
> Is there an option to change this behaviour?
>
> Best regards,
>
> Michael
>
> -----Original Message-----
> From: maxima-bounces at math.utexas.edu [mailto:
> maxima-bounces at math.utexas.edu] On Behalf Of Evgeniy Maevskiy
> Sent: Wednesday, May 23, 2012 8:31 AM
> To: maxima at math.utexas.edu
> Subject: Re: [Maxima] erf(inf)
>
> Not only this. We have also
>
> limit(1/zeroa-1/zeroa) => 0
>
> I.e. zeroa is the certain infinitesimal while usually in mathematics
> o(1) is equivalence class of infinitesimals.
>
> I think that erf(inf)=1 and atan(inf)=%pi/2, but 0*inf is 0*inf and not 0.
> Similarly, inf-inf is inf-inf, not 0.
>
> Another question whether we should assume that inf-inf=inf+minf. I think
> that is(inf-inf=inf+minf)=>false, but is(equal(inf-inf,inf+minf))=>true.
>
> I'm sorry that interfered.
>
>
> 23.05.2012 7:46, Raymond Toy ?????:
> > As mentioned a few days ago, maxima automatically simplifies erf(inf)
> > to 1. And also atan(inf) to %pi/2. This seems intentional, but can
> > lead to interesting things like
> >
> > (atan(inf)-%pi/2)*inf => 0
> > but
> > limit(atan(x)-%pi/2)*x,x,inf) => -1
> >
> > as Stavros mentioned.
> >
> > Therefore, I think we should change this behavior so that erf(inf) is
> > erf(inf) and not 1.
> >
> > But since this seems intentional, I'm soliciting opinions on this.
> > This also affects erfc, erfi, gamma_incomplete, fresnel_s and fresnel_c.
> > There might be others as well.
> >
> > Ray
> _______________________________________________
> Maxima mailing list
> Maxima at math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima
> _______________________________________________
> Maxima mailing list
> Maxima at math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima
>