Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.soft-sys.math.mathematica > #3747 > unrolled thread

Re: Numerical accuracy/precision - this is a bug or a feature?

Back to article view | Back to comp.soft-sys.math.mathematica

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Numerical accuracy/precision - this is a bug or a feature? Andrzej Kozlowski <akoz@mimuw.edu.pl> - 2011-07-15 09:07 +0000
    Solve never calls Equal? Richard Fateman <fateman@cs.berkeley.edu> - 2011-07-16 09:42 +0000
    Re: Solve never calls Equal? Andrzej Kozlowski <akoz@mimuw.edu.pl> - 2011-07-17 10:08 +0000
    Re: Solve never calls Equal? Andrzej Kozlowski <akoz@mimuw.edu.pl> - 2011-07-17 10:06 +0000
    Re: Solve never calls Equal? Andrzej Kozlowski <akoz@mimuw.edu.pl> - 2011-07-17 10:07 +0000
      Re: Solve never calls Equal? Richard Fateman <fateman@cs.berkeley.edu> - 2011-07-18 10:15 +0000
      Re: Solve never calls Equal? Richard Fateman <fateman@cs.berkeley.edu> - 2011-07-18 10:17 +0000
      Re: Solve never calls Equal? Andrzej Kozlowski <akoz@mimuw.edu.pl> - 2011-07-18 10:16 +0000
        Re: Solve never calls Equal? Richard Fateman <fateman@cs.berkeley.edu> - 2011-07-19 10:55 +0000
      Re: Solve never calls Equal? Andrzej Kozlowski <akoz@mimuw.edu.pl> - 2011-07-19 10:56 +0000
      Re: Solve never calls Equal? Richard Fateman <fateman@eecs.berkeley.edu> - 2011-07-19 11:00 +0000
      Re: Solve never calls Equal? Daniel Lichtblau <danl@wolfram.com> - 2011-07-19 11:01 +0000
    Re: Solve never calls Equal? Andrzej Kozlowski <akoz@mimuw.edu.pl> - 2011-07-17 10:08 +0000
    Re: Solve never calls Equal? Andrzej Kozlowski <akoz@mimuw.edu.pl> - 2011-07-18 10:13 +0000

#3747 — Re: Numerical accuracy/precision - this is a bug or a feature?

Well, here is one example of what would happen:

In[3]:= Unprotect[Equal]

Out[3]= {Equal}

In[5]:= Equal[a_, b__] := SameQ[a, b]

In[6]:= Protect[Equal]

Out[6]= {Equal}

In[7]:= Solve[3 x  == 1, x]

Out[7]= {}

Doesn't look like a great idea to me.

Andrzej Kozlowski




On 15 Jul 2011, at 03:18, Christoph Lhotka wrote:

> Dear group!
> 
> The number of posts has already become too large to read every of them, so
> I appologize if I repeat something which is already said but I think some
> people would like to see Equal to behave like SameQ.
> 
> Some now might think it is too much to write
> 
> In[1]:= 1.4===14/10
> Out[1]= False
> 
> instead of:
> 
> In[2]:= 1.4==14/10
> Out[2]= True
> 
> so one way would be to overwrite Equal itself:
> 
> In[2]:= Unprotect[Equal]
> Out[2]= {Equal}
> 
> In[3]:= Equal[a_,b__]:=SameQ[a,b]
> 
> In[4]:= Protect[Equal]
> Out[4]= {Equal}
> 
> In[5]:= 1.4==14/10
> Out[5]= False
> 
> My question is: how dangerous is it to overwrite such a fundamental
> function as Equal?
> 
> Best,
> 
> Christoph
> 
> 
> On 14/07/2011 11:20, Richard Fateman wrote:
>> On 7/13/2011 12:13 AM, Bill Rowe wrote:
>>> On 7/12/11 at 6:59 AM, slawek@host.pl (slawek) wrote:
>>> 
>>>> U=C2=BFytkownik "Oleksandr Rasputinov"<oleksandr_rasputinov@hmamail.com>
>>>> napisa=C2=B3 w wiadomo=C2=B6ci grup
> dyskusyjnych:iv6h68$s97$1@smc.vnet.net...
>>>>> considered too verbose), I do not think Mathematica's way of doing
>>>>> things is particularly arbitrary or confusing in the broader
>>>>> context of
>>> 
>>>> If  1.4 is not the same as 14/10, then Mathematica should evaluate
>>>> 1.4 == 14/10 as False.
>>> 
>>> The documentation for Equal (==) specifically states:
>>> 
>>> Approximate numbers with machine precision or higher are
>>> considered equal if they differ in at most their last seven
>>> binary digits (roughly their last two decimal digits).
>> 
>> You mean "considered Equal[] by Mathematica.
>> 
>>> 
>>> Since the exact value 14/10 differs from less than the last
>>> seven bits of the binary representation of 1.4 14/10 == 1.4
>>> returns true.
>>> 
>>> Note, by default whenever both machine precision values and
>>> exact values are in the same expression, Mathematica evaluates
>>> the expression as if everything was machine precision. And in
>>> general this is a good thing.
>>> 
>>> The other choices would seem to be either leave 1.4 == 14/10
>>> unevaluated or to return False.
>> 
>> Clearly Rasputinov thinks that if they are not equal they should not be
>> Equal.  Thus the answer is False.
>> 
>>  Both seem undesirable as they
>>> would likely cause far more problem than returning True as
>>> Mathematica presently does.
>> 
>> Actually, you are assuming users are routinely comparing floats and
>> exact numbers for equality which they should not be doing anyway.
>> Programmers in FORTRAN are told to not test for equality involving floats.
>> 
>>  Either of the other choices would
>>> certainly make expressions containing both exact and approximate
>>> values much more problematic to evaluate.
>> 
>> Or less, depending on what you expect for numbers.
>> 
>>> 
>>> Ultimately, since the developers are unlikely to change such a
>>> fundamental aspect of Mathematica, the only sensible thing is to
>>> understand how Mathematica does things if you want to
>>> effectively use Mathematica. The alternative would be to find a
>>> system that operates more to your liking.
>> 
>>  It might be fun to test to see if any of your code broke if you did this:
>> 
>> Unprotect[Equal]
>> Equal[a_Real,b_]:= Equal[Rationalize[SetAccuracy[a,Infinity]],b]
>> Equal[a_,b_Real]:= Equal[a,Rationalize[SetAccuracy[b,Infinity]]]
>> 
>> For example,
>> 0.1d0 is exactly p= 3602879701896397/36028797018963968
>> 
>> so my new and improved Equal thinks that
>> 0.1d0 and 1/10 are NOT equal,  (indeed, they differ by
> 1/180143985094819840)
>> 
>> but
>> 
>> 0.1d0 and p   ARE equal.
>> 
>> So the question is:  would any of YOUR code break if you used this patch
>> on Equal?  Really?
>> 
>> RJF
>> 
>> 
>> 
>> 
>>> 
>>> 
>> 
>> 
>> 
> 
> 
> 
> 

[toc] | [next] | [standalone]

#3759 — Solve never calls Equal?

(in a different thread, where replacing Equal by SameQ was proposed)


On 7/15/2011 2:07 AM, Andrzej Kozlowski wrote:
> Well, here is one example of what would happen:
>
> In[3]:= Unprotect[Equal]
>
> Out[3]= {Equal}
>
> In[5]:= Equal[a_, b__] := SameQ[a, b]
>
> In[6]:= Protect[Equal]
>
> Out[6]= {Equal}
>
> In[7]:= Solve[3 x  == 1, x]
>
> Out[7]= {}
>
> Doesn't look like a great idea to me.
>
> Andrzej Kozlowski
>

That's because  3*x==1  is immediately changed to False, and 
Solve[False, x] is indeed not a great idea.



Equal[a_?NumberQ, b_?NumberQ] :=  SameQ[a, b];

works better.  That Solve example works just fine.

Indeed, if one does this..

Equal[a_?NumberQ, b_?NumberQ] := (Print[test[a, b]]; SameQ[a, b]);

one can detect when, if ever, the Solve program calls Equal on two 
numbers.  It will print   test[...]  on such occasions.

When does Solve call Equal on 2 numbers?   I poked around a little and
found -- never.   I tried Integrate, Factor, Do, Product, Plot..  --never.


note that f[x_] := If [x == 0, 1, f[x - 1]*x]; f[5] computes 5! and 
calls Equal 6 times... but Factorial[5] does not.


Perhaps the internal support routines do not call Equal?
or calls to it are compiled away and not in reach of redefinition by the 
user?  Or do they call SameQ?   (no, they don't. I tried it).

Cheers


RJF

[toc] | [prev] | [next] | [standalone]

#3773 — Re: Solve never calls Equal?

On 17 Jul 2011, at 08:48, Richard Fateman wrote:

> The point of this predecessor note was to explain to Andrzej why Solve appeared to him to be broken.
> In fact, Solve does not use Equal in this example.

That's, of course, one of Richard's funnier jokes (as may people here I am sure will notice by themselves).

Andrzej Kozlowski

[toc] | [prev] | [next] | [standalone]

#3777 — Re: Solve never calls Equal?

On 16 Jul 2011, at 11:41, Richard Fateman wrote:

> (in a different thread, where replacing Equal by SameQ was proposed)
>
>
> On 7/15/2011 2:07 AM, Andrzej Kozlowski wrote:
>> Well, here is one example of what would happen:
>>
>> In[3]:= Unprotect[Equal]
>>
>> Out[3]= {Equal}
>>
>> In[5]:= Equal[a_, b__] := SameQ[a, b]
>>
>> In[6]:= Protect[Equal]
>>
>> Out[6]= {Equal}
>>
>> In[7]:= Solve[3 x  == 1, x]
>>
>> Out[7]= {}
>>
>> Doesn't look like a great idea to me.
>>
>> Andrzej Kozlowski
>>
>
> That's because  3*x==1  is immediately changed to False, and
> Solve[False, x] is indeed not a great idea.
>
>
>
> Equal[a_?NumberQ, b_?NumberQ] :=  SameQ[a, b];
>
> works better.  That Solve example works just fine.
>
> Indeed, if one does this..
>
> Equal[a_?NumberQ, b_?NumberQ] := (Print[test[a, b]]; SameQ[a, b]);
>
> one can detect when, if ever, the Solve program calls Equal on two
> numbers.  It will print   test[...]  on such occasions.
>
> When does Solve call Equal on 2 numbers?   I poked around a little and
> found -- never.   I tried Integrate, Factor, Do, Product, Plot..  =
--never.
>
>
> note that f[x_] := If [x == 0, 1, f[x - 1]*x]; f[5] computes 5! =
and
> calls Equal 6 times... but Factorial[5] does not.
>
>
> Perhaps the internal support routines do not call Equal?
> or calls to it are compiled away and not in reach of redefinition by =
the
> user?  Or do they call SameQ?   (no, they don't. I tried it).
>
> Cheers
>
>
> RJF
>
>

This may indeed "work", though one would have to check functions such as 
NSolve, NSum, Reduce, etc, which I haven't tried (and don't want to). 
But it certainly will produce effects like this:

In[1]:= Unprotect[Equal];

In[2]:= Equal[a_?NumberQ, b_?NumberQ] := SameQ[a, b]

In[3]:= Protect[Equal];

In[4]:= eqn = 2 x + 1 == 0;

In[5]:= Solve[eqn, x][[1]] // N

Out[5]= {x->-0.5}

In[6]:= eqn /. %

Out[6]= False

I am not at all convinced that the "naive user" will find this behaviour 
much of an improvement, in fact, quite the opposite.

Andrzej Kozlowski

[toc] | [prev] | [next] | [standalone]

#3779 — Re: Solve never calls Equal?

On 17 Jul 2011, at 07:10, Andrzej Kozlowski wrote:

>
> On 16 Jul 2011, at 11:41, Richard Fateman wrote:
>
>> (in a different thread, where replacing Equal by SameQ was proposed)
>>
>>
>> On 7/15/2011 2:07 AM, Andrzej Kozlowski wrote:
>>> Well, here is one example of what would happen:
>>>
>>> In[3]:= Unprotect[Equal]
>>>
>>> Out[3]= {Equal}
>>>
>>> In[5]:= Equal[a_, b__] := SameQ[a, b]
>>>
>>> In[6]:= Protect[Equal]
>>>
>>> Out[6]= {Equal}
>>>
>>> In[7]:= Solve[3 x  == 1, x]
>>>
>>> Out[7]= {}
>>>
>>> Doesn't look like a great idea to me.
>>>
>>> Andrzej Kozlowski
>>>
>>
>> That's because  3*x==1  is immediately changed to False, and
>> Solve[False, x] is indeed not a great idea.
>>
>>
>>
>> Equal[a_?NumberQ, b_?NumberQ] :=  SameQ[a, b];
>>
>> works better.  That Solve example works just fine.
>>
>> Indeed, if one does this..
>>
>> Equal[a_?NumberQ, b_?NumberQ] := (Print[test[a, b]]; SameQ[a, b]);
>>
>> one can detect when, if ever, the Solve program calls Equal on two
>> numbers.  It will print   test[...]  on such occasions.
>>
>> When does Solve call Equal on 2 numbers?   I poked around a little and
>> found -- never.   I tried Integrate, Factor, Do, Product, Plot..  --never.
>>
>>
>> note that f[x_] := If [x == 0, 1, f[x - 1]*x]; f[5] computes 5! and
>> calls Equal 6 times... but Factorial[5] does not.
>>
>>
>> Perhaps the internal support routines do not call Equal?
>> or calls to it are compiled away and not in reach of redefinition by the
>> user?  Or do they call SameQ?   (no, they don't. I tried it).
>>
>> Cheers
>>
>>
>> RJF
>>
>>
>
> This may indeed "work", though one would have to check functions such as NSolve, NSum, Reduce, etc, which I haven't tried (and don't want to). But it certainly will produce effects like this:
>
> In[1]:= Unprotect[Equal];
>
> In[2]:= Equal[a_?NumberQ, b_?NumberQ] := SameQ[a, b]
>
> In[3]:= Protect[Equal];
>
> In[4]:= eqn = 2 x + 1 == 0;
>
> In[5]:= Solve[eqn, x][[1]] // N
>
> Out[5]= {x->-0.5}
>
> In[6]:= eqn /. %
>
> Out[6]= False
>
> I am not at all convinced that the "naive user" will find this behaviour much of an improvement, in fact, quite the opposite.
>
> Andrzej Kozlowski


Well, I decided to test it, and, as I suspected, the results are not "great". Let's solve a nice equation:

Reduce[Exp[x] - x == 1/2 && Abs[x] < 1, x]//N
x==0.162909 -0.972479 I\[Or]x==0.162909 +0.972479 I

Great, now let's try Richard's "improved" Mathematica:

Unprotect[Equal];

Equal[a_?NumberQ, b_?NumberQ] := SameQ[a, b]

Protect[Equal];

Reduce[Exp[x]-x==1/2&&Abs[x]<1,x]
Reduce::nsmet: This system cannot be solved with the methods available to Reduce. >>


Bummer! It took ages to get to decide that it could no longer do it!.  The ability to solve such kind of equations is for me one of the major advances in Mathematica's capabilities in tis decade. (I am even teaching a course centered around explaining how this sort of thing is done).

Would I give this up to please Richard Fateman and his imaginary "naive users"? Would anyone?
(I don't think this really needs an answer).
Is WRI right to ignore all Richard's "helpful" code that "improves" Mathematica in various ways?
(I think the answer is also obvious).

Andrzej

[toc] | [prev] | [next] | [standalone]

#3782 — Re: Solve never calls Equal?

On 7/17/2011 3:07 AM, Andrzej Kozlowski wrote:

>>>
>>> (RJF wrote) When does Solve call Equal on 2 numbers?   I poked around a little and
>>> found -- never.   I tried Integrate, Factor, Do, Product, Plot..  --never.
>>>
>>>
>>> note that f[x_] := If [x == 0, 1, f[x - 1]*x]; f[5] computes 5! and
>>> calls Equal 6 times... but Factorial[5] does not.
>>>
>>>
>>> Perhaps the internal support routines do not call Equal?
>>> or calls to it are compiled away and not in reach of redefinition by the
>>> user?  Or do they call SameQ?   (no, they don't. I tried it).
>>>
>>> Cheers
>>>
>>>
>>> RJF
>>>
>>>
>>
>> This may indeed "work", though one would have to check functions such as NSolve,

  NSum, Reduce, etc, which I haven't tried (and don't want to). But it 
certainly will produce effects like this:
>>
>> In[1]:= Unprotect[Equal];
>>
>> In[2]:= Equal[a_?NumberQ, b_?NumberQ] := SameQ[a, b]
>>
>> In[3]:= Protect[Equal];
>>
>> In[4]:= eqn = 2 x + 1 == 0;
>>
>> In[5]:= Solve[eqn, x][[1]] // N
>>
>> Out[5]= {x->-0.5}
>>
>> In[6]:= eqn /. %
>>
>> Out[6]= False
>>
>> I am not at all convinced that the "naive user" will find this behaviour much of an improvement,

in fact, quite the opposite.
>>
>> Andrzej Kozlowski
>
>
> Well, I decided to test it, and, as I suspected, the results are not "great". Let's solve a nice equation:
>
> Reduce[Exp[x] - x == 1/2&&  Abs[x]<  1, x]//N
> x==0.162909 -0.972479 I\[Or]x==0.162909 +0.972479 I
>
> Great, now let's try Richard's "improved" Mathematica:
>
> Unprotect[Equal];
>
> Equal[a_?NumberQ, b_?NumberQ] := SameQ[a, b]
>
> Protect[Equal];
>
> Reduce[Exp[x]-x==1/2&&Abs[x]<1,x]
> Reduce::nsmet: This system cannot be solved with the methods available to Reduce.>>


To be specific, let's change the definition of Equal to the one that I 
suggested, but augmented to keep count of how many times it was called 
with at least one Real argument.  Unprotect[Equal] and then

  Equal[a_Real, b_] := (count++;
   Equal[Rationalize[SetAccuracy[a, Infinity]], b])

  Equal[a_, b_Real] := (count++;
   Equal[a, Rationalize[SetAccuracy[b, Infinity]]])

Initialize count to 0.

What is count, after these numerical operations:

NIntegrate[Sin[1/x], {x, 0.1, 10.0}]
   count is 0.

Reduce[Sin[1/x] == 0, x]
   count is 0.

f[x_] := If[x == 0.0, 1.0, x*f[x - 1]]; f[5]
   count is 5.

Reduce[Exp[x] - x == 1/2 && Abs[x] < 1, x]     (andrzej's example)
   count is 4.

NSolve[Sin[1.0/x] == 0.0, x]

   count is 3.
NSolve[Sin[1/x] == 0, x]
   count is 2.

These numbers are small enough that we might as well print out WHAT is 
being compared.
The Reduce example tests the following numbers for equality to exactly 0:
-0.972478922705943081742383427880
0.51462253970
0.972478922705943081742383427880
0.51462253970  (again).

The NSolve example compares some complicated expression to 1.0.

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

[toc] | [prev] | [next] | [standalone]

#3783 — Re: Solve never calls Equal?

On 7/17/2011 3:07 AM, Andrzej Kozlowski wrote:
...  snipped .. Andrzej's various claims that I was joking (no, I was 
exposing a flaw in his example, as Bill Rowe realized);  Andrzej's claim 
that he meant to do that.



>
> Great, now let's try Richard's "improved" Mathematica:

Actually, I did not propose to improve Mathematica by replacing Equal by 
SameQ. I observed that it was not a good substitute, and that in any 
case Solve did not, apparently, use Equal on 2 numbers.  Someone else
asked what would happen if you simply replaced Equal by SameQ.

I proposed this fix for Equal:

Unprotect[Equal]
  Equal[a_Real, b_] := Equal[Rationalize[SetAccuracy[a, Infinity]], b]
  Equal[a_, b_Real] := Equal[a, Rationalize[SetAccuracy[b, Infinity]]]



>(AK wrote...)

  Reduce[Exp[x]-x==1/2&&Abs[x]<1,x]
> Reduce::nsmet: This system cannot be solved with the methods available to Reduce.>>

With my "fix" Reduce obtains an answer.   Now I do not expect that all 
routines written will operate satisfactorily if the programmer 
originally wrote the code consciously adapted to the particular effects 
of significance arithmetic. Clearly one cannot, in general, find an 
exact solution to a transcendental equation using rational arithmetic, 
so I was a little surprised by Reduce working just fine, here.


>
>
> Bummer! It took ages to get to decide that it could no longer do it!.

But it works fine, with the actual suggested fix.

> The ability to solve such kind of equations is for me one of the major advances in

> Mathematica's capabilities in tis decade. (I am even teaching a course centered
 >around explaining how this sort of thing is done).

I too think that Reduce is very nice feature, especially when it works.

>
> Would I give this up to please Richard Fateman and his imaginary "naive users"? Would anyone?

It appears not to be necessary to give it up.  And one could, as 
mentioned, simply not use ==  in your own user code, but define 
NumericallyClose[a,b]  or some such thing.  Perhaps define =~=.



> (I don't think this really needs an answer).

Because it is a "straw man"?

> Is WRI right to ignore all Richard's "helpful" code that "improves" Mathematica in various ways?
> (I think the answer is also obvious).

How would you know if they ignore all my suggestions?

RJF

[toc] | [prev] | [next] | [standalone]

#3790 — Re: Solve never calls Equal?

>
>
> 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?

It's amazing that you can deny what you can and everyone can see and 
still claim that "Reduce has not been effected". It is also clear that 
you do not understand why I chose this particular example and why your 
improvement broke it.

Hint: this equation is being solved *exactly* and yet your "improvement" 
breaks it. 


The main problem is that you don't understand the mathematics involved 
here.   The fact that you than produces a lot of examples that have 
obviously no relevance to this issue confirms this.

This sort of thing is not new Richard. I have already offered, to 
re-post some of your past posts which show you lack of understanding of 
the basics of Mathematica. But I can also post some examples, like this 
one, that show that you do not understand the mathematics behind it, and 
yet arrogantly presume to be instructing those who do (at least better 
than you).

Andrzej Kozlowski

[toc] | [prev] | [next] | [standalone]

#3797 — Re: Solve never calls Equal?

On 7/18/2011 3:16 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?

As posted, my note on 7/18 just preceding yours, shows what happens when 
I tried it again, with the definition of Equal that I proposed, that 
compares numbers with full accuracy.  (Redefining Equal as SameQ is NOT 
something I recommended because SameQ is hardly better. Furthermore, to 
use SameQ for non-numbers is a very bad idea indeed since it has quite a 
different semantics from Equal in that case. Equal[x,y] returns 
unchanged if x,y are unknown. SameQ[x,y] returns False.)
>
> It's amazing that you can deny what you can and everyone can see and
> still claim that "Reduce has not been effected". It is also clear that
> you do not understand why I chose this particular example and why your
> improvement broke it.

Since my improvement did not break it, what can I say in response?
>
> Hint: this equation is being solved *exactly* and yet your "improvement"
> breaks it.
>
I should mention that the note I sent to mathgroup was accidentally not 
sent to Andrzej at the same time, as I usually do. Perhaps he would not 
have written with such certainty then.

>
> The main problem is that you don't understand the mathematics involved
> here.   The fact that you than produces a lot of examples that have
> obviously no relevance to this issue confirms this.

What can I say, "I'm rubber you're glue"?

>
> This sort of thing is not new Richard. I have already offered, to
> re-post some of your past posts which show you lack of understanding of
> the basics of Mathematica. But I can also post some examples, like this
> one, that show that you do not understand the mathematics behind it, and
> yet arrogantly presume to be instructing those who do (at least better
> than you).

More often I think that I understand what is going on in Mathematica, 
but believe it to be wrong.  You choose to interpret it as not 
understanding Mathematica.

RJF
>

[toc] | [prev] | [next] | [standalone]

#3799 — Re: Solve never calls Equal?

On 18 Jul 2011, at 12:14, Richard Fateman wrote:

> Clearly one cannot, in general, find an
> exact solution to a transcendental equation using rational arithmetic,

> so I was a little surprised by Reduce working just fine, here.

Of course one does not use "arithmetic". You still don't understand what 
is going on here, but I am now at an airport during a break in a long 
flight so won't be able to educated you how it is really done (and why 
your fix "works") just yet. But if you ask nicely, maybe in the future 
;-)

Andrzej Kozlowski

[toc] | [prev] | [next] | [standalone]

#3810 — Re: Solve never calls Equal?

On 7/18/2011 6:55 AM, Andrzej Kozlowski wrote:
> On 18 Jul 2011, at 12:14, Richard Fateman wrote:
>
>> Clearly one cannot, in general, find an
>> exact solution to a transcendental equation using rational arithmetic,
>> so I was a little surprised by Reduce working just fine, here.
> Of course one does not use "arithmetic".
Of course Reduce uses arithmetic in
Reduce[Exp[x] - x == 1/2 && Abs[x] < 1, x] // N

How else to explain that in it, proven by tracing Equal, it compares 
numbers like 0 and 0.907560823521493954198929899042.
Of course I did not convert all its internal arithmetic to rational 
arithmetic, just comparisons.
So in fact Reduce was doing its regular same-old thing, most of the 
time; if I had thought of that
I wouldn't have been surprised.  Testing for termination conditions 
using rationals didn't seem to hurt.
Again, that is not totally surprising since it seems a bit unlikely that 
Reduce relies, for
termination, on loss of precision.  But who knows.

> You still don't understand what is going on here, but I am now at an airport during a break in a long flight so won't be able to educated you how it is really done (and why your fix "works") just yet. But if you ask nicely, maybe in the future ;-)
Sure you write an explanation of how you think Reduce works, you can 
post it on a web page and provide a link here.
Otherwise we would just be left with the documentation, e.g.
http://reference.wolfram.com/mathematica/tutorial/SomeNotesOnInternalImplementation.html#25734


RJF

[toc] | [prev] | [next] | [standalone]

#3812 — Re: Solve never calls Equal?

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

[toc] | [prev] | [next] | [standalone]

#3781 — Re: Solve never calls Equal?

Maybe the "joke" should be more clearer for the benefit of the more 
naive users (and I include Richard in this category) for reasons that 
will soon become obvious (though they already are to many).

Firstly, Solve does not hold its arguments as everyone except the most 
naive users will know, so the fact that Solve[eqns,x] will first 
evaluate eqns and then will attempt to compare (using Equal) a symbolic 
expression to a number is also news to someone like Richard. (In fact I 
pointed out similar things to him in the past and if he really wants to 
be reminded of that I can post these messages).
So, of course, once Equal has been replaced by SameQ, you wil end up 
with Solve[False,x] etc.

Only someone like Richard will find this so exciting that it needs to be 
explained. I am sorry, but the only reason why I omitted doing so myself 
was that it seemed to me too patronising to other users to explain such 
obvious stuff.

On the other hand, the fact that having modified Equal in this way, 
Richard tested functions which do not normally use significance 
arithmetic instead of choosing an example that actually needs it, does 
show something about Richard's understanding of Mathematica.

So that is what makes his joke so funny, eve if he did not necessarily 
intend it to be so.

Andrzej Kozlowski


On 17 Jul 2011, at 09:30, Andrzej Kozlowski wrote:

>
> On 17 Jul 2011, at 08:48, Richard Fateman wrote:
>
>> The point of this predecessor note was to explain to Andrzej why 
Solve appeared to him to be broken.
>> In fact, Solve does not use Equal in this example.
>
> That's, of course, one of Richard's funnier jokes (as may people here 
I am sure will notice by themselves).
>
> Andrzej Kozlowski

[toc] | [prev] | [next] | [standalone]

#3787 — Re: Solve never calls Equal?

On 17 Jul 2011, at 12:03, Andrzej Kozlowski wrote:

>
> On 17 Jul 2011, at 07:10, Andrzej Kozlowski wrote:
>
>>
>> On 16 Jul 2011, at 11:41, Richard Fateman wrote:
>>
>>> (in a different thread, where replacing Equal by SameQ was proposed)
>>>
>>>
>>> On 7/15/2011 2:07 AM, Andrzej Kozlowski wrote:
>>>> Well, here is one example of what would happen:
>>>>
>>>> In[3]:= Unprotect[Equal]
>>>>
>>>> Out[3]= {Equal}
>>>>
>>>> In[5]:= Equal[a_, b__] := SameQ[a, b]
>>>>
>>>> In[6]:= Protect[Equal]
>>>>
>>>> Out[6]= {Equal}
>>>>
>>>> In[7]:= Solve[3 x  == 1, x]
>>>>
>>>> Out[7]= {}
>>>>
>>>> Doesn't look like a great idea to me.
>>>>
>>>> Andrzej Kozlowski
>>>>
>>>
>>> That's because  3*x==1  is immediately changed to False, and
>>> Solve[False, x] is indeed not a great idea.
>>>
>>>
>>>
>>> Equal[a_?NumberQ, b_?NumberQ] :=  SameQ[a, b];
>>>
>>> works better.  That Solve example works just fine.
>>>
>>> Indeed, if one does this..
>>>
>>> Equal[a_?NumberQ, b_?NumberQ] := (Print[test[a, b]]; SameQ[a, b]);
>>>
>>> one can detect when, if ever, the Solve program calls Equal on two
>>> numbers.  It will print   test[...]  on such occasions.
>>>
>>> When does Solve call Equal on 2 numbers?   I poked around a little and
>>> found -- never.   I tried Integrate, Factor, Do, Product, Plot..  --never.
>>>
>>>
>>> note that f[x_] := If [x == 0, 1, f[x - 1]*x]; f[5] computes 5! and
>>> calls Equal 6 times... but Factorial[5] does not.
>>>
>>>
>>> Perhaps the internal support routines do not call Equal?
>>> or calls to it are compiled away and not in reach of redefinition by the
>>> user?  Or do they call SameQ?   (no, they don't. I tried it).
>>>
>>> Cheers
>>>
>>>
>>> RJF
>>>
>>>
>>
>> This may indeed "work", though one would have to check functions such as NSolve, NSum, Reduce, etc, which I haven't tried (and don't want to). But it certainly will produce effects like this:
>>
>> In[1]:= Unprotect[Equal];
>>
>> In[2]:= Equal[a_?NumberQ, b_?NumberQ] := SameQ[a, b]
>>
>> In[3]:= Protect[Equal];
>>
>> In[4]:= eqn = 2 x + 1 == 0;
>>
>> In[5]:= Solve[eqn, x][[1]] // N
>>
>> Out[5]= {x->-0.5}
>>
>> In[6]:= eqn /. %
>>
>> Out[6]= False
>>
>> I am not at all convinced that the "naive user" will find this behaviour much of an improvement, in fact, quite the opposite.
>>
>> Andrzej Kozlowski
>
>
> Well, I decided to test it, and, as I suspected, the results are not "great". Let's solve a nice equation:
>
> Reduce[Exp[x] - x == 1/2 && Abs[x] < 1, x]//N
> x==0.162909 -0.972479 I\[Or]x==0.162909 +0.972479 I
>
> Great, now let's try Richard's "improved" Mathematica:
>
> Unprotect[Equal];
>
> Equal[a_?NumberQ, b_?NumberQ] := SameQ[a, b]
>
> Protect[Equal];
>
> Reduce[Exp[x]-x==1/2&&Abs[x]<1,x]
> Reduce::nsmet: This system cannot be solved with the methods available to Reduce. >>
>
>
> Bummer! It took ages to get to decide that it could no longer do it!.  The ability to solve such kind of equations is for me one of the major advances in Mathematica's capabilities in tis decade. (I am even teaching a course centered around explaining how this sort of thing is done).

I regret that at this point I did not simply write: "Mommy, Fateman broke my Mathematica!"  - something that by now must be all too familiar to all those "naive users" who decide to follow Richard's advice.

AK


>
> Would I give this up to please Richard Fateman and his imaginary "naive users"? Would anyone?
> (I don't think this really needs an answer).
> Is WRI right to ignore all Richard's "helpful" code that "improves" Mathematica in various ways?
> (I think the answer is also obvious).
>
> Andrzej
>
>
>
>
>
>

[toc] | [prev] | [standalone]

Back to top | Article view | comp.soft-sys.math.mathematica

csiph-web