Equality check involving two expressions with sqrt fails
czert opened this issue · 8 comments
Comparing the following two expressions via the .eq method wrongly returns false:
nerdamer("(1/2)*sqrt(3)").eq(nerdamer("(3/2)*sqrt(3)^(-1)"))When evaluated, these expressions return 1460609278594243300/1686566320354503200 and 50843527/58709048, respectively. Close, but not equal.
I assume this comes down to the simplification engine not being able to move the square root from the denominator to the numerator. How hard do you think it would be to improve the simplification heuristics for cases like these? Could you maybe give me some pointers where I should try and start hacking on this myself?
Alternatively, how far along is the SymType project? Any chance that making this work will already be simpler there? All I really need is simplification of convoluted expressions containing only numbers, addition, multiplication and square roots.
In any case, this fork is already miles better than the original nerdamer at simplifying expressions involving square roots. Thanks for taking the project under your wing.
Hi, thanks for the issue. Yes, I have a work item to try to simplify "sqrt(a)/sqrt(a^2)" to "1/sqrt(a)" and similar. The simplify() function is finicky. I can look at this case in the next few days and let you know how hard I think it will be. If you want to take a look already, see what I did with logSimp and imagine something similar for fracSimp. Remind me to look at this if you don't hear from me, it is the most important Nerdamer issue on my plate. Don't wait for SympType ;-) Thanks!
Hi, thanks for taking the time to look at this issue.
There's no rush, as it turned out that even powerful simplifications won't help me much in what I'm trying to achieve.
Incidentally, I did try using algebrite as well and it seemed much more powerful when it comes to convoluted expressions involving even powers and roots, but also slower by orders of magnitude. I guess that trade-off is always going to be there. Might be worth taking a look at their simplification heuristics, though.
Ok. I have already written the initial code - while CI runs on my "day job". Would love to see some example expressions it can't deal with. The problem with the current simplify code is that it is too simplistic - it clearly started out as "we'll try this, then that, then that ..." and then it added a small loop at the end and recursion in parts. It needs to be fully iterating until no further change is achieved.
Ooh, I wish I had kept my code before trying algebrite, then I would have examples aplenty. I'll give you instead a couple that even algebrite cannot simplify further:
When I try these out now, algebrite seems fine. These are results of simplification of much larger and more convoluted generated expressions, I guess it run out of time or operation count limit and just stopped here.
I have written and merged a first-level sqrt simplify optimization. It doesn't solve your issue (but one of mine). If you want to continue to try to use Nerdamer-prime for whatever you are doing, perhaps you will need to employ a strategy like we are using in together.math:
- try subtracting, simplifying and comparing to 0, if true, you are done
- try dividing the two terms and comparing to 1, return result
And, we always compare to within an epsilon we set that is not quite as ambitious as Nerdamer's 15 digits.
Given that nerdamer("(1/2)*sqrt(3)").divide(nerdamer("(3/2)*sqrt(3)^(-1)")).text() evaluates to 1, I am inclined to close this issue. Applying the heuristics I mentioned above for each .eq seems too expensive for the general case.
Cool, thanks! Sure, close this issue. I think I'll open another one some day, when I generate enough examples to test simplifying on.