Post Reply 
newRPL - build 1089 released! [update:build 1158]
05-15-2019, 09:00 PM
Post: #421
RE: newRPL - build 1089 released! [update:build 1158]
(05-15-2019 11:47 AM)Gilles Wrote:  Claudio, thanks for your reply. About the IP command, I noticed that the IP command returns an approx or exact number :

1.2 IP returns 1
but
1.2. IP returns 1.
and
1. IP returns 1.

Perhaps it would be more coherent that the IP command always return an exact number :

1. IP -> 1

?
An approximated number can only be guaranteed correct to the number of digits it carries (usually the current system precision), the dot doesn't have any real practical meaning other than confirming to the user that the number he's seeing on the screen may have been subjected to rounding error at the current precision.
IP of an approximated number is still an approximation. Let's say precision is 4 and the "exact" number should've been 0.99999 (5 digits of 9). At the current system precision of 4, the number in question would be represented as 1.000. (4 dgits w/ending dot) If you use IP of that approximated number you'll get 1. (one w/ending dot, not exact). Notice that IP of the exact number would've been 0, so the result of IP too may have been affected by rounding error and is therefore not guaranteed to be exact.

(05-15-2019 11:47 AM)Gilles Wrote:  If not, NewRpl lacks an R->I (or a more generic A->E Approx to exact) command

Why would you care to force an inexact number to be exact? Besides obsessing about whether a number is exact or not, I can't see any practical use for that.
If you can think of a specific use and can convince me to add the command, I'm open to it. I just never found any real case that would need it.
Find all posts by this user
Quote this message in a reply
05-15-2019, 11:11 PM
Post: #422
RE: newRPL - build 1089 released! [update:build 1158]
Hello Claudio,

first and foremost, I renew you my compliments for your work on newRPL: it's been a couple of years I haven't followed the progress of your project (life issues...) and having returned to it a couple of weeks ago I'm amazed to see latest advancements.

I'be been using regularly at work new RPL (build 1180) for some weeks and this allowed me to spot a few bugs, some of them by pure chance - or misfortune if you prefer! Wink

1) X*1_[m] EVAL (where X is an undefined variable) crashes the calc;
2) XROOT(1,0) sends the calc into an infinite loop. Interestingly (at least for me!), the actual result is not entirely trivial: https://www.quora.com/What-is-the-zeroth...any-number
3) (TVM) Solving for I%YR, N or PYR when other variables are undefined leaves the stack dirty besides erroring out as expected;
4) →Q doesn't work with parallel list processing
5) Type exactly 6π [ENTER]. Now you have 6 on level 2 and π on level 1: if you now issue →NUM you get a "π error: undefined variable" error
6) If in parallel processing a calculation returns NaN then no output is returned: I'll explain myself with an example: « ∞ SIN » returns NaN but « { ∞ ∞ } SIN » doesn't return { NaN NaN }. Instead, it aborts leaving unevaluated { ∞ ∞ } on the stack.
7) DIGITS should return a string, otherwise potential leading zeros are lost
8) Evaluation of the symbolic expression in the attachment crashes the calc.

   
Find all posts by this user
Quote this message in a reply
05-15-2019, 11:30 PM
Post: #423
RE: newRPL - build 1089 released! [update:build 1158]
(05-15-2019 09:00 PM)Claudio L. Wrote:  
(05-15-2019 11:47 AM)Gilles Wrote:  Claudio, thanks for your reply. About the IP command, I noticed that the IP command returns an approx or exact number :

1.2 IP returns 1
but
1.2. IP returns 1.
and
1. IP returns 1.

Perhaps it would be more coherent that the IP command always return an exact number :

1. IP -> 1

?
An approximated number can only be guaranteed correct to the number of digits it carries (usually the current system precision), the dot doesn't have any real practical meaning other than confirming to the user that the number he's seeing on the screen may have been subjected to rounding error at the current precision.
IP of an approximated number is still an approximation. Let's say precision is 4 and the "exact" number should've been 0.99999 (5 digits of 9). At the current system precision of 4, the number in question would be represented as 1.000. (4 dgits w/ending dot) If you use IP of that approximated number you'll get 1. (one w/ending dot, not exact). Notice that IP of the exact number would've been 0, so the result of IP too may have been affected by rounding error and is therefore not guaranteed to be exact.

(05-15-2019 11:47 AM)Gilles Wrote:  If not, NewRpl lacks an R->I (or a more generic A->E Approx to exact) command

Why would you care to force an inexact number to be exact? Besides obsessing about whether a number is exact or not, I can't see any practical use for that.
If you can think of a specific use and can convince me to add the command, I'm open to it. I just never found any real case that would need it.

From a numerical stand point, me neither can see a real use case for an approximate to exact conversion, which can be however emulated via the << ->STR RTAIL STR-> >> sequence (of course, the inverse is simply << 0. + >>.

Nevertheless, the string manipulation trick highlights an issue: ->STR respects the current numerical format, therefore if I have set a fancy format for my numbers but need a different one for e.g. result presentation/string manipulation I have to GETNFMT, SETNFMT, do my trick and re-SETNFMT.

It's cumbersome to write and requires unwanted stack manipulation: Claudio, would it be possible in the future to add a ->NFMT command which accepts a number and a format list and does a one-off string conversion?
Find all posts by this user
Quote this message in a reply
05-16-2019, 09:23 AM (This post was last modified: 05-16-2019 10:16 AM by Gilles.)
Post: #424
RE: newRPL - build 1089 released! [update:build 1158]
(05-15-2019 09:00 PM)Claudio L. Wrote:  
(05-15-2019 11:47 AM)Gilles Wrote:  If not, NewRpl lacks an R->I (or a more generic A->E Approx to exact) command

Why would you care to force an inexact number to be exact? Besides obsessing about whether a number is exact or not, I can't see any practical use for that.
If you can think of a specific use and can convince me to add the command, I'm open to it. I just never found any real case that would need it.

1/ To preserve backwards compatibility with the RPL language. In RPL : 123. R->I returns 123

2/ With some problem you have to find an exact solution. But to find it, you first have to deal with an approx solution (or an interval) and look around to find and verify the exact solution.

3/ To play with digits. I knows the DIGITS command. But in some case, it is interesting to do things like (probably not the best way) :

{ 1. 2. 3. 4. } << R->I ->STR >> MAP ΣLIST STR->
returns 1234

(NL->I behavior with the ListExt Library)

4/ Perhaps I missed a command, but if you need an 'exact' random integer/ or a random matrix with exact integers. Or generate a random number in Q (ie .'158/99')

EDIT :

in fact the ->Q command does the job ;D

123. ->Q returns 123
Find all posts by this user
Quote this message in a reply
05-16-2019, 10:15 AM
Post: #425
RE: newRPL - build 1089 released! [update:build 1158]
Hello Claudio, I've found a couple of regressions.

1) (1,∡0º) √ returns a wrong result. Wrong also if the angle is in radians or grads, but not if it is in DMS.
2) Entering (1 0X) puts a malformed symbolic on the stack (discovered by my clumsiness!)
Find all posts by this user
Quote this message in a reply
05-16-2019, 01:58 PM
Post: #426
RE: newRPL - build 1089 released! [update:build 1158]
Thanks for all the bug reports!
These will keep me busy, it seems you found quite a bit of special cases the compiler isn't handling well, I'll go one by one and clean everything up.
Find all posts by this user
Quote this message in a reply
05-16-2019, 02:33 PM
Post: #427
RE: newRPL - build 1089 released! [update:build 1158]
(05-16-2019 01:58 PM)Claudio L. Wrote:  Thanks for all the bug reports!
These will keep me busy, it seems you found quite a bit of special cases the compiler isn't handling well, I'll go one by one and clean everything up.

I hope you don't mind if I report a last one... A solitary dot is accepted by the parser, allowing construction of expressions such as 'SIN(.)' or '√.'
Find all posts by this user
Quote this message in a reply
05-16-2019, 05:19 PM
Post: #428
RE: newRPL - build 1089 released! [update:build 1158]
(05-16-2019 02:33 PM)JoJo1973 Wrote:  
(05-16-2019 01:58 PM)Claudio L. Wrote:  Thanks for all the bug reports!
These will keep me busy, it seems you found quite a bit of special cases the compiler isn't handling well, I'll go one by one and clean everything up.

I hope you don't mind if I report a last one... A solitary dot is accepted by the parser, allowing construction of expressions such as 'SIN(.)' or '√.'

I don't mind at all... that doesn't look good.

However, the dot is a valid character in a variable name (like many other symbols), therefore '.' is a valid variable name, though a bit unsightly. The only problem is, if I add the requirement of at least one letter in the name of the variable, it would rule out variables that are greek letters for example (since greek letters are just weird Unicode symbols after all, not too different from the dot). Even banning the dot you could always find some strange unicode symbol that's not forbidden and create a strange variable name like that. I don't know what's the proper solution in this case.
Find all posts by this user
Quote this message in a reply
05-16-2019, 06:05 PM
Post: #429
RE: newRPL - build 1089 released! [update:build 1158]
(05-16-2019 05:19 PM)Claudio L. Wrote:  
(05-16-2019 02:33 PM)JoJo1973 Wrote:  I hope you don't mind if I report a last one... A solitary dot is accepted by the parser, allowing construction of expressions such as 'SIN(.)' or '√.'

I don't mind at all... that doesn't look good.

However, the dot is a valid character in a variable name (like many other symbols), therefore '.' is a valid variable name, though a bit unsightly. The only problem is, if I add the requirement of at least one letter in the name of the variable, it would rule out variables that are greek letters for example (since greek letters are just weird Unicode symbols after all, not too different from the dot). Even banning the dot you could always find some strange unicode symbol that's not forbidden and create a strange variable name like that. I don't know what's the proper solution in this case.

IIRC, Unicode tables which you derive data from have flags to classify the code points: you could limit valid characters for identifiers to 0-9, letter-like symbols and a few selected symbols - underscore, dot (except a single dot character) and the likes.

Alternatively, you could limit the letter-like characters by blocks: Basic Latin, Greek, Cyrillic and Hebrew blocks have consecutive code points and cover 99.999% of practical uses.

I guess there is not much appetite to name a variable in Runic or Balinese! Wink
Find all posts by this user
Quote this message in a reply
05-16-2019, 11:05 PM
Post: #430
RE: newRPL - build 1089 released! [update:build 1158]
(05-16-2019 06:05 PM)JoJo1973 Wrote:  IIRC, Unicode tables which you derive data from have flags to classify the code points: you could limit valid characters for identifiers to 0-9, letter-like symbols and a few selected symbols - underscore, dot (except a single dot character) and the likes.

Right now it only has a list of forbidden characters (which are operators and separators in symbolic expressions), but anything else is valid. Since there's thousands of valid characters and only a few forbidden, it made sense at the time.

(05-16-2019 06:05 PM)JoJo1973 Wrote:  Alternatively, you could limit the letter-like characters by blocks: Basic Latin, Greek, Cyrillic and Hebrew blocks have consecutive code points and cover 99.999% of practical uses.

I guess there is not much appetite to name a variable in Runic or Balinese! Wink

newRPL has only the minimum information needed to perform a NFC normalization of a string. Other than that, it does not really mess with Unicode, other than properly decoding/encoding UTF-8 strings. So the information to know if a character is a punctuation symbol or a letter isn't really there (probably wouldn't fit in the entire flash!). Separating by blocks would be OK if there wasn't a lot of punctuations and symbols included within the blocks.
Having a lookup table for a few limited blocks with a bit indicating if it's a letter or not would be perhaps doable. I'll have to think about it some more.
Find all posts by this user
Quote this message in a reply
05-17-2019, 11:28 AM (This post was last modified: 05-17-2019 11:48 AM by Gilles.)
Post: #431
RE: newRPL - build 1089 released! [update:build 1158]
Hi Claudio,

I noticed 2 problems (Rev 1180)

1/ If you have in a program something like :

IF 'a>20 AND a<1000' THEN ....
It works fine but when you recall the program you get :
IF 'a>20ANDa<1000' THEN ...
and you have to add the losts spaces by hand to compil again.

2/ Suppose we have an object 'Lst' wich is { 2 4 6 8 }

Lst 3 GET returns 6
but
'Lst' 3 GET returns nothing and change Lst in 6

Same behavior if 'Lst' is a matrice.
Find all posts by this user
Quote this message in a reply
05-17-2019, 02:06 PM
Post: #432
RE: newRPL - build 1089 released! [update:build 1158]
(05-17-2019 11:28 AM)Gilles Wrote:  Hi Claudio,

I noticed 2 problems (Rev 1180)

1/ If you have in a program something like :

IF 'a>20 AND a<1000' THEN ....
It works fine but when you recall the program you get :
IF 'a>20ANDa<1000' THEN ...
and you have to add the losts spaces by hand to compil again.

I didn't think of that: some operators are not symbols, so the decompiler needs to add spaces if they are in a symbolic.

(05-17-2019 11:28 AM)Gilles Wrote:  2/ Suppose we have an object 'Lst' wich is { 2 4 6 8 }

Lst 3 GET returns 6
but
'Lst' 3 GET returns nothing and change Lst in 6

Same behavior if 'Lst' is a matrice.
Bizarre.


So, I added all these bugs you guys reported to the bug tracker, I'm going to start using it again since there's too many for me to remember and also to assign priorities (some of these last ones are really critical). If you guys want access to the bug tracker you could report issues directly there, just send me a PM with an email address. Don't worry your email address won't appear anywhere, I'll create virtual throw-away emails for you with an hpgcc3.org domain that forward to your emails, that way your private emails will never be stored in the bugtracker site (which is encrypted, non-public and secure, but you never know when a security hole will become known).
I'd like to recruit both of you as official bug hunters of newRPL.
Find all posts by this user
Quote this message in a reply
Post Reply 




User(s) browsing this thread: 1 Guest(s)