AVars parsing bug or limitation
|
11-14-2023, 04:08 PM
Post: #1
|
|||
|
|||
AVars parsing bug or limitation
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 Code: h.eval('AVars("x"):=456e+1') This is important because in python, programmer might generate: Code: cmd = 'AVars(x):=%e' % bignum |
|||
11-30-2023, 06:09 AM
(This post was last modified: 11-30-2023 06:15 AM by komame.)
Post: #2
|
|||
|
|||
RE: AVars parsing bug or limitation
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. |
|||
11-30-2023, 02:01 PM
Post: #3
|
|||
|
|||
RE: AVars parsing bug or limitation
(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) |
|||
11-30-2023, 02:46 PM
Post: #4
|
|||
|
|||
RE: AVars parsing bug or limitation
This solution better accounts for very small numbers. The '.30' is just to acquire max figures, fewer are available:
Code: def numToAvars(varName, val): |
|||
11-30-2023, 03:31 PM
Post: #5
|
|||
|
|||
RE: AVars parsing bug or limitation
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 |
|||
11-30-2023, 03:58 PM
Post: #6
|
|||
|
|||
RE: AVars parsing bug or limitation
(11-30-2023 03:31 PM)Albert Chan Wrote: After some time, it may not be obvious why the switch of '%.30e' vs '%.30f' I like your solution better because it still allows control of sig figs pushed out to AVars. Thanks! -Mike |
|||
12-01-2023, 01:43 PM
Post: #7
|
|||
|
|||
RE: AVars parsing bug or limitation
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 |
|||
12-16-2023, 08:04 PM
Post: #8
|
|||
|
|||
RE: AVars parsing bug or limitation
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 |
|||
12-17-2023, 10:02 PM
Post: #9
|
|||
|
|||
RE: AVars parsing bug or limitation | |||
03-28-2024, 07:06 AM
(This post was last modified: 03-28-2024 08:54 AM by komame.)
Post: #10
|
|||
|
|||
RE: AVars parsing bug or limitation
(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 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 Additionally, positive and negative infinity values are also supported: Code: numToAvars('v',float('inf')) → +Inf I think it's time to update your Prime Python page ![]() Piotr Kowalewski |
|||
03-28-2024, 12:13 PM
Post: #11
|
|||
|
|||
RE: AVars parsing bug or limitation
What a great solution, many thanks, Piotr! And the page of tips & techniques is updated with your discovery: https://udel.edu/~mm/hp/ :-) -Mike
|
|||
« Next Oldest | Next Newest »
|
User(s) browsing this thread: 1 Guest(s)