Mathematica 9 is now available
Services & Resources / Wolfram Forums / MathGroup Archive
-----

MathGroup Archive 2010

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

Search the Archive

Re: LessEqual vs Inequality, was ..Re: Replacement Rule with Sqrt in denominator

  • To: mathgroup at smc.vnet.net
  • Subject: [mg114729] Re: LessEqual vs Inequality, was ..Re: Replacement Rule with Sqrt in denominator
  • From: Richard Fateman <fateman at cs.berkeley.edu>
  • Date: Tue, 14 Dec 2010 06:56:38 -0500 (EST)

On 12/13/2010 8:53 AM, Andrzej Kozlowski wrote:
> On 13 Dec 2010, at 17:11, Richard Fateman wrote:
>
> ....

>>
>> So now we have set the stage for DanL and friends.
>> 1. Remove Less. and always replace it with Inequality ...
>> 2. Same for Greater, etc etc.
>> 3. (suggestion)  Rename Inequality with Comparison.
>> 4. modify the rest of the programs, like Compile, Display, as necessary.
>> 5. Change the documentation.
>>
>>
>> There may still be work to do for dealing with the elements in
>> Mathematica that do not obey the "law of trichotomy", which states
>> that a<b, a==b, or a>b.  But this is not true for objects that are
>> not comparable.  Like Complex numbers, various undefined objects,
>> Indeterminate, NaN.
>>
>>
> Yes, this seems plausible, but of course it would require a fundamental re-write of Mathematica for a very minor gain (though I admit that there would be some gain).
I'm not so convinced it would be a fundamental rewrite.  I have made 
other suggestions that
would be more of a challenge, some of which were implemented.  I think 
it might be incompatible
with some existing programs that depend on the syntactic property of the 
Heads of Less, etc.
But those program which perhaps would not operate on 
Inequality[a,Less,b,Less,c], but require Less[a,b,c]
might be, as one says, "in error"  even if that error is not exhibited.

>   But I would much rather Wolfram employed its resources on developing many new functions and algorithms that I actually use and that are important to me, so I would strenuously object to any idea of diverting these resources to anything of this kind.
  I think WRI  can allocate resources  without your pre- (or post-) 
censoring the list to exclude things not of interest to you personally.

>   As I have pointed out to you many times, I consider these sort of things that seem to excite you so much as essentially of very little practical interest to the "working mathematician". I would certainly not pay any money to get this sort of improvement and I doubt many users would.
My objections to the way small things are handled has to do with the 
hierarchical nature
of a computer algebra system.  That is, if you get some of the little 
things "just a little wrong"
(maybe something a physicist might not notice), then it is harder to 
build on top of
that foundation.  That's why I feel strongly about (say) arithmetic.  Or 
returning answers
that are right except at a few (unstated) places.  (few= something like 
a space of lower dimension).


>> Note that LogicalExpand does not distinguish between Less[x,y,z] and Inequality[x,Less,y,Less, z].
> What do you mean by note? I pointed this out to you, LogicalExpand reduces both to the same canonical form.
It is not a canonical form.

If it were,  LogicalExpand[a<b<c]   would be the same as 
LogicalExpand[c>b>a]
> I am curious if you really believe your own words when you write stuff
Generally, except when I make a typo,  or are being sarcastic, yes.
  Occasionally I may mis-read or misinterpret something.

> like this and whether I really like to imagine you discovered it all by yourself or knew it anyway.
>
>> FullSimplify [Less[x,y,z]-Inequality[x,Less,y,Less,z] ]
>> does not reduce to zero, as it should.  So Mathematica, dare
>> I say, exhibits a bug.
> No, these expressions are not equal but logically equivalent. The way to show that is
>
> In[103]:= Refine[Less[x, y, z], Inequality[x, Less, y, Less, z]]
>
> Out[103]= True
>
> In[104]:= Refine[Inequality[x, Less, y, Less, z], Less[x, y, z]]
>
> Out[104]= True
>
> or by using LogicalExpand (as you noticed below)
>
>> Oh, LogicalExpand[Inequality[x,Less,y,Less,z]] is x<y&&y<z
>> as is LogicalExpand[x<y<z].
>>
>>
>> Actually, you appear to be wrong, since
>> LogicalExpand[x<y<z]  and LogicalExpand[z>y>x]  are different.
> Again,
>
> In[107]:= Refine[x<  y<  z, z>  y>  x]
>
> Out[107]= True
>
> In[108]:= Refine[z>  y>  x, x<  y<  z]
>
> Out[108]= True

All you have to do is print out  LogicalExpand[x<y<z]  and 
LogicalExpand[z>y>x] to see that they are different.
That is the point of a canonical form.
You are asserting that "Refine" can be used.  Thus Refine, in the 
computer algebra terminology, is
a Zero Equivalence algorithm.   (or a Logical Tautology algorithm, in 
some sense).

> Actually, it would be good to have a function that checked both implications at once (Refine performs the job of ImpliesQ in older versions of Mathematica).
It would seem that something likeTautologyQ  could do that, but it assumes
that the components are Boolean, and not, as here, something like numbers.

Note that you can
do this, in Mathematica:

E1 = 0<foo[]<2
E2 = LogicalExpand[E1]
x=1
foo[]:=x++

E1 is True,  E2 is False.

Is it a bug?  Well, in the world of programming languages, the expression

(0< foo[]) && (foo[]<2)   is considered inefficient and maybe wrong because
of possible side effects,  especially   if what you  really mean is (in 
mathematica syntax...)

Module[{b=foo[]},   (0<b)&&(b<2)].

LogicalExpand and other things tend to fall apart when functions have 
side effects.
Computer science students are occasionally taught about such things for 
generating
code in compilation.

  If Mathematica were to be considered as (say) comparable to Lisp, and 
LogicalExpand
considered as some kind of optimization of code, then this would indeed 
be an error.
(Big if, there.)


>> You appear to be proposing some
>> kind of alternative to disjunctive normal form (or conjunctive normal
>> form), both of which are quite well studied. Re-grouping of logical
>> terms for logic synthesis is also quite well studied, (see circuit
>> minimization). The general circuit minimization problem is believed to be intractable. Apparently there are advantages to a computer science
>> education :)
> I am certainly not proposing this, as should have been quite clear from what I wrote.
It wasn't, at least to me.
> I had assumed, I admit mistakenly, that that was what you were proposing as it did not come to my mind that you were instead proposing a massive re-write of Mathematica that would, in effect, eliminate Greater, Less etc.
You are assuming I am proposing that someone should do a massive 
rewrite.  I am assuming that
this alternative view of comparison would be educational to you, other 
readers, and to WRI people
who may or may not have thought about it.  WRI would presumably decide 
whether this was
a good idea, and that would include consideration of how much of a 
rewrite it would be. And whether
it would be exposed to the user or not.   I suspect that defining 
Greater, Less, etc.
in terms of a single operator, Inequality   (or Comparison)  would be 
possible and advantageous,
but would possibly break existing programs that might refer explicitly 
to Less and Greater and ...

Note that the same philosophy Just as if WRI had included Divide, but 
only later decided to eliminate it in favor of
Times[ ..., Power[....,-1]]

I agree with the notion that it would be easier to adopt this strategy 
early on in the design of a system.
So sometime in the future someone may write another system in which 
Comparison takes the place
of  Less,Greater,LessEqual,GreaterEqual,Equal,Unequal,SameQ,unSameq, 
Equivalent,... ? any more??.
>   Thank you for confirming that the approach I thought you had proposed is intractable, as I had expected.
Well, I thought it was your approach. But maybe it was your 
misunderstanding of what I had written.
  It certainly wasn't mine. And I hope it wasn't what I wrote.

> I agree that there are some advantages to a computer science education - I do actually teach mathematics, and Mathematica,  to some excellent computer science students (among the best in the world).
> But I think there are even more advantages to a mathematics education.
I do not see these as mutually exclusive.
>   For one, one is less inclined to keep eternally circling the same basic issues rather than getting to some interesting problems.
To each his own.  I would hardly be one to deny you the opportunity to 
make snarky comments about
computer science research.

RJF


  • Prev by Date: Re: LessEqual vs Inequality, was ..Re: Replacement Rule with Sqrt in denominator
  • Next by Date: Re: How to create a notebook outside of Mathematica?
  • Previous by thread: Re: LessEqual vs Inequality, was ..Re: Replacement Rule with Sqrt in denominator
  • Next by thread: Re: LessEqual vs Inequality, was ..Re: Replacement Rule with Sqrt in denominator