+- 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: AVars parsing bug or limitation (/thread-20841.html)
AVars parsing bug or limitation - ab3ap - 11-14-2023 04:08 PM
I'm using AVars from python in firmware 2.1.14730 and find that exponents containing a plus sign cause an error. For example:
Code:
import hpprime as h
h.eval('AVars("x"):=456e1')Code:
h.eval('AVars("x"):=456e+1')This is important because in python, programmer might generate:
Code:
cmd = 'AVars(x):=%e' % bignum
h.eval(cmd)RE: AVars parsing bug or limitation - komame - 11-30-2023 06:09 AM
This is a problem related to the PPL interpreter and has nothing to do with AVars. When you try to perform the mathematical operation 1e+2+1 in Python, it will work correctly and return the result => 101. However, when you enter the HOME and try to perform the same mathematical operation, you will get an error message "Invalid exponent in number". PPL should support exponential notation with a positive sign, but it hasn't been anticipated, hence the compatibility issue with Python. Interestingly, CAS on HP Prime supports this notation; the problem only exists in the HOME/PPL environment.
I can report this to the bug tracker, but it's more of an enhancement request for PPL than a bug. However, as you've noticed yourself, it's not a major issue, so the likelihood of someone addressing it is unfortunately very low.
RE: AVars parsing bug or limitation - ab3ap - 11-30-2023 02:01 PM
(11-30-2023 06:09 AM)komame Wrote: ...I can report this to the bug tracker, but it's more of an enhancement request for PPL than a bug. However, as you've noticed yourself, it's not a major issue, so the likelihood of someone addressing it is unfortunately very low.
Thanks, komame! When email to Moravia was greeted with silence, I realized the low likelihood. But I think reporting is worthwhile so that a complete bug list exists. Maybe all the world suddenly wants Primes and money starts rolling in. :-)
I originally used the %e format to maintain proper number of significant figures in the app variable. However, it's easiest to avoid this bug by simply using %f. E.g.,
Code:
cmd='AVars("loss_dB"):=%f' % loss_dB)
h.eval(cmd)RE: AVars parsing bug or limitation - ab3ap - 11-30-2023 02:46 PM
This solution better accounts for very small numbers. The '.30' is just to acquire max figures, fewer are available:
Code:
def numToAvars(varName, val):
if -1 < val < 1:
cmd = 'AVars("%s"):=%.30e' % (varName, val)
else:
cmd = 'AVars("%s"):=%.30f' % (varName, val)
h.eval(cmd)RE: AVars parsing bug or limitation - Albert Chan - 11-30-2023 03:31 PM
After some time, it may not be obvious why the switch of '%.30e' vs '%.30f'
It may be better if we explicitly patch numbers with 'e+' to 'e'.
val = repr(val).replace('e+','e') # HOME/PPL have problem parsing 1.23e+45
RE: AVars parsing bug or limitation - ab3ap - 11-30-2023 03:58 PM
(11-30-2023 03:31 PM)Albert Chan Wrote: After some time, it may not be obvious why the switch of '%.30e' vs '%.30f'
It may be better if we explicitly patch numbers with 'e+' to 'e'.
val = repr(val).replace('e+','e') # HOME/PPL have problem parsing 1.23e+45
I like your solution better because it still allows control of sig figs pushed out to AVars. Thanks! -Mike
RE: AVars parsing bug or limitation - ab3ap - 12-01-2023 01:43 PM
I added the modified subroutine to a list of python-on-the-Prime discoveries (toward bottom) at https://udel.edu/~mm/hp/
Barring a bug fix, it seems to be an easy solution. Now, back to work on an RF app! -Mike
RE: AVars parsing bug or limitation - komame - 12-16-2023 08:04 PM
Hi Mike,
CAS.eval accepts all numeric formats that Python outputs and seems to be a universal solution.
An example of using CAS.eval() without AVars is included in the attachment.
Piotr
RE: AVars parsing bug or limitation - ab3ap - 12-17-2023 10:02 PM
(12-16-2023 08:04 PM)komame Wrote: CAS.eval accepts all numeric formats that Python outputs and seems to be a universal solution.
Thank you, Piotr, I will give it a try right after sending this. It sounds perfect and many thanks for finding a better solution!
Mike
RE: AVars parsing bug or limitation - komame - 03-28-2024 07:06 AM
(12-17-2023 10:02 PM)ab3ap Wrote: Thank you, Piotr, I will give it a try right after sending this. It sounds perfect and many thanks for finding a better solution!
Mike,
I found an even better solution, completely independent of the formatting settings and digit grouping in HOME.
Code:
import cas
def numToAvars(varName, val):
cas.caseval('AVars("%s"):=%s' % (varName,str(val)))As you can see, instead of using hpprime.eval, I used cas.caseval. This allows parsing to be done on the CAS side, which handles all numerical cases perfectly. There's no need to even specify the output format (%.11f); simple conversion through str is sufficient.
numToAvars('v',val) → val stored in AVars "v" variable
examples:
Code:
numToAvars('v',123e+3) → 123000
numToAvars('v',-0.000000000000000000000000000001234) → −1.234ᴇ−30
numToAvars('v',1234000000000000000000000000000) → 1234ᴇ30Additionally, positive and negative infinity values are also supported:
Code:
numToAvars('v',float('inf')) → +Inf
numToAvars('v',float('-inf')) → -Inf
numToAvars('v','∞') → +Inf
numToAvars('v','-∞') → -InfI think it's time to update your Prime Python page
RE: AVars parsing bug or limitation - ab3ap - 03-28-2024 12:13 PM
What a great solution, many thanks, Piotr! And the page of tips & techniques is updated with your discovery: https://udel.edu/~mm/hp/ :-) -Mike