+- HP Forums (https://www.hpmuseum.org/forum)
+-- Forum: HP Calculators (and very old HP Computers) (/forum-3.html)
+--- Forum: HP Prime (/forum-5.html)
+--- Thread: when tcollect goes (sorta) buggy.... (/thread-5360.html)
when tcollect goes (sorta) buggy.... - quinyu - 12-19-2015 12:06 AM
In differentiating the expression
(x^2)*sin(x)^4+x*(cos(x))^(-2)
the first response is essentially equivalent to the answer known to be the shortest to me:
4(x^2)*sin(x)^3*cos(x)+2x*sin(x)^4+2x*sin(x)*cos(x)^(-3)+cos(x)^(-2). The HP Prime result has a fraction, with denominator being cos(x)^3, as to prevent the negative powers of trigonometric functions in the numerator.
But then, on using tcollect(Ans) (which usually helps tidying trigonometric expressions), the result gets much worse, sprinkled with square roots, absolute values, sign functions etc. When asked to simplify, the calculator just gets stuck (I gave it 15 minutes and couldn't finish.) Either way, when tcollect cannot make an expression tidier, it should just return the original... or at least, provide an option for it to influence this behavior.
RE: when tcollect goes (sorta) buggy.... - parisse - 12-19-2015 07:08 AM
It is unfortunately impossible to predict the time that will be required to perform simplifications, and the Prime OS can currently not catch exceptions, making interruptions by ON difficult to propagate.
As for tcollect, it just does what it should, that is collect cos and sin of the same angle in one trigonometric function by the rule a*cos(theta)+b*sin(theta)=sqrt(a^2+b^2)*cos(theta-theta0)
You can avoid some sign and absolute values by making assumptions on x. But even with an assumption, calling tcollect is not a good idea here, as one can see just looking at the answer. And calling simplify on such an ugly answer is certainly not a good idea!
RE: when tcollect goes (sorta) buggy.... - quinyu - 12-19-2015 09:50 AM
Either way, thank you for your answer, Dr. Parisse - I don't know if I shouldn't just report these things directly to you in the end. Or whether they are of real value (please advise on this.) Or if I'm just being a nuisance with these reports.
I do like to fool around with the calculators (Prime and 50G) and indeed the CAS system is very powerful, but on occasions, I feel that the same power is very hard to control by the user (such as with the example above). I know that many times even very massive systems such as Matlab and its kind go very wrong, due to the very same reasons. But they are algorithms, doing what they were supposed to do, and indeed CAS systems aren't very good with guessing what the user might want
that latter would be a very different field altogether.Personally, I dislike the "unify everything with a common denominator" approach that is present in many of these systems... but that is just personal preference. I'd use a separate command for to find common denominators. But then again, many people are probably used to the way how it works now.
PS: I am uncertain of the title. I apologise if I got it wrong.
RE: when tcollect goes (sorta) buggy.... - parisse - 12-19-2015 11:35 AM
There is indeed a learning curve to control a CAS. The main reason is that there is most of the time no algorithm that will return in all cases what the user expect, for example for simplification, and the complexity of computations explodes very quickly.
I'm interested in experiences like those you report, they give me indications where I should put some safeguards if it is possible : I'll do that for simplify((sin(x-sin(x))')
RE: when tcollect goes (sorta) buggy.... - quinyu - 12-20-2015 02:41 PM
Perhaps one of the (agreed, very rudimentary) metrics that could be used to test if something is simpler after simplify() is to run a count on the operators (unary as well as binary etc. but don't count parentheses). If the result of simplify() has more operators then it didn't get simpler.
I am sure one could fine-tune this, but that would be much up to personal preferences (I would count a complex number on its own as an addition and a multiplication - addition of the imaginary part to the real part, and the imaginary part containing a multiplication with i... because I don't like to see many i's there, if I can avoid them. But that's just my way.) Either way, I'm certain that simply counting the operators is a relatively straightforward operation for any algebraic expression in most if not all CAS systems.
-----------
For an example I have just found: the derivative of sin(cos(2x-5)). The returned expression is actually the simplest that I know of, on the HP Prime. Clicking [ simplif ] or using tsimplify() however turns it into a considerably more complicated form. Same if you process the expression (cos(5*sin(x/3)))'. Good derivative, then nightmarish "simplify."
RE: when tcollect goes (sorta) buggy.... - parisse - 12-21-2015 07:23 AM
I have added a count before/after the algorithm is called, but this has side-effects, for example should simplify(sin(5x)/sin(x)) be left as is or be simplified as a polynomial in cos(x)? Comparing the count before and after would mean we leave sin(5x)/sin(x) as is, but I prefer the cos polynomial (and I think most users would). The current patch I did will add a coefficient before comparing, the limit being sin(10x)/sin(x) but this has a drawback: it is inconsistent.
I do not want to make things too inconsistent or to remove the power of simplify for expressions that should be simplified, just because some users are hitting blindly the simplify soft key. The solution is perhaps to remove the softkey and remove the maximum simplification level in the CAS settings if the users behavior can not be changed.
RE: when tcollect goes (sorta) buggy.... - quinyu - 12-21-2015 08:44 AM
In fact, the likely best solution would be an application similar to 50g's EQW, allowing selection of subexpressions and manipulate only those; or perhaps an interactive simplify/manipulate app where you could go step-by-step, and optionally influence how the next step is handled (in a pop-up menu or dynamic soft menu, perhaps.)
This, seeing that the Prime is aimed mainly at students (from what I hear), would have a multitude of benefits, first of which that they'd actually understand what's going on, also be able to choose the rewrites they are familiar with.
Then, for the transforms, I would leave the option to use the "nasty" trigonometric functions also accessible. "Nasty" meaning the cotangent, the secant and the cosecant - in many CAS systems they're much underused. I know there are other trigonometric functions (versine and its relatives, or the chord function) that many people did not even hear about; I'd not include those since likely the teachers would also get dumbfounded on them (even if they can produce very compact formulae, and in specialist fields, such as navigation, they are still used.)
But either way, thank you for any effort put into this - I am sure many users will welcome whatever improvements or changes they will receive in this bit of the calculator.