Timeline for Why is Mathematica's expansion of expressions with square roots so slow?
Current License: CC BY-SA 3.0
13 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 31, 2013 at 10:46 | vote | accept | matrix42 | ||
| Jan 25, 2013 at 10:38 | comment | added | jVincent | @AlbertRetey I updated the timing. And indeed, I would expect that Maple is just doing it iteratively while Mathematica evaluates each possible sequence. I expect it's a case where complexity analysis dictates the suboptimal algorithm for this case. I think the Maple style expansion will worst case get 5^O(n) terms that can then be collected, while Mathematica already has all the trival terms collected, and therefore only evaluates around 5000 terms. However, since the iterative approach can quite effectively reduce the number of terms, it's nowhere near the upper limit for this example. | |
| Jan 25, 2013 at 10:31 | history | edited | jVincent | CC BY-SA 3.0 | added 3 characters in body |
| Jan 25, 2013 at 10:28 | comment | added | Albert Retey | @jVincent: final remark: unless your computer is more the 10 times faster than mine the timing seems to still reflect the non-expanding case. For me the timings with version 9 are about 105 sec. for the naive Expand and about 0.15 sec. for the Nest case, results checked to be the same. I guess that the Nest timing is in the same order of magnitude as what maple will do with the naive input... | |
| Jan 25, 2013 at 10:22 | history | edited | jVincent | CC BY-SA 3.0 | deleted 1 characters in body |
| Jan 25, 2013 at 10:06 | comment | added | Albert Retey | @jVincent: actually I don't care what we call it, fact is that the most straightforward input does in this case perform very poor, and for some reason maple handles that case better internally. It could of course have deeper reasons that Mathematica does the expansion the way it does and even considered to be a feature, e.g. to avoid accumulation of numeric errors -- but whatever these reasons are they don't matter for this case which thus could be improved. By the way, I think the precedence of // and & is still not correct in your answer (sometimes FullForm has its advantages :-) | |
| Jan 25, 2013 at 9:54 | comment | added | jVincent | @AlbertRetey I wouldn't call it a workaround. They are two different methods of achieving the same result, and in this case one is faster. I would wonder however if anyone knows if there are arguments for using Mathematica's rather than iterating. Perhaps it's due to elements of Expand's other functionality. | |
| Jan 25, 2013 at 9:50 | history | edited | jVincent | CC BY-SA 3.0 | added 2 characters in body |
| Jan 25, 2013 at 9:45 | comment | added | Albert Retey | @jVincent: Your workaround hits the point and actually seems to work very well. But you have some errors there which you might want to correct, it should rather be Nest[Expand[#*term] &, term, 100 - 1]. Then the results can be checked to be the same (I only checked for 50, not 100). | |
| Jan 25, 2013 at 8:48 | history | edited | jVincent | CC BY-SA 3.0 | added 285 characters in body |
| Jan 25, 2013 at 8:40 | history | edited | jVincent | CC BY-SA 3.0 | added 397 characters in body |
| Jan 25, 2013 at 8:29 | comment | added | matrix42 | No, Maple also gives the exact result. | |
| Jan 25, 2013 at 8:23 | history | answered | jVincent | CC BY-SA 3.0 |