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