Re: LessEqual vs Inequality, was ..Re: Replacement Rule with Sqrt
- To: mathgroup at smc.vnet.net
- Subject: [mg114694] Re: LessEqual vs Inequality, was ..Re: Replacement Rule with Sqrt
- From: Richard Fateman <fateman at cs.berkeley.edu>
- Date: Mon, 13 Dec 2010 03:52:40 -0500 (EST)
- References: <ie2971$mqh$1@smc.vnet.net> <4D050013.8050105@cs.berkeley.edu> <928BCB32-AEF9-4D13-87E0-BDDACF1BF878@mimuw.edu.pl>
On 12/12/2010 9:34 AM, Andrzej Kozlowski wrote:
> 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]?
I did not propose to tie the user's hands in this way.
> Or should Less[2,x,3] always evaluate to Inequality[2,Less,x,Less,3]?
That would be my solution,. Is my solution. Indeed, Less[x,y] is
simplified to Inequality[x,Less,y]
> (In that case you would still have the same problem if, for some reason, you prevented evaluation).
If I prevented simplification/evaluation, I would presumably not expect
much of anything to work.
I can' t think of a reason.
> What about expressions such as
> x> 2&& x< 3? Should you now be allowed to enter them
sure. resulting in And [ Inequality[x,Greater,2], Inequality[x, Less,3]]
> and required always to enter Inequality[2, Less, x, Less, 3] instead?
no, of course not.
> Or should they always be converted to that form?
not necessarily.
> Even if that was feasible, what about its effect on performance?
Depending on the nature of the inequalities, a subset of the problems
can be simplified.
(e.g. linear, or even polynomials over the reals)
It would be a judgment call as to whether to try this by default, by
invoking Simplify or
invoking FullSimplify or setting some options. It might make an
interesting project,
but there is certainly a (huge) literature on this.
> Personally, your idea does not make much sense to me.
Odd, since you seem to have figured out how to make it work.
> I also don't understand however why you seem to consider a<b<=c as equivalent to a<b<c.
I don't.
> If you really think they are equivalent,
of course not.
> I don't think you will find many who agree with you. But then probably you meant something else.
No, if one applies a rule Less->Equal, that does not usually result in
an identity-preserving transformation.
> 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.
It's not a terrible solution if it solves the problem of canonical
simplifications of inequality constraints, which it might,
if computing (say) disjunctive normal form does the job. The description
of LogicalExpand, and the examples,
suggest that for the intended target domain it might not be canonical.
I don't have the patience to explore what
it really does, and since I have version 7.0, it might not even do the
same thing in version 8.0. So all I can say is
I think it doesn't solve the problem, but it might.
> 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).
No, I said that if a user (or many users) say that they would prefer a
different answer from the one that is
delivered by the software, (indeed the bold ones might call the answer a
bug) that is a factor in whether
something is indeed something should be changed (that is, should the
alleged bug be treated as
an actual bug and be fixed. ). There are other contributory factors in
determining whether something
should be fixed. (And I don't really distinguish between fixing a
"feature" and fixing a "bug" if it needs
to be fixed.)
> Do you mean any user
Well, in principle, any user can find (what I would consider) a bug.
Many user-reported "bugs" may not qualify, in
my judgment. But a bug tends to stand on its own feet, regardless of
who reports it.
> or many users
many users reporting the same bug would be more supportive, but not
determinative. As I have pointed out,
WRI does not operate on the principle of "the customer is always right".
> or perhaps just one very important user (Fields medal winner?)
I think that depends on whether he (or she) has found a bug. Maybe a
bug report from a famous person would
get faster attention from higher-up in the food chain at WRI. As I said
previously, I think this is some marketing
decision too. If there were some company that paid a large license fee
each year and the contact point for
that contract complained (and maybe threatened to cancel), then that
person can define a bug in any way
he (or she) wants.
> I had the impressions that bugs were things that were generally disliked by almost all users.
No, that would be great because you could then find all the bugs in a
system just by asking almost anyone.
In fact, most users are quite unaware of most bugs.
> 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".
I am not sure what your point is. Obviously if a particular user
identifies a particular behavior as a bug that can be
fixed, he/she would ordinarily prefer that it be fixed. I think that is
what you are saying.
As I said, most users don't even know of most bugs, so they have no
opinion about them. If they are given an example
of a situation in which Mathematica gives a subtlely wrong answer, they
might say, Oh, that looks fine.
But if they are shown why it is wrong, and what the right answer, they
might say "Oh, that would be better".
> So I get a distinct impression that, like Humpty Dumpty, you believe that words mean exactly what you want them to mean.
>
>
> Andrzej Kozlowski
>