I entered a contribution for the PI quest.
http://rosettacode.org/wiki/Pi But it got challenged. Turns out that the formula I used to calculate PI goes astray after 17 decimals. Here's what I used: (-1.0) -> acos) It will produce 3.141592653589793115997963468544185161590576171875 But only 3.141592653589793 is correct. I have since looked at some resources on the net but have to admit it is beyond my skills to convert it to Lasso code. For example here: https://cs.uwaterloo.ca/~alopez-o/math-faq/mathtext/node12.html (thanks Brian for link) If someone can pick up the challenge and produce code to return a really long PI I would be very grateful. I would like to get the contribution in the Rosetta code right. Promise I will not count the points for it, if I can get help setting it straight. Tip: Chat in the Lasso room suggested that the approach has to be to calculate decimal by decimal and add that to a string, then return the string. HDB Jolle ############################################################# This message is sent to you because you are subscribed to the mailing list Lasso [hidden email] To unsubscribe, E-mail to: <[hidden email]> Send administrative queries to <[hidden email]> |
Interesting, I did the same here:
http://rosettacode.org/wiki/Real_constants_and_functions#Lasso Will correct it to a hard coded version for now. define pi => 3.141592653589793 Ke On 3 November 2013 16:23, jolle <[hidden email]> wrote: > I entered a contribution for the PI quest. > http://rosettacode.org/wiki/Pi > > But it got challenged. Turns out that the formula I used to calculate PI > goes astray after 17 decimals. > > Here's what I used: > > (-1.0) -> acos) > > It will produce > 3.141592653589793115997963468544185161590576171875 > But only > 3.141592653589793 > is correct. > > I have since looked at some resources on the net but have to admit it is > beyond my skills to convert it to Lasso code. > For example here: > https://cs.uwaterloo.ca/~alopez-o/math-faq/mathtext/node12.html (thanks > Brian for link) > > > If someone can pick up the challenge and produce code to return a really > long PI I would be very grateful. I would like to get the contribution in > the Rosetta code right. Promise I will not count the points for it, if I > can get help setting it straight. > > Tip: > Chat in the Lasso room suggested that the approach has to be to calculate > decimal by decimal and add that to a string, then return the string. > > HDB > Jolle > > ############################################################# > This message is sent to you because you are subscribed to > the mailing list Lasso > [hidden email] > To unsubscribe, E-mail to: <[hidden email]> > Send administrative queries to <[hidden email]> > ############################################################# This message is sent to you because you are subscribed to the mailing list Lasso [hidden email] To unsubscribe, E-mail to: <[hidden email]> Send administrative queries to <[hidden email]> |
In reply to this post by Jolle Carlestam-2
On Nov 3, 2013, at 11:23 AM, jolle <[hidden email]> wrote: > I entered a contribution for the PI quest. > http://rosettacode.org/wiki/Pi > > But it got challenged. Turns out that the formula I used to calculate PI goes astray after 17 decimals. > > Here's what I used: > > (-1.0) -> acos) While looking at this earlier today I wrote a quick test C program using the same acos-to-PI technique and it had the same results. The precision you see seems to be a limitation of the trig calculations at the OS level (in the C library). This was on OS X. -Kyle > It will produce > 3.141592653589793115997963468544185161590576171875 > But only > 3.141592653589793 > is correct. > > I have since looked at some resources on the net but have to admit it is beyond my skills to convert it to Lasso code. > For example here: > https://cs.uwaterloo.ca/~alopez-o/math-faq/mathtext/node12.html (thanks Brian for link) > > > If someone can pick up the challenge and produce code to return a really long PI I would be very grateful. I would like to get the contribution in the Rosetta code right. Promise I will not count the points for it, if I can get help setting it straight. > > Tip: > Chat in the Lasso room suggested that the approach has to be to calculate decimal by decimal and add that to a string, then return the string. > > HDB > Jolle > > ############################################################# > This message is sent to you because you are subscribed to > the mailing list Lasso > [hidden email] > To unsubscribe, E-mail to: <[hidden email]> > Send administrative queries to <[hidden email]> ############################################################# This message is sent to you because you are subscribed to the mailing list Lasso [hidden email] To unsubscribe, E-mail to: <[hidden email]> Send administrative queries to <[hidden email]> |
If I remember correctly — and just doing some cursory searches — there is a method of solving a mathematical equation with 100s of digits of precision, overcoming a OS or hardware restrictions. I am still poking around - but just wanted to get that out there in case someone has a lightbulb appear over their head! :)
This program is big, so maybe I am thinking about a different problem I solved back in college (I know it wasn’t PI), but it was another equation. http://gmplib.org/pi-with-gmp.html This is open-source, and the code is big, but it is one of the methods I am think of... ________________________________ Greg Jewett Senior Network and Domain Administrator Signature Science, LLC (512) 533-2027 [hidden email]<mailto:[hidden email]> Save a tree! Don't print this e-mail unless it's necessary. Be the Solution! On Nov 4, 2013, at 11:07 pm, Kyle Jessup <[hidden email]<mailto:[hidden email]>> wrote: On Nov 3, 2013, at 11:23 AM, jolle <[hidden email]<mailto:[hidden email]>> wrote: I entered a contribution for the PI quest. http://rosettacode.org/wiki/Pi But it got challenged. Turns out that the formula I used to calculate PI goes astray after 17 decimals. Here's what I used: (-1.0) -> acos) While looking at this earlier today I wrote a quick test C program using the same acos-to-PI technique and it had the same results. The precision you see seems to be a limitation of the trig calculations at the OS level (in the C library). This was on OS X. -Kyle It will produce 3.141592653589793115997963468544185161590576171875 But only 3.141592653589793 is correct. I have since looked at some resources on the net but have to admit it is beyond my skills to convert it to Lasso code. For example here: https://cs.uwaterloo.ca/~alopez-o/math-faq/mathtext/node12.html (thanks Brian for link) If someone can pick up the challenge and produce code to return a really long PI I would be very grateful. I would like to get the contribution in the Rosetta code right. Promise I will not count the points for it, if I can get help setting it straight. Tip: Chat in the Lasso room suggested that the approach has to be to calculate decimal by decimal and add that to a string, then return the string. HDB Jolle ############################################################# This message is sent to you because you are subscribed to the mailing list Lasso [hidden email]<mailto:[hidden email]> To unsubscribe, E-mail to: <[hidden email]> Send administrative queries to <[hidden email]> ############################################################# This message is sent to you because you are subscribed to the mailing list Lasso [hidden email]<mailto:[hidden email]> To unsubscribe, E-mail to: <[hidden email]> Send administrative queries to <[hidden email]> ############################################################# This message is sent to you because you are subscribed to the mailing list Lasso [hidden email] To unsubscribe, E-mail to: <[hidden email]> Send administrative queries to <[hidden email]> |
Kyle and Brad both took it upon them to find a better (correct) approach to the challenge. Interestingly they both came up with a solution that turned out to have the same flaw. Out of a PI calculation with a thousand decimals they had three that was wrong. Same three in both code solutions.
We (who are not Kyle) of course claimed that it has to be something wrong with Lasso. He (who is Kyle) did not come to the same conclusion. And that is where it is left for the moment. I think Kyle is doing things but he is probably reluctant to communicate it until he has a solution. I for one think that someone skilled at math should chime in. That person is not me. Brad also admitted that he did not understand the equation he implemented in his solution. He rewrote code written for another language using the same algebra. Is there anyone out there that can do math, please speak up. HDB Jolle 5 nov 2013 kl. 16:28 skrev Jewett, Greg <[hidden email]>: > If I remember correctly — and just doing some cursory searches — there is a method of solving a mathematical equation with 100s of digits of precision, overcoming a OS or hardware restrictions. I am still poking around - but just wanted to get that out there in case someone has a lightbulb appear over their head! :) > > This program is big, so maybe I am thinking about a different problem I solved back in college (I know it wasn’t PI), but it was another equation. > > http://gmplib.org/pi-with-gmp.html > > This is open-source, and the code is big, but it is one of the methods I am think of... > > > ________________________________ > Greg Jewett ############################################################# This message is sent to you because you are subscribed to the mailing list Lasso [hidden email] To unsubscribe, E-mail to: <[hidden email]> Send administrative queries to <[hidden email]> |
I implemented the Bailey–Borwein–Plouffe formula <https://en.wikipedia.org/wiki/Bailey%E2%80%93Borwein%E2%80%93Plouffe_formula> below:
local(n, sum = 0.0, i = 15) loop(-from = 0, -to = #i) #n = loop_count #sum += ( 1.0 / math_pow(16, #n)) * ( (4.0 / (8 * #n + 1)) - (2.0 / (8 * #n + 4)) - (1.0 / (8 * #n + 5)) - (1.0 / (8 * #n + 6)) ) '<br>' + #sum->asstring(-precision = 50) /loop ... 3.14159265358979311599796346854418516159057617187500 It works, but the values start mirroring each other after the 10th iteration, and any values greater than 16 for #i fail with a "divide by zero" error. This is because of a limitation with the decimal type, e.g. [(1.0/math_pow(16, 15))->asstring(-precision = 50)] returns a value, but [(1.0/math_pow(16, 16))->asstring(-precision = 50)] fails. You'll note that the produced value loses accuracy after 3.141592653589793, at the same spot as [((-1.0) -> acos)->asstring(-precision = 50)]. ‐‐‐‐‐‐‐‐‐‐✂‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ Eric3 On 2013-11-05, at 11:10 AM, jolle wrote: > Kyle and Brad both took it upon them to find a better (correct) approach to the challenge. Interestingly they both came up with a solution that turned out to have the same flaw. Out of a PI calculation with a thousand decimals they had three that was wrong. Same three in both code solutions. > > We (who are not Kyle) of course claimed that it has to be something wrong with Lasso. He (who is Kyle) did not come to the same conclusion. > > And that is where it is left for the moment. I think Kyle is doing things but he is probably reluctant to communicate it until he has a solution. > > I for one think that someone skilled at math should chime in. That person is not me. Brad also admitted that he did not understand the equation he implemented in his solution. He rewrote code written for another language using the same algebra. > Is there anyone out there that can do math, please speak up. > > HDB > Jolle > > 5 nov 2013 kl. 16:28 skrev Jewett, Greg <[hidden email]>: > >> If I remember correctly — and just doing some cursory searches — there is a method of solving a mathematical equation with 100s of digits of precision, overcoming a OS or hardware restrictions. I am still poking around - but just wanted to get that out there in case someone has a lightbulb appear over their head! :) >> >> This program is big, so maybe I am thinking about a different problem I solved back in college (I know it wasn’t PI), but it was another equation. >> >> http://gmplib.org/pi-with-gmp.html >> >> This is open-source, and the code is big, but it is one of the methods I am think of... >> >> >> ________________________________ >> Greg Jewett > > > ############################################################# > This message is sent to you because you are subscribed to > the mailing list Lasso > [hidden email] > To unsubscribe, E-mail to: <[hidden email]> > Send administrative queries to <[hidden email]> ############################################################# This message is sent to you because you are subscribed to the mailing list Lasso [hidden email] To unsubscribe, E-mail to: <[hidden email]> Send administrative queries to <[hidden email]> |
5 nov 2013 kl. 23:59 skrev Eric Knibbe <[hidden email]>:
> I implemented the Bailey–Borwein–Plouffe formula <https://en.wikipedia.org/wiki/Bailey%E2%80%93Borwein%E2%80%93Plouffe_formula> below: > > local(n, sum = 0.0, i = 15) > loop(-from = 0, -to = #i) > #n = loop_count > #sum += ( 1.0 / math_pow(16, #n)) * ( (4.0 / (8 * #n + 1)) - (2.0 / (8 * #n + 4)) - (1.0 / (8 * #n + 5)) - (1.0 / (8 * #n + 6)) ) > '<br>' + #sum->asstring(-precision = 50) > /loop > > ... > 3.14159265358979311599796346854418516159057617187500 > > It works, but the values start mirroring each other after the 10th iteration, and any values greater than 16 for #i fail with a "divide by zero" error. This is because of a limitation with the decimal type, e.g. [(1.0/math_pow(16, 15))->asstring(-precision = 50)] returns a value, but [(1.0/math_pow(16, 16))->asstring(-precision = 50)] fails. You'll note that the produced value loses accuracy after 3.141592653589793, at the same spot as [((-1.0) -> acos)->asstring(-precision = 50)]. > ‐‐‐‐‐‐‐‐‐‐✂‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ > Eric3 The only way to do it, also the way other program languages has dealt with it is to not aim at producing a decimal type result. Instead have some kind of iteration that calculates each decimal value and add it to a string variable. The other languages has been able to produce very long, and correct, PI results using this approach. Brads and Kyles worked along the same path, just have those three digits that goes way astray. Still really strange. As you can see here, position 5-7 are whacked, the rest is correct. I have compared it to other solutions and verified it. 3, 1, 4, 1, 490735, 2, -49072928, 6, 5, 3, 5, 8, 9, 7, 9, 3, 2, 3, 8, 4, 6, 2, 6, 4, 3, 3, 8, 3, 2, 7, 9, 5, 0, 2, 8, 8, 4, 1, 9, 7, 1, 6, 9, 3, 9, 9, 3, 7, 5, 1, 0, 5, 8, 2, 0, 9, 7, 4, 9, 4, 4, 5, 9, 2, 3, 0, 7, 8, 1, 6, 4, 0, 6, 2, 8, 6, 2, 0, 8, 9, 9, 8, 6, 2, 8, 0, 3, 4, 8, 2, 5, 3, 4, 2, 1, 1, 7, 0, 6, 7, 9, 8, 2, 1, 4, 8, 0, 8, 6, 5, 1, 3, 2, 8, 2, 3, 0, 6, 6, 4, 7, 0, 9, 3, 8, 4, 4, 6, 0, 9, 5, 5, 0, 5, 8, 2, 2, 3, 1, 7, 2, 5, 3, 5, 9, 4, 0, 8, 1, 2, 8, 4, 8, 1, 1, 1, 7, 4, 5, 0, 2, 8, 4, 1, 0, 2, 7, 0, 1, 9, 3, 8, 5, 2, 1, 1, 0, 5, 5, 5, 9, 6, 4, 4, 6, 2, 2, 9, 4, 8, 9, 5, 4, 9, 3, 0, 3, 8, 1, 9, 6, 4, 4, 2, 8, 8, 1, 0, 9, 7, 5, 6, 6, 5, 9, 3, 3, 4, 4, 6, 1, 2, 8, 4, 7, 5, 6, 4, 8, 2, 3, 3, 7, 8, 6, 7, 8, 3, 1, 6, 5, 2, 7, 1, 2, 0, 1, 9, 0, 9, 1, 4, 5, 6, 4, 8, 5, 6, 6, 9, 2, 3, 4, 6, 0, 3, 4, 8, 6, 1, 0, 4, 5, 4, 3, 2, 6, 6, 4, 8, 2, 1, 3, 3, 9, 3, 6, 0, 7, 2, 6, 0, 2, 4, 9, 1, 4, 1, 2, 7, 3, 7, 2, 4, 5, 8, 7, 0, 0, 6, 6, 0, 6, 3, 1, 5, 5, 8, 8, 1, 7, 4, 8, 8, 1, 5, 2, 0, 9, 2, 0, 9, 6, 2, 8, 2, 9, 2, 5, 4, 0, 9, 1, 7, 1, 5, 3, 6, 4, 3, 6, 7, 8, 9, 2, 5, 9, 0, 3, 6, 0, 0, 1, 1, 3, 3, 0, 5, 3, 0, 5, 4, 8, 8, 2, 0, 4, 6, 6, 5, 2, 1, 3, 8, 4, 1, 4, 6, 9, 5, 1, 9, 4, 1, 5, 1, 1, 6, 0, 9, 4, 3, 3, 0, 5, 7, 2, 7, 0, 3, 6, 5, 7, 5, 9, 5, 9, 1, 9, 5, 3, 0, 9, 2, 1, 8, 6, 1, 1, 7, 3, 8, 1, 9, 3, 2, 6, 1, 1, 7, 9, 3, 1, 0, 5, 1, 1, 8, 5, 4, 8, 0, 7, 4, 4, 6, 2, 3, 7, 9, 9, 6, 2, 7, 4, 9, 5, 6, 7, 3, 5, 1, 8, 8, 5, 7, 5, 2, 7, 2, 4, 8, 9, 1, 2, 2, 7, 9, 3, 8, 1, 8, 3, 0, 1, 1, 9, 4, 9, 1, 2, 9, 8, 3, 3, 6, 7, 3, 3, 6, 2, 4, 4, 0, 6, 5, 6, 6, 4, 3, 0, 8, 6, 0, 2, 1, 3, 9, 4, 9, 4, 6, 3, 9, 5, 2, 2, 4, 7, 3, 7, 1, 9, 0, 7, 0, 2, 1, 7, 9, 8, 6, 0, 9, 4, 3, 7, 0, 2, 7, 7, 0, 5, 3, 9, 2, 1, 7, 1, 7, 6, 2, 9, 3, 1, 7, 6, 7, 5, 2, 3, 8, 4, 6, 7, 4, 8, 1, 8, 4, 6, 7, 6, 6, 9, 4, 0, 5, 1, 3, 2, 0, 0, 0, 5, 6, 8, 1, 2, 7, 1, 4, 5, 2, 6, 3, 5, 6, 0, 8, 2, 7, 7, 8, 5, 7, 7, 1, 3, 4, 2, 7, 5, 7, 7, 8, 9, 6, 0, 9, 1, 7, 3, 6, 3, 7, 1, 7, 8, 7, 2, 1, 4, 6, 8, 4, 4, 0, 9, 0, 1, 2, 2, 4, 9, 5, 3, 4, 3, 0, 1, 4, 6, 5, 4, 9, 5, 8, 5, 3, 7, 1, 0, 5, 0, 7, 9, 2, 2, 7, 9, 6, 8, 9, 2, 5, 8, 9, 2, 3, 5, 4, 2, 0, 1, 9, 9, 5, 6, 1, 1, 2, 1, 2, 9, 0, 2, 1, 9, 6, 0, 8, 6, 4, 0, 3, 4, 4, 1, 8, 1, 5, 9, 8, 1, 3, 6, 2, 9, 7, 7, 4, 7, 7, 1, 3, 0, 9, 9, 6, 0, 5, 1, 8, 7, 0, 7, 2, 1, 1, 3, 4, 9, 9, 9, 9, 9, 9, 8, 3, 7, 2, 9, 7, 8, 0, 4, 9, 9, 5, 1, 0, 5, 9, 7, 3, 1, 7, 3, 2, 8, 1, 6, 0, 9, 6, 3, 1, 8, 5, 9, 5, 0, 2, 4, 4, 5, 9, 4, 5, 5, 3, 4, 6, 9, 0, 8, 3, 0, 2, 6, 4, 2, 5, 2, 2, 3, 0, 8, 2, 5, 3, 3, 4, 4, 6, 8, 5, 0, 3, 5, 2, 6, 1, 9, 3, 1, 1, 8, 8, 1, 7, 1, 0, 1, 0, 0, 0, 3, 1, 3, 7, 8, 3, 8, 7, 5, 2, 8, 8, 6, 5, 8, 7, 5, 3, 3, 2, 0, 8, 3, 8, 1, 4, 2, 0, 6, 1, 7, 1, 7, 7, 6, 6, 9, 1, 4, 7, 3, 0, 3, 5, 9, 8, 2, 5, 3, 4, 9, 0, 4, 2, 8, 7, 5, 5, 4, 6, 8, 7, 3, 1, 1, 5, 9, 5, 6, 2, 8, 6, 3, 8, 8, 2, 3, 5, 3, 7, 8, 7, 5, 9, 3, 7, 5, 1, 9, 5, 7, 7, 8, 1, 8, 5, 7, 7, 8, 0, 5, 3, 2, 1, 7, 1, 2, 2, 6, 8, 0, 6, 6, 1, 3, 0, 0, 1, 9, 2, 7, 8, 7, 6, 6, 1, 1, 1, 9, 5, 9, 0, 9, 2, 1, 6, 4, 2, 0, 1, 9, 8 I'm not sure I can post the code used to produce this since I didn't write it. Kyle or Brad has to chime in, or do it. HDB Jolle ############################################################# This message is sent to you because you are subscribed to the mailing list Lasso [hidden email] To unsubscribe, E-mail to: <[hidden email]> Send administrative queries to <[hidden email]> |
On 2013-11-05, at 6:18 PM, jolle wrote:
> The only way to do it, also the way other program languages has dealt with it is to not aim at producing a decimal type result. Instead have some kind of iteration that calculates each decimal value and add it to a string variable. The other languages has been able to produce very long, and correct, PI results using this approach. Brads and Kyles worked along the same path, just have those three digits that goes way astray. Good point. Instead I've implemented the algorithm from <http://crypto.stanford.edu/pbc/notes/pi/code.html>, viewable here <https://gist.github.com/EricFromCanada/7329267>, which appears not to have any of the above issues. ‐‐‐‐‐‐‐‐‐‐✂‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ Eric3 ############################################################# This message is sent to you because you are subscribed to the mailing list Lasso [hidden email] To unsubscribe, E-mail to: <[hidden email]> Send administrative queries to <[hidden email]> |
In reply to this post by Jolle Carlestam-2
Mine's here: https://gist.github.com/bfad/7308315
While I'm glad Eric got another algorithm to work, what concerns me is that this exact same algorithm written in different languages doesn't have problems with the 5-7 digits as noted by Jolle. What's up with Lasso's integer calculations that would cause this? Brad ############################################################# This message is sent to you because you are subscribed to the mailing list Lasso [hidden email] To unsubscribe, E-mail to: <[hidden email]> Send administrative queries to <[hidden email]> |
In reply to this post by Eric Knibbe-2
Great work, Eric!
I also saw you've updated the pi example in the Rosetta code. Please officially note that I no longer claim points for my failing pi contribution. They are instead all yours, Eric. You are now 5 points closer to winning. Congratulations! Also, big thanks to Brad and Kyle for their excellent work on the matter! HDB Jolle Sent from a thin, flat, touchy device from an undetermined place in space. 6 nov 2013 kl. 02:18 skrev Eric Knibbe <[hidden email]>: > Good point. Instead I've implemented the algorithm from <http://crypto.stanford.edu/pbc/notes/pi/code.html>, viewable here <https://gist.github.com/EricFromCanada/7329267>, which appears not to have any of the above issues. > > ‐‐‐‐‐‐‐‐‐‐✂‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ > Eric3 ############################################################# This message is sent to you because you are subscribed to the mailing list Lasso [hidden email] To unsubscribe, E-mail to: <[hidden email]> Send administrative queries to <[hidden email]> |
In reply to this post by Brad Lindsay
It seems something's awry with some of Lasso's calculations (filed as #7646). In digging into Brad's implementation of the spigot algorithm, which mirrors others given on the Rosetta page, I found these examples:
Lasso: >: -8/15 0 <--- rounds down >: -8/15.0 -0.533333 >: -8.0/15 -0.533333 >: 1201079895356252 / 213458046676875 486851 <--- ?? >: 1201079895356252 / 213458046676875.0 5.626773 >: 1201079895356252.0 / 213458046676875 5.626773 >: 56542415804396156252 / 6332659870762850625 8 >: 56542415804396156252 / 6332659870762850625.0 0.189839 <--- ?? >: 56542415804396156252.0 / 6332659870762850625 8.928699 >: 56542415804396156252->asDecimal 1202183583267501312.000000 <--- ?? >: 6332659870762850625->asDecimal 6332659870762850304.000000 <--- ?? Python, for comparison: >>> -8/15 -1 <--- rounds to nearest integer >>> -8/15.0 -0.5333333333333333 >>> -8.0/15 -0.5333333333333333 >>> 1201079895356252 / 213458046676875 5 >>> 1201079895356252 / 213458046676875.0 5.6267726330992005 >>> 1201079895356252.0 / 213458046676875 5.6267726330992005 >>> 56542415804396156252 / 6332659870762850625 8L >>> 56542415804396156252 / 6332659870762850625.0 8.928699307765743 >>> 56542415804396156252.0 / 6332659870762850625 8.928699307765743 >>> float(56542415804396156252) 5.654241580439616e+19 >>> float(6332659870762850625) 6.33265987076285e+18 I was hoping to change Lasso's rounding behaviour by adding ->asDecimal to any divisors and applying math_floor() to the result, but the last pair of examples show why that won't work (unless decimal conversion is only applied to divisors below an unknown upper bound; somewhere around 1000000000000000). While doing so allows the spigot algorithm to generate the 5th digit correctly ("5"), the problems with decimal conversion kick in soon after. ‐‐‐‐‐‐‐‐‐‐✂‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ Eric3 On 2013-11-05, at 8:36 PM, Brad Lindsay wrote: > Mine's here: https://gist.github.com/bfad/7308315 > > While I'm glad Eric got another algorithm to work, what concerns me is that this exact same algorithm written in different languages doesn't have problems with the 5-7 digits as noted by Jolle. What's up with Lasso's integer calculations that would cause this? > > Brad > > ############################################################# > This message is sent to you because you are subscribed to > the mailing list Lasso > [hidden email] > To unsubscribe, E-mail to: <[hidden email]> > Send administrative queries to <[hidden email]> ############################################################# This message is sent to you because you are subscribed to the mailing list Lasso [hidden email] To unsubscribe, E-mail to: <[hidden email]> Send administrative queries to <[hidden email]> |
I’m so glad that NONE of my projects rely on anything past 3.14.
:P Thanks Steffan --------------------------------------------------------------- T E L 6 0 2 . 7 9 3 . 0 0 1 4 | F A X 6 0 2 . 9 7 1 . 1 6 9 4 Steffan A. Cline [hidden email] http://www.ExecuChoice.net Phoenix, Arizona USA --------------------------------------------------------------- On 11/6/13, 12:15 PM, "Eric Knibbe" <[hidden email]> wrote: >It seems something's awry with some of Lasso's calculations (filed as >#7646). In digging into Brad's implementation of the spigot algorithm, >which mirrors others given on the Rosetta page, I found these examples: > >Lasso: >>: -8/15 >0 <--- rounds down >>: -8/15.0 >-0.533333 >>: -8.0/15 >-0.533333 > >>: 1201079895356252 / 213458046676875 >486851 <--- ?? >>: 1201079895356252 / 213458046676875.0 >5.626773 >>: 1201079895356252.0 / 213458046676875 >5.626773 > >>: 56542415804396156252 / 6332659870762850625 >8 >>: 56542415804396156252 / 6332659870762850625.0 >0.189839 <--- ?? >>: 56542415804396156252.0 / 6332659870762850625 >8.928699 > >>: 56542415804396156252->asDecimal >1202183583267501312.000000 <--- ?? >>: 6332659870762850625->asDecimal >6332659870762850304.000000 <--- ?? > >Python, for comparison: >>>> -8/15 >-1 <--- rounds to nearest integer >>>> -8/15.0 >-0.5333333333333333 >>>> -8.0/15 >-0.5333333333333333 > >>>> 1201079895356252 / 213458046676875 >5 >>>> 1201079895356252 / 213458046676875.0 >5.6267726330992005 >>>> 1201079895356252.0 / 213458046676875 >5.6267726330992005 > >>>> 56542415804396156252 / 6332659870762850625 >8L >>>> 56542415804396156252 / 6332659870762850625.0 >8.928699307765743 >>>> 56542415804396156252.0 / 6332659870762850625 >8.928699307765743 > >>>> float(56542415804396156252) >5.654241580439616e+19 >>>> float(6332659870762850625) >6.33265987076285e+18 > >I was hoping to change Lasso's rounding behaviour by adding ->asDecimal >to any divisors and applying math_floor() to the result, but the last >pair of examples show why that won't work (unless decimal conversion is >only applied to divisors below an unknown upper bound; somewhere around >1000000000000000). While doing so allows the spigot algorithm to generate >the 5th digit correctly ("5"), the problems with decimal conversion kick >in soon after. >‐‐‐‐‐‐‐‐‐‐✂‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ >Eric3 > > >On 2013-11-05, at 8:36 PM, Brad Lindsay wrote: > >> Mine's here: https://gist.github.com/bfad/7308315 >> >> While I'm glad Eric got another algorithm to work, what concerns me is >>that this exact same algorithm written in different languages doesn't >>have problems with the 5-7 digits as noted by Jolle. What's up with >>Lasso's integer calculations that would cause this? >> >> Brad >> >> ############################################################# >> This message is sent to you because you are subscribed to >> the mailing list Lasso >> [hidden email] >> To unsubscribe, E-mail to: <[hidden email]> >> Send administrative queries to <[hidden email]> > > >############################################################# >This message is sent to you because you are subscribed to > the mailing list Lasso >[hidden email] >To unsubscribe, E-mail to: <[hidden email]> >Send administrative queries to <[hidden email]> ############################################################# This message is sent to you because you are subscribed to the mailing list Lasso [hidden email] To unsubscribe, E-mail to: <[hidden email]> Send administrative queries to <[hidden email]> |
In reply to this post by Eric Knibbe-2
On 11/6/13, 2:15 PM, Eric Knibbe wrote:
> Lasso: >> : -8/15 > 0<--- rounds down >> : -8/15.0 > -0.533333 >> : -8.0/15 > -0.533333 > Python, for comparison: >>>> -8/15 > -1<--- rounds to nearest integer >>>> -8/15.0 > -0.5333333333333333 >>>> -8.0/15 > -0.5333333333333333 Interesting. I thought both Python and Lasso did floor division of integers. It looks like what really happens is that Lasso truncates the division and Python does the floor division. Another way to put it is that Lasso integer division rounds towards 0 http://en.wikipedia.org/wiki/Rounding#Rounding_to_integer This is especially interesting since that's not the behavior of the math_floor method (Ex. Calling [math_floor(-0.5333)] in Lasso results in -1, not 0.) Brad ############################################################# This message is sent to you because you are subscribed to the mailing list Lasso [hidden email] To unsubscribe, E-mail to: <[hidden email]> Send administrative queries to <[hidden email]> |
In reply to this post by Steffan A. Cline
In regards to real usage of PI in Lasso solutions this is mostly an academic discussion. If you call pi in Lasso 9 you will get back a value that is hardcoded:
define pi() => 3.14159265 IF you on rare occasions should need higher precision than that, use the same approach, hard code it to whatever precision you require. After all, PI doesn't change so why have a complicated algorithm to provide it each time you use it. The primary task here was to fulfill the requirements of the specific Rosetta task. That has been done, thanks to Eric. And the good that came out of the exercise was that it highlighted an area where Lassos math handling differs from other languages. Something that is probably worth looking into but is in no way critical for the wast majority of lasso users or solutions. Still good to have the flaw looked into and solved. After all we want true math geeks to love Lasso too. HDB Jolle 6 nov 2013 kl. 20:17 skrev Steffan A. Cline <[hidden email]>: > I’m so glad that NONE of my projects rely on anything past 3.14. > > :P > > > Thanks > > Steffan ############################################################# This message is sent to you because you are subscribed to the mailing list Lasso [hidden email] To unsubscribe, E-mail to: <[hidden email]> Send administrative queries to <[hidden email]> |
In reply to this post by Eric Knibbe-2
On 11/6/13 at 2:15 PM, [hidden email] (Eric Knibbe) pronounced:
>It seems something's awry with some of Lasso's calculations >(filed as #7646). In digging into Brad's implementation of the >spigot algorithm, which mirrors others given on the Rosetta >page, I found these examples: >Lasso: >>: -8/15 >0 <--- rounds down Nope, it rounds up. Rounding down would be to -1. >Python, for comparison: >>>> -8/15 >-1 <--- rounds to nearest integer It depends on the version of Python. It either floors (not rounds) or uses decimal. Python is going through its own growing pains, just like Lasso. Python 2.7.1: >>> -8/15 -1 # floors >>> -7/15 -1 # floors >>> 1201079895356252 / 213458046676875 5L Python 3.3.2: >>> 1201079895356252 / 213458046676875 5.6267726330992005 >>> -8/15 -0.5333333333333333 >>> -7/15 -0.4666666666666667 >>> --steve -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Steve Piercy Web Site Builder Soquel, CA <[hidden email]> <http://www.StevePiercy.com/> ############################################################# This message is sent to you because you are subscribed to the mailing list Lasso [hidden email] To unsubscribe, E-mail to: <[hidden email]> Send administrative queries to <[hidden email]> |
In reply to this post by Eric Knibbe-2
On Nov 6, 2013, at 11:15 AM, Eric Knibbe <[hidden email]> wrote: > It seems something's awry with some of Lasso's calculations (filed as #7646). In digging into Brad's implementation of the spigot algorithm, which mirrors others given on the Rosetta page, I found these examples: > > Lasso: >> : -8/15 > 0 <--- rounds down >> : -8/15.0 > -0.533333 >> : -8.0/15 > -0.533333 > This isn't that surprising, at least to me. I do a lot of programming in RealBasic (now called Xojo) and to ensure a calculation takes place in "decimal space" one should start the list of numbers with a decimal value (1.0 rather than 1) it seems Lasso works in a similar manner although it doesn't only take it's cue from the first value it sees. If it see's a decimal value, then it does it's calculation using decimals for all values. I bet if you put "1.0 *" in front of all your tests you will get the same value for all. >> : 1201079895356252 / 213458046676875 > 486851 <--- ?? >> : 1201079895356252 / 213458046676875.0 > 5.626773 >> : 1201079895356252.0 / 213458046676875 > 5.626773 > The first one probably overloads the integer value whereas decimals hold larger numbers (I'm assuming, I don't know the details of Lasso's numerology) >> : 56542415804396156252 / 6332659870762850625 > 8 >> : 56542415804396156252 / 6332659870762850625.0 > 0.189839 <--- ?? >> : 56542415804396156252.0 / 6332659870762850625 > 8.928699 > This one is interesting. Overall I'd start all calculations with a decimal value and write all numbers as decimal values for safety. regards, Steve ############################################################# This message is sent to you because you are subscribed to the mailing list Lasso [hidden email] To unsubscribe, E-mail to: <[hidden email]> Send administrative queries to <[hidden email]> |
On 11/6/13, 3:50 PM, Steve Upton wrote:
> The first one probably overloads the integer value whereas decimals hold larger numbers (I'm assuming, I don't know the details of Lasso's numerology) > Not the case. Try this in L9: Decimal ---------- 10000000000000000000000000000.0 + 1.0 // => 9999999999999999583119736832.000000 vs Integer ---------- 10000000000000000000000000001 Brad ############################################################# This message is sent to you because you are subscribed to the mailing list Lasso [hidden email] To unsubscribe, E-mail to: <[hidden email]> Send administrative queries to <[hidden email]> |
On Nov 6, 2013, at 12:55 PM, Brad Lindsay <[hidden email]> wrote: > On 11/6/13, 3:50 PM, Steve Upton wrote: >> The first one probably overloads the integer value whereas decimals hold larger numbers (I'm assuming, I don't know the details of Lasso's numerology) >> > > Not the case. Try this in L9: > > Decimal > ---------- > 10000000000000000000000000000.0 + 1.0 > // => 9999999999999999583119736832.000000 > > vs > > Integer > ---------- > 10000000000000000000000000001 Interesting. That certainly smells funny. What happens if you store your 10000000000000000000000000000.0 in a decimal var? What do you get back? Steve ############################################################# This message is sent to you because you are subscribed to the mailing list Lasso [hidden email] To unsubscribe, E-mail to: <[hidden email]> Send administrative queries to <[hidden email]> |
On 11/6/13, 4:06 PM, Steve Upton wrote:
> > Interesting. That certainly smells funny. > > What happens if you store your 10000000000000000000000000000.0 in a decimal var? What do you get back? 9999999999999999583119736832.000000 It doesn't smell funny. One of the new features of Lasso 9 is arbitrarily big integers without the need of a separate BigInt type being exposed. Brad ############################################################# This message is sent to you because you are subscribed to the mailing list Lasso [hidden email] To unsubscribe, E-mail to: <[hidden email]> Send administrative queries to <[hidden email]> |
> On 6. nov. 2013, at 22:08, Brad Lindsay <[hidden email]> wrote:
> >> On 11/6/13, 4:06 PM, Steve Upton wrote: >> >> Interesting. That certainly smells funny. >> >> What happens if you store your 10000000000000000000000000000.0 in a decimal var? What do you get back? > > 9999999999999999583119736832.000000 > > It doesn't smell funny. One of the new features of Lasso 9 is arbitrarily big integers without the need of a separate BigInt type being exposed. I am not sure I understand; how do these big integers relate to decimal numbers in Lasso 9? Thx! Richard Taubo ############################################################# This message is sent to you because you are subscribed to the mailing list Lasso [hidden email] To unsubscribe, E-mail to: <[hidden email]> Send administrative queries to <[hidden email]> |
Free forum by Nabble | Edit this page |