Tripartite Palindromic Partition of Integer (HP 50g) Challenge

[2old2randr]

(02-28-2023 09:54 AM)Gerald H Wrote:  Could you, 2old2randr, please publish here your collection of programmes as they appear on the screen of the calculator, I have problems to transfer them to the calculator in the format you use. eg

This is difficult to do because symbols such as "greater than or equal to" on the 50g are represented by character code 138 (for example) but this a different character in Unicode. This is why all the non-ASCII characters in my programs are represented by trigraphs ("\>=" and "\<<" for example) that can be understood by the calculator as documented in the AUR appendix J.

My method of working is to type in the code on my Mac using a regular text editor, transfer to the HP 50g using the SD card, convert into a program from string and then test on the calculator. Sadly, there seem to be no dev tools for RPL on the Mac so I don't have a choice even though this approach is inefficient.

The string to code object translation is done using the below program (I got this from a post in this forum) which translates strings to objects (and EVALs) or object to string depending on what is on the stack.

Code:


« RCWS RCLF → ws f
    « 3 TRANSIO DUP
        IF TYPE 2 == THEN
            →STR
            f SIZE 3 > #2F34Dh #3016Bh IFTE SYSEVAL + STR→
        ELSE
            STD 64 STWS →STR
            f SIZE 3 > #2F34Eh #2FEDDh IFTE SYSEVAL
        END
        ws STWS f STOF
    »
»
'INOUT' STO

Quote:Also do you have suggestions how to produce three guesses for input to the programme?

The program cannot take guesses as an input since it is a translation of the algorithmic proof in the paper referred to previously. The way it works is that depending on the given number, the three palindromes (x, y and z) are assumed to be of a certain form (length and first one or two digits of each). Subsequently, the remaining digits of the palindromes are simultaneously generated from the end towards the middle one digit at a time. In general, the digit in position 'n' for x depends on the input number and the digits of x, y and z in position 'n-1'. Sometimes additional digits are considered. Similarly, for y and z - these also take into account the digits generated for x and y in position 'n'.

In any case, there was a serious bug in ALGO5 which I've corrected and the attachment in the original post has been updated.

Sudhir