Little explorations with HP calculators (no Prime)

03272017, 07:39 PM
Post: #41




RE: Little explorations with the HP calculators
(03272017 12:14 PM)pier4r Wrote:Quote:Brilliant.org Let's divide one of the righttriangles into four righttriangles (two with sides lengths equal to r and x and two with side lengths r and 1x) and a square with side r. Then it's area is S = r*x + r(1x) + 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 righttriangles 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 

03272017, 07:58 PM
Post: #42




RE: Little explorations with the HP calculators
Gerson do you mean the following subdivision?
Wikis are great, Contribute :) 

03272017, 08:01 PM
Post: #43




RE: Little explorations with the HP calculators
(03272017 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 \] Graph 3D  QPI  SolveSys 

03272017, 08:07 PM
Post: #44




RE: Little explorations with the HP calculators
(03272017 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. Graph 3D  QPI  SolveSys 

03272017, 08:08 PM
Post: #45




RE: Little explorations with the HP calculators
(03272017 08:01 PM)Han Wrote:(03272017 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.... <0ɸ0> Joe 

03272017, 08:14 PM
(This post was last modified: 03272017 08:19 PM by pier4r.)
Post: #46




RE: Little explorations with the HP calculators
(03272017 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? Wikis are great, Contribute :) 

03272017, 08:36 PM
(This post was last modified: 03272017 09:00 PM by Han.)
Post: #47




RE: Little explorations with the HP calculators
(03272017 08:14 PM)pier4r Wrote:(03272017 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. Graph 3D  QPI  SolveSys 

03272017, 08:44 PM
(This post was last modified: 03272017 09:18 PM by pier4r.)
Post: #48




RE: Little explorations with the HP calculators
(03272017 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. Wikis are great, Contribute :) 

03272017, 08:55 PM
Post: #49




RE: Little explorations with the HP calculators  
03272017, 10:12 PM
Post: #50




RE: Little explorations with the HP calculators  
03272017, 10:35 PM
Post: #51




RE: Little explorations with the HP calculators
(03272017 08:55 PM)Dieter Wrote:(03272017 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. 

03282017, 10:44 AM
(This post was last modified: 03282017 10:47 AM by pier4r.)
Post: #52




RE: Little explorations with the HP calculators
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/cgisys/cgiwrap/...ead=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/...discussion (Simone knows a lot / has great searching skills) Wikis are great, Contribute :) 

03282017, 11:07 AM
(This post was last modified: 03282017 05:39 PM by pier4r.)
Post: #53




RE: Little explorations with the HP calculators
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:
Wikis are great, Contribute :) 

03282017, 05:33 PM
(This post was last modified: 03282017 05:35 PM by Dieter.)
Post: #54




RE: Little explorations with the HP calculators
(03282017 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 

03282017, 05:46 PM
(This post was last modified: 03282017 05:54 PM by Dieter.)
Post: #55




RE: Little explorations with the HP calculators
(03212017 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 log_{A}B = 2 and log_{√A}B = 2 · 2 = 4. No calculator required. Dieter 

03282017, 06:13 PM
Post: #56




RE: Little explorations with the HP calculators
(03282017 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) ? Wikis are great, Contribute :) 

03282017, 06:17 PM
(This post was last modified: 03282017 06:20 PM by pier4r.)
Post: #57




RE: Little explorations with the HP calculators
(03282017 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. Wikis are great, Contribute :) 

03282017, 07:32 PM
Post: #58




RE: Little explorations with the HP calculators
(03282017 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.) Graph 3D  QPI  SolveSys 

03282017, 07:36 PM
Post: #59




RE: Little explorations with the HP calculators
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.
Graph 3D  QPI  SolveSys 

03282017, 08:15 PM
(This post was last modified: 03292017 08:47 AM by pier4r.)
Post: #60




RE: Little explorations with the HP calculators
(03282017 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! Wikis are great, Contribute :) 

« Next Oldest  Next Newest »

User(s) browsing this thread: