Threaded Mode | Linear Mode

Valentin Albillo · 04-17-2024, 01:47 AM

Hi, all,

VA (i.e. me) Wrote:I'll post the next two LOLs in a couple' days or so. Meanwhile, let's see your comments.

Well, it seems that I was being overoptimistic, as usual, because after 5 days 5 elapsed only the illustrious Gerson W. Barbosa bothered to post an interesting new HP-75C program to solve LOL 1 and (drum roll) also explicitly listed all four beautiful squares I wanted everyone to behold, plus a bonus fifth square in the same fashion. Thanks a lot, Gerson, and here you are, another bonus square featuring $\pi$ no less than three times i.e. at the very beginning, in the middle and near the end, a worthy apropos appearance:

²

31444111334433114334141133143444444313434111431113141443344

Now, these are my original solutions and comments for the next two sections, i.e. LOL the Third: Random and LOL the Fourth: Logs. The show must go on ...

3. LOL the Third: Random

This mini-challenge's question is:

How close can two consecutive RNDs actually be ? Use RANDOMIZE 1 as the seed and write code to output the list of ever closer consecutive RNDs and their index N in the sequence.

My original solution is this 3-line, 89-byte never-ending program which will produce the goods:

1  DESTROY ALL @ RANDOMIZE 1 @ STD @ N=0 @ X=99 @ L=1
2  N=N+1 @ Y=RND @ D=ABS(X-Y) @ IF D<L THEN DISP N;X;Y;D @ L=D
3  X=Y @ GOTO 2

>RUN
       N     First RND         Next RND          |Difference|
-------------------------------------------------------------
         2  .731362440213     .77207218067      .040709740457
        13   5.64471991805E-2  6.30768172146E-2  6.6296180341E-3
       125  .805774019056     .803607575861     .002166443195
       316  .128424219936     .126476247276     .001947972660
       378  .128629571043     .127765838222     .000863732821
      1746  .657235932954     .658084547243     .000848614289
      1864  .724574750035     .724711386925     .000136636890
      3091  .804652037305     .804530031878     .000122005427
      4983  .900183907166     .900119502104     .000064405062
      5002  .185041013513     .184988311770     .000052701743
      5964  .350363678669     .350333411003     .000030267666
     33971  .800461443203     .800483558857     .000022115654
     56943  .322507676917     .322505089514     .000002587403
    144113  .468047416778     .468049379480     .000001962702
    192237  .771445619886     .771443980639     .000001639247
   1606781  .176400853304     .176399416567     .000001436737
   1732702   3.20935575951E-2  3.20944940649E-2  9.364698E-7
   1840905  .862173808769     .862174478752     .000000669983
   1969683  .573449101200     .573448667982     .000000433218
   2143212  .948380454319     .948380365276     .000000089043
  10684317  .555880267196     .555880325796     .000000058600
  38181163  .151576837566     .151576827517     .000000010049
157373808  .477539626899     .477539622968     .000000003931
322950317  .325324468276     .325324470156     .000000001880
431380423  .275319512003     .275319511289     .000000000714
1838286534  .564079556829     .564079556839     .000000000010

at which time I interrupted the search, with my record being the last line shown in the output, i.e. two consecutive RNDs, namely 0.564079556829 and 0.564079556839 , which differ by just 0.00000000001.

Of course this finding took waaaay long to run even on a very fast emulator, so eventually I had to stop the search without looking at the entire one-trillion-long sequence. Thus, I can't confirm whether closer consecutive RNDs are possible or not in this specific sequence generated by the seed 1, in particular consecutive ones identical to 12-digit accuracy (i.e. difference = 0).

Also, I feel that there's something eerie (IMHO) in seeing two consecutive RNDs come out as the almost identical value (or even identical just on screen if you use FIX 4 or FIX 6, say), so if you want to experience this feeling yourself try this 4-line, 149-byte ad-hoc variant of the above program:

Note: Yes, I know that you can go directly to the vicinity of the two close consecutive RNDs using PEEK$ and POKE so saving much running time but I like it better this way.

   1  DESTROY ALL @ RANDOMIZE 1 @ STD @ N=0 @ X=99 @ L=1 @ INPUT "N=";M
   2  IF N=M-2 THEN DISP @ DISP "Execute RND ; RND ..." @ PAUSE
   3  N=N+1 @ Y=RND @ D=ABS(X-Y) @ IF D<L THEN DISP N;X;Y;D @ L=D
   4  X=Y @ GOTO 2

Now, in the list above we have this line:

      1864  .724574750035     .724711386925     .000136636890

so to see by yourself that those two very close RNDs are indeed produced consecutively at that point in the sequence, do the following:

N=

{ key in 1864 and [END LINE] }

{ normal output as above, until ... }

Execute RND ; RND ...

{ the program stops; execute the following: }

0.7246

0.7247

or for a much closer pair of consecutive RNDs:

N=

{ key in 56943 and [END LINE] }

{ normal output as above, until ... }

Execute RND ; RND ...

{ the program stops; execute the following: }

0.322508

0.322505

and last, still closer so even more impressive:

N=

{ key in 10684317 and [END LINE] }

{ normal output as above, until after a really, really long while ... }

Execute RND ; RND ...

{ the program stops; execute the following: }

0.5558803

and le voilà!. Reminds me of Groundhog Day, it looks like RND is broken ...

Additional comments: J-F Garnier did his best to try and solve this mini-challenge. He used a "super-fast" HP-71B emulator with his own 3-line BASIC program which was very similar to my own original solution above (although he forgot to include the nearly-mandatory DESTROY ALL statement at the very beginning Smile

) and let it run for presumably large amounts of time until at last he exactly matched my own record, namely:

1838286534 .564079556829 .564079556839 1.E-11

but although he let it run for 5 billion-deep values in the sequence before stopping it for good, he was unable to get two identical (to 12-digit) consecutive random numbers in this particular sequence created by the original seed 1, as he theorized to be possible. He adds:

"but only a small fraction of the RND period has been explored"

and I agree, as 5 billion is only 0.5% of the whole 1-trillion-strong sequence so 99.5% of it remains unexplored.

Last but absolutely not least, J-F left some intriguing observations which he never fully developed. For example, he said:

"The RND value is determined by the internal seed, which is stored with 15 digits. Or, in other words,we can't predict the next RND value from the last one (well, the possibilities for the next RND are limited)."

but he never explained the underlying algorithm used and why and how the possibilities for the very next RND value are limited. Knowing that, perhaps it'd be much easier to see if two consecutive values can indeed be identical to 12-digit accuracy or not, without having to generate and check tens or hundreds of billions of RNDs.

He also posted two sequences generated by different seeds which include the same 11-digt (not 12-digit) value .14159265359 but he didn't tell how he found those particular seeds, nor did he explain why the very next RND values after the .14159265359 do differ from their second decimal digit on (namely .494478890124 and .41675139916,) while it would seem that, as the possibilities are "limited", they should be much closer and not differ so markedly.

Adding to the mysteries, J-F also said:

"[...] It could be possible to get two consecutive RND values that are equal. Matter of fact, I have one example. Can you find it? :-)"

and again he never bothered to post that "one example" he found nor to explain how did he find it.

In short: for sure J-F is under no obligation whatsoever to share or post anything at all but I've always thought that one of the goals of these mini-challenges is to provide entertainment while also introducing useful math concepts & programming techniques to learn from. So, having at hand the solutions by me and by others serves as an effective way of sharing knowledge, but if you won't share what you know or what you found, then what's the point ? I don't give prizes, you know.

Frankly, I was expecting J-F to eventually provide answers to the above matters so that me and other interested people would learn something new and be enlightened in the process, but to my big surprise he never did. At least so far, several weeks (as of 2024-04-17) since he posted his message. As Chloe B. would say: "C'est décevant, totalement décevant". Smile

4. LOL the Fourth: Logs

This wasn't a mini-challenge per se but simply me reporting an unusual finding, namely that LOG₁₀ seemed to be the most accurate logarithm available in some HP vintage calcs (namely the 10-digit HP-15C and the 12-digit HP-71B). I then suggested the following for interested people to explore and post their findings:

Try the above examples in your HP models, both 10-digit and 12-digit, from the first HP-35 up to the latest RPL models, to see if LOG₁₀ and LN differ that much in their respective errors.
Test other range of values (here from 5² = 25 to 5⁹ = 1,953,125).
Find out if there are arguments with even larger errors.

Regrettably, only J-F Garnier investigated the matter in this excellent post of his, coming to the conclusion that "we can't say that the decimal LOG provides more accurate results than the natural LN, overall", conclusion with which I mostly agree.

He also asks a related question which is pending further investigation but this LOL the Fourth seems to have been largely ignored so far (J-F excepted, of course,) though I think it's an interesting topic related to the innards of HP algorithms and even perhaps to their architecture. And answering J-F's question, no, I couldn't find any references in older threads either nor do I remember this topic having been discussed here ever. I took my observations from ancient (20-25 year-old or more) notes which I wrote at the time but never published before.

Enough for now. I'll post my original solutions and comments to the two final LOL 5 and LOL 6 sections either in an unspecified number of days (a few, a week, a month ...) or right after the next comment(s), whichever comes first.

In the meantime, you might want to have a look at some of my previous April 1st challenges, they feature a true plethora of interesting topics, solutions and comments which are sure to keep you entertained while you wait:

SRC #011 - April 1st, 2022 Bizarro Special

SRC #007 - 2020 April 1st Ramblings

SRC #005- April, 1st Mean Minichallenge

Introducing APRIL microchallenge

Short & Sweet Math Challenge 20 April 1st Spring Special

Short & Sweet Math Challenge 18 April 1st Spring Special

Short & Sweet Math Challenge 15 April 1st Spring Special

Regards.
V.