Little explorations with HP calculators (no Prime)

[pier4r]

Another question.

I do not remember to have read about a numeric solver for the 50g that solves returning the nearest integer. I did also a quick search focused on hpmuseum.org but the results are negative as well.

The idea would be that the numeric solver searches only for integer solutions, not returning real ones. In some problems would be helpful.

[pier4r]

Observation about the 50g AUR bookmarked.

Even with all the bookmarks, search function and whatnot , I find the index at the end of the document quite powerful for searches based on one command. This especially if the word I am searching can be easily part of other words. For example AXL is easy to find, REPL requires the help of the index.

My point is: document extensions that are meant to facilitate the search when the document is printed, such as the index at the end of the book, actually are helpful also with digital searches. In particular it is quite helpful if there is a bookmark to jump on the page that contains the indexed word.

[pier4r]

I'd like to share the following little exploration.

Since I am trying to collect as much interesting digital content* as possible with the hp calc torrent I started also to use what I collect there, even just to check possible damaged documents.

While re-reading the hp solve issue no1 , I noticed the exercises about approximating PI.

The MoHPC forums are full of very beautiful attempts to compute as much digits of PI as possible in creative ways. Try on your favorite search engine the search string: site:hpmuseum.org compute pi (I tried it on google).

Therefore I was unmoved by the exercise, I mean it appeared quite trivial (not the part with the continued fraction though). Nonetheless I gave it a shot to use a bit my 506w and I can be damned, it led to nice questions! From whatever exercise (or action) one can open up a nice world that one did not see before.

So my related question to the exercise was to find the following:
- given a fixed denominator D that is a whole number.
- find the largest whole number L so that L/D < PI and the smallest whole number H so that H/D > PI
- increase D of 1 and do the entire procedure again.

In this way one find, for each fixed D, a range that enclose PI in terms of L and H.
What interested me is that it seems that it builds a pattern pretty quickly:

Code:


(denominator L H)
x/1: 3 4
x/2: 6 7
x/3: 9 10
x/4: 12 13
x/5: 15 16
x/6: 18 19
x/7: 21 22
x/8: 25 26
x/9: 28 29
....

One can observe that after denominators that are multiple of 7 the next L is 3 units bigger as the previous H instead of 2.

While I could explain myself why a range, for whatever denominator, seems to be only 1 unit large, I was curious about the +3 jump and so far I discovered that it is not only caused after denominators that are multiple of 7. The denominator that cause the next range to be 3 units apart is 113, from the famous 355/133.

So thanks to the hp 50g and the following naive program

Code:


\<<
    1               "lvFirstDenominator"                  DROP
    1000           "lvLastDenominator"                   DROP
    0               "lvMinValue"                          DROP
    0               "lvMaValue"                           DROP
    
    \->
    lvFirstDenominator
    lvLastDenominator
    lvMinValue
    lvMaxValue
    
    \<<
      lvFirstDenominator lvLastDenominator
      FOR lvDenominator
        lvDenominator \pi * IP
          @ this give us the largest integer numerator that
          @ makes x/lvDenominator smaller than Pi.
        
        @ then we need to find the smallest integer numerator that
        @ makes x/lvDenominator greater than pi.
        @ According to my test on paper this seems to be always
        @ a number one value higher than the one previously found.
        @ I did not prove it, so let's be safe.
        @ no, without being safe. I may have a non-rigorous proof.
        @ if den*pi = K , where K is real with decimals since 'den' is an integer,
        @ and den*x = int(K) = floor(K) because x is exactly floor(den*pi); then
        @ den*(x+1) is bigger than den*pi. 
        @ den*(x+1) cannot be equal to den*pi because
        @ 'den' and 'x+1' are integers while pi is a real with decimals.
        @ x+1 cannot be smaller than 'den*pi' because by construction the largest
        @ multiple of 'den' smaller than 'den*pi' is 'den*x' thus 'den*(x+1)'
        @ is bigger than 'den*pi' and therefore (x+1) is the upper bound
        @ of the wanted range.
        DUP 1 + @compute x+1
      NEXT
      
      @we have on the stack many values now, let's pack them in a list
      @how many?
      lvLastDenominator lvFirstDenominator - 1 +
      2 *
      \->LIST
      
      @now compute the differences between values in the list
      DUP \GDLIST
    \>>

and some manual manipulations directly on the hp50g I collected the denominators that shows L numerators with +3 difference from the previous H.
The sequence is like: { 8, 15, 22, 29, 36, 43, 50, 57, 64, 71, 78, 85, 92, 99, 106, 114, 121 ... }.
The sequence is not yet in the OEIS database for what I know.

To obtain it, after the \GDLIST pick all the positions that contains a 3 (with MPOS of the listEXT library it is easy) . Then divide the results by 2 and after that apply CEIL. It should return the related denominators of the range that was 3 unit away from the previous one.

I am pretty sure this question was already explored, but still it is interesting for me to explore it myself. Does anyone has pointers to studies that explains what I am computing, so I can read them after I finish my personal attempt?
(Edit: found two pointers, although I expected more https://oeis.org/A063438 -- https://oeis.org/A022844 )

Otherwise I should find the time to explain to myself, somehow, why the +2 distance? Why the +3 distances only after some denominators? Are there more distances? Etc...

* related to the hp calculators (and calculators/math in general).

[Claudio L.]

(10-31-2017 02:22 PM)pier4r Wrote:  Otherwise I should find the time to explain to myself, somehow, why the +2 distance? Why the +3 distances only after some denominators? Are there more distances? Etc...

Start with the equality. A=number, not necessarily integer. L=Floor(A) and H=ceil(A).

A/n=pi
A=pi*n

Therefore your L and H are:
L=floor(n*pi)
H=ceil(n*pi)

This means in general, L and H both skip in pi steps as you increase n, but after you round with floor/ceil you only move 3 units, leaving a remainder of (pi-3) that accumulates for the next iteration. Once that reminder accumulates to 1 you'll skip 4 instead of 3.
Turns out 1/(pi-3) = 7.06xxxx that's why you accumulate one unit every 7 iterations.

[pier4r]

(10-31-2017 03:12 PM)Claudio L. Wrote:  Start with the equality. A=number, not necessarily integer. L=Floor(A) and H=ceil(A).

A/n=pi
A=pi*n

Therefore your L and H are:
L=floor(n*pi)
H=ceil(n*pi)

This means in general, L and H both skip in pi steps as you increase n, but after you round with floor/ceil you only move 3 units, leaving a remainder of (pi-3) that accumulates for the next iteration. Once that reminder accumulates to 1 you'll skip 4 instead of 3.
Turns out 1/(pi-3) = 7.06xxxx that's why you accumulate one unit every 7 iterations.

Nice idea, I should reflect on it to see if I can explain all the non-7-based skips.
For the next time I ask you if you could put it in spoilers though, like this:

Code:



spoilers below












below










I said below









almost














here: hugs

[pier4r]

On a side note, recently I was trying to find a minimalist wallpaper with the German flag. My search skills did not help.

Since at the end a desktop wallpaper is a 2d image, I decided to attack the problem with some math, 50g and highcharts.js for plotting (or html5 canvas when things get rough, although highcharts.js is quite neat).

So far I got this, that for me is quite satisfying.

https://i.imgur.com/THesJyE.png
preview


the problem is that the canvas is pretty big, 3840 x 2880 and the points I used from a sine function are not much.

hp50g code

Code:


gpPlotSines
  \<<
    @remark: mode should be in degrees!
    @ it uses listExt of DavidM

    @Plan: see gpSlightlyRandomFunctions

    @2017-10-28: amplitude, offset and highchart setup are important elements
    @ that play together a role to let the graph be as you wish.

    36             "lvIterations"            DROP
    10             "lvIncrementDegrees"      DROP
    2              "lvPeriods"               DROP
    {}             "lvResultValues"          DROP
    1000           "lvAmplitude"             DROP
    1000000        "lvOffset"                DROP
    0              "lvStartingAngle"         DROP
    0              "lvElementsToPackInList"  DROP

    \->
    lvIterations
    lvIncrementDegrees
    lvPeriods
    lvResultValues
    lvAmplitude
    lvOffset
    lvStartingAngle
    lvElementsToPackInList

    \<<
      0 lvIterations 1 - 
      @ the sine is periodical so one does not necessarily need to compute it
      @ all the time, if the computation returns always the same results.
      @ because computing 1000 SINes is slow, about 613 seconds with the 50g.
      @ while repeating the same block of 24 values, takes circa 3 seconds.
      @ some big difference.
      @ but this is complicated when the increment is not a divisor of 360,
      @ so let's make it proper.
      FOR lvIndex
        lvStartingAngle lvIncrementDegrees lvIndex * +
        SIN

        @amplitude and offset
        lvAmplitude *
        @0 RND
        IP
        lvOffset +

        @leave it on the stack
        @and count
        'lvElementsToPackInList' 1 STO+
      NEXT

      @pack the list of values
      lvElementsToPackInList \->LIST
      @not needed: 'lvResultValues' STO

      gpConvertListToJsArray
    \>>
  \>>

  gpConvertListToJsArray
  \<<
    @input a list
    @transform in string
    \->STR
    @replace the string opening and closing with squared brackets
    "{" "[" SREPL DROP
    "}" "]" SREPL DROP

    @replace the "." of the real numbers with no decimals (assuming integers)
    "." "," SREPL
    DROP @drop the number of replacements
  \>>

  gpConvertJsArrayToList
  \<<
    @input a string
    @replace the string opening and closing with squared brackets
    "[" "{" SREPL DROP
    "]" "}" SREPL DROP

    @replace the "," (assuming integers)
    "," "." SREPL DROP

    @transform from string
    OBJ\->
  \>>

highcharts.js code

Code:


<!DOCTYPE html>
  <html>
    <html lang="en"> 
    <head>
      <meta charset="utf-8"/>
      <title>Three functions german colors</title>
      <!-- <script src="https://code.highcharts.com/highcharts.js"></script> -->
      <script src="highcharts_6_0_2.js"></script>
      <!-- <script src="https://code.highcharts.com/modules/exporting.js"></script> -->
      <script src="highcharts_6_0_2_exporting.js"></script>
    </head>  
    <body>
      <!-- <div id="chart_div" style="min-width: 310px; height: 400px; margin: 0 auto"></div> -->
      <!-- <div id="chart_div" style="width: 1920px; height: 1440px; margin: 0 auto"></div> -->
      <div id="chart_div" style="width: 1920px; height: 1440px; margin: 0 auto"></div>
      <script>
        var container_element = document.getElementById("chart_div");
        Highcharts.chart(container_element , {
            title: {
              text: null
            },

            subtitle: {
              text: null
            },

            yAxis: {
              visible: false,
              min: 998500,
              max: 1001000,
            },

            xAxis: {
              visible: false,
              min: 24,  //quick way to leave data points in, but put them outside the graph.
            },

            chart: {
              marginLeft: 0,
              //backgroundColor: '#2bb71b',
              //backgroundColor: '#3dce7c',
              //backgroundColor: '#21a515',
              //backgroundColor: '#53a34c',
              backgroundColor: '#4156a3',
              /*
              backgroundColor: {
                  //top to bottom
                  linearGradient: { 
                    x1: 0, y1: 0, 
                    x2: 0, y2: 1, 
                  },
                  stops: [
                      [0, '#e5e4e3'],
                      [1, '#6d6d6c'],
                  ]
              },
              */
            },

            /*
            plotOptions: {
              series: {
                pointStart: 10
              }
            },
            */

            legend: {
              enabled: false,
            },

            series: [
              {
                name: null,
                //black
                color: '#000000',
                lineWidth: 40,
                marker: { 
                  enabled : false,
                },
                visible: true,
                enableMouseTracking: false,
                index: 3,
                // 999035 with amplitude 1000 and offset 1000000 is sin(75)
                data: [ 999035, 999030, 999026, 999022, 999019, 999016, 999013, 999010, 999008, 999006,
999004, 999003, 999002, 999001, 999001, 999000, 999001, 999001, 999002, 999003, 999004, 999006, 
999008, 999010, 999013, 999016, 999019, 999022, 999026, 999030, 999035, 999039, 999044, 999049, 
999055, 999061, 999067, 999073, 999080, 999087, 999094, 999102, 999109, 999118, 999126, 999134, 
999143, 999152, 999162, 999171, 999181, 999191, 999202, 999212, 999223, 999234, 999246, 999257, 
999269, 999281, 999293, 999306, 999319, 999331, 999344, 999358, 999371, 999385, 999399, 999413, 
999427, 999441, 999456, 999471, 999485, 999500, 999516, 999531, 999547, 999562, 999578, 999594, 
999610, 999626, 999642, 999658, 999675, 999691, 999708, 999725, 999742, 999759, 999776, 999793, 
999810, 999827, 999844, 999861, 999879, 999896, 999913, 999931, 999948, 999966, 999983, ]
              }, 
              {
                name: null,
                //red
                color: '#f22121',
                lineWidth: 40,
                marker: { 
                  enabled : false,
                },
                visible: true,
                enableMouseTracking: false,
                index: 2,
                data: [ 999087, 999080, 999073, 999067, 999061, 999055, 999049, 999044, 999039, 999035, 
999030, 999026, 999022, 999019, 999016, 999013, 999010, 999008, 999006, 999004, 999003, 999002, 
999001, 999001, 999000, 999001, 999001, 999002, 999003, 999004, 999006, 999008, 999010, 999013, 
999016, 999019, 999022, 999026, 999030, 999035, 999039, 999044, 999049, 999055, 999061, 999067, 
999073, 999080, 999087, 999094, 999102, 999109, 999118, 999126, 999134, 999143, 999152, 999162, 
999171, 999181, 999191, 999202, 999212, 999223, 999234, 999246, 999257, 999269, 999281, 999293, 
999306, 999319, 999331, 999344, 999358, 999371, 999385, 999399, 999413, 999427, 999441, 999456, 
999471, 999485, 999500, 999516, 999531, 999547, 999562, 999578, 999594, 999610, 999626, 999642,
 999658, 999675, 999691, 999708, 999725, 999742, 999759, 999776, 999793, 999810, 999827, ]
              },
              {
                name: null,
                //gold
                color: '#ffcf0f',
                lineWidth: 40,
                marker: { 
                  enabled : false,
                },
                visible: true,
                enableMouseTracking: false,
                index: 1,
                data: [ 999162, 999152, 999143, 999134, 999126, 999118, 999109, 999102, 999094, 999087, 
999080, 999073, 999067, 999061, 999055, 999049, 999044, 999039, 999035, 999030, 999026, 999022, 
999019, 999016, 999013, 999010, 999008, 999006, 999004, 999003, 999002, 999001, 999001, 999000, 
999001, 999001, 999002, 999003, 999004, 999006, 999008, 999010, 999013, 999016, 999019, 999022, 
999026, 999030, 999035, 999039, 999044, 999049, 999055, 999061, 999067, 999073, 999080, 999087, 
999094, 999102, 999109, 999118, 999126, 999134, 999143, 999152, 999162, 999171, 999181, 999191, 
999202, 999212, 999223, 999234, 999246, 999257, 999269, 999281, 999293, 999306, 999319, 999331, 
999344, 999358, 999371, 999385, 999399, 999413, 999427, 999441, 999456, 999471, 999485, 999500, 
999516, 999531, 999547, 999562, 999578, 999594, 999610, 999626, 999642, 999658, 999675, ]
              },
            ],
        });
      </script>
    </body>
  </html>

[pier4r]

I am slowly continuing to explore the "integer numerator ranges that enclose pi" (I post it here and not in another thread because I already mentioned the exploration here).

At the moment I'd like to see how the numerators approaches pi keeping a dynamic TopX of approximations. The program I assembled so far does a lot of list processing and the listExt library of DavidM is super helpful. Especially KSORT is great.

The program has the following idea:

create a list that contains quintuplets
{ D NL NH VL VH }
D: denominator
NL: numerator low (minimum of the range given the denominator)
NH: numerator high (maximum of the range given the denominator)
VL: value NL/D
VH: value NH/D

I do not just add to the result all the quintuplets between firstDenominator (say 1) and maxDenominator (say 10).
Instead I want to add those approximations that make it to the "actual top5", where actual means: considering the quintuplets computed so far. This excluding quintuplets that produce the same best approximation.

For example
14 43 44 3.071... 3.14285...
is considered equal to
7 21 22 3 3.14285...
because the best approximation produced ( 44/14 ) is already in the top 5, since 22/7 was the first instance found for that approximation. (I may later on check if also the second approximation is worth the top5)

The program is the following

Code:


gpIntegerRangeEnclosePiAttempt201711051450
  \<<
    @use the listExt of davidM
    1               "lvFirstDenominator"                  DROP
    10              "lvLastDenominator"                   DROP
    0               "lvCountElements"                     DROP
    { }             "lvCurrentTopApproximations"          DROP
    { }             "lvCurrentTopApproxDist"              DROP
    5               "lvNumberTopApproxSave"               DROP
    0               "lvValueMin"                          DROP
    0               "lvValueMax"                          DROP
    0               "lvApproxInIteration"                 DROP
    0               "lvDistInIteration"                   DROP
    
    
    \->
    lvFirstDenominator
    lvLastDenominator
    lvCountElements
    lvCurrentTopApproximations
    lvCurrentTopApproxDist
    lvNumberTopApproxSave
    lvValueMin
    lvValueMax
    lvApproxInIteration
    lvDistInIteration
    
    
    \<<
      0 lvNumberTopApproxSave NDUPN \->LIST 
      DUP 'lvCurrentTopApproximations' STO
      \pi - ABS 'lvCurrentTopApproxDist' STO
      
    
      lvFirstDenominator lvLastDenominator
      FOR lvDenominator
        lvDenominator @den
        DUP \pi * IP @min num
        DUP 1 + @max num
          @see explanation in other attemps
        OVER lvDenominator / @min num/den 
        DUP 'lvValueMin' STO
        
        OVER lvDenominator / @max num/den
        DUP 'lvValueMax' STO
        
        IF
          @if there is not already the best approximation inside the top list
          lvValueMin lvValueMax 2 \->LIST @make a list of value
          DUP 'lvApproxInIteration' STO
          DUP \pi - ABS @distance from pi in absolute value
          DUP 'lvDistInIteration' STO
          KSORT @sort by distance
          DROP @drop the distance
          HEAD @pick the approx with the closest distance to PI
          lvCurrentTopApproximations SWAP POS 0 ==
            @the best value is not in the list
        THEN
          @see if any of those two values is in the best approximations
          @optimizations come later
          lvCurrentTopApproximations lvApproxInIteration +
          lvCurrentTopApproxDist lvDistInIteration +
          
          @ sort by the absolute distance from PI
          KSORT
          
          @save the distance
          lvNumberTopApproxSave LFRST 'lvCurrentTopApproxDist' STO
          @save the list of the 5 best approx
          lvNumberTopApproxSave LFRST 'lvCurrentTopApproximations' STO
          
          IF
            lvCurrentTopApproximations lvValueMin POS 0 >
            lvCurrentTopApproximations lvValueMax POS 0 >
            OR
            @ if Any approximation made it in the top list
          THEN
            @save the computations
            'lvCountElements' 5 STO+
          ELSE
            @discard
            5 DROPN
          END
        ELSE
          @discard
          5 DROPN
        END
      NEXT
      
      @we have on the stack many values now, let's pack them in a list
      lvCountElements
      \->LIST
      
    \>>
  \>>

The program runs on my hp50g in 646 seconds for the first 1000 denominators.

And uses 10232 seconds for the first 10k denominators. Seeing the fraction slowly closing in pi is satisfying.

The values so far:

Code:


{ 1. 3. 4. 3. 4. 4. 12. 13. 3. 3.25 5. 15. 16. 3. 3.2 6. 18. 19. 3. 3.16666666667 
7. 21. 22. 3. 3.14285714286 8. 25. 26. 3.125 3.25 
9. 28. 29. 3.11111111111 3.22222222222 10. 31. 32. 3.1 3.2 
11. 34. 35. 3.09090909091 3.18181818182 
13. 40. 41. 3.07692307692 3.15384615385 
15. 47. 48. 3.13333333333 3.2 17. 53. 54. 3.11764705882 3.17647058824 
19. 59. 60. 3.10526315789 3.15789473684 20. 62. 63. 3.1 3.15 
22. 69. 70. 3.13636363636 3.18181818182 23. 72. 73. 3.13043478261 3.17391304348 
27. 84. 85. 3.11111111111 3.14814814815 29. 91. 92. 3.13793103448 3.1724137931 
34. 106. 107. 3.11764705882 3.14705882353 36. 113. 114. 3.13888888889 3.16666666667 
41. 128. 129. 3.12195121951 3.14634146341 43. 135. 136. 3.13953488372 3.16279069767 
48. 150. 151. 3.125 3.14583333333 50. 157. 158. 3.14 3.16 
57. 179. 180. 3.14035087719 3.15789473684 64. 201. 202. 3.140625 3.15625 
71. 223. 224. 3.14084507042 3.15492957746 78. 245. 246. 3.14102564103 3.15384615385 
85. 267. 268. 3.14117647059 3.15294117647 92. 289. 290. 3.14130434783 3.15217391304 
99. 311. 312. 3.14141414141 3.15151515152 106. 333. 334. 3.14150943396 3.15094339623 
113. 354. 355. 3.13274336283 3.14159292035 120. 376. 377. 3.13333333333 3.14166666667 
127. 398. 399. 3.13385826772 3.14173228346 205. 644. 645. 3.14146341463 3.14634146341 
219. 688. 689. 3.14155251142 3.14611872146 233. 731. 732. 3.13733905579 3.14163090129 
325. 1021. 1022. 3.14153846154 3.14461538462 332. 1043. 1044. 3.14156626506 3.14457831325 
346. 1086. 1087. 3.1387283237 3.14161849711 445. 1398. 1399. 3.14157303371 3.14382022472 
459. 1441. 1442. 3.1394335512 3.14161220044 558. 1753. 1754. 3.14157706093 3.14336917563 
572. 1796. 1797. 3.13986013986 3.14160839161 671. 2108. 2109. 3.14157973174 3.14307004471 
685. 2151. 2152. 3.1401459854 3.14160583942 784. 2463. 2464. 3.14158163265 3.14285714286 
798. 2506. 2507. 3.14035087719 3.14160401003 897. 2818. 2819. 3.14158305463 3.14269788183 
911. 2861. 2862. 3.14050493963 3.14160263447 1010. 3173. 3174. 3.14158415842 3.14257425743 
1024. 3216. 3217. 3.140625 3.1416015625 1123. 3528. 3529. 3.14158504007 3.14247551202 
1137. 3571. 3572. 3.14072119613 3.14160070361 1236. 3883. 3884. 3.14158576052 3.14239482201 
1250. 3926. 3927. 3.1408 3.1416 1349. 4238. 4239. 3.14158636027 3.14232765011 
1363. 4281. 4282. 3.14086573734 3.14159941306 1462. 4593. 4594. 3.14158686731 3.14227086183 
1476. 4636. 4637. 3.14092140921 3.14159891599 1575. 4948. 4949. 3.14158730159 3.14222222222 
1589. 4991. 4992. 3.140969163 3.14159848962 1688. 5303. 5304. 3.14158767773 3.14218009479 
1702. 5346. 5347. 3.14101057579 3.14159811986 1801. 5658. 5659. 3.14158800666 3.14214325375 
1815. 5701. 5702. 3.14104683196 3.14159779614 1914. 6013. 6014. 3.14158829676 3.1421107628 
1928. 6056. 6057. 3.14107883817 3.14159751037 2027. 6368. 6369. 3.14158855451 3.14208189443 
2041. 6411. 6412. 3.14110730034 3.14159725625 2140. 6723. 6724. 3.14158878505 3.14205607477 
2154. 6766. 6767. 3.14113277623 3.14159702878 2253. 7078. 7079. 3.14158899245 3.1420328451 
2267. 7121. 7122. 3.1411557124 3.141596824 2366. 7433. 7434. 3.14158918005 3.14201183432 
2380. 7476. 7477. 3.14117647059 3.14159663866 2479. 7788. 7789. 3.14158935054 3.14199273901 
2493. 7831. 7832. 3.14119534697 3.14159647012 2592. 8143. 8144. 3.14158950617 3.14197530864 
2705. 8498. 8499. 3.1415896488 3.14195933457 2818. 8853. 8854. 3.14158977999 3.14194464159 
2931. 9208. 9209. 3.14158990106 3.14193108154 3044. 9563. 9564. 3.14159001314 3.14191852825 
3157. 9918. 9919. 3.1415901172 3.14190687361 3270. 10273. 10274. 3.14159021407 3.14189602446 
3383. 10628. 10629. 3.14159030446 3.14188590009 3496. 10983. 10984. 3.14159038902 3.14187643021 
3609. 11338. 11339. 3.14159046827 3.14186755334 3722. 11693. 11694. 3.14159054272 3.14185921548 
3835. 12048. 12049. 3.14159061278 3.14185136897 3948. 12403. 12404. 3.14159067882 3.14184397163 
4061. 12758. 12759. 3.1415907412 3.14183698596 4174. 13113. 13114. 3.14159080019 3.14183037853 
4287. 13468. 13469. 3.14159085608 3.14182411943 4400. 13823. 13824. 3.14159090909 3.14181818182 
4513. 14178. 14179. 3.14159095945 3.14181254155 4626. 14533. 14534. 3.14159100735 3.14180717683 
4739. 14888. 14889. 3.14159105296 3.14180206795 4852. 15243. 15244. 3.14159109646 3.14179719703 
4965. 15598. 15599. 3.14159113797 3.14179254783 5078. 15953. 15954. 3.14159117763 3.14178810555 
5191. 16308. 16309. 3.14159121557 3.14178385668 5304. 16663. 16664. 3.14159125189 3.14177978884 
5417. 17018. 17019. 3.14159128669 3.14177589071 5530. 17373. 17374. 3.14159132007 3.1417721519 
5643. 17728. 17729. 3.14159135212 3.14176856282 5756. 18083. 18084. 3.1415913829 3.14176511466 
5869. 18438. 18439. 3.14159141251 3.14176179928 5982. 18793. 18794. 3.14159144099 3.14175860916 
6095. 19148. 19149. 3.14159146842 3.14175553733 6208. 19503. 19504. 3.14159149485 3.14175257732 
6321. 19858. 19859. 3.14159152033 3.14174972315 6434. 20213. 20214. 3.14159154492 3.14174696923 
6547. 20568. 20569. 3.14159156866 3.14174431037 6660. 20923. 20924. 3.14159159159 3.14174174174 
6773. 21278. 21279. 3.14159161376 3.14173925882 6886. 21633. 21634. 3.1415916352 3.14173685739 
6999. 21988. 21989. 3.14159165595 3.1417345335 7112. 22343. 22344. 3.14159167604 3.14173228346 
7225. 22698. 22699. 3.1415916955 3.14173010381 7338. 23053. 23054. 3.14159171436 3.14172799128 
7451. 23408. 23409. 3.14159173265 3.14172594283 7564. 23763. 23764. 3.1415917504 3.14172395558 
7677. 24118. 24119. 3.14159176762 3.14172202683 7790. 24473. 24474. 3.14159178434 3.14172015404 
7903. 24828. 24829. 3.14159180058 3.14171833481 8016. 25183. 25184. 3.14159181637 3.14171656687 
8129. 25538. 25539. 3.14159183171 3.14171484807 8242. 25893. 25894. 3.14159184664 3.14171317641 
8355. 26248. 26249. 3.14159186116 3.14171154997 8468. 26603. 26604. 3.1415918753 3.14170996693 
8581. 26958. 26959. 3.14159188906 3.14170842559 8694. 27313. 27314. 3.14159190246 3.14170692432 
8807. 27668. 27669. 3.14159191552 3.14170546156 8920. 28023. 28024. 3.14159192825 3.14170403587 
9033. 28378. 28379. 3.14159194066 3.14170264585 9146. 28733. 28734. 3.14159195277 3.14170129018 
9259. 29088. 29089. 3.14159196458 3.1416999676 9372. 29443. 29444. 3.1415919761 3.14169867691 
9485. 29798. 29799. 3.14159198735 3.14169741697 9598. 30153. 30154. 3.14159199833 3.14169618671 
9711. 30508. 30509. 3.14159200906 3.14169498507 9824. 30863. 30864. 3.14159201954 3.14169381107 
9937. 31218. 31219. 3.14159202979 3.14169266378 }

I do not use heavy stack manipulations, although I use them more than before. For example I build the list only at the end of the iterations, as suggested by John Keith. I avoid too much stack acrobatics due to readability of the code but I am pretty sure other people could make the program way faster.

Therefore I posted it because I am curious to see how it can be optimized.

[Joe Horn]

(11-05-2017 04:05 PM)pier4r Wrote:  I am slowly continuing to explore the "integer numerator ranges that enclose pi" ...

... I am pretty sure other people could make the program way faster. Therefore I posted it because I am curious to see how it can be optimized.

Although the following does not "optimize" your code per se, but rather replaces its algorithm with a much faster one, it still might be of some interest to you. Given any decimal fraction in level 2, and a maximum denominator in level 1, it returns the best fraction, much faster than the brute-force search method.

Example:
pi, 1000, DEC2FRAC --> 355/113 in 0.39 seconds
pi, 100000, DEC2FRAC --> 312689/99532 in 0.43 seconds

This program is a slight modification of a program on HP48 Goodies Disk #3.

Everything after each "@" is a comment.

Code:

%%HP:T(3);
@ DEC2FRAC, by Joseph K. Horn
\<< DUP2 @ Must be two arguments.  Exit now if max denominator < 2,
  IF 1 > SWAP FP AND @ or if decimal fraction is an integer.
  THEN \-> f c @ Store decimal fraction, and max denominator.

    \<< 0 1 f @ Calculate only denominators.  Do numerator only at end.
      WHILE OVER c < OVER AND @ Do until bigger than max denominator
      REPEAT INV DUP FP 4 ROLLD IP OVER * ROT + ROT @ This is the
      END DROP DUP2 c @ recursion formula continued fraction expansion.

      IF DUP2 > @ Is there a possible "missing" fraction?
      THEN - OVER / CEIL * - @ This is the new, fast "jump backwards".
      ELSE 3 DROPN @ (Sometimes there's no need to jump.)
      END DUP2 1 2 @ Take the new denominator & the previous one, and

      START DUP f * 0 RND SWAP / f - ABS SWAP @ turn into fractions.
      NEXT @ See which one's closest to the original decimal fraction.

      IF > @ Compare the two solutions, and
      THEN SWAP @ pick the better one.
      END DROP DUP f * 0 RND SWAP @ Calculate the numerator.
    \>> @ End of real work; now clean up the output.

    IF DUP ABS 1 > @ Is the denominator greater than 1?
    THEN -3 CF R\->I SWAP R\->I SWAP / @ If so, make output into 'A/B' form.
    ELSE DROP @ Otherwise, get rid of extraneous denominator,
    END @ and exit program.

  ELSE DROP @ If bad arguments, do nothing to "decimal fraction", but
  END @ get rid of "maximum denominator" and exit program.
\>>

HP 50g BYTES: 298.5 #ED4h

[pier4r]

Thanks Joe.

I do not really want a "brute force search" , rather to see how the improvements progresses (therefore keeping a dynamic topX of values). Nevertheless your code is interesting. I'll try to analyze it asap.



Other question. As I wrote some weeks ago, I am collecting data in lists that are contained in a directory. Then I have a simple backup script that puts the directory on the SD card of the 50g.

The other day I finally copied all the backups (150, one for each day) on the pc. With cygwin I can see, with the command file, that the files are HP 49 files, but they are not made by plain text as I would have expected.

Is there a preferred convert tool that converts hp49 directories in their text equivalent on the pc?

Otherwise I will check what I can do with the 50g, to store something that is "text editor friendly".


Edit: if I store the directory as a string object. It works.
So now I need a program similar to some I saw on this forum. The one I saw inspected directory and sub directories to order them by type and what not - it is quite a nice challenge; I'll have to go recursively in a directory and subdirectories to convert files from HPDIR to STR.

The hp50g does everything, not only math and programming, it is even a platform for system administrators.

[DavidM]

(11-07-2017 07:33 PM)pier4r Wrote:  The other day I finally copied all the backups (150, one for each day) on the pc. With cygwin I can see, with the command file, that the files are HP 49 files, but they are not made by plain text as I would have expected.

You've probably already realized that →STR will help you out with this conversion. Note that it's not a 100% safe conversion, though. →STR will convert objects into strings which are similar to the object's representation when recalled to the stack, which doesn't necessarily contain an exact copy of the underlying data.

(11-07-2017 07:33 PM)pier4r Wrote:  Is there a preferred convert tool that converts hp49 directories in their text equivalent on the pc?

Some objects stored on your calculator may not have an exact "text equivalent". In those cases, you may find that →STR creates placeholders for the parts it can't directly convert.

(11-07-2017 07:33 PM)pier4r Wrote:  Otherwise I will check what I can do with the 50g, to store something that is "text editor friendly".

Back in this thread, we discussed another issue that you might run into with this. In particular, the names of objects on the calculator may not be compatible with the SD card's file system, so you might run into trouble saving the files. I also recall finding that I would run into sporadic "invalid DOS name" errors when attempting to copy objects to the SD card, even when there was no compatibility issue with the name in question. But that may have been isolated to some sort of file system corruption on the SD card (see the thread I referenced). I never was able to find a sequence of steps that would recreate those errors, though.

[pier4r]

Thanks for the link, I saved in the bookmark to read it soon. Of course thanks for the general hint as well.

[pier4r]

Today, while searching for a live stream on youtube regarding Berlin, I found a peculiar stream (regarding Tempelhof). It is a stream pointed for half of the image on an highway. I realized that with the view on the highway I could investigate myself, from home, one of the questions that I had during courses at the university: whether the frequency of "arrivals" on the highway would match easily the theoretical distributions that I studied (Poisson for example).

Problem: how do I collect the data? Aside from the errors of manual collection (that more or less should be systematic) , doing it completely in a manual way won't be fast enough.

So once again the trusty calculator (50g) saves the day. With a rough but working program like the following

Code:


WHILE
  0 WAIT 102.1 ==
    @if the 0 key is pressed (10th row, 2nd column from F1. No modifiers)
REPEAT
  TIME @leave time on the stack.
END
@otherwise quit.

I could collect timings for a short while.

Then I did:
DEPTH \->LIST
to save them in a list.

After that:
4 RND
To shorten the timings to seconds.

\GDLIST (delta list)
to get the difference in seconds between entries. (it does not really work when the time distance is over 60 seconds)

Then
DUP LDDUP
to get the single values

Saving the list of values (the one done with \GDLIST ) in a variable, say TLIST1

and then having:
L1: list with delta of timestamps
1 \<< DUP TLIST SWAP LCNT \>> DOSUBS

One can get the value of how many times arrivals where within a certain amount of seconds.

But the fun part is to collect data from the stream as "relaxing" activity.
The entire process can be greatly improved, but I always think that the initial input/question can be useful (as input) when shared.

[pier4r]

I thought a bit about it but with my (seemingly limited) experience I am not able to find a solution.

Is it possible to produce textbook notes for the hp 50g?

I mean I know one can save text as a string. My point is, can one insert in a string also formulas, in a way that when they are viewed by the viewer in the 50g (or a 3rd party viewer library if needed) the formula appear as rendered in the textbook format?

Similarly as instead of writing x+5=3 one can invoke mathjax in the forum writing \( x+5=3 \) .

Because such notes may be useful to keep a readily explanation of some formulas.

Thanks for the help

[Joe Horn]

'expr' 0 →GROB turns any algebraic object 'expr' into a grob in EquationWriter format. The 0 is what tells →GROB to do this.

[pier4r]

Thanks Joe , I will have to check it. Although for clarification I mean to convert a text, containing formulas, to a pretty format.

Something like

"This text will contain a prettified traction

5/(3+x)

More text"

[Joe Horn]

(12-18-2017 07:08 AM)pier4r Wrote:  Thanks Joe , I will have to check it. Although for clarification I mean to convert a text, containing formulas, to a pretty format.

Something like

"This text will contain a prettified traction

5/(3+x)

More text"

No, there is no way for the 50g to magically know which parts of your text you want to be interpreted as an algebraic expression. I'd suggest handling the plain text separately from the algebraic expressions, then combining the results.

[pier4r]

Thanks. I expected that but I hoped in a simpler way than packing grobs together.

Another observation. In my data collection I observed that two lists of the same length, 193 elements, both holding reals, have two different sizes . One list has values between 0 and 4 (integers expressed as reals) and uses less than 500 bytes.
The other holds integers expressed as reals from 0 to 520 and uses more than 2000 bytes.

I thought that the size of a real number was always the same as long as the number could be saved as real.

[DavidM]

(12-19-2017 09:15 PM)pier4r Wrote:  Another observation. In my data collection I observed that two lists of the same length, 193 elements, both holding reals, have two different sizes . One list has values between 0 and 4 (integers expressed as reals) and uses less than 500 bytes.
The other holds integers expressed as reals from 0 to 520 and uses more than 2000 bytes.

Some reals are built-in to ROM (as are some exact integers), and are usually referenced in a list by their 2.5 byte address instead of the actual raw data (which consumes 10.5 bytes). In particular, all integer reals in the range -9..35 can be referenced this way. There's others, too, but that should give you some idea of where the size differences come from.

[pier4r]

Is John H Meyers still active? It is impressive how many 48/50g-based contributions he made that pop ups in searches (same with DavidM, Joe Horn, James Prager and the like)!

I was searching about Inform (only 4 values per column) and I found this:
https://groups.google.com/forum/#!topic/...2VOANxBLIs

Impressive the dedication.

And adding it to the userRPL entries.

edit: if someone knows better replacements to INFORM, please share!
edit2: if you wish to put INFORML and INLIST in port2, remember to edit INFORML to call :2:INLIST and your program to call :2:INFORML . (on the calculator :2:INLIST shows up as :2: INLIST with a space. Dunno why)

[rprosperi]

(02-19-2018 08:03 PM)pier4r Wrote:  Is John H Meyers still active? It is impressive how many 48/50g-based contributions he made that pop ups in searches (same with DavidM, Joe Horn, James Prager and the like)!

A (possibly too) quick search seems to indicate that this was his last post in comp.sys.hp48 in late 2013, and I agree his contributions are amazing. I've learned it's generally necessary to read them several times to both follow and appreciate everything he's saying, and even then often I cannot fully do so. Also, he's quite acerbic, in an entertaining way, when annoyed.

One of my favorite posts John contributed is this one about implementing the PI (Product) function on the 48/49/50. The short program listings are misleading regarding the elegance of his implementation. At least for me they are, ymmv. Dissecting this helped teach me about some of the subtleties of RPL.