newRPL - build 1255 released! [updated to 1299]
|
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 :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. |
|||
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! ![]() 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. |
|||
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 :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. 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? |
|||
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 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 |
|||
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!) |
|||
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. |
|||
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! 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 '√.' |
|||
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! 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. |
|||
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 '√.' 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! ![]() |
|||
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. 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. |
|||
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. |
|||
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 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 }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. |
|||
05-20-2019, 09:26 PM
(This post was last modified: 05-20-2019 09:53 PM by Gilles.)
Post: #433
|
|||
|
|||
RE: newRPL - build 1089 released! [update:build 1158]
PM sended.
I started to adapt a subset of David Mutter's ListExt library and GoferList to newRPL. It's very fast and efficient. On the other hand I noticed that the structure DIR ... END is not supported in newRPL. Claudio, will it be in the future? It would give more readable sources than having to do "STO" for each program. Just to illustrate : Code: @============================================================================== |
|||
05-20-2019, 10:41 PM
Post: #434
|
|||
|
|||
RE: newRPL - build 1089 released! [update:build 1158]
Hi Gilles,
this program will do: Code:
|
|||
05-22-2019, 02:00 AM
Post: #435
|
|||
|
|||
RE: newRPL - build 1089 released! [update:build 1158]
(05-20-2019 09:26 PM)Gilles Wrote: PM sended. Yes, directories aren't objects, more like dictionaries so they live outside of the RPL realm. I didn't implement that syntax because I had something better in mind, more like RPL libraries than directories, the idea is a generic container of named objects that could be installed as a system-wide library, extracted to a directory or even to a local var environment without exploding the object. Anyway, it's not yet implemented so for now you have to use lists, but perhaps it's time to discuss the final details of that format. By the way, there's a couple of new commands in newRPL that I added, inspired by David's library that will help in the implementation of some of his commands. |
|||
05-22-2019, 04:42 AM
(This post was last modified: 05-22-2019 04:42 AM by The Shadow.)
Post: #436
|
|||
|
|||
RE: newRPL - build 1089 released! [update:build 1158] | |||
05-22-2019, 08:37 AM
Post: #437
|
|||
|
|||
RE: newRPL - build 1089 released! [update:build 1158]
(05-22-2019 04:42 AM)The Shadow Wrote:(05-22-2019 02:00 AM)Claudio L. Wrote: By the way, there's a couple of new commands in newRPL that I added, inspired by David's library that will help in the implementation of some of his commands. Claudio, talking about lists, I've seen you have implemented support for case lists. If I'm not mistaken, at the moment they behave as normal lists: do they have some special propriety you are planning to add? |
|||
05-23-2019, 02:44 AM
Post: #438
|
|||
|
|||
RE: newRPL - build 1089 released! [update:build 1158]
(05-22-2019 08:37 AM)JoJo1973 Wrote:(05-22-2019 04:42 AM)The Shadow Wrote: So what are they? List commands are near and dear to my heart. I just realized the module that has commands for composite objects is completely missing from the wiki (another thing to fix...), no wonder you are asking what they are. It's just a few I found useful, like RHEAD gives you the head of the reverse list (last element). I'll add that module to the wiki so they show up. As far as case lists: they are not the same as regular lists. A case list is assumed to have multiple values of the same variable, so operations between them are not the same as regular lists. For example { A B } { C D } * would normally multiply element by element { A*C B*D }. With case lists, something that could be A or B multiplied by something that could be C or D creates 4 different possible outcomes: {A*C B*C A*D B*D }. This is mainly used internally to evaluate expressions with variables that could have multiple values. Just assign each variable a case list of all possible values and EVAL will return a list of all possible outcomes of the expression. |
|||
05-23-2019, 09:57 AM
Post: #439
|
|||
|
|||
RE: newRPL - build 1089 released! [update:build 1158]
Very interesting... Evaluating
Code:
results in Code:
|
|||
05-23-2019, 02:06 PM
Post: #440
|
|||
|
|||
RE: newRPL - build 1089 released! [update:build 1158]
(05-23-2019 09:57 AM)JoJo1973 Wrote: Very interesting... Evaluating If you like that... you'll like the ALLROOTS command. Try '√4' ALLROOTS and you'll see that it applies a group of rules that will replace any square root or power with exponent in the 1/n form with a case list using the command XROOT (which only returns the principal root) or the actual principal root magnitude if it's numerically exact, multiplied by a case list with all the complex angles needed to return exact values for all roots. I think the command is still incomplete, it doesn't cover all cases but it's easy to add rules as needed since it's a plain RPL source file (here is an area where I can get help from math-minded people like yourself). |
|||
« Next Oldest | Next Newest »
|
User(s) browsing this thread: 2 Guest(s)