
12

I entered a contribution for the PI quest.
http://rosettacode.org/wiki/PiBut 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/~alopezo/mathfaq/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, Email to: < [hidden email]>
Send administrative queries to < [hidden email]>


Interesting, I did the same here:
http://rosettacode.org/wiki/Real_constants_and_functions#LassoWill 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/~alopezo/mathfaq/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, Email 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, Email to: < [hidden email]>
Send administrative queries to < [hidden email]>


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 acostoPI 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/~alopezo/mathfaq/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, Email 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, Email 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/piwithgmp.htmlThis is opensource, 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) 5332027 [hidden email]<mailto: [hidden email]>
Save a tree! Don't print this email 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/PiBut 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 acostoPI 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/~alopezo/mathfaq/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, Email 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, Email 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, Email 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/piwithgmp.html>
> This is opensource, 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, Email 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 20131105, 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/piwithgmp.html>>
>> This is opensource, 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, Email 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, Email 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 57 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, Email to: < [hidden email]>
Send administrative queries to < [hidden email]>


On 20131105, 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, Email to: < [hidden email]>
Send administrative queries to < [hidden email]>


Mine's here: https://gist.github.com/bfad/7308315While 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 57 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, Email to: < [hidden email]>
Send administrative queries to < [hidden email]>


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, Email to: < [hidden email]>
Send administrative queries to < [hidden email]>


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 20131105, 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 57 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, Email 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, Email 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 20131105, 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 57 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, Email 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, Email 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, Email to: < [hidden email]>
Send administrative queries to < [hidden email]>


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_integerThis 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, Email to: < [hidden email]>
Send administrative queries to < [hidden email]>


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, Email to: < [hidden email]>
Send administrative queries to < [hidden email]>


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, Email to: < [hidden email]>
Send administrative queries to < [hidden email]>


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, Email 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, Email 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, Email 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, Email 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, Email to: < [hidden email]>
Send administrative queries to < [hidden email]>

12
