HP Forums
Little explorations with HP calculators (no Prime) - Printable Version

+- HP Forums (https://www.hpmuseum.org/forum)
+-- Forum: HP Calculators (and very old HP Computers) (/forum-3.html)
+--- Forum: General Forum (/forum-4.html)
+--- Thread: Little explorations with HP calculators (no Prime) (/thread-7955.html)

Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18


RE: Little explorations with the HP calculators - Gerson W. Barbosa - 03-27-2017 07:39 PM

(03-27-2017 12:14 PM)pier4r Wrote:  
Quote:Brilliant.org

[Image: sCHSWIp.png]

Let's divide one of the right-triangles into four right-triangles (two with sides lengths equal to r and x and two with side lengths r and 1-x) and a square with side r. Then it's area is

S = r*x + r(1-x) + r^2

S = r^2 + r

The area of the larger square, witch we know is equal to 1, is the sum of the areas of these four right-triangles plus the area of the smaller square in the center, with side 2*r:

S = 4(r^2 + r) + (2*r)^2 = 1

Or

8*r^2 + 4*r - 1 = 0

Here I am tempted to just take my wp34s and do 8 ENTER 4 ENTER 1 +/- SLVQ and get a valid numerical answer for the quadratic equation, but I decide to go through a few more steps by hand and get the exact answer:

r = (sqrt(3) - 1)/4


RE: Little explorations with the HP calculators - pier4r - 03-27-2017 07:58 PM

Gerson do you mean the following subdivision?

[Image: oWQ6dpil.jpg]


RE: Little explorations with the HP calculators - Han - 03-27-2017 08:01 PM

(03-27-2017 07:24 PM)Joe Horn Wrote:  So it SEEMS to be zeroing on something close to -LOG(LOG(2)), but I give up.

Some multivariate calculus and probability theory will get you:

\[ \frac{2+\sqrt{2}+5\ln(1+\sqrt{2})}{15} \approx 0.521405433164720678330982356607243974914031567779008341796 \]


RE: Little explorations with the HP calculators - Han - 03-27-2017 08:07 PM

(03-27-2017 07:24 PM)Joe Horn Wrote:  After running 100 million iterations several times in UBASIC, I'm surprised that each run SEEMS to be converging, but each run ends with a quite different result:

I wonder if this may be due to precision. The shorter the distance between two points, the higher the probability of seeing that distance appear. Thus, you're looking at a lot of tiny values (as they are more likely) that represent the distance, which may or may not get picked up in the sum if your machine precision is not large enough.


RE: Little explorations with the HP calculators - Joe Horn - 03-27-2017 08:08 PM

(03-27-2017 08:01 PM)Han Wrote:  
(03-27-2017 07:24 PM)Joe Horn Wrote:  So it SEEMS to be zeroing on something close to -LOG(LOG(2)), but I give up.

Some multivariate calculus and probability theory will get you:

\[ \frac{2+\sqrt{2}+5\ln(1+\sqrt{2})}{15} \approx 0.521405433164720678330982356607243974914031567779008341796 \]

Awesome! Time to dust off these old math texts....


RE: Little explorations with the HP calculators - pier4r - 03-27-2017 08:14 PM

(03-27-2017 08:01 PM)Han Wrote:  Some multivariate calculus and probability theory will get you:

\[ \frac{2+\sqrt{2}+5\ln(1+\sqrt{2})}{15} \approx 0.521405433164720678330982356607243974914031567779008341796 \]

This formula comes out from? I suppose a double integral (for x and y?)

On a side note: by chance could you tell me why my algorithm screws up so many digits? Did I make a mistake somewhere or is it again a problem of precision?


RE: Little explorations with the HP calculators - Han - 03-27-2017 08:36 PM

(03-27-2017 08:14 PM)pier4r Wrote:  
(03-27-2017 08:01 PM)Han Wrote:  Some multivariate calculus and probability theory will get you:

\[ \frac{2+\sqrt{2}+5\ln(1+\sqrt{2})}{15} \approx 0.521405433164720678330982356607243974914031567779008341796 \]

This formula comes out from? I suppose a double integral (for x and y?)

Since the distance between two points \( x_1 , y_1 \) and \( x_2, y_2\) is
\[ d = \sqrt{ (x_2 - x_1)^2 + (y_2 - y_1)^2}, \]
I took the approach of looking at the probability density function for the distance between each of the coordinates: \( |x_2 - x_1| \) and \( |y_2 - y_1| \). Since they are independent and identically distributed, just consider the probability density of \( x=|x_2 - x_1| \). Once I got the probability distribution function (it's a triangular distribution with \( 0\le x \le 1 \) ), the integral I ended up with was indeed a double integral. EDIT: there were two of them; one for find the PDF and the other to compute the expected value. (I had to pull out my calculus textbook because the second one is quite a tedious computation to do by hand. I started with a double integral in x and y, but had to convert over to polar coordinates.)

Quote:On a side note: by chance could you tell me why my algorithm screws up so many digits? Did I make a mistake somewhere or is it again a problem of precision?

My suspicion is that it is due to precision. This is just a hunch, though. Here is my thought process. For 1000000 iterations, the sum must be close to 520000 so that the average comes out to be about .52. However, the small distances that are added into the running average (that appear the most frequently) would be very close to zero (but sufficiently many occurrences to add up to a significant value if there was enough precision). Each incremental sum, however, would likely be computed as adding 0 once the partial sum has reached a large enough magnitude.


RE: Little explorations with the HP calculators - pier4r - 03-27-2017 08:44 PM

(03-27-2017 08:36 PM)Han Wrote:  Since the distance between two points \( x_1 , y_1 \) and \( x_2, y_2\) is
\[ d = \sqrt{ (x_2 - x_1)^2 + (y_2 - y_1)^2}, \]
I took the approach of looking at the probability density function for the distance between each of the coordinates: \( |x_2 - x_1| \) and \( |y_2 - y_1| \). Since they are independent and identically distributed, just consider the probability density of \( |x_2 - x_1| \). Once I got the probability distribution function, the integral I ended up with was indeed a double integral. (I had to pull out my calculus textbook because it is quite a tedious computation to do by hand.)


My suspicion is that it is due to precision.

Interesting, both parts. I do indeed take only the integer part of the random value, after 3 digits (with IP). I will check what happens if I extend it to 6. Now I compute... poor batteries.

[Image: bW6WDYp.png]


RE: Little explorations with the HP calculators - Dieter - 03-27-2017 08:55 PM

(03-27-2017 07:39 PM)Gerson W. Barbosa Wrote:  ...
r = (sqrt(3) - 1)/4

Finally a concise analytic solution, much more elegant than mine – congratulations, Gerson.
I'm glad that at least the results agree. ;-)

Dieter


RE: Little explorations with the HP calculators - Gerson W. Barbosa - 03-27-2017 10:12 PM

(03-27-2017 07:58 PM)pier4r Wrote:  Gerson do you mean the following subdivision?

[Image: oWQ6dpil.jpg]

Yes, exactly. Thanks for both the problem and the drawing!


RE: Little explorations with the HP calculators - Gerson W. Barbosa - 03-27-2017 10:35 PM

(03-27-2017 08:55 PM)Dieter Wrote:  
(03-27-2017 07:39 PM)Gerson W. Barbosa Wrote:  ...
r = (sqrt(3) - 1)/4

Finally a concise analytic solution, much more elegant than mine – congratulations, Gerson.
I'm glad that at least the results agree. ;-)

Thanks, Dieter! Honestly, I was a bit lucky on this one. I had only introduced the x and while I was still worried about how to get rid of it, it just magically disappeared in the second line :-)
Probably there are better solutions around.

Gerson.


RE: Little explorations with the HP calculators - pier4r - 03-28-2017 10:44 AM

So there is the summation function built in in the 50g, I searched for the product function (like \PI ) in the AUR and I had no luck. So using a quick search on this site using a search engine I found this:

http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/archv021.cgi?read=249353

Message #10

Quote:Outside the equation writer one could use a combination of SEQ and PILIST (from the MTH/LIST menu). This would also work for negative members of the series.

n
n
-5
5
2
SEQ

You'll get a list:

{-5 -3 -1 1 3 5}

PILIST

I have to say that this is pretty neat, but do you know any better way to achieve the same (function / user defined program)? Of course I could do a rough program by myself, but I do like to reuse code, especially if the code is well tested and refined.

I may also study the following post, maybe it yields to neat results: https://groups.google.com/forum/#!topic/comp.sys.hp48/UGkp_1wb1X8/discussion (Simone knows a lot / has great searching skills)


RE: Little explorations with the HP calculators - pier4r - 03-28-2017 11:07 AM

Quote:brilliant.org (this site is very nice on certain topics, other topics are a bit, well, low profile still)

[Image: gewiGNI.png]

On this I have at first no useful direction whatsoever. Anyway since the intention is to burn the 50g somehow, I will try with a trial and error approach in the range of possible values (knowing that the diameter cannot be smaller than, say, 10, and bigger than 10 * sqrt(2) ) until I fit the mentioned form.

edit, the minvalue 10 is a tad too much, since the diameter is included in the radius of the big circle. So the maxvalue is 10 actually.

Ok wrote the program, not so nice but it is the first iteration. Its output are all the possible "valid" length of the diameter, given that the diameter is expected to be greater or equal to 7 and smaller or equal to 10, plus the value of a b and c. The problem is, to deremine the right value if the right value is there (there could be the case that a is large, while sqrt(b) and c have a small difference, this is not captured by the program.
Code:

@ problem:
@ take a circle of radius 10. Take a quarter of it.
@ Inscribe the biggest circle in it.
@ the diameter of the inscribed circle can be written in the form:
@ a*(sqrt(b)-c) . a,b,c are integers, b is square free.
@ We need to find the value of floor( a^2*b^2*c^2 / (a+b+c) )
@ but this program is mainly to find the 3 single values

@ Addition1: due to changes in parts of the program, may be that variables are unused.
@ they stay until the program is stable.

\<<
  7 @ minDValue
    @ because the diameter is longer than half the diagonal of a square of side 10.
  10 @maxDValue
    @ because the diameter is smaller than the radius
  1 @a
  2 @b
  1 @c
  0 @result
  10 @uFstopComputation
     @handy for boolean variables
  11 @uFisResultValid
  12 @uFcanIncrementA
  13 @uFcanIncrementB
  14 @uFcanIncrementC
  15 @uFexitLoop
  16 @uFbSquareFree
  20 @uFdebug
  10000 @maxIterations (debug)
  0 @iterations (debug)
  0 @sF3
  0 @sF105
  \->
  minDValue @starting the search from here as diameter
  maxDValue @stopping the search here as diameter
  a
  b
  c
  result
  uFstopComputation
  uFisResultValid
  uFcanIncrementA
  uFcanIncrementB
  uFcanIncrementC
  uFexitLoop
  uFbSquareFree
  uFdebug
  maxIterations
  iterations
  sF3
  sF105
  \<<
    @system flag set, then restored at the end
    -3 FS? 'sF3' STO
    -105 FS? 'sF105' STO
    -3 SF
    -105 SF
    
    uFdebug SF
  
    uFstopComputation CF
      @we stop the computation if the flag is set
    uFcanIncrementA SF
      @we can increment a
    uFcanIncrementB SF
    uFcanIncrementC SF
    

    WHILE 
      uFstopComputation FC?
      
      iterations maxIterations \<=
      uFdebug FS?
      AND
      
      AND
    REPEAT
      b \v/ 
        @sqrt b
      c -
      a *
      'result' STO
      
      IF
        result  minDValue \>=
        result  maxDValue \<=
        AND
      THEN
      
        IF
          b 1 >
        THEN
          @ testing the square free
          uFbSquareFree SF
          
          2 @ start
          b \v/ FLOOR @end
          FOR testN
            IF
              b testN 2 ^ \>=
              @ no need to go further when the testN is bigger than b
            THEN
              IF
                b testN 2 ^ MOD
                0 ==
                @ if no remainder for the division
              THEN
                uFbSquareFree CF @ no square free
                @uFisResultValid CF
                  @result not valid
                
                @ugly break
                b 'testN' STO
              END
            ELSE
              @ugly break
              b 'testN' STO
            END
          NEXT
        END
        
        IF
          uFbSquareFree FS?
        THEN
          @ the result should be fine, post it
          @ for further checks in packed list that are compact
          result  a b  c 
          4 \->LIST
        END
      END
      
      IF
        result  maxDValue \<=
      THEN
        @ as long as the result is under the max value.
        IF
          b \v/ c \>=
            @ otherwise the sqrt(b) -c is negative
        THEN
          1 'c' STO+
        ELSE
          @if c cannot be incremented, time for b
          1 'b' STO+
          1 'c' STO @reset c
        END
      ELSE
        IF
          a b <
        THEN
          @the program incremented b (in the case also c)
          @ until the value grew too much, time to increment a
          1 'a' STO+
          @ reset the rest
          2 'b' STO 
          1 'c' STO
        ELSE
          @a > b
          IF
            b == 2
            c == 1
          THEN
            @ we are in the case that
            @ with default b and c values, a is already too big.
            @ stop sim.
            uFstopComputation SF
          END
        END
      END
      
      IF
        uFdebug FS?
      THEN
        1 'iterations' STO+
        @ a b c 3 \->LIST
      END
    END
    
    IF
      uFdebug FS?
    THEN
      iterations
      "iter" \->TAG
    END
    
    @system flag restored
    IF
      sF3
    THEN
      -3 SF
    END
    
    IF
      sF105
    THEN
      -105 SF
    END
  \>>
\>>



RE: Little explorations with the HP calculators - Dieter - 03-28-2017 05:33 PM

(03-28-2017 11:07 AM)pier4r Wrote:  On this I have at first no useful direction whatsoever.

What? No clue? Really ?-)

Take a look at the picture. From the upper left corner to the point where the circle touches the arc it's √2 · d/2 plus d/2, and this sum is 10. This directly leads to d = 20/(1+√2) or 8,284. Expand this with 1–√2 to get d = 20 · (√2–1). So a=20, b=2, c=1, and the desired value is floor(1600/23) = 69.

Dieter


RE: Little explorations with the HP calculators - Dieter - 03-28-2017 05:46 PM

(03-21-2017 10:40 PM)pier4r Wrote:  So I got to another problem and I'm stuck.

Quote:Brilliant.org
Let

\[A= \sum_{n=1}^{2014}{n} ~~~\text{and} ~~~ B= \sum_{n=1}^{2014}{n^3}.\]

Find the value of \(\log_{\sqrt A} {B}\)

Now, I know the closed formulas for the two summations, but I want to solve it with the calculator as much as I can.

Better use your brain. ;-)

You know the summation formulas. For any positive upper limit (not just 2014), B is the square of A.
So logAB = 2 and log√AB = 2 · 2 = 4. No calculator required.

Dieter


RE: Little explorations with the HP calculators - pier4r - 03-28-2017 06:13 PM

(03-28-2017 05:33 PM)Dieter Wrote:  What? No clue? Really ?-)

Take a look at the picture. From the upper left corner to the point where the circle touches the arc it's √2 · d/2 plus d/2, and this sum is 10. This directly leads to d = 20/(1+√2) or 8,284. Expand this with 1–√2 to get d = 20 · (√2–1). So a=20, b=2, c=1, and the desired value is floor(1600/23) = 69.

Dieter

Thanks for the contribution, my only clue (see image below) died immediately because I did try to determine the x in the image but I failed with my rusty knowledge. And if your solution is correct (we need peer review here) then my program fails even to capture the solution.

http://i.imgur.com/24nmK1G.jpg

Could you explain (or hint a known relationship) how did you get that d/2+x = d/2*sqrt(2) ?


RE: Little explorations with the HP calculators - pier4r - 03-28-2017 06:17 PM

(03-28-2017 05:46 PM)Dieter Wrote:  Better use your brain. ;-)

But the idea of the explorations is: either when I know the shortcut or solutions, or when I do not know them, can I let the calculator solve most of the problem?

In particular that problem raised the problem of "hidden digits by the real representation" that then was solved first with a homemade program (and proper flags), then with the knowledge of Joe Horn with flags and built in summation function.

The problem of the circle above, where I ask you to justify how do you get that x+r = r*sqrt(2), let me refresh a couple of userRPL commands and the usage of flags as booleans.

I mean, the more I analyze the failures, the better.


RE: Little explorations with the HP calculators - Han - 03-28-2017 07:32 PM

(03-28-2017 06:13 PM)pier4r Wrote:  Could you explain (or hint a known relationship) how did you get that d/2+x = d/2*sqrt(2) ?

The right picture can be worth a 1000 words, as they say :-)

Draw a line segment from the point of tangency (where the circle touches the radial segments of length 10) toward the center of the inner circle. This length is d/2, and the line segment we created is perpendicular to the segments of length 10. (You can produce a square whose diagonal lies at the center of the two circles, and whose side lengths are d/2.)


RE: Little explorations with the HP calculators - Han - 03-28-2017 07:36 PM

Also, for the summation problem, one does not actually need to know either summation formulas. The value 2014 is not that significant (likely chosen because the problem may have been created in 2014). You can make up a conjecture about \( \log_{\sqrt{A}}B \) by using smaller values instead of 2014, and computing the individual sums on your calculator (no program needed, really) which should lead you to the conclusion that the result is always 4. Moreover, this result would enable one to deduce the formula for the sum of cubes if one knew only the formula for the sum of the integers.


RE: Little explorations with the HP calculators - pier4r - 03-28-2017 08:15 PM

(03-28-2017 07:32 PM)Han Wrote:  Draw a line segment from the point of tangency (where the circle touches the radial segments of length 10) toward the center of the inner circle. This length is d/2, and the line segment we created is perpendicular to the segments of length 10. (You can produce a square whose diagonal lies at the center of the two circles, and whose side lengths are d/2.)

Understood. I thought about that but I could not prove... frick. I relied too much on the visual image. Instead of thinking that when a line is tangent to a circle then the radius is perpendicular to it (otherwise the circle would pass through the line), I looked at the picture and I sad "hmm, here I cannot build a square with the radius, I do not see perpendicularity". So it was actually trivial but I relied too much on the visual hint.

Damn me. Well, experience for the next time.

Thanks!