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: [mg114685] Re: LessEqual vs Inequality, was ..Re: Replacement Rule with Sqrt in denominator
  • From: Andrzej Kozlowski <akoz at mimuw.edu.pl>
  • Date: Mon, 13 Dec 2010 03:51:00 -0500 (EST)
  • References: <ie2971$mqh$1@smc.vnet.net> <4D050013.8050105@cs.berkeley.edu>

On 12 Dec 2010, at 18:02, Richard Fateman wrote:

> On 12/12/2010 2:46 AM, Andrzej Kozlowski wrote:
>> On 11 Dec 2010, at 07:52, Jack L Goldberg 1 wrote:
>>
>>>
>>> a)  Input as typed:  2<==x<==4.  Look at its fullform.  On my Mac
>>> running ver. 7 of Mathematica, I get returned,
>>>                    LessEqual[2,x,4].
>>>
>>> b)  Now type in Reduce[2<==x<==4].  You will get
>>> Inequality[2,LessEqual,x,LessEqual,4].
>>>
>>> These are are different expressions!  How can one program replacement
>>> rules when one can not be sure of the FullForm?  These structures are
>>> entirely different.  Which fullform can one assume is the one Mathematica sees
>>> in some complicated module wherein one step is a replacement rule?
>>>
>>> Jack Goldberg
>>> Mathematics
>>> University of Michigan
>>>
>>
>> O.K. but I don't see anything here that in any way contradicts anything that
>
>> has been said about the need for
>> for looking at FullForm before trying pattern matching. Actually, it is als
>> o an argument against using Copy and Paste. To see that, evaluate
>
>> Reduce[2<==x<==4]. Now, copy the output and paste it into another cell
>
>> and wrap FullForm around it, then evaluate. You will get  LessEqual[2,x,4].
>>
>> I don't see this as a problem, do you? You can certainly match both forms
>
>> with a single pattern:
>>
>>  {2<== x<== 4, Reduce[2<== x<== 4]} /.
>>    (a_)<== x<== (b_) |  Inequality[a_, LessEqual, x, LessEqual, b_] :>  {a, b}
>>
>> {{2, 4}, {2, 4}}
>>
>
> I find it remarkable that you can claim this is a solution.  First of all, the original poster said that he was taken by surprise that there
> are two rather simple expressions where both are simplified, and which print the same, and both have the same meaning, but don't
> match.  Your response is to write a pattern that matches them both by including each as a separate pattern.
>
> This is a bug, in my opinion. And there is a way around it, which is to
> always parse an inequality or equality of more than 2 arguments as
> inequality. e.g.  a==b==c  is Inequality(a,Equal,b,Equal,c).  I recall doing this when I implemented my parser in Mockmma.
>
> Note that one can
> construct such things in Mathematica, e.g.
> a<b<=c  /. LessEqual-> Less
> which has FullForm Inequality[a,Less,b,Less,c].
>
> But if you type it in as a<b<c, it is Less[a,b,c].
> So you have two items whose 'difference' does not simplify to zero,
> and which is not simplified by FullSimplify[] to zero.
>
> (parenthetically,  (3<4) - (5<6) DOES simplify to zero.  )
>
> I would be surprised to find other people so accepting of this "solution".
>
> RJF
>

Do you mean a user should not be allowed to enter Less[2,x,3] but always required to use the form Inequality[2,Less,x,Less,3]? Or should Less[2,x,3] always evaluate to Inequality[2,Less,x,Less,3]? (In that case you would still have the same problem if, for some reason, you prevented evaluation). What about expressions such as
x > 2 && x < 3? Should you now be allowed to enter them and required always to enter Inequality[2, Less, x, Less, 3] instead? Or should they always be converted to that form? Even if that was feasible, what about its effect on performance?

Personally, your idea does not make much sense to me.

I also don't understand however why you seem to consider a<b<c as  equivalent to a<b<c. If you really think they are equivalent, I don't  think you will find many who agree with you. But then probably you meant  something else.

There is, by the way, another "solution", that I am sure you will also not like (so I am mentioning it only for general information). One can always get rid of all "Inequalities" in an expression expr by means of the pattern:

expr/.y__Inequality :> LogicalExpand[y]

Once you do that, all inequalities in the expr will involve (conjunctions ) of Less, LessEqual etc, and can be matched without any ambiguity.

By the way, I see that in another thread you argued that a bug is anything that a user dislikes (maybe I am misrepresenting you again but if so you make it terribly easy). Do you mean any user or many users or perhaps just one very important user (Fields medal winner?)  I had the impressions that bugs were things that were generally disliked by almost all users. I honestly don't know of any "bug" in ordinary sense of the word about which most or even a significant  number of users would say "I like it just fine the way it is now". So I get a distinct impression that, like Humpty Dumpty, you believe that words mean exactly what you want them to mean.

Andrzej Kozlowski



  • Prev by Date: Re: Replacement Rule with Sqrt in denominator
  • Next by Date: Re: Replacement Rule with Sqrt in denominator. Also Bug in Series
  • 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