newRPL - Updated to build 1510 [official build remains at 1487]

[Sylvain Cote]

(08-09-2021 07:25 PM)Wes Loewer Wrote:  (Are there other languages that execute FOR loops at least once like this?)

I am not a RPL specialist here, but the problem lies that the loop tester is in the NEXT or the STEP instruction instead of in the FOR instruction.
I agree that this is unconventional at best, I would suggest to create a new instruction (ex: FORIF, IFFOR, etc) that would include an embedded IF in the FOR, thus not breaking existing programs.
My two cents.
Sylvain

[Claudio L.]

(08-09-2021 07:25 PM)Wes Loewer Wrote:  Okay, will do. The following aren't bugs but rather more design decision questions.

I was relieved to see that ADD and + are reversed for list processing. This was a longstanding shortcoming in the 50g and its ancestors. (For those unfamiliar with this issue, see https://groups.google.com/g/comp.sys.hp4...rvP3IHIdEJ from 10+ years ago.)
I wonder though if using a word like CONCAT might be better than ADD as it is more descriptive. Perhaps you could make CONCAT a synonym but keep ADD for historical reasons.

I don't oppose to having an alias, but if it has more than 3 letters it's harder to type, so I would personally never use it!

(08-09-2021 07:25 PM)Wes Loewer Wrote:  Another quirk of the 50g that I found annoying when programming was the behavior of the FOR and START loops in that they alway execute at least once, even when the condition would indicated that the loop should not be executed at all.

In other languages that I am familiar with (pascal, c/c++, java, hp ppl), something equivalent to

Code:

 FOR I FROM 5 TO 1 DO PRINT(I) END

would not print anything at all since the exit condition is already met before the loop begins. However, on the 50g, FOR loops are always executed at least once. So instead of something like

Code:

A B FOR I ... NEXT

you'd have to nest it within an IF statement.

Code:

IF A B <= THEN A B FOR I ... NEXT END

which always struck me as a bit of a kludge.

I noticed that newRPL reproduces this behavior. I can understand the pressure to do this to maintain compatibility, but I wondered since you were willing to break compatibility with ADD/+ for a good cause, then maybe you'd be willing to do the same with the FOR and START loops in order to be more logical and more consistent with other languages.

(Are there other languages that execute FOR loops at least once like this?)

Thoughts?

This is a very fundamental behavior of RPL. Breaking + and ADD affects only a few programs and it's a relatively easy fix. Changing the behavior of loops means almost EVERY program would be affected, and they would all need to be rewritten.

So I'd keep FOR the way it is, but I agree with Sylvain nothing prevents creating a new loop structure.
The problem with FOR is because the STEP is not known until you reach that statement, so the check cannot be done at the beginning.
Maybe:

Code:


<start> <end> <step> STEPFOR ... NEXT
<start> <end> <step> STEPFOR ... <step> STEP

This would be exactly like performing an additional STEP instruction before the FOR, which would exit the loop if the limits are in the wrong direction, and enter the loop otherwise (without actually doing the STEP in the counter). This solution could easily be intermixed with the standard FOR NEXT and STEP instructions.

Another completely different direction would be to implement a more generic FOR (C-Style):

Code:


 <<init clause>> <<test clause>> <<increment clause>> STARTFOR ... ENDFOR

In this case, STARTFOR takes 3 arguments. It EVALs the first, then EVALs the test clause before entering the loop, then ENDFOR will EVAL increment clause, then test clause, then restart the loop.

But it becomes very similar to the DO ... UNTIL ... END, or WHILE ... REPEAT ... END loop, so I'm not convinced it's worth adding something like this.

[Wes Loewer]

(08-09-2021 09:39 PM)Claudio L. Wrote:  I don't oppose to having an alias, but if it has more than 3 letters it's harder to type, so I would personally never use it!

I almost suggested CAT (à la unix)

Quote:So I'd keep FOR the way it is, but I agree with Sylvain nothing prevents creating a new loop structure.

Yes, that's an even better idea.

Quote:Maybe:

Code:

<start> <end> <step> STEPFOR ... NEXT

Of all the examples you showed, this one would get my vote. As you said, anything more starts to look the same as a WHILE-DO loop. Although, I would reverse the name to FORSTEP which indicates that it replaces the FOR-STEP loop and suggests the order of the arguments. (Likewise for STARTSTEP.)

For style, you could even have a command that would replace "1 STEPFOR" such as the FORIF suggested by Sylvain. Such commands could only be paired with a NEXT, not a STEP.

Code:

<start> <end> <step> FORSTEP <var> ... NEXT
<start> <end> <step> STARTSTEP ... NEXT

<start> <end> FORIF <var> ... NEXT
<start> <end> STARTIF ... NEXT

of some such appropriately named commands.

Of course, my suggestion could be viewed as unnecessary since the desired behavior could be produced with a FOR nested in an IF, but I figured, hey, if you're going to create a new product, now is the time to bring things like this up before things get set in stone.

-wes

[John Keith]

I agree that AND is rather non-intuitive for concatenating lists, on the other hand CAT makes me think CATalog more than conCATenation. Haskell uses ++ which I like but I doubt that the parser could handle it. Also potentially confusing since ++ means increment in C.

I also like the idea of FORSTEP/STARTSTEP but I'm not sure which syntax I prefer.

[Wes Loewer]

(08-10-2021 03:43 PM)John Keith Wrote:  I agree that AND is rather non-intuitive for concatenating lists

Especially since AND is already used with list processing.

[Claudio L.]

(08-10-2021 03:09 PM)Wes Loewer Wrote:  

(08-09-2021 09:39 PM)Claudio L. Wrote:  I don't oppose to having an alias, but if it has more than 3 letters it's harder to type, so I would personally never use it!

I almost suggested CAT (à la unix)

Quote:So I'd keep FOR the way it is, but I agree with Sylvain nothing prevents creating a new loop structure.

Yes, that's an even better idea.

Quote:Maybe:

Code:

<start> <end> <step> STEPFOR ... NEXT

Of all the examples you showed, this one would get my vote. As you said, anything more starts to look the same as a WHILE-DO loop. Although, I would reverse the name to FORSTEP which indicates that it replaces the FOR-STEP loop and suggests the order of the arguments. (Likewise for STARTSTEP.)

For style, you could even have a command that would replace "1 STEPFOR" such as the FORIF suggested by Sylvain. Such commands could only be paired with a NEXT, not a STEP.

Code:

<start> <end> <step> FORSTEP <var> ... NEXT
<start> <end> <step> STARTSTEP ... NEXT

<start> <end> FORIF <var> ... NEXT
<start> <end> STARTIF ... NEXT

of some such appropriately named commands.

Of course, my suggestion could be viewed as unnecessary since the desired behavior could be produced with a FOR nested in an IF, but I figured, hey, if you're going to create a new product, now is the time to bring things like this up before things get set in stone.

-wes

Thinking some more about it: since the variable is not changed during the early check, we don't need the magnitude of the step, just the direction.
The early check then becomes:
If sign('step') > 0 ---> Loop if 'start' <= 'end' , otherwise exit
if sign('step') < 0 ---> Loop if 'start' >= 'end' , otherwise exit
if sign('step') == 0 ---> Loop if 'start' == 'end', otherwise exit

So, instead of taking an extra argument with the step, maybe we should include the direction in the command name, that way all new commands become "drop-in" replacements for the standard FOR when the user needs that early check.
I think we'll settle for the following (unless there's any objections):

Code:


<start> <end> FORFWD <var> ... NEXT (or STEP)
<start> <end> FORREV <var> ... NEXT (or STEP)

<start> <end> STARTFWD ... NEXT (or STEP)
<start> <end> STARTREV ... NEXT (or STEP)

[Wes Loewer]

(08-10-2021 06:29 PM)Claudio L. Wrote:  I think we'll settle for the following (unless there's any objections):

Code:


<start> <end> FORFWD <var> ... NEXT (or STEP)
<start> <end> FORREV <var> ... NEXT (or STEP)

<start> <end> STARTFWD ... NEXT (or STEP)
<start> <end> STARTREV ... NEXT (or STEP)

Seems very reasonable to me. Simple, clear, effective, easily understood.

I assume the FWD versions would require a positive STEP and the REV would require a negative STEP.

[ttw]

Fortran (starting in Fortran 77) uses the equivalent formulation:

DO I=k1,k2,k3
...
ENDDO

where k1 is the start, k2 the end, and k3 the increment. There is a formula giving the number of cycles. If k2-k1>0 and k3 is positive (default +1), then (k1-k2)/k3 gives the number of iterations (think the floor is used as zero or negative trip loops are skipped). A negative k3 runs the loop backward. The trip count is computed before the loop started and changes in any of the arguments within the loop are ignored. I preferred using DO I=k1:k2:k3 in line with Fortran's list constructors but the commas have been used since 1954. (Fortran is mostly backward compatible.)

The "mandatory one trip" loop did exist in non-standard Fortrans and (I think) Fortran 66.

The 77 style loops are mainly used for array manipulation. Earlier style control structures are more easily (and flexibly) handled by IF constructs and GOTOs. Most array manipulations can even be used with Fortran 90s array stuff.

As an aside, while working on the Fortran standard, I put together an array-oriented language that had some unusual stuff. Loops used the Fortran 77 loop starting but allowed the index to be varied as the array operations handled everything else. Arrays used C=A op B for the usual (+ - * / ^ ) for conformable arrays. Dummy bound arguments for the linear algebra of tensor stuff. Matrix multiply: C(*i, *j) = A(*i, %k)*B(%k, *j) or something similar: *s represented ordinary bound variables running over array bounds and %s represented bound variables summed over. (Or maybe other symbols.) It was convenient enough that I still write formulas this way, then convert to Fortran (or whatever.)

[Claudio L.]

(08-10-2021 06:56 PM)Wes Loewer Wrote:  

(08-10-2021 06:29 PM)Claudio L. Wrote:  I think we'll settle for the following (unless there's any objections):

Code:


<start> <end> FORFWD <var> ... NEXT (or STEP)
<start> <end> FORREV <var> ... NEXT (or STEP)

<start> <end> STARTFWD ... NEXT (or STEP)
<start> <end> STARTREV ... NEXT (or STEP)

Seems very reasonable to me. Simple, clear, effective, easily understood.

I assume the FWD versions would require a positive STEP and the REV would require a negative STEP.

It wouldn't "require" anything, you are still free to use any STEP if you want to.
The logic of FOR is a little quirky:
FOR determines the direction of the loop from the start and end arguments: if start<end it assumes forward (positive) and vice versa. That implied direction determines the check that STEP uses, regardless of the actual value given to STEP.
For example, 1 3 FOR K ... n STEP will assume a forward loop, and the comparison to end the loop is K<=3, regardless of the value of n. This allows a loop to backtrack the variable by using a negative STEP whenever needed.
Is this automatic determination of the direction what prevents the loop from exiting early: it always does one run because (start <= end) or (start >= end) is always true for the chosen loop direction.

The new proposal, providing the loop direction explicitly is the best solution. FORFWD will always use var<=end, therefore upon entry you can exit if start>end. Same for FORREV.

Which name is best, FORFWD of FORUP, also FORREV or FORDN or FORDOWN?

[rprosperi]

1 vote for FORUP / FORDN.

They're shorter and 'counting up' and 'counting down' is probably more intuitive than 'counting forward' and 'counting backward'.

[Sylvain Cote]

(08-11-2021 02:54 PM)rprosperi Wrote:  1 vote for FORUP / FORDN.

FWIW same here!

[Wes Loewer]

(08-11-2021 02:31 PM)Claudio L. Wrote:  Which name is best, FORFWD of FORUP, also FORREV or FORDN or FORDOWN?

I think they are both equally clear. I'd give FORDN/FORDOWN a slight advantage as being consistent with some languages (pascal, hp-ppl) which use DOWNTO to count backwards.

Between FORDN and FORDOWN, DOWN is more clear but DN is easier to type. I have no opinion on that one.

[John Keith]

(08-13-2021 04:10 AM)Wes Loewer Wrote:  [

Between FORDN and FORDOWN, DOWN is more clear but DN is easier to type. I have no opinion on that one.

Terseness being a hallmark of RPL, I vote for FORDN.

[Claudio L.]

Unofficial ROMs updated to 1497.

Time to test the new FORUP and FORDN commands!
Other bugs in ATAN, LN should be fixed now, please test.

[gianluca]

(08-24-2021 03:55 PM)Claudio L. Wrote:  Unofficial ROMs updated to 1497.

Time to test the new FORUP and FORDN commands!
Other bugs in ATAN, LN should be fixed now, please test.

Hi Claudio, I have just updated my hp39gs from v.1487 to v.1497 and... it's not gone as expected.
the "Data abort" error appeared and persisted: no way to get rid of it via H/W reset or via key combinations (ON+A+F, ON+A+C, etcetera).

   

The device could not be turned off, so the only way to actually restart the calculator was to remove all the batteries (CR2032 included, otherwise it will not work), wait a few seconds and re-install them.

Now the 39gs seems to be ok (as in the second image attached); my only question is: there is another way to effectively reset the device in case of Data abort exception, just not to panic the next time this will happen?
Maybe this behaviour only happens with the hp39gs?

   

Thank you for your work!

GianLuca

[Claudio L.]

(09-01-2021 03:49 PM)gianluca Wrote:  

(08-24-2021 03:55 PM)Claudio L. Wrote:  Unofficial ROMs updated to 1497.

Time to test the new FORUP and FORDN commands!
Other bugs in ATAN, LN should be fixed now, please test.

Hi Claudio, I have just updated my hp39gs from v.1487 to v.1497 and... it's not gone as expected.
the "Data abort" error appeared and persisted: no way to get rid of it via H/W reset or via key combinations (ON+A+F, ON+A+C, etcetera).



The device could not be turned off, so the only way to actually restart the calculator was to remove all the batteries (CR2032 included, otherwise it will not work), wait a few seconds and re-install them.

Now the 39gs seems to be ok (as in the second image attached); my only question is: there is another way to effectively reset the device in case of Data abort exception, just not to panic the next time this will happen?
Maybe this behaviour only happens with the hp39gs?



Thank you for your work!

GianLuca

Yes, of course there is. The equivalent of TTRM+"NO" to wipe out corrupted memory works like this:
After reset, press any key immediately, but I mean *immediately* (you need to be really, really fast).

Reset may be done from the Data abort exception screen with the "Reset" option using any shift key (in other words, shift-hold+ Reset), but you need to have quick fingers: As soon as you release the reset you need to press another key (like backspace) but really quick. What works best for me is to do a "triple-click" on that key as fast as possible because if you are too quick you'll get a gray blank screen that's just waiting for you to release all keys. In that case you need to release and press back very quickly (hence the triple-click helps because you are mentally ready to release and press back).
Using the paperclip hole for reset makes it very hard to be quick enough (because you are holding the calc in the air), so I lay the calc flat and do a software Reset (On+A+F then Shift+Reset or in this case from the Data Abort screen) followed by a triple-click very fast.
If you do it quick enough (might have to try a couple of times), it will show "EXCEPTION: Wipeout requested". Now you'll select "Clear Memory" pressing ALL 3 SHIFTS simultaneously (ON+RS+LS+(C or D)).

Takes a long time to explain it, but a fraction of a second to do it, that's life

[Claudio L.]

(09-01-2021 03:49 PM)gianluca Wrote:  Hi Claudio, I have just updated my hp39gs from v.1487 to v.1497 and... it's not gone as expected.

By the way, this happened to me also in some occasions but only between 1487 and 1497. I tried older versions and did not have a problem upgrading. I do not know why, so I added a note on the first post to make sure you back up before (did you!?? I hope so).

[gianluca]

(09-01-2021 04:53 PM)Claudio L. Wrote:  Using the paperclip hole for reset makes it very hard to be quick enough (because you are holding the calc in the air), so I lay the calc flat and do a software Reset (On+A+F then Shift+Reset or in this case from the Data Abort screen) followed by a triple-click very fast.
If you do it quick enough (might have to try a couple of times), it will show "EXCEPTION: Wipeout requested". Now you'll select "Clear Memory" pressing ALL 3 SHIFTS simultaneously (ON+RS+LS+(C or D)).

Takes a long time to explain it, but a fraction of a second to do it, that's life

Alright, I should definitely try and learn these manual skills.

(09-01-2021 04:58 PM)Claudio L. Wrote:  By the way, this happened to me also in some occasions but only between 1487 and 1497. I tried older versions and did not have a problem upgrading. I do not know why, so I added a note on the first post to make sure you back up before (did you!?? I hope so).

Yes, I did :-) .

Thank you again.

GianLuca

[Wes Loewer]

(08-24-2021 03:55 PM)Claudio L. Wrote:  Unofficial ROMs updated to 1497.

When trying to update to 1497, the install seemed to go okay, but upon reboot the calculator would bring up an exception screen. I tried downloading and installing multiple times without success.

Reinstalling 1487 went fine and the calculator is now working as before.
-wes

[JoJo1973]

(08-24-2021 03:55 PM)Claudio L. Wrote:  Unofficial ROMs updated to 1497.

Time to test the new FORUP and FORDN commands!
Other bugs in ATAN, LN should be fixed now, please test.

I'd like to submit my entry for the Suggested Command of the Month© contest... an implementation of the Check&Dispatch structure!

As we all know, all RPL variants encourage a bottom-up approach to programming and this means that usually there is a main program that crunches the input data to ensure it is valid before calling the actual subroutines.

The problem is that this task can become incredibly boring and convoluted, especially if the objective is to write a library. The simple task to check for three arguments on the stack being a list and two positive integers robs the programming of half the fun!

To ease the burden nothing beats the elegance of SystemRPL's Ck&Dispatch structure which I propose to implement in NewRPL as follows:

Code:


CHECK
    { arglist1 } THEN
        ...
    END
    { arglist2 } THEN
        ...
    END
    .
    .
    .
    ELSE
        ...
    END
END

Each arglist is a list of real numbers, where positive ones are compared against the output of TYPE (if integer) / TYPEE (if they have fractional part), negative one against the output of VTYPE/VTYPEE and 0's are just placeholders meaning "any type".

The check mechanism would retain SystemRPL behaviour wrt tagged objects: the arguments are checked twice; in the first pass tagged objects trigger a match only if arglist explicitly requires a tagged object; in the second pass the tags are stripped and the payload is checked to trigger a match.

It's not mandatory for the arglists to have the same length: the first valid match is dispatched.

The ELSE clause is optional: the default behaviour is "Bad Argument Count" in case of total mismatch or "Bad Argument Type" if at least there is a count match.

Some arglist examples:

Code:


{ } THEN 'SUB0' XEQ END                   @ No arguments: trivial but legal

{ 0 0 0 } THEN 'SUB1' XEQ END             @ Three items on the stack, no matter their type

{ 62 10 } THEN 'SUB2' XEQ END             @ A list and a real number (any kind of real: integer, not integer, exact, approximate, binary, hexadecimal...)

{ 52 10.22 10.33 } THEN 'SUB3' XEQ END    @ A matrix and two real numbers, an approx octal and an exact hex

{ -62 0 10.12 } THEN 'SUB4' XEQ END       @ A variable containing a list, a generic object
                                          @ and a real number, integer and exact

Of course the CHECK..END structure isn't necessarily used to call other programs:

Code:


«
  CHECK
    { 62 } THEN
      « CHECK { 10.12 } THEN DROP 1 END ELSE DROP 0 END »
      1
      DOLIST
      ΠLIST
    END
    { -62 } THEN
      DUP RCL
      « CHECK { 10.12 } THEN DROP 1 END ELSE DROP 0 END »
      1
      DOLIST
      ΠLIST
    END
  END
»

Returns 1 if the argument is a list (or a variable storing a list) of undetermined size containing integer, exact elements and 0 otherwise. I'm assuming here that CHECK doesn't 'consume' the stack.

The arglist concept could also be useful during library creation: at the moment the programmer must provide the number of parameters; instead it could provide a "list of arglists" albeit with the limitation that they must have the same size to comply with NewRPL programming practices.

The beauty is also that as long as sub-type identification becomes smarter, CHECK..END becomes more powerful.

What do you think?