[VA] Short & Sweet Math Challenge #22: April 1st, 2018 Spring Special

[Valentin Albillo]

 
Hi all,

After a mere 10-year hiatus here's again my super-duper S&SMC April 1st, 2018 Spring Special to welcome the new season and give you all a chance to put to good use both your favourite HP calculator and your programming ingenuity.

The thing is, I've always been very interested in primes and algorithms for factorization and primality tests of big numbers and recently computed the factorization of

      555555555555554444444444444443333333333333332222222222222222211111111111111

and proceeded to check it out with my trusty HP-71B (it checked OK!), so I got the idea of making some kind of primality testing the main subject of this S&SMC#22, plus assorted goodies. Read on !:

Notes :

Any HP model of your choice may be used but I'll suggest a Minimum Recommended Model (MRM) for each problem, which is the  minimum model I deem capable of solving it more or less comfortably. Obviously, using a more powerful model might make life easier and, conversely, using a less powerful model might succeed or not.

If you use an HP­41C/CX/CV you can also use any of these ROM: Math, Advantage, Card Reader, Printer. No  other ROM or extra routines allowed. If you use an HP­71B, you can also use any of these ROM: Math, HP­IL, JPC, STRNGLEX Lex file. No other ROMs or LEX files allowed.

Using a PC or any computing device other than a physical or emulated HP calculator is strictly disallowed. You can write your code in any language supported in any HP calc and it must run in that calc (i.e.: RPN, RPL, 71B BASIC, 71B FORTH, etc). Googling for the solutions is lame beyond belief, frankly.


The Challenge - Main Course:

[MRM: HP42S and up] Write code that takes as input any of the following six test numbers and simply outputs whether it's a prime or not (no need to compute or output its factorization if not prime). Your code might or might not work for some other arbitrary numbers of arbitrary length but it should definitely output the correct result for each of the following six test numbers:

      8082737769637879
      89698373657765787367698082737769
      677977807983738469788577666982
      7365778082737769847979
      677977807983738469658387697676
      7378686969688082737769

Your code must be as short and fast as possible, in that order. Within a few days I'll give a 72-byte solution for the HP-71B (an User-Defined Function) and a 39-byte solution for the HP42S (a program) but meanwhile let's see what you can do.


The Challenge - 4 Desserts:

1) [MRM: HP-10C and up] Starting from no assumptions (angular mode, stack contents, memory contents, etc) write a program to output the constant 9.99999999999 (for 12-digit machines, 12 nines) or 9.999999999 (for 10-digit machines, 10 nines). Your code must be as short as possible. For instance, in the HP-71B you could use:

      1 DISP 9.99999999999

but this is 14 bytes long and as "1 DISP" itself takes 5 bytes you're using 9 additional bytes to generate the constant, which are way too many. I'll give an 8-5 = 3-byte solution for the plain vanilla HP-71B, see what you can do with your favourite HP calc.

      
2) [HP-71B specific; perhaps RPL models too, not sure] Everyone has seen math expressions which give the machine value of Pi as a result so let's try for a slightly different thing here.

Starting from no assumptions (angular mode, stack contents, memory contents, etc) find the shortest, simplest command-line math expression which upon evaluation in your calc produces the machine value of -Pi (i.e.: -3.14159265359 for 12-digit calcs, -3.141592654 for 10-digit ones).

Your expression can't use PI (of course!), strings/string functions, trigonometric/logarithmic/exponential/gamma/complex functions, and also last but not least, neither any digits (in any base) nor "-" should appear in it. I'll give a 6-byte, 16-character solution for the HP-71B, let's see yours.

Also, if you succeed, try to get -Pi/100 or even -Pi/10000 under the same conditions. I'll also give a 6-byte solution for those as well.

      
3) [MRM: HP-11C and up] Informally, for real-valued functions of real-valued arguments we may say that G(X) is the inverse function of F(X) if theoretically G(F(X)) = X. For instance, with F(X)=EXP(X) we have that G(X)=LN(X) and G(F(X)) = LN(EXP(X)) = X.

This said, produce some real-valued F(X) of a real-valued argument X and its theoretical inverse G(X) for your favourite HP calc such that the actual evaluation of G(F(X)) differs from X by at least 2% of X for some relatively small argument X, say X less than 20 in absolue value. No code required, just the F(X) and G(X).

If you succeed in finding such an F(X), try to find the smallest value of X which results in said 2% difference.

I'll give my solution for the HP-11C, HP42S and HP71B (the exact details differ slightly from calc to calc).

      
4) [HP-71B specific; perhaps RPL models too, not sure] Produce the shortest single-statement command-line expression which when executed outputs this line:

      0 1 2 3 4 5 6 7 8 9 10

Your expression can´t use either strings/string functions or any digits in any base and must fit in a single 1-statement line (i.e., no statement concatenation via @ in the HP-71B) less than 80 characters in length, and also can't call any program code, it must generate the ouput by itself.

I'll give my 74-character solution for the HP-71B in a few days but meanwhile give it a try !

Finally, a caveat: PLEASE do NOT include "CODE:" panels in your replies to this thread, as it makes it difficult for me to generate the final PDF document which will include the full thread in order to make it available online for free and for everyone in the future. I sincerely expect you'll kindly comply with this reasonable requirement but in any case I'll remove from the final PDF document any replies featuring CODE: panels. Thank you.

That's all. Hope you'll enjoy it !

Best regards.
V.
      

[Didier Lachieze]

Hi Valentin, thanks for this nicely crafted challenge !

Let me start with the easy part, the first dessert:
- for the HP-71B, 8 bytes : 1 DISP MAXREAL*EPS
- for the HP-25, 7 bytes :
01 FIX 9
02 .
03 3
04 1/x
05 3
06 x
07 GTO 00

[rprosperi]

For Desert #2:

SGN(EXPONENT(EPS))*RAD(ANGLE(SGN(EXPONENT(EPS)),EPS))

53 chars and 23 bytes with line number.

It works and meets the criteria, but it's still waaay too long.

Will keep looking for shorter ways to generate -1...

Edit 1:

Shorter, but still long:

SGN(DVZ)*RAD(ANGLE(SGN(DVZ),EPS))

[Paul Dale]

Desert 3.

F(X) = X + 10⁹⁰.
G(X) = X - 10⁹⁰.

G(F(X)) is zero for |x| < 20. It's correct only at X=0. The smallest X where the difference is > 2% will be the largest negative number allowed in the small range around zero i.e. -19.999...999. The smallest in absolute will be the smallest positive X such that X - X/50 doesn't underflow.

[pier4r]

(04-01-2018 09:08 PM)Valentin Albillo Wrote:  Finally, a caveat: PLEASE do NOT include "CODE:" panels in your replies to this thread, as it makes it difficult for me to generate the final PDF document which will include the full thread in order to make it available online for free and for everyone in the future. I sincerely expect you'll kindly comply with this reasonable requirement but in any case I'll remove from the final PDF document any replies featuring CODE: panels. Thank you.

Just an observation. Why do you say "code" shouldn't be included? If you see the thread with the printable version (at the end of the thread there is a link) listing in code are not bad when properly formatted.

See for example
http://www.hpmuseum.org/forum/printthread.php?tid=8555

search for "listHeadIterate". It is pretty nice.

[J-F Garnier]

Desserts #1 and #3 (related solutions), on HP71 w/ Math ROM or Pioneer machines.

#1:
1 DISP TANH(14)*10
[edited: not an efficient solution of the challenge, of course]

#3
F(X)=TANH
G(X)=ATANH
X=14.5

J-F

[J-F Garnier]

Dessert #4 [HP71 specific]

One 74-char. solution:
INX-INX;INX=INX;INX-OVF;INX-DVZ;-INX;-UNF;-OVF;-DVZ;-IVL;-INX-UNF;-INX-OVF

J-F

[Dieter]

(04-01-2018 11:44 PM)Mike (Stgt) Wrote:  [9,999999999]
4 bytes if I count corretly.

Yes, this does it on a 10-digit calculator – I had the same idea. ;-)
But it doesn't work with 12 digits.

(04-01-2018 11:44 PM)Mike (Stgt) Wrote:  (Sorry, not using code: multiple blanks get lost.)

You may use hard blanks (Alt+0160):

01-      1  1
02-      0  0
03-     11  SQRT
04-  42 11  x^2

But, as already mentioned, "view a printable version" at the page bottom expands all code boxes, so such tricks should not be required.

Dieter

[J-F Garnier]

After the desserts, back to the main course!

I have a nice little HP71 program that is able to output the (assumed) correct result for each of the six test numbers.
However, I will not publish my very clever program here, just the results as NO or YES:
8082737769637879 NO
89698373657765787367698082737769 YES
677977807983738469788577666982 NO
7365778082737769847979 YES
677977807983738469658387697676 NO
7378686969688082737769 YES

:-)
J-F

[rprosperi]

(04-02-2018 07:53 PM)J-F Garnier Wrote:  Dessert #4 [HP71 specific]

One 74-char. solution:
INX-INX;INX=INX;INX-OVF;INX-DVZ;-INX;-UNF;-OVF;-DVZ;-IVL;-INX-UNF;-INX-OVF

J-F

Brilliant! This must be the same result as Valentin's.
You have me digging into parts of the 71 manual that are not familiar...

[Gerson W. Barbosa]

(04-02-2018 12:24 AM)rprosperi Wrote:  Shorter, but still long:

SGN(DVZ)*RAD(ANGLE(SGN(DVZ),EPS))

Slightly shorter and still too long:

RAD(INX*ANGLE(EPS,EPS))

Both ANGLE and RAD are listed under Trigonometric Operations in the Keyword Index, though.

[rprosperi]

(04-02-2018 09:53 PM)Gerson W. Barbosa Wrote:  Slightly shorter and still too long:

RAD(INX*ANGLE(EPS,EPS))

Both ANGLE and RAD are listed under Trigonometric Operations in the Keyword Index, though.

You beat me Gerson, I was just exploring INX (JFG's post was an excellent hint!).

I suspect by 'no trig functions' Valentin was implying SIN/COS/etc. but you could be right. We have to wait for a judge's ruling on that, but I'll keep digging.)

[Didier Lachieze]

(04-02-2018 09:53 PM)Gerson W. Barbosa Wrote:  

(04-02-2018 12:24 AM)rprosperi Wrote:  Shorter, but still long:

SGN(DVZ)*RAD(ANGLE(SGN(DVZ),EPS))

Slightly shorter and still too long:

RAD(INX*ANGLE(EPS,EPS))

Both ANGLE and RAD are listed under Trigonometric Operations in the Keyword Index, though.

Nice solutions, and I'm learning new HP-71 tricks with this challenge. Unfortunately they work in Degrees but not in Radians angular mode.

[rprosperi]

(04-02-2018 10:13 PM)Didier Lachieze Wrote:  

(04-02-2018 09:53 PM)Gerson W. Barbosa Wrote:  Slightly shorter and still too long:

RAD(INX*ANGLE(EPS,EPS))

Both ANGLE and RAD are listed under Trigonometric Operations in the Keyword Index, though.

Nice solutions, and I'm learning new HP-71 tricks with this challenge. Unfortunately they work in Degrees but not in Radians angular mode.

Indeed, the 71 has lots of these kinds of tricks buried deep inside.

6 bytes means Valentin found a solution with only 3 XROM (function) calls... so there are clearly still some tricks hidden

[Gerson W. Barbosa]

(04-02-2018 10:06 PM)rprosperi Wrote:  I suspect by 'no trig functions' Valentin was implying SIN/COS/etc. but you could be right. We have to wait for a judge's ruling on that, but I'll keep digging.)

If RAD is allowed then RAD(UNF*OVF*OVF) does the trick, regardless the angle mode.

(Using other people’s ideas only, yours included)

[rprosperi]

(04-03-2018 02:17 PM)Gerson W. Barbosa Wrote:  If RAD is allowed then RAD(UNF*OVF*OVF) does the trick, regardless the angle mode.

Cool!

String length is right, though byte count is higher (11 bytes with line number, I think 8 for just the expression).

Valentin is laughing now... can you hear it?

[Gerson W. Barbosa]

(04-03-2018 08:47 PM)rprosperi Wrote:  [quote='Gerson W. Barbosa' pid='94428' dateline='1522765035']


String length is right, though byte count is higher (11 bytes with line number, I think 8 for just the expression).

Valentin is laughing now... can you hear it?

On the other hand, Valentin said “1 DISP itself takes 5 bytes”, so I assume the expression takes 6 bytes, unless I’m wrong, of course.

Six byte and 16 characters for -pi is indeed awesome. I would need much more just for pi :-)

LN(SQRT(SQRT((305^3+25^3+5^3+5)/(4^3+3^3+2^3))))

16*3 characters and 6*6 bytes

[rprosperi]

(04-03-2018 09:05 PM)Gerson W. Barbosa Wrote:  On the other hand, Valentin said “1 DISP itself takes 5 bytes”, so I assume the expression takes 6 bytes, unless I’m wrong, of course.

Six byte and 16 characters for -pi is indeed awesome. I would need much more just for pi :-)

LN(SQRT(SQRT((305^3+25^3+5^3+5)/(4^3+3^3+2^3))))

16*3 characters and 6*6 bytes

Sorry, I missed that note inside Desert #1 when I skipped straight to Desert #2. I was not sure how many bytes a line number takes, but it looks like it's 3.

So then yes, of course this is the answer.

Good job team! I wonder if Valentin awards partial credit?

[Valentin Albillo]

.
Hi all,

First of all thanks for the overwhelming interest in my humble SSMC#22, I'm very grateful for it.

I'll post my original solutions to Main Course and 4 Desserts within two days (next April, 5) so you've still got time to solve them all, but meanwhile I'll address here some of the things you either commented or asked. Read on:

Didier Lachieze Wrote:Hi Valentin, thanks for this nicely crafted challenge !

You're welcome, thanks for your appreciation.

pier4r Wrote:Just an observation. Why do you say "code" shouldn't be included? If you see the thread with the printable version (at the end of the thread there is a link) listing in code are not bad when properly formatted.

You may be right but for this challenge I'll stick to my plea not to use it. I make change my mind though after I do some tests. Thanks for pointing this out to me.

Mike (Stgt) Wrote:"At one's ease"? So the following determinations are not too serious? Please explain.
...
"We may say", why not "we say"?

Please, Mike (Stgt), English is not my native language and I'm doing what I can with it so please cut me some slack, will you ?

Gerson W. Barbosa Wrote:Both ANGLE and RAD are listed under Trigonometric Operations in the Keyword Index, though.

They're not trigonometric *functions* so they're perfectly legal.

rprosperi Wrote:Valentin is laughing now... can you hear it?
...
Good job team! I wonder if Valentin awards partial credit?

Indeed I was, you all are quite funny and it's a pleasure to read your attempts (and eventual success!). And yes, I award credit to all involved.

That's all, see you next April 5.
Best regards and keep on trying till you get all solved, Main Course & 4 Desserts.
V.
.

[Gerson W. Barbosa]

(04-03-2018 09:31 PM)rprosperi Wrote:  So then yes, of course this is the answer.

Good job team! I wonder if Valentin awards partial credit?

OVF*OVF*RAD(UNF) is another variation. But Dessert #2 won’t be over until -Pie/100 and -Pie/10000 are served.

RAD(INX+UNF)/UNF returns Pie/100, but we need -Pie/100. It looks like Pie and wine don’t match :-)