Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Doing Symbolic Math with SymPy

lwn.net

Post reply on HN
Print view View original

51–60 of 81 posts

Re: Doing Symbolic Math with SymPy

#51

Post by mehrdadn »

BeetleB wrote: post #50
mehrdadn wrote: post #49

Earlier quoted context omitted.

Yeah. For what it's worth (not sure if it makes you feel better or worse...) I've found similarly bad bugs in SciPy too.

Curious what those were.

Here's the one I can find (might not have reported/written others so I don't recall them): https://github.com/scipy/scipy/issues/7332

I can't tell if I'm just exceptionally good at making bugs explode in my face or something, but these are so simple that it boggles my mind when I'm the first person to report them...

Re: Doing Symbolic Math with SymPy

#52

Post by [deleted] »

BeetleB wrote: post #48
mehrdadn wrote: post #16

The trouble with SymPy is it's, well, buggy. I tried it a few years ago, and as soon as I got serious, I quite quickly ran into problems that I reported, some of which I now see they apparently still haven't gotten around to addressing. [1] [2] Symbolic math is hard ; they have my sympathies. I don't think I could do better. But as long as bugs like these exist, it's going to be hard to convince people to switch away…

Yikes those are bad. As a non-user interested in it, I must confess that seeing those issues (especially the 2nd one) makes me not want to use it! I do get that it is a hard problem, but I would then recommend they not have an option for "real" if they can't get it right. Users will expect it to work (unless the docs point out it is unreliable).

[deleted]

Re: Doing Symbolic Math with SymPy

#53

Post by blt »

creata wrote: post #25
leephillips wrote: post #18

Earlier quoted context omitted.

This is problem I have with Python in general; that even if you prefer to use it in a functional style, most libraries are written by real Python programmers, and using them will force you to grapple with the object-oriented inversion of common sense ( https://lee-phillips.org/pythonhate/ ). My favorite example is: ','.join(['a', 'b'])

What's wrong with (','.join(['a', 'b']))? If it's the order of arguments, then I want to point out that the order has two big advantages: * partial application is actually useful: I've actually used (','.join) before, but (lambda sep: sep.join(['a', 'b'])) seems relatively useless. That's why Haskell also uses this order with (intercalate sep listOfStrings). * it accepts any iterable, rather than just lists.

OOP interface is wrong for this functionality. It should be a free function. There is no reason it should be restricted to strings -- "join" makes sense on any sequence-like objects. We should be able to join(Iter1, Iter2[Iter3]) where Iter* are all arbitrary iterable data types.

Re: Doing Symbolic Math with SymPy

#54

Post by ogogmad »

BeetleB wrote: post #48
mehrdadn wrote: post #16

The trouble with SymPy is it's, well, buggy. I tried it a few years ago, and as soon as I got serious, I quite quickly ran into problems that I reported, some of which I now see they apparently still haven't gotten around to addressing. [1] [2] Symbolic math is hard ; they have my sympathies. I don't think I could do better. But as long as bugs like these exist, it's going to be hard to convince people to switch away…

Yikes those are bad. As a non-user interested in it, I must confess that seeing those issues (especially the 2nd one) makes me not want to use it! I do get that it is a hard problem, but I would then recommend they not have an option for "real" if they can't get it right. Users will expect it to work (unless the docs point out it is unreliable).

> I would then recommend they not have an option for "real" if they can't get it right. Users will expect it to work (unless the docs point out it is unreliable).

You should be suspicious of using floats and expecting the solver to detect if a solution is real. Consider the polynomial $x^2 + C$ for $C \approx 0$. Are all of its roots real or complex? The problem is that even a very small change in C, maybe caused by rounding errors, can easily change a root from real to not real.

When solving polynomials, either use complex numbers throughout or insist on exact solutions and don't use floats.

Re: Doing Symbolic Math with SymPy

#55

Post by BeetleB »

mehrdadn wrote: post #51
BeetleB wrote: post #50

Earlier quoted context omitted.

Curious what those were.

Here's the one I can find (might not have reported/written others so I don't recall them): https://github.com/scipy/scipy/issues/7332 I can't tell if I'm just exceptionally good at making bugs explode in my face or something, but these are so simple that it boggles my mind when I'm the first person to report them...

That one seems a bit more reasonable, though. When doing numerical computation (as opposed to symbolic), you should never assume the algorithm "just works". You need to know the quirks of the underlying method, etc. And I believe most root finding numerical algorithms will be sensitive to the initial guess.

Surprised they haven't added the warning and closed the bug.

Re: Doing Symbolic Math with SymPy

#56

Post by bee_rider »

mehrdadn wrote: post #16

The trouble with SymPy is it's, well, buggy. I tried it a few years ago, and as soon as I got serious, I quite quickly ran into problems that I reported, some of which I now see they apparently still haven't gotten around to addressing. [1] [2] Symbolic math is hard ; they have my sympathies. I don't think I could do better. But as long as bugs like these exist, it's going to be hard to convince people to switch away…

Have you tried out SageMath? It seemed to work pretty well when I tried it out, but I never got serious really. My needs for symbolic math programming are pretty limited.

Re: Doing Symbolic Math with SymPy

#57

Post by fractionalhare »

mehrdadn wrote: post #51
BeetleB wrote: post #50

Earlier quoted context omitted.

Curious what those were.

Here's the one I can find (might not have reported/written others so I don't recall them): https://github.com/scipy/scipy/issues/7332 I can't tell if I'm just exceptionally good at making bugs explode in my face or something, but these are so simple that it boggles my mind when I'm the first person to report them...

That's not really a bug, it's just behavior explained by numerical analysis. A very small change in the initial guess can be the difference between success and a blowup for numerical algorithms; particularly rootfinding algorithms.

Sometimes this is implementation specific, and is numerical instability. Sometimes this is endemic to the algorithm regardless of implementation, like Runge's phenomenon. Often there is no fix, or the fix would be inordinately complicated or only generalize poorly, etc.

In this situation scipy should probably just pop a warning.

Re: Doing Symbolic Math with SymPy

#58

Post by mehrdadn »

BeetleB wrote: post #55
mehrdadn wrote: post #51

Earlier quoted context omitted.

Here's the one I can find (might not have reported/written others so I don't recall them): https://github.com/scipy/scipy/issues/7332 I can't tell if I'm just exceptionally good at making bugs explode in my face or something, but these are so simple that it boggles my mind when I'm the first person to report them...

That one seems a bit more reasonable, though. When doing numerical computation (as opposed to symbolic), you should never assume the algorithm "just works". You need to know the quirks of the underlying method, etc. And I believe most root finding numerical algorithms will be sensitive to the initial guess. Surprised they haven't added the warning and closed the bug.

Not at all. I've worked on numerical stuff myself; unlike the symbolic bugs, I have little sympathy for these particular numerical errors. It would be far more reasonable if it was convoluted composition of functions, or some kind of bizarre numerical edge case. However:

(a) Univariate quadratics are extremely well-understood and extremely important. For example, the convergences of optimization algorithms (this is root-finding, and there are some differences, but they're not unrelated, and this is beside my point) are often proven on quadratics first, and then they're applied to other functions.

(b) (x - 1)^2 - 1 is just about the simplest quadratic you can possibly imagine that isn't outright lacking in other terms (like x^2), and quadratics are pretty much the simplest nonlinear functions.

(c) No matter how good or bad your algorithm is, it is absolutely trivial to do a few quick tests afterward to sanity-check the result, and to return some kind of error if it looks wrong.

This isn't some kind of quibbling over a solver that has an error of 0.0001 or something. We're feeding in the most basic quadratic you can imagine, and the solver is telling you with confidence that the solution is 1.01 when in fact it's supposed to be 2. It's just inexcusable. At the very least (and even this would honestly still be woefully lacking), it should be able to do the dumbest thing possible, which is to plug that back in, and maybe plug in a couple close numbers (maybe +/- some epsilon) and see if results change sign or land anywhere near zero. In reality there are all kinds of tests they could and should be doing to check things like concavity and switch to better algorithms, but that's kind of moot when they're not doing the most basic check.

Edit: Actually I could probably say something similar about one of the SymPy bugs too (they really shouldn't have trouble telling if 0.66 + 0.56I is a real number), but one key difference is at least their problem is in filtering out correct solutions, not in returning completely wrong solutions with full confidence.

Re: Doing Symbolic Math with SymPy

#59

Post by adenozine »

stochastician wrote: post #12

I want to encourage people to think of sympy not just as a competitor to Mathematica but additionally as an incredibly valuable library that can be used _inside_ of other projects. Sometimes, you just want to compute an antiderivative, or you want user-supplied functions that you can manipulate easily, or you want to do some actual algebra. Think of it less as a Mathematica replacement (like "Linux on the Desktop") a…

This may be a stretch, but can you point to any examples or articles about using SymPy outside of a strictly mathematical context?

Re: Doing Symbolic Math with SymPy

#60

Post by mehrdadn »

fractionalhare wrote: post #57
mehrdadn wrote: post #51

Earlier quoted context omitted.

Here's the one I can find (might not have reported/written others so I don't recall them): https://github.com/scipy/scipy/issues/7332 I can't tell if I'm just exceptionally good at making bugs explode in my face or something, but these are so simple that it boggles my mind when I'm the first person to report them...

That's not really a bug, it's just behavior explained by numerical analysis. A very small change in the initial guess can be the difference between success and a blowup for numerical algorithms; particularly rootfinding algorithms. Sometimes this is implementation specific, and is numerical instability. Sometimes this is endemic to the algorithm regardless of implementation, like Runge's phenomenon. Often there is no…

I know how numerical stuff works, but no, this is pretty inexcusable. See my other comment: https://news.ycombinator.com/item?id=25689916
Post reply on HN