newRPL - build 1255 released! [updated to 1299]

[compsystems]

Hello
I do not know if the following was already discussed: Optional Arguments

The RPN commands of the hp48 / 50 interpret a number of fixed arguments, while in the functional standard notation some languages the number of call arguments can be variable

if a function is defined as f1 (arg1, [arg2], [arg3], ...)

The following three calling options can be made.
f1(arg1) [enter]
f1(arg1, arg2) [enter]
f1(arg1, arg2, arg3) [enter]

for example Xcas syntax python

PHP Code:

#cas
def legendre_( n, evalX="" ):
    local px, x, type2arg; purge(x)
    px := 1/(2^n*n!)*diff((x^2-1)^n,x,n)
    type2arg := getType(evalX)   
    if type2arg=="NUM" or type2arg=="EXPR" or type2arg=="VAR":
        px:=subst(px,x=evalX)
    elif type2arg=="STR" and evalX=="list":
        px:=e2r(px)   
    return px;
#end 


legendre_(2), legendre_(2,y), legendre_(2,"list"), legendre_(2,10), legendre_(2,cos(t)) [enter]

1/8*(12*x^2-4), 1/8*(12*y^2-4), poly1[3/2,0,-1/2],2 99/2, 1/8*(12*cos(t)^2-4)

I think the only way in RPN is to specify the number of arguments, it can be with the symbols <-

arg1 f1 [enter]
arg1, arg2 f1←2 [enter]
arg1, arg2, arg3 f1←3 [enter]

[Claudio L.]

(04-19-2019 01:11 PM)compsystems Wrote:  Hello
I do not know if the following was already discussed: Optional Arguments

No, it wasn't because it does not apply in RPN/RPL.

(04-19-2019 01:11 PM)compsystems Wrote:  The RPN commands of the hp48 / 50 interpret a number of fixed arguments, while in the functional standard notation some languages the number of call arguments can be variable

Wrong: all commands in RPN/RPL are free to use how many elements (arguments) they want from the stack.

(04-19-2019 01:11 PM)compsystems Wrote:  I think the only way in RPN is to specify the number of arguments

Wrong again, on all languages, each command/function knows how many arguments it needs depending on the values of other arguments or any other markers.
In other languages you ARE providing the number of arguments when you enclose them in parenthesis. Of course you can do the same in RPL, just put a marker on the stack where the arguments start, everything below that is an argument.

Code:


"LASTARGUMENT"
1
2
3

COUNTARGS

The command COUNTARGS would simply look for the string "LASTARGUMENT" in the stack and use it as an end marker, everything below is an argument. Of course, providing explicitly the number of arguments is easy and quick, but not the only way as you stated (and this is true for all languages, not just RPL).
By the way, some RPL commands require different number of arguments depending on the type of arguments passed, some others even analyze the arguments to make a smart "guess" at how many arguments are needed (look at DOLIST in the AUR, on stock 50g it requires or not an explicit number of lists depending on analyzing the program you provided to see how many arguments it needs).
This is also the same for other languages, printf() analyzes the string you passed on the first argument to see how many arguments it needs and their type.

To close this: there's no need for anything special to do variable arguments in RPL.

[Gilles]

I use version 1089 on the simulator ans version 1180 on the 50g hardware. My PC is in Windows10. My HP50g is connected to my PC in USB.

I'm unable to transfer a program from the simulator to the real calc.
How to do this ?

[Claudio L.]

(04-21-2019 07:48 AM)Gilles Wrote:  I use version 1089 on the simulator ans version 1180 on the 50g hardware. My PC is in Windows10. My HP50g is connected to my PC in USB.

I'm unable to transfer a program from the simulator to the real calc.
How to do this ?

I was made aware of this by another user a while ago, it seems the newer ROMs aren't communicating well with the windows version of the Desktop. I'm currently giving the finishing touches to completely new communication protocols and very soon will release updated ROMs and Desktop application.
Give me another week to clean up things and it should be out.

[franco51]

Great news!
BR
Frank

[Gilles]

I spended some time today to test NewRPL both with the simulator and real HP50g : It is better and better! My english is too bad to improve the english documentation project but I consider about a french wiki version of the manual. It could be french translation of the english version for some parts and new french articles. That means thats this french wiki could be different of the english version. Claudio is this OK for you ? Could I reuse some parts, graphics etc.?

[Gilles]

Bug report with HP50g Rev 1180

In degree

(5 <\45d)
(5 <\45d)
+

-> (10. <\ 44.6.d) @ ?? expected (10. <\45.d)

RECT->

-> (7.071067812. 7.071067812. ) @ ??

45 SIN

-> 0.707106781.

44.6 SIN

-> 0.707106781 @ ?? same than sin(45)

44.9 SIN
-> 0.713250449 @ ?? expected 0,7058715706786...

Results are correct on simulator build 1089

[Claudio L.]

(04-23-2019 05:22 PM)Gilles Wrote:  Bug report with HP50g Rev 1180

In degree

(5 <\45d)
(5 <\45d)
+

-> (10. <\ 44.6.d) @ ?? expected (10. <\45.d)

RECT->

-> (7.071067812. 7.071067812. ) @ ??

45 SIN

-> 0.707106781.

44.6 SIN

-> 0.707106781 @ ?? same than sin(45)

44.9 SIN
-> 0.713250449 @ ?? expected 0,7058715706786...

Results are correct on simulator build 1089

Makes no sense, that code hasn't changed in over 2 years! What I changed is the compiler... I wonder if there's some shady compiler optimization that's hurting the math code. I'll take a look, but that's very bad news... As soon as I release the new ROM, we'll need to do thorough testing to make sure all results are correct.
Thanks for the report!
And yes, I don't have a problem in you translating the wiki to French. I wonder if there's a way to switch languages in the same wiki, then I would just give you access to the wiki and you could write it directly in the official one. I'll investigate that.

EDIT: I just downloaded the android port and checked, all results are correct and it's version 1177. I'm sure the compiler is exactly the same (different ARM targets but still), I did not change compilers between 1177 and 1180 so this is very strange. I'll check if the latest build has the problem and will replace the bogus builds in the server so people don't download them. The only thing I can think of is that by updating the compiler for the newer chips perhaps they broke something for the old ones. Perhaps I'll have to downgrade the compiler to an older version. We'll see.

[Gilles]

Claudio, it's very strange… Il tried again this morning on the _same_ unit, _same_ build 1180 and… and now all is OK!... And no, I'm not mad ;D

I remember that I played a lot with SETNFMT and SETLOCALE yesterday sometimes with wrong arguments, but perhaps just coincidence. If i rebember well (but i'm not sure what i do before putting the HP50 OFF) : the bug was here just before the OFF, and dispareared after the ON...

.

[bzoom]

Looks like the problem is somehow connected to deg.min.sec DD.MMSS format, 45 deg = 44 deg 60 min.

[Gilles]

(04-24-2019 01:43 PM)bzoom Wrote:  Looks like the problem is somehow connected to deg.min.sec DD.MMSS format, 45 deg = 44 deg 60 min.

Yes! good catch.. and explains why :

44.9 SIN -> 0.713250449
as 44.9 -> 44+1°30mn ->45.5 and sin(45.5) is 0.713250449

EDIT : BINGO !

To reproduce the "bug" : Menu : System -> Setting -> DMS
and you get the previous behaviour. To comeback 'normal' calculation, set DEG.

To be honest, I was not aware of what is the 'DMS' mode (and understood '.d' like '.°') . But this DMS mode is little confusing for me and not coherent for now in my point of view. The good news for you Claudio is this this just a 'cosmetic' problem (or perhaps also a user problem, or a mix of the two ;D )

[Claudio L.]

(04-24-2019 03:03 PM)Gilles Wrote:  

(04-24-2019 01:43 PM)bzoom Wrote:  Looks like the problem is somehow connected to deg.min.sec DD.MMSS format, 45 deg = 44 deg 60 min.

Yes! good catch.. and explains why :

44.9 SIN -> 0.713250449
as 44.9 -> 44+1°30mn ->45.5 and sin(45.5) is 0.713250449

EDIT : BINGO !

To reproduce the "bug" : Menu : System -> Setting -> DMS
and you get the previous behaviour. To comeback 'normal' calculation, set DEG.

To be honest, I was not aware of what is the 'DMS' mode (and understood '.d' like '.°') . But this DMS mode is little confusing for me and not coherent for now in my point of view. The good news for you Claudio is this this just a 'cosmetic' problem (or perhaps also a user problem, or a mix of the two ;D )

Ohhhhhhh... And here I was going crazy, I couldn't reproduce the problem at all, but I always thought you used a 'd' in the post in lieu of the proper degree symbol, so in my tests I used the degree symbol.
Anyway, you got 44.60d as an answer which is the same as 45 degrees except I need to override the rounding on DD.MMSS quantities and make sure I consider the corner cases to avoid displaying things like 44.60d
So... to make you feel better: it is indeed a bug, it should display as 45, not 44.60
And... to make *me* feel better... it should be easy to fix, and it doesn't "taint" the reputation of newRPL as a trustworthy number cruncher.
And this same fact... should make all newRPL fans feel better.

[Gilles]

About DMS mode, perhaps it could be better that this applies only with numbers taged as angle when we use trigonometric functions (like it does for the addition). For exemple :

<\30.4510d SIN would return the SINUS of 30°45'10"
but :
30.4510 SIN would return the SINUS of decimal 30.4510 even if you are in DMS mode

The actual behaviour seems inconsistant for me, because :

<\44.30d
<\0.30d
+
returns <\45.d

but of course :
44.30
0.30
+
returns 44.60

Nota : My old Casio fx-602P displays the dms mode with a unambigous 30°45'10". It could be nice to a have in New RPL a display like this : <\30°45'10"

[Claudio L.]

(04-26-2019 10:08 PM)Gilles Wrote:  About DMS mode, perhaps it could be better that this applies only with numbers taged as angle when we use trigonometric functions (like it does for the addition). For exemple :

<\30.4510d SIN would return the SINUS of 30°45'10"
but :
30.4510 SIN would return the SINUS of decimal 30.4510 even if you are in DMS mode

The actual behaviour seems inconsistant for me, because :

<\44.30d
<\0.30d
+
returns <\45.d

but of course :
44.30
0.30
+
returns 44.60

Nota : My old Casio fx-602P displays the dms mode with a unambigous 30°45'10". It could be nice to a have in New RPL a display like this : <\30°45'10"

Let's go by parts:
The angular mode only affects how trig functions interpret raw numbers.
In other words, if a function expects an angle and you pass a real number, what should the system do?
In the same way, inverse trig functions that return an angle, in which system do you want it? That's all that DMS, DEG, RAD, GRAD modes do. Everything else is business as usual (and that's where the consistency is).

You can always enter an angle as an angle object, regardless of the mode, and it will be correctly processed. Your first example of 30.4510 SIN being interpreted as decimal degrees is exactly what you get using DEG mode (you can still feed SIN with angle objects in any other system). DMS mode is for surveyors that want quick input of angles, forcing them to use the angle symbol defeats the purpose.

Your second example of 44.30 0.30 + giving you 44.60 is consistent... with math! The system doesn't have any way to know those numbers are angles and not reals, so why would it do a DMS addition? DMS mode only affects how trig commands interpret raw numbers, not how + interprets raw numbers, that should be clear.

In my view, a programmer should always use angle objects whenever they deal with angles. They are always consistent and flag-independent. However, old code might expect SIN to accept real numbers, so I couldn't completely eliminate that without breaking a lot of old RPL code. The compromise solution was to have a systemwide angle mode alongside the new angle objects.
If it was for me, the system would be locked into RAD mode (which is the only one that gives symbolic expressions like 'SIN(X)' a unique result, independent of any flags), any other system would have to be explicitly noted using angle objects.

[Gilles]

Thanks for the reply. I understand your point of view. The key is :

(04-27-2019 06:23 PM)Claudio L. Wrote:  (...) In my view, a programmer should always use angle objects whenever they deal with angles. They are always consistent and flag-independent. However, old code might expect SIN to accept real numbers, so I couldn't completely eliminate that without breaking a lot of old RPL code. The compromise solution was to have a systemwide angle mode alongside the new angle objects. (…)

If I'm not mistaken, RPL has no specific object for 'angle'. NewRPL has it and it's a very good thing. So use it is good practice.

[3298]

Going on a tangent again...

(04-28-2019 08:30 AM)Gilles Wrote:  If I'm not mistaken, RPL has no specific object for 'angle'.

It has. The stock firmware uses the regular units system for them, which also gives you angle conversion for free. (100_grad 1_arcmin CONVERT -> 5400_arcmin) Even plain numbers are accepted for conversions, CONVERT treats them as having the unit of the current angle mode just like the trig commands do!
The only thing missing is a way to output in DMS. Input is possible by adding numbers with \^o, arcmin, arcs units together; slightly unwieldy, but it works.
Fortunately, DMS output could be retrofitted like this:

Code:

\<<
  DUP 1._\^o CONVERT IP
  OVER 1._arcmin CONVERT IP OVER 1._arcmin CONVERT -
  ROT 1._arcs CONVERT PICK3 PICK3 + 1._arcs CONVERT -
\>>

... That little program splits any angle into the three DMS components. (Lots of CONVERT here, but a simple variant down-converting through \^o, arcmin, arcs and splitting via DUP IP SWAP FP tends to introduce rounding errors when it receives a value that is in arcmin or arcs already.) Maybe this is not settable as a mode, but you can stick the program into a custom menu or a key definition so it's available on demand...
Even better, with library 256 you can have it construct a symbolic object containing the unevaluated sum, which would only occupy a single stack level instead of three. (Inspired by what complex numbers look like when flag -27 is set.)

Code:

\<<
  DUP 1._\^o CONVERT IP
  OVER 1._arcmin CONVERT IP OVER 1._arcmin CONVERT -
  ROT 1._arcs CONVERT PICK3 PICK3 + 1._arcs CONVERT -
  { + } OBJ\-> DROP DUP UNROT 5. \->ALG
\>>

Unlike complex numbers this needs an EVAL to be accepted for conversion. Other calculations get appended without being carried out; all of this happens because it's no longer a unit object but an algebraic instead.

Claudio, what will happen to existing programs using unit objects for angles - will they work in newRPL at some point?

[Claudio L.]

(04-28-2019 07:03 PM)3298 Wrote:  Claudio, what will happen to existing programs using unit objects for angles - will they work in newRPL at some point?

Good point, completely forgot that trig functions accepted unit objects. I should implement that of course, but it's not the highest priority. I'll put it in the TODO list.
There's quite a few other areas where units aren't being considered and they should be, for instance the numeric solvers. I still have to add unit support there.

[Gilles]

Hi all !

Bug report, HP50 Hdw, release 1180

Code:

 0 0 FOR 'a' a -1 STEP

or

Code:

 0 0 FOR 'a' a 1 NEG STEP

goes in endless loop or "out of memory error". Need a hdw reset.

I also noticed that ->#d can't be use in a program.

Nota : Autocompletion and new ALPHA scheme is great compared to stock HP50g.

[Claudio L.]

(05-13-2019 10:39 AM)Gilles Wrote:  Hi all !

Bug report, HP50 Hdw, release 1180

Code:

 0 0 FOR 'a' a -1 STEP

or

Code:

 0 0 FOR 'a' a 1 NEG STEP

goes in endless loop or "out of memory error". Need a hdw reset.

Thanks! I guess I have to consider the case with equal limits as a special case. Rookie mistake...

(05-13-2019 10:39 AM)Gilles Wrote:  I also noticed that ->#d can't be use in a program.

Nota : Autocompletion and new ALPHA scheme is great compared to stock HP50g.

I didn't do base conversion as separate commands. I figured since conversion is automatic (preserves the base of the first operand), all you need to do to convert a number is any operation with one argument in the desired base, for example add zero.

0 #ffh + --------> 255

I guess it wouldn't hurt to add the conversion commands, I just had better things to do at the time.

By the way, I've been quiet but active, I wrote the USB protocols for a third time, then the PC version started crashing and corrupting memory, apparently access to USB devices is not thread safe in Windows (worked so well in Linux when I developed it...). So, I had to rewrite the drivers to guarantee access to the USB device happens always from the same thread. Seems to have solved the crashes, now I'm back to polishing the new transfer protocols. Works mostly fine, it disconnects sometimes so I need to figure that out, can't be anything less than perfect if we use it for firmware updates.

[Gilles]

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

?

If not, NewRpl lacks an R->I (or a more generic A->E Approx to exact) command