Re: Interval[{a,b}]-Interval[{a,b}] = 0?
- To: mathgroup at smc.vnet.net
- Subject: [mg66722] Re: Interval[{a,b}]-Interval[{a,b}] = 0?
- From: "David W.Cantrell" <DWCantrell at sigmaxi.org>
- Date: Sat, 27 May 2006 21:03:39 -0400 (EDT)
- References: <e592g8$3am$1@smc.vnet.net>
- Sender: owner-wri-mathgroup at wolfram.com
Andrzej Kozlowski <akoz at mimuw.edu.pl> wrote:
> On 27 May 2006, at 07:27, David W. Cantrell wrote:
>
> > Concerning the fact that Interval[{a,b}]-Interval[{a,b}]=0 in
> > Mathematica, Andrzej Kozlowski wrote:
> >
> >> Note that in Mathematica you will get things like:
> >>
> >> In[8]:=
> >> "a dog" - "a dog"
> >>
> >> Out[8]=
> >> 0
> >>
> >> Now, one could also argue that this is a bug, since first of all
> >> subtraction of strings (or animals) is not defined
[snip of philosophy]
> > Apparently, Mathematica does have some "arithmetic" which it applies
> > to strings.
Note that I did _not_ say:
some arithmetic which is designed specifically for strings.
It does have some "arithmetic" (my quotation marks intended to convey
that I think of it as possibly being an arithmetic only in some loose
sense) which it applies to strings. And, as Andrzej points out well, to
many other sorts of things.
> > As further examples:
> >
> > In[4]:= "hgf" - "abcd"
> > Out[4]= -"abcd" + "hgf"
> >
> > In[5]:= "hgf" + "hgf"
> > Out[5]= 2*"hgf"
> >
> > In[6]:= 0*"DWC"
> > Out[6]= 0
> >
> > That doesn't disturb me. I might even applaud it if I knew of a use
> > for it.
> >
>
> There is no "arithmetic of strings" involved here at all.
Agreed. And I never thought that there was. Rather, it's more of an
"arithmetic of miscellaneous stuff", in which strings are part of that
broad miscellany.
> What you
> are seeing is only a consequence of the Orderless attribute of Plus,
> the canonical ordering of all Mathematica objects, and a few other
> facts. To see what I mean :
>
> 1 + "cat" + DisplayFunction
>
> "cat" + DisplayFunction + 1
>
> 0*HoldAll
>
> 0
>
> Expand[(Sin[x] + dog + DisplayFunction)*(1 + "cat")]
>
> "cat"*DisplayFunction + DisplayFunction + "cat"*dog + dog + "cat"*Sin
> [x] + Sin[x]
>
> It is probably possible to view Mathematica as something like a
> commutative algebra generated by all well formed expressions,
> including symbols, strings, names of functions, and so on, with
> certain relations. But certainly there is no kind of arithmetic of
> strings.
Right.
> >> and besides there is no reason to assume that the second dog is the
> >> same as the first one.
> >>
> >
> > As I said, no dogs are involved. And the first string is clearly the
> > same as the second.
> >
>
> Hmm.. you seem to be in a rather unhumorous mood today...
Not really. I'm just more of a "cat person" than a "dog person". :-)
> Do we really need these silly smileys ;-) ? Anyway, it is nothing to do
> with it being a string. You will get the same thing if you subtract
> any two symbols in Mathematica, which do not have any UpValues
> involving Plus defined.
>
> >
> >
> >> Unfortunately Mathematica is very simple minded and when it has
> >> no rules for dealing with some object you can always subtract it
> >> from itself and get 0
> >>
> >
> > I don't really mind that, when Mathematica has no rules for dealing
> > with some object, you can always subtract it from itself and get 0.
> > What I mind is that, since Mathematica implements interval arithmetic,
> > it has no correct rule for dealing with something as trivial as
> > Interval[{a,b}]-Interval[{a,b}]. After all, if one is going to claim to
> > have implemented an arithmetic specialized for a certain type of
> > object, then one should have already had the appropriate rules
> > implemented!
> >
>
> Mathematica does not implement interval arithmetic for symbolic
> endpoints.
You're absolutely right. Thanks for pointing that out! I'm astounded. Of
course, that means that my whole premise in my previous quoted paragraph
was garbage.
Here's how I went wrong:
Mathematica inplements interval arithmetic, I thought. Since I consider
CASs as being largely _symbolic_ manipulators, I assumed that interval
arithmetic was implemented for symbolic endpoints.
Once you pointed out that my assumption was wrong, I looked at the
documentation. All the examples involve intervals with endpoints which are
specific numbers. Nonetheless, I think my incorrect assumption was a
natural one. Therefore, until such a time as interval arithmetic for
symbolic endpoints is implemented, if ever, I think it would be good for
the documentation to be explicit in this regard, giving a disclaimer to the
effect that interval arithmetic for symbolic endpoints is not implemented.
Furthermore, until such a time, I wonder if it might not be better (less
likely to cause confusion, etc.) for Mathematica to give Indeterminate for
Interval[{a,b}]-Interval[{a,b}], rather than 0.
Now you might say: "Wait, David! I thought you didn't object to things like
0*"DWC" giving 0." Well, I still don't have any serious objection to that.
That comes under the category of "arithmetic of miscellaneous stuff". If we
did have an arithmetic designed specifically for strings, according to
which 0*"DWC" = 0 were incorrect, then of course I would object to 0*"DWC"
giving 0... But we _do_ have an arithmetic designed specifically for
intervals, according to which Interval[{a,b}]-Interval[{a,b}] = 0 is
incorrect. Until the symbolic version of that arithmetic is implemented in
Mathematica, I think that Indeterminate would be a much less confusing
result.
> In the same way Complex[a,b] is not a complex number in
> Mathematica, unless a and b are real numbers,
That doesn't surprise me. But suppose they _are_ real numbers:
In[5]:= Refine[Complex[a,b]+Complex[c,d],
Element[a,Reals]&&Element[b,Reals]&&Element[c,Reals]&&Element[d,Reals]]
Out[5]= Complex[a,b]+Complex[c,d]
It surprises me that I can't get Complex[a+c, b+d] or (a+c) + (b+d)I. But
I suppose I shouldn't be surprised; you probably meant "unless a and b
are _specific_ real numbers".
Of course, I'm not going to say that Complex[a,b]-Complex[a,b] should
perhaps give Indeterminate. Regardless of the reason it gives 0, there is
no potential confusion.
Regards,
David Cantrell