MathGroup Archive 1997

[Date Index] [Thread Index] [Author Index]

Search the Archive

Re: RE: Trivial integral freezes 3.

  • To: mathgroup at smc.vnet.net
  • Subject: [mg9865] Re: [mg9800] RE: Trivial integral freezes 3.
  • From: Olivier Gerard <jacquesg at mail.pratique.fr>
  • Date: Sat, 29 Nov 1997 00:10:55 -0500
  • Sender: owner-wri-mathgroup at wolfram.com

Ted Ersek wrote in replying

>It seems the algorithm ends up trying to evaluate
>(2-2(-1)^(1/3)+2(-1)^(2/3))
>using numerical approximations, and can never get enough Precision
>because the value is actually zero.  I don't know why numerical
>approximations are  needed in this problem.

Dear Ted and Carlos,

being quite accustomed to $Maxprecision::meprec messages I can guess
that there was a Positive or Negative test involved requiring an
estimation of the argument to branch to a correct form.
I have already encountered several times a similar situation when
intermediate expressions (often involving surds) were critical for a
decision (such as in Solve), could be simplified to zero, but could not
be seen as such in the form they took in the internal code.

At least in your case FullSimplify would be up to do the work, but this
is a very time-expensive function, not always easy to manage (at least
for us, poor users). This was certainly the reason why it is not
usually called.

One could imagine that, when reaching Maxprecision in such a case, the
higher level function issues at warning like:

Solve::assnull "Assuming `1` is zero. Some symbolic results returned may
depend on this being correct."

similar to the warning about inverse functions.


Olivier




  • Prev by Date: Re: RE: Trivial integral freezes 3.
  • Next by Date: EulerPhi[1]
  • Previous by thread: Re: RE: Trivial integral freezes 3.
  • Next by thread: Control Systems with Mathematica