The Math Forum

Search All of the Math Forum:

Views expressed in these public forums are not endorsed by NCTM or The Math Forum.

Math Forum » Discussions » sci.math.* » sci.math.symbolic

Notice: We are no longer accepting new posts, but the forums will continue to be readable.

Replies: 31   Last Post: Jan 12, 1998 9:12 AM

Advanced Search

Back to Topic List Back to Topic List Jump to Tree View Jump to Tree View   Messages: [ Previous | Next ]
Leon Granowitz

Posts: 16
Registered: 12/8/04
Posted: Dec 2, 1997 4:05 AM
  Click to see the message monospaced in plain text Plain Text   Click to reply to this topic Reply

Marc A. Murison wrote:
> Leon Granowitz wrote:

> > James Phillips wrote:
> > > My simple example of mathcad's weak symbolics is this bug, which has
> > > been present and repeatable since about v3: the conversion of -b+c
> > > into b+c when you select it from a-b+c ...
> > >

> > What's the problem with the a-b+c example? The minus in front of the b
> > is not the sign of b but the subtraction operator between a and b. Or
> > am I missing something?
> > --

> Syntactical elegance is in the eye of the parser, I suppose, but most people
> would probably consider a-b+c to be equivalent to a+(-b)+c. That is, the
> leaves of the expression tree contain a, -b, and c, and the two nodes both
> contain the operation "+". In Mathcad, selecting the subexpression -b+c in
> fact gives you b+c when you paste it in elsewhere, requiring you to manually
> reinsert the minus on b. This is *very* annoying, since it needlessly
> introduces nasty opportunities for user error. We already have too much to
> occupy our minds when in the midst of grunging through a tough problem -- the
> software should take care of silly bookkeeping such as this.
> But, for whatever (possibly valid) reasons, MathSoft refuses to get a clue.
> Over the years, it has been demonstrated over and over again that the
> programmers at MathSoft use at best toy algebra to test their interface, and
> that they don't understand at all the kinds of things that would make a
> symbolic manipulator's life easier. Silly problems like this get reported and
> are seemingly routinely ignored, as evidenced by their continued appearance in
> version after version. They really should consult with and *listen* to people
> who grind through real problems for a living, but they never seem to. A big
> part of the problem seems to be that, right or wrong, symbolics has a low
> priority at MathSoft. They have to allocate their finite resources as they see
> fit, but I sure do wish they'd spend some quality time on the symbolic
> interface.
> --
> Marc A. Murison
> Astronomical Applications Dept.
> U.S. Naval Observatory, Washington, D.C.
> Utinam logica falsa tuam philosophiam totam suffodiant!

O.K. already. I still think it's trivial. At least you see what it is
doing. By the way, I can't select b + c in version 6+, but I can in
version 7+.

Here's a more serious problem with Mathcad. It gives the answer 0 for
the indeterminate form 0/0 (even for a symbolic form such as f(x)/g(x)
at x = a where f(a) = g(a) = 0 and limit as x --> a of f(x)/g(x) is
non-zero). Because you may not realize that both the numerator and
denominator are zero you are not aware of the wrong answer. This
problem should be given a much higer priority than the one above. Oddly,
the solution is more than halfway there in Mathcad. Mathcad gives a
divide by zero error if the denominator is zero and the numerator is
non-zero. All they need to do is provide a indeterminate form message
instead of 0 when the numerator is also 0 (for numeric problems) and
make use of their limit function for the symbolic case.

Leon Granowitz |
Principal Engineer |
Raytheon | (617) 275-2665

Point your RSS reader here for a feed of the latest messages in this topic.

[Privacy Policy] [Terms of Use]

© The Math Forum at NCTM 1994-2018. All Rights Reserved.