AVars parsing bug or limitation

[ab3ap]

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')

works fine. However,

Code:

h.eval('AVars("x"):=456e+1')

yields 'Error: Invalid input'. An exponent 'e-1' is accepted.

This is important because in python, programmer might generate:

Code:

cmd = 'AVars(x):=%e' % bignum
h.eval(cmd)

which can include exponent with plus sign. This is a minor bug but I'm not certain where to report it. Any suggestions from those more familiar with the process? Thanks. -Mike

[komame]

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.

[ab3ap]

(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)

[ab3ap]

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)

[Albert Chan]

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

[ab3ap]

(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

[ab3ap]

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

[komame]

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

[ab3ap]

(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

[komame]

(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ᴇ30

Additionally, positive and negative infinity values are also supported:

Code:

numToAvars('v',float('inf')) → +Inf
numToAvars('v',float('-inf')) → -Inf
numToAvars('v','∞') → +Inf
numToAvars('v','-∞') → -Inf

I think it's time to update your Prime Python page

[ab3ap]

What a great solution, many thanks, Piotr! And the page of tips & techniques is updated with your discovery: https://udel.edu/~mm/hp/ :-) -Mike