CAS and small numbers

[Nigel (UK)]

I'm having problems when working with equations with small coefficients in the Prime CAS? For example, evaluating the equation

e=6.63e-34*f

gives e=0, because the CAS simplifies small numbers to zero. This makes it impossible to rearrange the equation to get f=e/6.63e-34: solving for f returns an empty list.

I agree that this is a trivial example, but the same problem arises with more complicated equations. I've asked this question before (on the old forum, I think) but I'm wondering if anyone has any new ideas? I realise that setting small approximate numbers to zero is an intended feature of Xcas, but the Prime would be more useful to physicists (and physics students) if this behaviour could be turned off or at least worked around in some way.

Nigel (UK)

[Tim Wessman]

Does setting your epsilon limit on page 2 in CAS settings not work for you?

[Han]

When working in CAS, you are much better off using exact values. So instead of typing something like: 2.1E-10, I would recommend 21*10^(-11) as the value. Then you can convert to decimal form at the very end if needed. Most CAS will treat values having a fraction mark (in your case, a decimal point) as an implicit request to use approximate algorithms so that roundoff could possibly result in "useless" answers.

[Nigel (UK)]

Thanks for your answers.

(04-22-2014 07:21 PM)Tim Wessman Wrote:  Does setting your epsilon limit on page 2 in CAS settings not work for you?

No. If I set epsilon to 10^-50 the equation I gave still evaluates to e=0 (on the Prime, although not on the "real" Xcas).

It seems to me that epsilon is intended to deal with rounding errors, or to tell recursive algorithms when to stop. Setting a very small value for epsilon might cause problems on a limited precision device like the Prime. In any case, Planck's constant is small in standard units. Quantum mechanics is not a rounding error!

(04-22-2014 07:28 PM)Han Wrote:  When working in CAS, you are much better off using exact values. So instead of typing something like: 2.1E-10, I would recommend 21*10^(-11) as the value. Then you can convert to decimal form at the very end if needed. Most CAS will treat values having a fraction mark (in your case, a decimal point) as an implicit request to use approximate algorithms so that roundoff could possibly result in "useless" answers.

I've tried this and it does work. The problem is that numbers in Physics are genuinely approximate, and it feels strange to enter them as exact numbers. Also, the power of ten to use depends on how many significant figures there are. It requires extra brainpower to convert 6.63e-34 to 663*10^{-36}, and 6.626e-34 to 6626*10^{-37} without getting in a muddle!

I only have experience of two other CAS systems: the TI CAS and Mathematica. Neither treat small approximate numbers in this way by default. Some numbers really are small and approximate; it would be nice to do symbolic algebra with expressions involving them. I suppose that I could define variables with the small numbers in first, but that seems rather complicated.

Nigel (UK)

[Han]

(04-22-2014 08:22 PM)Nigel (UK) Wrote:  I've tried this and it does work. The problem is that numbers in Physics are genuinely approximate, and it feels strange to enter them as exact numbers. Also, the power of ten to use depends on how many significant figures there are. It requires extra brainpower to convert 6.63e-34 to 663*10^{-36}, and 6.626e-34 to 6626*10^{-37} without getting in a muddle!

I only have experience of two other CAS systems: the TI CAS and Mathematica. Neither treat small approximate numbers in this way by default. Some numbers really are small and approximate; it would be nice to do symbolic algebra with expressions involving them. I suppose that I could define variables with the small numbers in first, but that seems rather complicated.

Rather than converting yourself, have the calculator do it. For example, for 6.626e^-34, I would type (in CAS) 6.626, hit the [ENTER] key and then the [a b/c] key, and then type * 10^(-34). Then store that using the STO menu key to whatever variable you wanted.

If you hit the [a b/c] key with the exact result, it will convert it to scientific notation.

[Nigel (UK)]

(04-22-2014 08:53 PM)Han Wrote:  Rather than converting yourself, have the calculator do it. For example, for 6.626e^-34, I would type (in CAS) 6.626, hit the [ENTER] key and then the [a b/c] key, and then type * 10^(-34). Then store that using the STO menu key to whatever variable you wanted.

If you hit the [a b/c] key with the exact result, it will convert it to scientific notation.

Thanks for this idea. What I've done now is to define a function exeex (exact exponent):

(a,b) -> exact(a)*10^b

This lets me enter exact powers of ten inline, which is workable.

I still think Xcas would be more useful to scientists if this feature was reconsidered, or its implementation was changed in some way. Perhaps setting small values to zero could be separated out from the default "simplify" routine, rather like "Chop" in Mathematica?

Nigel (UK)[/font]

[Tugdual]

(04-22-2014 09:19 PM)Nigel (UK) Wrote:  

(04-22-2014 08:53 PM)Han Wrote:  Rather than converting yourself, have the calculator do it. For example, for 6.626e^-34, I would type (in CAS) 6.626, hit the [ENTER] key and then the [a b/c] key, and then type * 10^(-34). Then store that using the STO menu key to whatever variable you wanted.

If you hit the [a b/c] key with the exact result, it will convert it to scientific notation.

Thanks for this idea. What I've done now is to define a function exeex (exact exponent):

(a,b) -> exact(a)*10^b

This lets me enter exact powers of ten inline, which is workable.

I still think Xcas would be more useful to scientists if this feature was reconsidered, or its implementation was changed in some way. Perhaps setting small values to zero could be separated out from the default "simplify" routine, rather like "Chop" in Mathematica?

Nigel (UK)[/font]

I agree, the mitigation given by Han is too tricky to be convenient.
I recently used the prime for some matrices calculation (very nice and convenient!) but for the rest I tend to be faster on the 34s or the 15C because of those so many glitches that still make the Prime not trustable. I heard of an update which is excellent news, totally looking forward to get it and see if I will finally change my mind. May be I expect too much from HP but if we could have a decent RPN I may finally use this very promising hardware.

[parisse]

I would recommend using symbols for physical constants, e.g. h for the Planck constant, then at the end of the computation replace h and other constants by their numerical value, for example
subst(expression,[h,q],[6.626e-34,1.6e-19])
or with units:
mksa(subst(h/m*q,[h,m,q],[_h_,_me_,_qe_]))

[Nigel (UK)]

(04-23-2014 07:14 AM)parisse Wrote:  I would recommend using symbols for physical constants, e.g. h for the Planck constant, then at the end of the computation replace h and other constants by their numerical value, for example
subst(expression,[h,q],[6.626e-34,1.6e-19])
or with units:
mksa(subst(h/m*q,[h,m,q],[_h_,_me_,_qe_]))

Thank you for these suggestions; the first works, and I shall use it.

The problem with your second suggestion is that mksa(_h_) (for example) gives zero, but with the correct units! If I'm solving for something that is small (energies in joules, masses in kilograms, charges in coulombs) I'll just get zero as my answer. Is this behaviour intended?

Nigel (UK)

[parisse]

Haven't tried on the Prime, I just tried with Xcas, I'll check tomorrow.

[Tim Wessman]

(04-23-2014 06:35 PM)Nigel (UK) Wrote:  as my answer. Is this behaviour intended?

Nope. Working with Bernard I believe the issue has been identified. It will go on the list of potential future fixes. Thanks!

I was expecting the page 2 setting to work as you were as well.

[Nigel (UK)]

Thanks, Tim and Parisse! Glad to be of service. Long may the Prime continue improving!

Nigel (UK)