Am 16.12.2014 um 01:52 schrieb Richard Fateman:

On Saturday, December 13, 2014 6:08:58 AM UTC-8, Joachim Durchholz wrote:

But that wasn't my point anyway. I was thinking about calculating for
all principal roots in parallel, and not choosing at all until it turns
out that some choice is inconsistent with other assumptions.

This would be, in my opinion, an excellent tactic.

The problem with it that it is prone to exponential blowup.
We'd want to exclude combinations as early as possible, but avoid checking for that more often than necessary (because that could slow SymPy to a crawl). I don't know of any algorithm to ensure that; I don't even know a coding strategy for arriving there.

You can do all kinds of things if you know what you are doing.
The CAS is supposed to do the right thing for people who don't know
what they are doing.

In practice, those people will need to know what the CAS is doing, and they need enouth math skills to properly interpret (and hopefully double-check) the answers, so I think that's not actually the case, not totally anyway. I see the advantage of a CAS in that it can do the clerical work, and quickly and without making silly mistakes.

True, I am assuming you met up with the quadratic formula.  In high school.

Heh. While my background is certainly not up to par with that of many others here (I'm more the program design type), I certainly know the standard results about multiple roots. (A few other areas of math as well, but none of that at the pro level.)

But in that formula you can switch the values +- and the formula
is still valid.

Not sure what you mean with that - switching the signs means I still
get
the same set of expressions.

That's why the formula works. switching the sign on sqrt just exchanges
the
roots.

The point now being...?

As long as you keep the formula together  (both roots)  it doesn't matter
which sign you pick.
However, if you separate them and ask which is (say) positive,  now it
matters.

Ah ok.
That's not what I'd do though, a set of assumptions can't be split up without changing its semantics, because you lose the AND resp. OR connector.

How many other formulas do you expect to fiddle with where that is
true?

Certainly not this one:    sqrt(y^2) = abs(y).

That could still be handled by doing case distinctions.

If you plot abs(y)  you get a V-shaped curve, with a singularity at 0.
neither square root of y^2 has such a plot.

Yeah, you need both plots.
And you need to match them with abs() using a case distinction. Which
happen to be the same as the one abs() is making (otherwise the equation
wouldn't hold).

huh?  abs(x) is not analytic.  It is really a bad idea to introduce such
functions
if they are not necessary.

Ah, I thought you meant the real-valued function because you used the word "graph".
True, for complex-valued functions things are different.

OTOH non-analytic functions are important, often because the domain is the real numbers where analytic isn't relevant, less often because the domain is complex numbers and really need that non-analytic function anyway (rare because for those situations one would probably use vectors instead of complex numbers, but then there might the odd problem where analyticness isn't a given and you still want that special multiplication rule).

perhaps that is why some people advise against learning
math from a physicist.

Heh. I can understand that sentiment.

(I think the same sentiment works for learning programming...)

Sure. You shouldn't learn programming from a mathematician, statistics expert, or (worst of them all) experimental physicists. Well, at least that's common wisdom. In practice, I doubt that the data masses gathered at sites like CERN could be handled by piling layers of throwaway code on each other. A more relevant caveat against learning programming from nonprogrammers is that the list of things you learn is usually tailored towards the field of application, and too narrow to become a good programmer outside of that field. Of course that isn't applicable if you're going to work just in that field.

Regards,
Jo

--
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/549070F3.1060400%40durchholz.org.
For more options, visit https://groups.google.com/d/optout.

Reply via email to