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) |
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 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? 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. 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: 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: 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 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. RE: Little explorations with the HP calculators - Dieter - 03-27-2017 08:55 PM (03-27-2017 07:39 PM)Gerson W. Barbosa Wrote: ... 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? 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: ... 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. 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) 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:
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. 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 ?-) 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! |