Re: Matlab -- Venting, Plus Miscellaneous Questions



My example was wrong...


Actually, I found this mail....



the bug report to Mathworks was this...
...........
version 6.5 student version. Try

x=34
simplify(x)
simplify(x+sym(0))
simplify(pi+sym(0))
pi

Do you want this behavior?

...........
[I didn't write down the results here, but as I recall,
all the lines but the first and last are Matlab errors.
simplify(pi+sym(0)) gives pi, but pi gives 3.14159....

(The response was, this is not a bug, and I guess that Steven
Lord is (a) confirming this, but (b) providing a way to add
this feature anyway. )



Steven Lord wrote:

.......
>
>
> I checked our records. The problem you reported was basically that
> something like "simplify(34)" did not call the Symbolic SIMPLIFY function
> that is only defined for symbolic objects. This is because 34 is not a
> symbolic object -- it is a double array and MATLAB treats it as such until
> you explicitly convert it to something else. Either "simplify(sym(34))" or
> "simplify(34+sym(0))" would work by converting the expression inside the
> SIMPLIFY call into a symbolic object, then calling the symbolic SIMPLIFY
> function on it.

This still seems to me to be a bug. Any number it seems to me should be
a special case of a symbol.
>
> There is a problem with doing an "automatic cast" type of operation on 34 in
> a situation like this, which is what I gather you were expecting.

Yes.

> Currently, SIMPLIFY is only defined for symbolic objects. What if someone
> else creates a class (say a polynomial class) and implements the SIMPLIFY
> function for that class?

A special symbolic simplification for a 1X1 (scalar) number? I think
that if you have a polynomial class, then you should be able to overload
+ so that it can add a polynomial to an (appropriate) sym, even if it is
sym(34). But that would break other things if you overloaded *.

MATLAB would no longer be able to do the
> "automatic cast" to symbolic -- it would have to guess whether you wanted 34
> to be a symbolic object or 34 to be an object of that other class. Now it's
> likely that in some cases MATLAB would guess correctly ... and in some cases
> it wouldn't.

There should be no guessing. It is, I guess, part of Matlab's lore that
something like [3 4] could be your way of representing (x=3,y=4), or
3+4*x, or 3+4*i, or March 4, 2004, or ... and there is no way of
telling because there is no tag associated with the array. This is, I
think, a fundamental problem for "compound objects" all of which look
the same. But that's a digression here..

It seems to me that the casting of 34 to sym(34) in the context
simplify(34) is pretty unambiguous. If there is ANOTHER cast possible,
say to the polynomial 34*x^0+0*x^1+0*x^2+.... then one would also have
to cast simplify(sym(x)) to 0*x^0+1*x^1+ ... and thereby break many
other things. You would also need to overload +, *, etc for polys, but
they look like arrays.. Or maybe I'm misunderstanding your problem.

Basically,
Matlab treats symbolic stuff as a peculiar and special case niche within
a numerical system. A more appropriate view, and one which does NOT
necessarily lead to inefficiency, given that Matlab's top level is
interpreted and array-based is to view everything as symbolic, and
numeric as a special case. From this perspective, ANYTHING should be
acceptable to the simplify() function. It is certainly my perspective.
I would hope simplify( array) would map sym over every element, if
necessary.

>
> If you want this to work, there is a way to do it ... but be aware of the
> problem I listed above. Create a directory, @sym, inside a directory on
> your MATLAB path. The @sym directory should not be on your path, just its
> parent. Put the following function inside that directory as simplify.m:
>
> function y=simplify(x)
> y = simplify(sym(x));
>
This suggestion was not offered when I reported the bug. I would have
immediately used it, and I suggest you add it to your documentation.
I will certainly suggest it to anyone I know using Matlab.
>
.....
>
>
> The example with EZPLOT was simply intended to show that MATLAB could not
> only manipulate symbolic objects but could also display them graphically.

But now you admit that Matlab can't simplify the sum of
a symbolic object and a number and somehow this is a feature!

Matlab is popular here for numerics, but when someone says it is like
Maple, etc. the superficial similarity is "it is interactive" and
it is distinct from "C,C++, Java" where programs are composed in an
editor and run through a compiler/loader/etc.

It is like asking "which is better: budweiser, coors, or coke?" not
noticing that two of them are alcoholic, can't be sold to minors, and in
large enough quantity can get you drunk.

Thanks for the explanation and solution.
RJF




>

.

Quantcast