CAS simplifying non-zero expressions to 0

[kickniko]

Working with a rather lengthy rational quotient of polynomials with numeric coefficients I just encountered a problem in the CAS. Simplifying the quotient just wiped out powers with small coefficients. I didn't even notice that at first, since the disappearing powers were way off screen to the right. It was only afterwards (after two hours work!), trying a plot of the simplified expression, when I saw that something probably went astray, since the behavior of the plot for big values of X was completely wrong. (It should fall with growing X but it was rising.) So the whole work inbetween was in vain.

Searching for the reason of this behavior I tried to simplify one of the powers in the denominator of the original expression using:

simplify(6.0929985e-32*Cvar^2*Omega^8)

The result was 0. (Omega denotes the capital greek letter omega here.) There is nothing stored in variables Cvar and Omega.

I tried tinkering around with epsilon (down to 1e-200) and it did not help.

Then I tried

exact(6.0929985e-32*Cvar^2*Omega^8)

and it returned

0*Cvar^2*Omega^8

Even exact(6.0929985e-32) returns 0, no matter of epsilon and/or Exact/Approx setting of the CAS.

So it seems that simplify tries first to "exactify" the numeric coeffs, which just returns 0 for small numbers that do not fit its plan? Is this is the reason for simplifying the non-zero sub-expressions to 0?

Anyway, expanding the expression worked OK and all powers remained intact. (This is important since Omega is of order of 10^6 and more here.)

So, is it better to not use simplify when small but still important floats are involved? Are there any other similar caveats that we should be aware of?

Ciao,

Nick

P.S.: Bummer! Unfortunately even expanding does not do my job since it returns an expression which looks right, but with which I cannot do anything anymore. Whatever I try to do with that I get a syntax error. Just tried to substitute X for Omega in order to plot it, and it complains about syntax. Same behavior when I just try to copy the result of expand into the command line. So, what do I do?

[Nigel (UK)]

I've noticed this before. As a physicist small numbers are a completely normal part of my work and are not an indication of rounding error. I find this behaviour a real obstacle to whole-heartedly embracing the Prime in my teaching and to recommending it to my physics students. To work around it, you can replace approximate numbers by exact numbers (e.g., write 663/100 * 10^{-34} for Planck's constant) or use symbols that you then substitute numerical values for at the end of a calculation, but neither approach is anywhere near convenient in all circumstances.

I would really like to see this truncation of small quantities as an optional function to be applied when and if I choose to do so (like Chop[] in Mathematica, if my memory serves me correctly). I think it is no more logical to replace small numbers by zero by default than it is to replace numbers greater than three by the string "many"!

Sorry to be unhelpful.

Nigel (UK)

[parisse]

When I learned physics, I was always told not to use numbers in equations, but always symbols, and replace them only at the end (when all computations are done) by their numeric values. If you follow this rule, you will never have these kind of problems with CAS instructions like simplify, expand, etc.
A CAS can not work properly with approx data, it has to replace them by exact data, and it can not guess if 1e-34 or any other value is near 0 because of the dimension of the quantity (I mean unit choice, since dimensionless number are rarely close to 0) and should not be replaced by 0 (but should be replaced by a nonzero symbolic constant), or if it's a rounding error and should be replaced by 0.

[kickniko]

Hi Nigel,

and thanks for being helpfully unhelpful!

(10-06-2014 11:08 AM)Nigel (UK) Wrote:  I've noticed this before. As a physicist small numbers are a completely normal part of my work and are not an indication of rounding error. I find this behaviour a real obstacle to whole-heartedly embracing the Prime in my teaching and to recommending it to my physics students.

Same with me, more or less, Nigel. Since some days I try to finish the design of an HF-amp stage for my business, and small floats are a completely normal part of the job. It may be "only" a coefficient of 6.0929985e-32 for Omega^8, but Omega runs up to 10^6 (and so f even more).

(10-06-2014 11:08 AM)Nigel (UK) Wrote:  To work around it, you can replace approximate numbers by exact numbers (e.g., write 663/100 * 10^{-34} for Planck's constant) or use symbols that you then substitute numerical values for at the end of a calculation, but neither approach is anywhere near convenient in all circumstances.

This is exactly what I was trying to do. Formulate complex Z as a function of all participating circuitry variables, make some assumptions for helping the CAS, then let it find the magnitude of Z, substitute real values, and then simplify/expand for getting some more "pleasant" expression for the plotter. (Or else plotting takes for ever.) But after substitution and simplification I got the (unwished) conversion of small coeffs of Omega to 0.

Substituting with exact numbers instead of floats ends up with the calc hanging or crashing - I guess the expression for abs(Z) gets too big for it then, as it is about 33K already with floats. Not necessary to mention that I don't have any intention to edit such an expression manually - or what did I buy the Prime for? (And this was also why I was asking about commands for decomposing and composing expressions in my other post).

So, as you say, how could somebody not develop quite an ambivalent opinion about the Prime?....

(10-06-2014 11:08 AM)Nigel (UK) Wrote:  I would really like to see this truncation of small quantities as an optional function to be applied when and if I choose to do so (like Chop[] in Mathematica, if my memory serves me correctly). I think it is no more logical to replace small numbers by zero by default than it is to replace numbers greater than three by the string "many"!

Exactly! The many auto-assumptions of the makers about the work of other people are becoming a boomerang against their own machine that could have been fantastic otherwise. Even for example the pre-definition of home variables but without any kind of folders is a big obstacle for work beyond the level of "exploration of the quadratic equation". (What a fancy terminology! "Exploration"!!!!)

I will have to search some other way to work out such things on the Prime, but if the search evolves to a dissertation work for itself, then it is obvious that something is wrong already in the concepts of the calculator. For I did not buy it in order to change my profession to IT/CAS-specialist, but rather as a help for my own business.

Still hoping. Ciao,

Nick

[kickniko]

(10-06-2014 12:06 PM)parisse Wrote:  When I learned physics, I was always told not to use numbers in equations, but always symbols, and replace them only at the end (when all computations are done) by their numeric values. If you follow this rule, you will never have these kind of problems with CAS instructions like simplify, expand, etc.

How did you conclude that I did not work this way? Excuse me, but this is exactly what I was doing in this case, and also exactly what I always do! Only at the end of this process I have to substitute symbolic variables with the real values, or else I will get no plot. And I need a plot.

(10-06-2014 12:06 PM)parisse Wrote:  A CAS can not work properly with approx data, it has to replace them by exact data, and it can not guess if 1e-34 or any other value is near 0 because of the dimension of the quantity (I mean unit choice, since dimensionless number are rarely close to 0) and should not be replaced by 0 (but should be replaced by a nonzero symbolic constant), or if it's a rounding error and should be replaced by 0.

If it cannot guess, then why not leave such values untouched until the user says what to do with them? (See Mathematica, as Nigel already said. It works perfectly with both kinds of data in one and the same expression.)

Sorry, I can't spend all my time searching for "the right way to do things" on the Prime or on any other tool. (I am running business and not tea parties.) Can the Prime handle correctly expressions with floats or not? (Answers like "yes, but" are already negative for me.)

Ciao,

Nick

[parisse]

kickniko, I just read your first post where you wrote in bold the command simplify(6.0929985e-32*Cvar^2*Omega^8), a mix of floating point value and symbolic expression. It means you have replaced some constant(s) by a numeric value before the end of the computation, and that's the explanation of my previous post. By the way, if I set epsilon to 0 in my emulator, the simplify command above returns the expression unchanged.
If you need to work with mixed data (float and symbols) you should use a command that uses numerical algorithms and not symbolic algorithms, e.g. fsolve for numeric equation solving, or polynomial operations in list form (poly1[coeffs]), etc.. Trying to run simplify is a bad idea: simplify and related command can not work properly with approx data (the reason is that simplifying fractions is implemented via the Euclidean gcd algorithm). If you really think you need to run simplify, rewriting floating point numbers as an exact fraction might be a solution, but only if the computation does not require too much ressources and in the end you will probably get something big and not useful.
I have no idea how mathematica handles that, because I don't have a license of mathematica (I will certainly not spend the money for that myself) and even if I had one, there is probably a Xcas way that would be as appropriate as the mma way.
I can understand that you are frustated not to find the right way on the Prime if you are used to mathematica, but you can not expect that Xcas or the Prime CAS will work the same way. I can help you adapt, but I will not do that (remember it's on my free time) if your request is "it should be like in mma". If you don't want to adapt, then just stick with mma and goodbye!

[Nigel (UK)]

(10-06-2014 12:06 PM)parisse Wrote:  When I learned physics, I was always told not to use numbers in equations, but always symbols, and replace them only at the end (when all computations are done) by their numeric values. If you follow this rule, you will never have these kind of problems with CAS instructions like simplify, expand, etc.
A CAS can not work properly with approx data, it has to replace them by exact data, and it can not guess if 1e-34 or any other value is near 0 because of the dimension of the quantity (I mean unit choice, since dimensionless number are rarely close to 0) and should not be replaced by 0 (but should be replaced by a nonzero symbolic constant), or if it's a rounding error and should be replaced by 0.

The questions my students are set often involve a series of calculations, with numerical answers required at each stage and with earlier answers feeding into the later calculations. It is possible to define a symbol for each intermediate answer but it slows things down. It is quicker simply to work with the numerical values.

At the moment I'm teaching circular motion in my lessons. Some of the questions are about cars and trains; some of them are about elementary particles in magnetic fields. For the former type of question I can enter equations with approximate numbers and find solutions; for the latter I must define symbols or everything is simplified to zero, even though both questions are essentially of the same type. This is unnecessarily confusing.

In pure maths I imagine that small numbers are usually the result of rounding errors; in physics small numbers are completely normal and no such judgement should be made. Xcas is perfectly able and willing to work with approximate numbers - it solves 6.63 x f = E for f and raises no objection. All I would like is the option to solve 6.63e-34 x f = E for f in the same way.

In case I'm coming across as miserable, I love the Prime and I think it is tremendous to have something as powerful as Xcas in portable form. But this "feature" is annoying!

Nigel (UK)

[Nigel (UK)]

(10-06-2014 01:46 PM)parisse Wrote:  I have no idea how mathematica handles that, because I don't have a license of mathematica (I will certainly not spend the money for that myself) and even if I had one, there is probably a Xcas way that would be as appropriate as the mma way.
I can understand that you are frustated not to find the right way on the Prime if you are used to mathematica, but you can not expect that Xcas or the Prime CAS will work the same way. I can help you adapt, but I will not do that (remember it's on my free time) if your request is "it should be like in mma". If you don't want to adapt, then just stick with mma and goodbye!

I entirely understand this. Maybe Mathematica was a bad example - the behaviour I'm looking for is displayed by TI machines (e.g., TI-89, TI NSpire) and also by the HP-50g. If this aspect of simplification can't be easily turned on and off in Xcas then I have to accept that, but I think it's a shame.

Nigel (UK)

[kickniko]

(10-06-2014 01:46 PM)parisse Wrote:  kickniko,

I am Nick. Kickniko is only my member name since Nick was not available.

(10-06-2014 01:46 PM)parisse Wrote:  I just read your first post where you wrote in bold the command simplify(6.0929985e-32*Cvar^2*Omega^8), a mix of floating point value and symbolic expression. It means you have replaced some constant(s) by a numeric value before the end of the computation, and that's the explanation of my previous post. By the way, if I set epsilon to 0 in my emulator, the simplify command above returns the expression unchanged.

This is after all possible symbolic work has finished. Omega is (going to be) the independent variable. (I substitute X for it forplotting later on.) And Cvar will have to take several values, as it is the capacity of a varicap which changes for different resonance freqs. I am not trying to get a single value of abs(Z) for a single value of Omega and Cvar, but to graphically examine the dependency of abs(Z) on Omega and (parametrically) on Cvar.

Here the exact way of what I did, as also described in my post to Nigel:

1) Formulated the complex Z, using only symbolic variables (w=greek small omega) and exact numbers, as:

Code:


                         1
----------------------------------------------------------
 1          1                       1
---- + -------- + ----------------------------------------
 Ra     i*w*La              1               1
                       -------- + ------------------------
                        i*w*Cc             1
                                      ------- + i*w*Cr
                                       i*w*Lr

2) Formulated assumptions for all participating variables, as

assume(w>=0)
... etc.

3) Took the absolute value of that and simplified it. The symbolic result is about 18Kb.

4) It was then, that I subsituted the real values for Ra, La, Cc, and Lr, in the expectation to reduce the size of the expression and have quicker plots. If I put the symbolic expression in the plotter and store real in variables Ra, La, Cc and Lr, then the plot takes way too long. (Or the calc crashes.)

5) So, then I wanted to simplify the result with the real values because several multiplications of reals were not carried out yet. As a precaution (because of the assumptions still stored in w and Cr) I substituted the remaining symbolic variables w to Omega (=capital greek omega) and Cr to Cvar.

6) Then I tried to simplify that. It is here when the conversion to 0 happened. The quick examination of the sub-expression, that you refer to, was a test in my search for finding out what happens.

7) Then I also tried to expand the expression, which worked OK. But the result is unusable as the Prime complains about syntax. I can't take that into the plotter.

8) So I had to leave the expression as it was after substitution of real values but with no further simplifications, substitute X for Omega, store several values for Cvar, and see how the plot changes.

(10-06-2014 01:46 PM)parisse Wrote:  If you need to work with mixed data (float and symbols) you should use a command that uses numerical algorithms and not symbolic algorithms, e.g. fsolve for numeric equation solving, or polynomial operations in list form (poly1[coeffs]), etc.. Trying to run simplify is a bad idea: simplify and related command can not work properly with approx data (the reason is that simplifying fractions is implemented via the Euclidean gcd algorithm). If you really think you need to run simplify, rewriting floating point numbers as an exact fraction might be a solution, but only if the computation does not require too much ressources and in the end you will probably get something big and not useful.

Simplification of the expression which contains reals (but also unfinished multiplications of reals) would be nice but not necessary for the plot. It still takes a long time but not as long as storing values in the participating variables and putting the completely symbolical result into the plotter.

But you can't say what kind of result is useful for me, and what is not. Unfortunately all useful things in my business are big. Very big! And this is why I have to use such tools like the Prime. For equations with two variables and three powers I don't need any other tools than pencil and paper. It is the big ones for which I think of buing it for the staff.

(10-06-2014 01:46 PM)parisse Wrote:  I have no idea how mathematica handles that, because I don't have a license of mathematica (I will certainly not spend the money for that myself) and even if I had one, there is probably a Xcas way that would be as appropriate as the mma way.

Hmmm...

(10-06-2014 01:46 PM)parisse Wrote:  I can understand that you are frustated

I am not frustrated. I simply have to decide if I will buy Primes as mobile tools for the staff of my company, or if I will reject it. For that I need real consistent info.

(10-06-2014 01:46 PM)parisse Wrote:  not to find the right way on the Prime if you are used to mathematica, but you can not expect that Xcas or the Prime CAS will work the same way.

So, just one message before you told me:

(10-06-2014 01:46 PM)parisse Wrote:  A CAS can not work properly with approx data, it has to replace them by exact data, ....

Notice the usage of the indefinite article "a" in front of the word CAS, which implies more or less, that this is the behavior of any CAS in general, and that nothing else is possible. Now you tell me, more or less again, it is your CAS (and not a CAS in general) that works this way.

(10-06-2014 01:46 PM)parisse Wrote:  I can help you adapt, but I will not do that (remember it's on my free time) if your request is "it should be like in mma". If you don't want to adapt, then just stick with mma and goodbye!

I did not request it to be like Mathematica. I mentioned that it cannot be generally necessary for a CAS to work the way you explained before. Mathematica was but an example for negation of your statement, which now indeed yourself negate too by speaking about Xcas and not about a CAS.

So, thanks for the info and the support. You made up my decision. Prime is out of my company.

Ciao,

Nick

[parisse]

Nick: Ok, take something else if you think you will find elsewhere. That will not change the fact that rewriting your large expression as a rational fraction (that's what simplify does, and perhaps that's what you misunderstood) will return a big answer. If you need to plot this |Z|, writing it as a rational fraction is a bad idea, you should keep it as is (I wonder what kind of simplification you expected by the way). This is not my CAS versus other CAS, it's math. And by the way, Xcas has a fast kernel for polynomial/rational fraction computations (comparable to the best CAS).

Nigel: Solving 6.63e-34 x f = E should ideally be done via solve(h*f=E,f) then replace h and E by their values or with fsolve (E replaced by it's numerical value). I'll have a look for solve(6.63e-34*f = E,f) but improving the exact solver is certainly difficult (not for linear equations of course, but for more complicated equations, symbolic solving does not use the same kind of algorithms than numeric solving).

[kickniko]

(10-06-2014 04:27 PM)parisse Wrote:  Nick: Ok, take something else if you think you will find elsewhere.

You bet I know now what we will be using as a mobile tool.

(10-06-2014 04:27 PM)parisse Wrote:  That will not change the fact that rewriting your large expression as a rational fraction (that's what simplify does, and perhaps that's what you misunderstood) will return a big answer. If you need to plot this |Z|, writing it as a rational fraction is a bad idea, you should keep it as is (I wonder what kind of simplification you expected by the way).

Leaving it the way it was before trying to simplify it means to be left with a 1 over a huge square root of nested fractions of squares. And this is something for which I do not need such a tool. Turning it to a rational fraction, for example, would be of help for us for understanding a bit better what happens when Cvar varies, or similar things.

On with my expectations: I expected that simplification, after substituting the real values, would perhaps have the grace to bring it to the form of a fraction and to collect the many different numerical coefficients of like powers of Omega, something that already the 48 could do (but of course much slower). This is what I thought about simplifying in this case, since indeed there is not anything more to simplify, as you say. But simplification zeroed out very important terms of the polynomials on both numerator and denominator, and made the expression simply wrong.

Further expectations: I thought that simplifying first and then substituting real values would do better job. But unfortunately it has the disadvantage that you end up without collection of like powers. The result is a sum of powers of Omega both on the numerator as also on the denominator, but unfortunately not of the form

a(n)*Omega^n+a(n-1)*Omega^(n-1)+...+a0

but rather

a(n)*Omega^n+b(n)*Omega^n+c(n)*Omega^n+...
a(n-1)*Omega^(n-1)+b(n-1)*Omega^(n-1)+c(n-1)*Omega^(n-1)+....

where all the a, b, c.... are real numbers. If you then try to simplify, of course the same powers of Omega as before disappear again. If you stay with the above result... Well, let's say it is correct and, lets say it is usable then. At least it can be put into the plotter and be plotted, if one has the money to invest for... waiting and for having to do collection of coefficients of like powers by hand. Sorry HP, sorry Tim, and sorry Bernard, I am not going to do that.

I then expected too, that perhaps expansion could collect the like powers. Well, it did, but the result was not further usable. It displays correctly but cannot be copied/pasted/edited/whatever. We cannot do anything more with that than... looking at it. Of course it is a big expectation to think that results put on history are further usable the normal way...

(10-06-2014 04:27 PM)parisse Wrote:  This is not my CAS versus other CAS, it's math.

You do not convince me as long as I see that other CAS tools on comparable hardware do what I/we want right out of the box. (Except of course if all the others are not CASs and Wolfram is some kind of Houdini-Club, in which case I will be only glad to buy non-CAS tools and to hire magicians!)

(10-06-2014 04:27 PM)parisse Wrote:  And by the way, Xcas has a fast kernel for polynomial/rational fraction computations (comparable to the best CAS).

Sorry, if it does not serve our needs, then it may also fly faster than light and lay golden eggs. It is still as useless to us as a Ferrari on the dirtway.

It is absolutely no option for us the way it is now. Perhaps some future update but not now.

Ciao,

Nick

[Nigel (UK)]

(10-06-2014 04:27 PM)parisse Wrote:  Nigel: Solving 6.63e-34 x f = E should ideally be done via solve(h*f=E,f) then replace h and E by their values or with fsolve (E replaced by it's numerical value). I'll have a look for solve(6.63e-34*f = E,f) but improving the exact solver is certainly difficult (not for linear equations of course, but for more complicated equations, symbolic solving does not use the same kind of algorithms than numeric solving).

Thank you for trying to see my position. I understand that numerical solving and symbolic solving are different and I do not expect miracles, but it would be nice if what works for normal-sized approximate numbers could be made to work for smaller approximate numbers as well, so that I can tackle microscopic problems and macroscopic problems in the same way.

Nigel (UK)

[parisse]

Nigel, I confirm I can easily modify solve to solve your equation (will work for linear equations).
Nick, here is a way to "simplify" your absolute value
z:=1/(1/r+1/i/w/La+1/(1/i/w/Cc+1/(i*w*Cr+1/i/w/Lr)));
z2:=factor(z*conj(z));
If you want the coefficients of w of the denominator of z2: d:=symb2poly(denom(z2),w). There you can subst the value of r, etc. with numeric values. For back evaluation at some value of w, you can use horner(d,value).
I think that the main misunderstanding is about simplify : simplify is probably a bad CAS commandname, because there is no way to guess what the user means by simplification.
I hope you will reconsider your opinion about Xcas and the Prime CAS...

[DrD]

Kudos, Parisse! Your response is very professional and above reproach. Kickniko seems to be trying very hard to derail issues and solutions with character and product aggravations. You aren't falling for it. Yet another important reason tremendous value is added to the hp Prime and hp products, by virtue of your efforts.

Your contributions have not gone unnoticed. Thank you for that.

-Dale-