text:
newRPL - Updated to build 1497 [official build remains at 1487]
09-07-2021, 08:54 PM
Post: #181
 BruceH Senior Member Posts: 390 Joined: Dec 2013
RE: newRPL - Updated to build 1497 [official build remains at 1487]
(09-07-2021 06:07 PM)JoJo1973 Wrote:  What do you think?

An alternative approach to parameter checking that results in a very compact check at the start of a program was written for the HP50G and appears in Datafile V27N4P20 (available on Jake Schwartz's PPC Computer Archive collection).

For example a program starting << "Xnu" PTYPE ... >> will abort with an error message (the 'X') unless the stack contains a number (real or integer) on level 1 and a number with units attached in level 2.

I'd be happy for Claudio to include something like PTYPE in newRPL.
09-08-2021, 03:10 PM (This post was last modified: 09-08-2021 03:14 PM by Claudio L..)
Post: #182
 Claudio L. Senior Member Posts: 1,840 Joined: Dec 2013
RE: newRPL - Updated to build 1497 [official build remains at 1487]
(09-07-2021 06:07 PM)JoJo1973 Wrote:  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?

Looks nice and clean! But maybe we can reuse the CASE structure with some clever commands and not introduce another complex flow control structure into the language.
On another hand, the CK&Dispatch method almost never worked for me in real life, except for very simple commands.
You end up with situations where 5 or 10 cases are needed for the same basic code, then other 5 or 10 for another, etc.
A very simple example, some code takes 1 argument: can be a real or a complex. Your code works the same whether is a real or complex, all you need is a "numeric". Also you may accept the complex i constant (which has a different type but it's 100% equivalent to (0,1)), so you'll end up with 3 argument list cases for the exact same code. Now let's imagine one that takes 2 of these arguments. Your list cases will need to cover all combinations: real/real, real/complex, real/i, complex/real, complex/complex, complex/i, i/real, i/complex, i/i.
So it explodes into a nightmare really easily. It would be OK if you needed different code for each case, but in most cases you don't.
What I find works better for me is to check the arguments one by one, and each argument against a list of valid types, not just one type.
Something like:
Code:
 1 { 10 30 55 } ARGCK
In this case, ARGCK takes a stack level and a list of valid types. It will error Bad Argument Type if there's no match, or continue execution if everything is fine. There could also be a version that doesn't error but returns true/false for example, to be used in IF or CASE statements.
In the example above with 2 arguments, you could simply do them in sequence:
Code:
 1 { 10 30 55 } ARGCK 2 { 10 30 55 } ARGCK

If it didn't error, you have the right types. Now let's say some cases need special handling, in the example above we may want to convert the constant 'i' into a complex number by doing ->NUM, and perhaps accept other things like a complex number in symbolic form '1+i'.
Let's say we create the ARGCKTF command (ARG ChecK True/False, I'm open to better name suggestions) that doesn't error, we can use IF to simply do ->NUM and try again:
Code:
 IF 1 { 55 32 56 } ARGCKTF THEN ->NUM END 1 {10 30 } ARGCK

So we check first if argument 1 is a constant, a variable identifier (because, why not?) or a symbolic and we run ->NUM. After that, we check that we ended up either with a real or a complex number, and error if not.

This is some hybrid between what Bruce proposed (one compact command that errors if there's no match), your proposal using a list of TYPE/TYPEE numbers and my own spin checking arguments one by one in sequence rather than in bulk.

Can you think of cases where these 2 commands would fail to work well?

**EDIT**: By the way, if the depth of the stack is less than the argument number you passed to ARGCK, then it will error Bad Argument Count so that case is covered and you never need to provide an argument count.
09-08-2021, 05:21 PM
Post: #183
 3298 Member Posts: 179 Joined: Oct 2014
RE: newRPL - Updated to build 1497 [official build remains at 1487]
I believe that a custom case structure is an overengineered solution, the simple command CKARG appears more reasonable (a building block that can be used in a normal case structure, or in a wholly different manner if you want).

If I may, I'd like to request replacing the simple true/false flag with an index of which type in the list matched (with 0 as placeholder for no match, like POS does). In RPL anything that isn't 0 counts as true anyway, so the value can be used for the same purposes, and performance-wise it should be a freebie, but in situations where the cases are similar but not quite the same the programmer could use this index to pull the type-specific handling code out of a list, then follow up with the common code. For instance, if your program shall accept a list or a vector and treat either as coordinates, that would allow something like this, based around AXL to coerce the input into one canonical format:
Code:
... CKARGTF IF DUP NOT THEN DROP "Bad Argument Type" DOERR ELSE { AXL \<< \>> } SWAP GET EVAL   ... END
(NOP would be nice to have by the way, here I used an empty program instead. And yes, I'm using traditional RPL trigraphs instead of newRPL's Unicode glyphs; should be understandable either way.)
This kind of dispatching also opens the door to a third command that returns the index but retains the error-out on no match.

In the end, CKARGTF would arrive at something like this UserRPL implementation:
Code:
\<<   SWAP   1. + (adjusting stack level parameter for the types list in the way)   PICK (fetch the object for examination; also serves as a stack depth guard)   TYPE POS \>>
This one doesn't have auto-detagging and such, but it should serve as a prototype to experiment with before deciding on whether to implement it as a native command. Additional features can be prototyped as wrappers around this, e.g. the error-checking CKARG would be
Code:
\<<   IF CKARGTF NOT   THEN "Bad Argument Type" DOERR   END \>>
As a hint for a tag-stripping wrapper, DTAG would be the key command; though I didn't check if newRPL has that one yet.

Side note: I'm a SysRPL programmer, but in >90% of my programs type-checking doesn't use CK&Dispatch1 or its siblings. It's not as awesome as it appears to be. Checking each stack level (or group of them, in some cases) in turns is where it's at.
09-08-2021, 05:35 PM
Post: #184
 JoJo1973 Member Posts: 104 Joined: Apr 2016
RE: newRPL - Updated to build 1497 [official build remains at 1487]
(09-08-2021 03:10 PM)Claudio L. Wrote:  Looks nice and clean! But maybe we can reuse the CASE structure with some clever commands and not introduce another complex flow control structure into the language.
On another hand, the CK&Dispatch method almost never worked for me in real life, except for very simple commands.
You end up with situations where 5 or 10 cases are needed for the same basic code, then other 5 or 10 for another, etc.
A very simple example, some code takes 1 argument: can be a real or a complex. Your code works the same whether is a real or complex, all you need is a "numeric". Also you may accept the complex i constant (which has a different type but it's 100% equivalent to (0,1)), so you'll end up with 3 argument list cases for the exact same code. Now let's imagine one that takes 2 of these arguments. Your list cases will need to cover all combinations: real/real, real/complex, real/i, complex/real, complex/complex, complex/i, i/real, i/complex, i/i.
So it explodes into a nightmare really easily. It would be OK if you needed different code for each case, but in most cases you don't.

Well, Ck&Dispatch is probably best suited for Saturn architecture: your 'orthogonal' approach yields more synthetic code so I'm all for it.

Quote:What I find works better for me is to check the arguments one by one, and each argument against a list of valid types, not just one type.
Something like:
Code:
 1 { 10 30 55 } ARGCK
In this case, ARGCK takes a stack level and a list of valid types. It will error Bad Argument Type if there's no match, or continue execution if everything is fine. There could also be a version that doesn't error but returns true/false for example, to be used in IF or CASE statements.
In the example above with 2 arguments, you could simply do them in sequence:
Code:
 1 { 10 30 55 } ARGCK 2 { 10 30 55 } ARGCK

If it didn't error, you have the right types. Now let's say some cases need special handling, in the example above we may want to convert the constant 'i' into a complex number by doing ->NUM, and perhaps accept other things like a complex number in symbolic form '1+i'.
Let's say we create the ARGCKTF command (ARG ChecK True/False, I'm open to better name suggestions) that doesn't error, we can use IF to simply do ->NUM and try again:
Code:
 IF 1 { 55 32 56 } ARGCKTF THEN ->NUM END 1 {10 30 } ARGCK

So we check first if argument 1 is a constant, a variable identifier (because, why not?) or a symbolic and we run ->NUM. After that, we check that we ended up either with a real or a complex number, and error if not.

This is some hybrid between what Bruce proposed (one compact command that errors if there's no match), your proposal using a list of TYPE/TYPEE numbers and my own spin checking arguments one by one in sequence rather than in bulk.

It's pretty versatile, what about 'CHECK' for the T/F version and 'CHECKFAIL' for the other one?

What I think is important is to keep the usage of negative types to differentiate between TYPEE/VTYPEE and the automatic stripping of tags à la Ck&Dispatch

BTW CHECK could return the matching type or 0 instead of a plain 1/0.

Quote:Can you think of cases where these 2 commands would fail to work well?

**EDIT**: By the way, if the depth of the stack is less than the argument number you passed to ARGCK, then it will error Bad Argument Count so that case is covered and you never need to provide an argument count.

That's good!
09-08-2021, 09:28 PM
Post: #185
 Claudio L. Senior Member Posts: 1,840 Joined: Dec 2013
RE: newRPL - Updated to build 1497 [official build remains at 1487]
(09-08-2021 05:21 PM)3298 Wrote:  If I may, I'd like to request replacing the simple true/false flag with an index of which type in the list matched (with 0 as placeholder for no match, like POS does). In RPL anything that isn't 0 counts as true anyway, so the value can be used for the same purposes, and performance-wise it should be a freebie, but in situations where the cases are similar but not quite the same the programmer could use this index to pull the type-specific handling code out of a list, then follow up with the common code. For instance, if your program shall accept a list or a vector and treat either as coordinates, that would allow something like this, based around AXL to coerce the input into one canonical format:
Code:
... CKARGTF IF DUP NOT THEN DROP "Bad Argument Type" DOERR ELSE { AXL \<< \>> } SWAP GET EVAL   ... END

I like it, well thought out and minimal implementation effort on my part.

(09-08-2021 05:21 PM)3298 Wrote:  (NOP would be nice to have by the way, here I used an empty program instead. And yes, I'm using traditional RPL trigraphs instead of newRPL's Unicode glyphs; should be understandable either way.)
This kind of dispatching also opens the door to a third command that returns the index but retains the error-out on no match.

Perhaps there should be only one command that ALWAYS return a result, worst case if you don't need it just DROP it.

(09-08-2021 05:21 PM)3298 Wrote:  Side note: I'm a SysRPL programmer, but in >90% of my programs type-checking doesn't use CK&Dispatch1 or its siblings. It's not as awesome as it appears to be. Checking each stack level (or group of them, in some cases) in turns is where it's at.

Yeah, that was my experience as well, looks great on paper but doesn't help at the most basic things.

(09-08-2021 05:35 PM)JoJo1973 Wrote:  Well, Ck&Dispatch is probably best suited for Saturn architecture: your 'orthogonal' approach yields more synthetic code so I'm all for it.

[quote='JoJo1973' pid='151885' dateline='1631122553']
It's pretty versatile, what about 'CHECK' for the T/F version and 'CHECKFAIL' for the other one?
I used ARGCK, 3298 used CKARG (I think it's better than mine) and you used CHECK. I don't know, we can always leave that decision for the last minute, once we agree on the functionality of each command maybe the right the name will come to us.

(09-08-2021 05:35 PM)JoJo1973 Wrote:  What I think is important is to keep the usage of negative types to differentiate between TYPEE/VTYPEE and the automatic stripping of tags à la Ck&Dispatch

BTW CHECK could return the matching type or 0 instead of a plain 1/0.
I like the idea of the negative numbers, but perhaps we can expand it a little more.
As far as TAGs, all tagged objects TYPE is 10000 + the type of the tagged object, so you don't really need to strip the tag to type check it.

Perhaps we could use exact/approximated numbers in the list to indicate a "loose" comparison.
where:
* First the objects are type-matched exactly.
* Tagged objects are type-matched after subtracting 10000 to the type
If the number in the argument list is exact, comparison ends here.
If there's no match, it continues as follows...
If the number in the list is approximate, additional checks are done:
* Variable names are recalled and their content is type-matched.
* Constants are replaced with their numeric values then type-matched
* Symbolic expressions are evaluated with ->NUM and the result is type-matched
* Programs are executed with XEQ and the result type-matched (that program better leave one result on the stack...)

Some examples:
10. ----> Match a real number, even when inside a variable, or an expression that evaluates to a real number, or a tagged real.
10010 -----> Match a tagged real number only, tag is required.
10010. -----> Match a tagged real inside a variable
10000 -----> Match any tagged object

We still have the negative sign to do other stuff.
09-08-2021, 10:40 PM
Post: #186
 JoJo1973 Member Posts: 104 Joined: Apr 2016
RE: newRPL - Updated to build 1497 [official build remains at 1487]
(09-08-2021 09:28 PM)Claudio L. Wrote:  As far as TAGs, all tagged objects TYPE is 10000 + the type of the tagged object, so you don't really need to strip the tag to type check it.

Huh, didn't realize it!

Quote:Perhaps we could use exact/approximated numbers in the list to indicate a "loose" comparison.
where:
* First the objects are type-matched exactly.
* Tagged objects are type-matched after subtracting 10000 to the type
If the number in the argument list is exact, comparison ends here.
If there's no match, it continues as follows...
If the number in the list is approximate, additional checks are done:
* Variable names are recalled and their content is type-matched.
* Constants are replaced with their numeric values then type-matched
* Symbolic expressions are evaluated with ->NUM and the result is type-matched
* Programs are executed with XEQ and the result type-matched (that program better leave one result on the stack...)

Some examples:
10. ----> Match a real number, even when inside a variable, or an expression that evaluates to a real number, or a tagged real.
10010 -----> Match a tagged real number only, tag is required.
10010. -----> Match a tagged real inside a variable
10000 -----> Match any tagged object

We still have the negative sign to do other stuff.

But this would mean to devise a comparison schema that is radically different from the one used by TYPEE. We would end having two incomplete features instead of one.

Inspired by the initial implementation of TYPEE I drafted a proposal that can be adapted to all object types and it's based on the principle that each property is encoded by a decimal digit different from zero. The zero being a wildcard when the extended type is interpreted in the context of type matching.

For example, the extended type for real numbers would be like this:

Therefore the extended type of 123.45. becomes 10.12122 and you can extract (with DIGITS perhaps?) all the info you might need.

In type-checking this value would still match against 10(.00000) if you need a simple real or against 10.1002 if you need a finite approx.

Real numbers are the building block of more complicate types therefore if you need to check for a temperature increment greater or equal to zero (or a variable containing it) you would do

Code:
 IF 1 { 54.04 -54.04 } ARGCKTF THEN ->NUM UVAL END 1 { 10.100011 } ARGCK

Since unit subtype describes only properties relevant to unit objects and not relevant to the "payload".

Attached File(s)
09-08-2021, 10:50 PM
Post: #187
 JoJo1973 Member Posts: 104 Joined: Apr 2016
RE: newRPL - Updated to build 1497 [official build remains at 1487]
(09-08-2021 09:28 PM)Claudio L. Wrote:  I like the idea of the negative numbers, but perhaps we can expand it a little more.
As far as TAGs, all tagged objects TYPE is 10000 + the type of the tagged object, so you don't really need to strip the tag to type check it.

Perhaps we could use exact/approximated numbers in the list to indicate a "loose" comparison.
where:
* First the objects are type-matched exactly.
* Tagged objects are type-matched after subtracting 10000 to the type
If the number in the argument list is exact, comparison ends here.
If there's no match, it continues as follows...
If the number in the list is approximate, additional checks are done:
* Variable names are recalled and their content is type-matched.
* Constants are replaced with their numeric values then type-matched
* Symbolic expressions are evaluated with ->NUM and the result is type-matched
* Programs are executed with XEQ and the result type-matched (that program better leave one result on the stack...)

Some examples:
10. ----> Match a real number, even when inside a variable, or an expression that evaluates to a real number, or a tagged real.
10010 -----> Match a tagged real number only, tag is required.
10010. -----> Match a tagged real inside a variable
10000 -----> Match any tagged object

We still have the negative sign to do other stuff.

Oops, I re-read it less hastily and I realize that your extension is not in conflict with extended types... Now I understand your point!
09-09-2021, 03:19 AM
Post: #188
 Claudio L. Senior Member Posts: 1,840 Joined: Dec 2013
RE: newRPL - Updated to build 1497 [official build remains at 1487]
(09-08-2021 10:50 PM)JoJo1973 Wrote:  Oops, I re-read it less hastily and I realize that your extension is not in conflict with extended types... Now I understand your point!

Yes, I never meant to break the extended type checking. Just that in my examples I used only integers. But I like the extend type information as a means to reject arguments out of range. Although the automatic argument check will not produce an error message as useful as if the programmer does it manually. I like newRPL style errors like "Expected an integer number" rather than "Bad Argument Type".
The automatic checker will never give an error like "Expected a real number 0<x<30" unfortunately.
09-09-2021, 07:49 AM (This post was last modified: 09-09-2021 07:51 AM by JoJo1973.)
Post: #189
 JoJo1973 Member Posts: 104 Joined: Apr 2016
RE: newRPL - Updated to build 1497 [official build remains at 1487]
(09-09-2021 03:19 AM)Claudio L. Wrote:  The automatic checker will never give an error like "Expected a real number 0<x<30" unfortunately.

ARGCK could accept a third parameter:

Integer: Issue corresponding error
String: DOERR
Program/Identifier: Error handler
09-09-2021, 03:47 PM
Post: #190
 Claudio L. Senior Member Posts: 1,840 Joined: Dec 2013
RE: newRPL - Updated to build 1497 [official build remains at 1487]
(09-09-2021 07:49 AM)JoJo1973 Wrote:
(09-09-2021 03:19 AM)Claudio L. Wrote:  The automatic checker will never give an error like "Expected a real number 0<x<30" unfortunately.

ARGCK could accept a third parameter:

Integer: Issue corresponding error
String: DOERR
Program/Identifier: Error handler

OK, so let's get organized:
The commands would be then 2 separate ones:
Code:
 <arg # (stack level)> <List of valid types> CKARG <arg # (stack level)> <List of valid types> <Error/Message> CKARGERR

Where the <Error/Message> parameter can be as you described above.

CKARG would return the POS of the item that matches, or 0 if no match. No error is thrown.
CKARGERR returns the POS of the item, otherwise throws the given error message (or XEQ the handler).
Now there's 2 possible error conditions:
a) If the stack is not deep enough ---> issues a "Bad Argument Count" error, it does NOT run the handler or use the given message
b) If there's no match ---> Custom message / XEQ error handler

Are we good with this? I think specs are pretty much finished, let's agree on names and I can get coding.
09-09-2021, 05:25 PM
Post: #191
 JoJo1973 Member Posts: 104 Joined: Apr 2016
RE: newRPL - Updated to build 1497 [official build remains at 1487]
(09-09-2021 03:47 PM)Claudio L. Wrote:
(09-09-2021 07:49 AM)JoJo1973 Wrote:  ARGCK could accept a third parameter:

Integer: Issue corresponding error
String: DOERR
Program/Identifier: Error handler

OK, so let's get organized:
The commands would be then 2 separate ones:
Code:
 <arg # (stack level)> <List of valid types> CKARG <arg # (stack level)> <List of valid types> <Error/Message> CKARGERR

Where the <Error/Message> parameter can be as you described above.

CKARG would return the POS of the item that matches, or 0 if no match. No error is thrown.
CKARGERR returns the POS of the item, otherwise throws the given error message (or XEQ the handler).
Now there's 2 possible error conditions:
a) If the stack is not deep enough ---> issues a "Bad Argument Count" error, it does NOT run the handler or use the given message
b) If there's no match ---> Custom message / XEQ error handler

Are we good with this? I think specs are pretty much finished, let's agree on names and I can get coding.

Sure, Bad Argument Count should have the precedence.
10-04-2021, 09:17 PM
Post: #192
 JoJo1973 Member Posts: 104 Joined: Apr 2016
RE: newRPL - Updated to build 1497 [official build remains at 1487]
Code:
 { 1 2 { 3 4 { 5 } } « →STR » MAPLIST→
returns
Code:
 "1" "2" { "3" "4" { "5" } }
Code:
 "1" "2" "3" "4" "5"

It seems to me that since the program is mapped to all elements thru full depth then all the sublists should be exploded, but maybe that's a design choice and not a bug.

Claudio could you clarify?
10-06-2021, 12:32 AM (This post was last modified: 10-06-2021 12:38 AM by Claudio L..)
Post: #193
 Claudio L. Senior Member Posts: 1,840 Joined: Dec 2013
RE: newRPL - Updated to build 1497 [official build remains at 1487]
(10-04-2021 09:17 PM)JoJo1973 Wrote:
Code:
 { 1 2 { 3 4 { 5 } } « →STR » MAPLIST→
returns
Code:
 "1" "2" { "3" "4" { "5" } }
Code:
 "1" "2" "3" "4" "5"

It seems to me that since the program is mapped to all elements thru full depth then all the sublists should be exploded, but maybe that's a design choice and not a bug.

Claudio could you clarify?

MAPLIST→ is simply a shortcut for « MAP LIST→ DROP », in other words, it does MAP but doesn't recreate the list, simply leaves the items on the stack. This saves time when you don't actually need the list created. Creating the list has a cost in time and memory, as all objects must be copied within the new list object.
I can't recall where exactly I needed this (maybe a solver, or symbolics rule processing, menus, etc.) so I created this command to improve performance.

EDIT: I wanted to clarify that going into the sub-lists individual elements while still retaining the structure is a feature of MAP, coming directly from the 50g AUR. LIST→ on the other hand, does not recurse.
05-04-2022, 05:25 PM
Post: #194
 Kevin Ouellet Member Posts: 145 Joined: Dec 2013
RE: newRPL - Updated to build 1497 [official build remains at 1487]
In the first post, I noticed that there's an HP 39g+ version of NewRPL available, but the HP 39g+ doesn't support ROM updates. Anyone has any idea how NewRPL works and install on this model? I couldn't find any instructions on how to put it on it online.

-DJ Omnimaga
Semi-calculator-related Discord (CodeWalrus): https://discord.gg/cuZcfcF
Music and games: https://www.djomnima.ga
05-04-2022, 08:03 PM
Post: #195
 erazor Junior Member Posts: 16 Joined: Nov 2019
RE: newRPL - Updated to build 1497 [official build remains at 1487]
(05-04-2022 05:25 PM)Kevin Ouellet Wrote:  In the first post, I noticed that there's an HP 39g+ version of NewRPL available, but the HP 39g+ doesn't support ROM updates. Anyone has any idea how NewRPL works and install on this model? I couldn't find any instructions on how to put it on it online.
Hope the manual helps:
https://newrpl.wiki.hpgcc3.org/doku.php?...stallation
05-05-2022, 03:58 AM
Post: #196
 The Shadow Member Posts: 231 Joined: Jan 2014
RE: newRPL - Updated to build 1497 [official build remains at 1487]
Been quite a while since I've stopped by, when I get some time I should try NewRPL on a Prime!

I like what I'm seeing with the new loop structures and CKARG. As long as we're meddling, how feasible would these changes be?

* Allowing negative numbers for list slots. -1 being the last element, -2 being the second to last, etc. (Unfortunately there probably shouldn't be a slot 0 for fear of confusing POS and other commands.)

* Allowing a list as the first input for a FOR loop. The second input specifies where in the list to start, and the FOR variable reads out of the list thereafter, with STEP skipping entries as desired. The loop ends when STEP (or NEXT) produces a value that doesn't correspond to a list slot.

If altering FOR is not in the cards, perhaps a new loop FORLIST?
05-05-2022, 10:16 AM
Post: #197
 Kevin Ouellet Member Posts: 145 Joined: Dec 2013
RE: newRPL - Updated to build 1497 [official build remains at 1487]
(05-04-2022 08:03 PM)erazor Wrote:
(05-04-2022 05:25 PM)Kevin Ouellet Wrote:  In the first post, I noticed that there's an HP 39g+ version of NewRPL available, but the HP 39g+ doesn't support ROM updates. Anyone has any idea how NewRPL works and install on this model? I couldn't find any instructions on how to put it on it online.
Hope the manual helps:
https://newrpl.wiki.hpgcc3.org/doku.php?...stallation

I couldn't find any info about the 39g+ installation process in the entire manual.

-DJ Omnimaga
Semi-calculator-related Discord (CodeWalrus): https://discord.gg/cuZcfcF
Music and games: https://www.djomnima.ga
05-05-2022, 05:53 PM
Post: #198
 SammysHP Member Posts: 152 Joined: Jul 2018
RE: newRPL - Updated to build 1497 [official build remains at 1487]
(05-05-2022 10:16 AM)Kevin Ouellet Wrote:  I couldn't find any info about the 39g+ installation process in the entire manual.

Hmm… but what is this?

Quote:2. For USB installation: just connect the cable and start the Connectivity Kit that came with the calculator. Once newRPL is installed for the first time, all future updates can also be made using newRPL Desktop.

3. Enter the Boot/Self Test Mode: Power the calculator OFF, press and hold the plus(+) and minus(-) keys simultaneously, insert a paper clip into the reset hole on the back of the calculator, remove the paper clip and then release the plus/minus keys after a few seconds. The screen will have two options when in this mode: 1.UPDATE CODE, and 2.SELFTEST (the Boot version and the serial number appear at the bottom of the screen).

4. Enter mode 1.UPDATE CODE.

5. Choose 2.CARD if using an SD card, or 1.USB if using the Connectivity Kit (and start the transfer from the Connectivity Kit).

I used a Windows XP virtual machine to run the ancient HP39gs Connectivity Kit.
05-05-2022, 07:21 PM
Post: #199
 Eric Rechlin Senior Member Posts: 374 Joined: Dec 2013
RE: newRPL - Updated to build 1497 [official build remains at 1487]
(05-05-2022 05:53 PM)SammysHP Wrote:
(05-05-2022 10:16 AM)Kevin Ouellet Wrote:  I couldn't find any info about the 39g+ installation process in the entire manual.

Hmm… but what is this?

Quote:2. For USB installation: just connect the cable and start the Connectivity Kit that came with the calculator. Once newRPL is installed for the first time, all future updates can also be made using newRPL Desktop.

3. Enter the Boot/Self Test Mode: Power the calculator OFF, press and hold the plus(+) and minus(-) keys simultaneously, insert a paper clip into the reset hole on the back of the calculator, remove the paper clip and then release the plus/minus keys after a few seconds. The screen will have two options when in this mode: 1.UPDATE CODE, and 2.SELFTEST (the Boot version and the serial number appear at the bottom of the screen).

4. Enter mode 1.UPDATE CODE.

5. Choose 2.CARD if using an SD card, or 1.USB if using the Connectivity Kit (and start the transfer from the Connectivity Kit).

I used a Windows XP virtual machine to run the ancient HP39gs Connectivity Kit.

That's for the 39gs, not the 39g+. Did the 39g+ even have flash memory? It's possible newRPL doesn't work on it.
05-05-2022, 11:11 PM (This post was last modified: 05-05-2022 11:11 PM by rprosperi.)
Post: #200
 rprosperi Super Moderator Posts: 5,285 Joined: Dec 2013
RE: newRPL - Updated to build 1497 [official build remains at 1487]
(05-05-2022 07:21 PM)Eric Rechlin Wrote:  That's for the 39gs, not the 39g+. Did the 39g+ even have flash memory? It's possible newRPL doesn't work on it.

Eric is right, I'm fairly sure the 39g+ is not supported on newRPL.

Although it is ARM-based, with the same RAM and Flash as the 39gs, it's core OS was really just the 39g/40g with the CAS actually removed, not just disabled as on the 39g. I think it was released simply so HP could get it approved for school tests where CAS was not allowed, since a hack was quickly found to enable CAS in the 39g. The 39g+ was only sold for about 18 months and then the 39gs came out, so there are relatively few of these out there, so probably not worth Claudio's time to port to.

The good news is that 39gs machines are available cheaply, I've purchased more than one for under \$20, one of them new in sealed package.

--Bob Prosperi
 « Next Oldest | Next Newest »

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


text:
currently i am in a situation where i have inserted some pages via includepdf, followed by additional \includepdf calls that use the addtotoc function, as follows:

\includepdf{pdffile1}
\includepdf{pdffile2}
\includepdf{pdffile3}
\includepdf{pdffile4}
\includepdf{pdffile5}
\includepdf{pdffile6}

...
n, subsection, 2, somenameN, somenameNlabel}]{./part1docs}

...
n, subsection, 2, somenamepart2N, somenamep2Nlabel}]{./part2docs}

i would like to now add a new section heading, called "Part 3", where the subsections would refer to the pages in the \includepdf{pdffile1}..\includepdf{pdffile6} calls.

edit: i found someone's macro that allows me to put in entries

\newcommand*{\NoPageAddContentsLine}[3]{%
\begingroup
\newpage
\let\protected@write\protected@immediate@write
\endgroup
\stepcounter{page}%
}

\setcounter{page}{1}
...

it looks right but the linking is still an issue. even if i add a link=true, linkname=x to each of the pdffiles, it does not work.

any tips on getting a working link to a contents entry added in this way, if the link is created through pdfpages?

• Your question is confusing. To clarify: You are talking about two different documents? You want to link from one PDF to another, similar to using \href{foo.pdf#section}{...}. And the difficulty is, that you would like this \href command to be inside a TOC entry. Is this what you want? – Andreas Matthias Sep 25 '20 at 13:28
• hi matthias. i reworked my question. i think it's much easier to understand now. this is all for a single tex file. i just want to include some pdf files in a section that is after some pdf files that call addtotoc (and addcontentsline), if that makes sense. – user41816 Sep 25 '20 at 14:12
• hi matthias, i am almost there, but i still have an issue with linking. hoping you can check out the additions and help me conjure a solution to hacking a link to each of pages included through pdfpages – user41816 Sep 25 '20 at 15:21

Do you really want a TOC that does not follow the structure of your document? I suppose this will be highly confusing for everyone reading your document.

Maybe a simple table with references to the other pages might be a better solution than putting it into the TOC.

Anyway, here's a quick solution without page numbers. Adding page numbers would be much more cumbersome.

\documentclass[a4paper]{article}
\usepackage{pdfpages}
\usepackage{hyperref}

\makeatletter
\newcommand\mysection[2]{%
\stepcounter{section}
\protect\contentsline{section}%
{\protect\numberline {\thesection}#1}%
{}%
{#2}%
\protected@file@percent}}
\makeatother

\begin{document}

\tableofcontents
\section{First}
\mysection{Let's see}{AAA.2}
\section{Next}

\end{document}

• thanks for this solution matthias, but one thing i've noticed is that, for my example, this will not show up since "Part 3" is technically an empty "part" (i.e. no \part*{} or \part{} has been declared). if the section is created "normally" (with some declaration prior to adding the entry), then it works. – user41816 Sep 25 '20 at 17:23

by using

\newcommand*{\NoPageAddContentsLine}[3]{%
\begingroup
\newpage
\let\protected@write\protected@immediate@write
\endgroup
\stepcounter{page}%
}

and then adding \label{x} after each includepdf call that's being indexed out-of-order:

\includepdf{pdffile1}\label{whatiwant}

and then using hyperref in the nopageaddcontentsline,

\NoPageAddContentsLine{toc}{subsection}{\hyperref[whatiwant]{pdffile1 header name}}

it will work. it's not the prettiest solution, but it's generated so i'll take it.

and i agree matthias, it's not the best way to do things.

but The < Vaunted Entity > is The < Vaunted Entity >. your documents must meet their criteri prior to arguing with them ;)

format: plain


text:
# Open Questions about Wasserstein Space and PDE

While working on my thesis, I encountered the idea of OMT and started reading some more (like Villani's book). In particular, I came across a PhD thesis by Martial Agueh. I thought it was interesting because it explicitly investigated the geodesics of Wasserstein space to produce solutions to a type of parabolic PDE.

I have some questions and I know this is probably something I should reach out to a researcher about, but I'm in another very different field (computational neuroscience) and few people around me that have the ability to address these questions with sufficient detail -- so I figure I'd try my luck and ask here.

1. Are there any open questions that would require a detailed study of the geodesics in Wasserstein space to understand the existence of PDE solutions (as in Agueh's thesis) or are these results mostly covered now by the general theory in Ambrosio's book on Gradient Flows?

2. Are there any open questions about analysis on Wasserstein space itself? I think one game people try to play is defining Laplacians on this space. Anything else?

3. Are there any PDE problems that have not yet been looked at through the Wasserstein perspective?

• Please read the tag descriptions before using a tag. The [open-problems] tag is for indicating that the mathematical question being asked turns out to be equivalent to a known open problem. Mar 20, 2019 at 14:22

I work in a bit different field too, but your question is quite interesting for me. So I have looked up in the literature just for curiosity. Since there are (surprisingly) no answers yet, let me share some references where open problems related to Wasserstein space are mentioned:

1. Topics in Optimal Transportation by C. Villani (2003).
For instance see Open Problem 7.20.

2. A geometric study of Wasserstein spaces: Euclidean spaces by B. Kloeckner, Annali della Scuola Normale Superiore di Pisa - Classe di Scienze, Série 5, Volume 9 (2010) no. 2, p. 297-323.

3. A user’s guide to optimal transport by L. Ambrosio and N. Gigli (2012).
For instance see Open Problem 5.7.

4. { Euclidean, Metric, and Wasserstein } Gradient Flows: an overview by F. Santambrogio (2016).

In addition, I am not aware if an explicit formula for $$W_p$$ distance between two Gaussian measures is known for $$p\ne 2$$, see e.g. this question.


text:
# Probability distribution over cluster size in Erdős–Rényi random graph.

My question is about the probability distribution over the possible size of the containing cluster of a randomly chosen node in an Erdős–Rényi random graph.

Let G(n,p) be an Erdős–Rényi random graph (with n nodes, and each edge included with probability p). Uniform-randomly select one of the n nodes from the graph. What is the probability of the node belonging to a cluster of size k, for k in {1,2,..,n}?

-

One can break up the probability that a specific vertex is in a component of size $k$ by $$P(v \text{ is in a component of size }k) = {n-1 \choose k-1}P(k,p)q^{k(n-k)},$$ where $P(k,p)$ is the probability that $G(k,p)$ is connected. However, now you would need to find $P(k,p)$, which is just as complicated. Often in random graphs, one only cares to bound this probability from above, such as an union bound over all spanning trees, $$P(k,p) \leq k^{k-2} p^{k-1},$$ or Stepanov's Inequality, $$P(k,p) \leq (1-q^{k-1})^{k-1}.$$

-

You should check any of:

• Alon and Spencer 2008, "The Probabilistic Method"

• Janson Et Al 2001, "Random Graphs"

• Grimmett 2010 "Probability on Graphs"

• Durrett 2007 "Random Graph Dynamics"

to cite only a few.

I believe the answer is essentially that dependent on $c$, where $p = \frac{c}{n}$:

• when $c < 1$, all the connected components are of size $O(\log n)$

• when $c > 1$, there exists a unique component of size $O(n)$, all other components are of size at most $O(\log n)$

• when $c=1$, the components size have an amazing structure described by Aldous (1997) "Brownian Excursions, Critical Random Graphs and the Multiplicative Coalescent"

I hope this helps.

-
Thanks. It seems relatively easy to find results about the largest clusters, and about bounds on cluster size, but the actual distribution of cluster sizes seems to be hard to pin down! –  ts09 Jun 17 '13 at 13:10
I have had a brief look at some of those papers and it seems, that the answer isn't there, at least not in an easy to decipher form! I suppose in particular I would like to know, is there a closed form expression for calculating P(k), from n and p? –  ts09 Jun 24 '13 at 13:32


text:
# Setup

Take the following 4x4x4 cube along with a 2D view of 3 of its faces, with a common 1x1x1 cube highlighted:

The arrows represent the points of view that generated the V1, V2 and V3 faces drawn underneath the big cube.

Given an arrangement of some 1x1x1 cubes inside the main cube we can try and identify it with only three projections. For example, the arrangement below:

could be represented as follows:

V1
X...
....
....
XXXX

V2
X...
X...
X...
X..X

V3
X...
X...
X...
XXXX

However, if we consider only projections on V1 and V2, most of the time we can't identify uniquely the arrangement being considered.(there are arrangements that can't be uniquely identified, even with the 6 projections)

Given projections on V1 and V2, output the minimum and maximum number of 1x1x1 cubes that an arrangement could have and still produce the projections V1 and V2.

I'll walk you through 2 examples:

## Explained example 1

V1
XXXX
....
....
....

V2
X...
X...
X...
X...

These two projections signal some directions along which there must be cubes:

and the output would be 4, 16; This is the case because both V3 below represent valid projections on V3:

V3a
X...
.X..
..X.
...X

This is a "diagonal" pattern of cubes in the back plane, when viewed from V3; ...

V3b
XXXX
XXXX
XXXX
XXXX

and this is a full face in the back plane.

## Explained example 2

V1
XXXX
XXXX
XXXX
XXXX

V2
XXXX
....
....
....

These projections represent the top face of the main cube, so in this case we managed to identify the arrangement uniquely. The output in this case would be 16, 16 (or 16, see output rules below).

# Input

Your code takes the projections on V1 and V2 as input. There are a variety of reasonable ways for you to take this input. I suggest the following to represent each projection:

• An array of length 4 with strings of length 4, two different characters to encode "empty" or "filled", like ["X...", ".X..", "..X.", "...X"] for the V3a above.
• An array/string of length 16, representing the 16 squares of the projection, like "X....X....X....X" for V3a above.
• An integer where its base 2 expansion encodes the string above; 1 must represent the X above, so V3a above would be 33825 = b1000010000100001.

For any of the alternatives above, or for any other valid alternative we later decide that is helpful for you guys, you can take any face in any orientation you see fit, as long as it is consistent across test cases.

# Output

The two non-negative integers representing the minimum and maximum possible number of 1x1x1 cubes in an arrangement that projects onto V1 and V2 like the input specifies. If the minimum and maximum are the same, you can print only one of them, if that helps you in any way.

# Test cases

(I didn't really know how to format these... if needed, I can reformat them! Please let me know.)

XXXX
....
....
....,
X...
X...
X...
X... -> 4, 16

XXXX
XXXX
XXXX
XXXX,
XXXX
....
....
.... -> 16, 16

XXXX
XXXX
XXXX
XXXX,
XXXX
....
..X.
.... -> 16, 20

X..X
.XX.
.XX.
X..X,
X.XX
.X..
..X.
XX.X -> 8, 16

XXXX
XXXX
XXXX
XXXX,
XXXX
XXXX
XXXX
XXXX -> 16, 64

X...
....
....
XXXX,
X...
X...
X...
X..X -> 8, 8

X..X
....
....
XXXX,
X...
X...
X...
X..X -> 8, 12

This is so shortest submission in bytes, wins! If you liked this challenge, consider upvoting it! If you dislike this challenge, please give me your feedback. Happy golfing!

• brute-forcing is gonna take a while... – Surculose Sputum Mar 24 at 0:17
• Can I take V1 rotated once, so that V1 and V2 are vertically aligned? – Bubbler Mar 24 at 0:31
• @Bubbler can take any face in any orientation you see fit, as long as it is consistent across test cases – RGS Mar 24 at 6:40
• @RGS I had this wild brute force idea where each cube was one bit, so V1 and V2 started off as bit arrays, and the way things were set up it would save bytes for V1 to be represented on a by-row basis where each row was a 4-bit number instead of individual bits. It doesn't matter anymore though, it would save even more bytes if I threw my solution out the window and just ported Surculose's Python solution to Ruby instead. – Value Ink Mar 24 at 17:00
• @ValueInk I also had to throw my brute force solution out the window. – Neil Mar 24 at 21:34

# APL (Dyalog Unicode), 11 bytes

+.(⌈,×)/+⌿¨

Try it online!

Takes V1 and V2 as two binary matrices inside a nested vector, and V1 is rotated so that it vertically lines up with V2. Returns doubly nested vector of (min, max).

### How it works

The first column of V1 and the first column of V2 decide the first vertical layer of 4x4 cells. If n cells are shaded in V1's column and m cells in V2's, the minimum number of shaded cells in the corresponding 4x4 layer is max(m,n), and the maximum is m * n.

min          |  max
| 1 0 1 0  |    | 1 0 1 0
-----------  |  -----------
1 | 1 0 0 0  |  1 | 1 0 1 0
1 | 1 0 0 0  |  1 | 1 0 1 0
0 | 0 0 0 0  |  0 | 0 0 0 0
1 | 0 0 1 0  |  1 | 1 0 1 0

Therefore, it suffices to count ones in each column, and evaluate sums of the pairwise max (for minimum) and pairwise product (for maximum) of the column sums.

+.(⌈,×)/+⌿¨
+⌿¨  ⍝ In each matrix, evaluate column sums
/     ⍝ Over the two vectors,
+. ⌈         ⍝ Evaluate the sum of pairwise max
,        ⍝ and
+.   ×       ⍝ the sum of pairwise product

• Really lovely answer. – Jonah Mar 24 at 1:22

# Python 3, 74 71 bytes

-3 bytes thanks to @Bubbler!

lambda V:(sum(f(*map(sum,p))for p in zip(*V))for f in[max,int.__mul__])

Try it online!

Input: a list of faces [V1,V2], each face is a 4x4 list of binary digit. The orientation of each face is as follow (V2 is rotated 90 degree clock-wise compare to the challenge's default orientation). Output: A tuple of 2 integers, representing the min and max number of blocks.

### Approach

Consider each of the 4 slices of the cube: We can see that for each slice, the min and max number of block in that slice is respectively the max and the product of the top and left strips.

### Code explanation:

lambda V:(sum(f(*map(sum,p))for p in zip(*V))for f in[max,int.__mul__])

• for f in[max,int.__mul__] assigns f first to the function max, then to the integer multiply function.
• p in zip(*V) pairs each corresponding strips (aka rows) of the 2 faces together.
• map(sum,p) applies the sum function to each row in the pair. The result is effectively (top, left).
• f(*map(...)) computes either max(top,left) or top*left.
• sum(f(...)) sums over all slices.
• – Bubbler Mar 24 at 1:28
• @Bubbler thanks! I also came up with the same thing. Writing my explanation now, will update in a bit. – Surculose Sputum Mar 24 at 1:30
• Also 71 – xnor Mar 24 at 2:18
• Another 71 – xnor Mar 24 at 2:19
• @Jonah MS Paint :) – Surculose Sputum Mar 24 at 2:56

# Jelly, 7 bytes

§µ»/,P§

A monadic Link accepting a list of the two projections each being a list of lists of 1s and 0s, [V1, V2], with V2 rotated a quarter turn clockwise which yields a list of two integers, [min, max]

Try it online!

### How?

The same method as Bubbler & Surculose Sputum came up with.

§µ»/,P§ - Link: list of two lists of lists of 1s and 0s
§       - sums
µ      - start a new monadic chain, call that v
/    - reduce (v) by:
»     -   maximum (vectorises)
P  - product of (v) (vectorises)
,   - pair
§ - sums

# Charcoal, 6158 22 bytes

≔Ｅ⁴ＥθΣ§λιθＩ⟦ΣＥθ⌈ιΣＥθΠι

Try it online! Takes input as a list of lists in a different orientation to the examples. Uses @Bubbler's formula. Explanation:

≔Ｅ⁴ＥθΣ§λιθ

Transpose the input while taking the count of the number of cubes in each row.

Ｉ⟦ΣＥθ⌈ιΣＥθΠι

Calculate the minimum and maximum cubes for each row, and then take the totals for all four rows.

• This one contains so much Greek it's almost readable. – probably_someone Mar 24 at 15:55