Re: Solve never calls Equal?
- To: mathgroup at smc.vnet.net
- Subject: [mg120331] Re: Solve never calls Equal?
- From: Daniel Lichtblau <danl at wolfram.com>
- Date: Tue, 19 Jul 2011 06:56:26 -0400 (EDT)
- References: <201107150118.VAA23606@smc.vnet.net> <ivovvt$qpa$1@smc.vnet.net> <201107160941.FAA08237@smc.vnet.net> <7BBB2BCC-0234-4BDA-A129-3270EBA623CE@mimuw.edu.pl> <ivuc93$gth$1@smc.vnet.net> <4E2377E3.2010606@cs.berkeley.edu> <201107181013.GAA26896@smc.vnet.net>
On 07/18/2011 05:13 AM, Andrzej Kozlowski wrote: >> >> >> I think it is hard to claim that these test could be done only with > Significance arithmetic. However, DanL has indicated that tracing Equal > may not be effective if the system programs utilize some internal call > to a system entry into PossibleZeroQ. The point remains that >> redefining Equal as done here does not seem to adversely affect > NSolve, Reduce, NIntegrate. Nor does it seem to take much time. >> >> RJF > > As usual, your reply avoids the only important thing, which is the > example that I posted. > > Reduce[Exp[x] - x == 1/2&& Abs[x]< 1, x] > > > Try it again yourself, with Equal replaced by SameQ and without. What do > you see? > [...] > Hint: this equation is being solved *exactly* and yet your "improvement" > breaks it. > [...] I think a minor variant of the Equal-->SameQ might be safer. One needs to restrict to cases where both arguments have finite precision. Unprotect[Equal]; Equal[a_?NumericQ, b_?NumericQ] /; (Precision[a] =!= Infinity && Precision[b] =!= Infinity) := SameQ[a, b] With this version the Reduce example will work. Not sure what will be the effect in gerneral though. Daniel Lichtblau Wolfram Research
- References:
- Re: Numerical accuracy/precision - this is a bug or a feature?
- From: "Christoph Lhotka" <christoph.lhotka@univie.ac.at>
- Solve never calls Equal?
- From: Richard Fateman <fateman@cs.berkeley.edu>
- Re: Solve never calls Equal?
- From: Andrzej Kozlowski <akoz@mimuw.edu.pl>
- Re: Numerical accuracy/precision - this is a bug or a feature?