Re: Contesting for Idiot du Jour

[Roger Guay via use-livecode]

That’s why I said most!

> On Sep 7, 2020, at 12:05 PM, Pi Digital via use-livecode 
>  wrote:
> 
> Except Black
> 
> ... and white. 
> 
> 
>> On 7 Sep 2020, at 18:16, Roger Guay via use-livecode 
>>  wrote:
>> 
>> … and reminding me yet again that most things are never black or white!
> 
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Contesting for Idiot du Jour

[Pi Digital via use-livecode]

Except Black

... and white. 


> On 7 Sep 2020, at 18:16, Roger Guay via use-livecode 
>  wrote:
> 
> … and reminding me yet again that most things are never black or white!


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Contesting for Idiot du Jour

[Roger Guay via use-livecode]

… and reminding me yet again that most things are never black or white!

> On Sep 7, 2020, at 2:04 AM, Pi Digital via use-livecode 
>  wrote:
> 
> Sure. Draw a circle on a 10x10, 20x20, 100x100, etc grid. Only Whole pixels 
> get counted (Pass or 1 in digital binary). Depending on the methodology, 
> either 1) only those within the circle line (complete) or 2) those on the 
> line itself  and within it (incomplete). 
> 
> In your example, a 200x200 circle has a resolution where it’s practically 
> negligible from regular mathematics. However, the resolution at 100x100 and 
> lower starts to flat wildly away from it. If you are measuring using 
> collision and it’s accounting for antialiased pixels it can become even more 
> diverse from standard math as it does not ‘see’ it in percentages of visible, 
> only on or off. 
> 
> So, the difference between measuring only inside of a 200x200 and outside of 
> the 100x100 will throw off considerably any ordinary calculations you might 
> expect. Even a 400x400 PixelWise ‘circle’. 
> 
> Look up Gauss’ Circle Problem. The same chap we get the name for Gaussian 
> blur from. 
> 
>> On 7 Sep 2020, at 05:26, Roger Guay via use-livecode 
>>  wrote:
>> 
>> I’m sorry, I don’t understand your terminology. Could you please elaborate? 
>> 
>> Thanks,
>> Roger
>> 
>>> On Sep 6, 2020, at 10:54 AM, Pi Digital via use-livecode 
>>>  wrote:
>>> 
>>> Pixel math:
>>> 
>>> Counting incomplete pixels within a circle outline (%Pass)(%Fail):
>>> 10x10 = 88 (88%)(12%)
>>> 20x20 = 344 (86%)(14%)
>>> 100x100 = 8012 (80%)(20%)
>>> 
>>> Counting complete pixels:
>>> 10x10 = 48 (48%)(52%)
>>> 20x20 = 276 (69%)(31%)
>>> 100x100 = 7444 (74.4%)(26%)
>>> 
>>> Your conclusion here: _
>>> 
>>> ___
>>> use-livecode mailing list
>>> use-livecode@lists.runrev.com
>>> Please visit this url to subscribe, unsubscribe and manage your 
>>> subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>> 
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription 
>> preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
> 
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Contesting for Idiot du Jour

[Roger Guay via use-livecode]

Thank you! This is excellent information for me to keep in mind. And a special 
thanks for pointing me to the Gauss Circle Problem.

Roger



> On Sep 7, 2020, at 2:04 AM, Pi Digital via use-livecode 
>  wrote:
> 
> Sure. Draw a circle on a 10x10, 20x20, 100x100, etc grid. Only Whole pixels 
> get counted (Pass or 1 in digital binary). Depending on the methodology, 
> either 1) only those within the circle line (complete) or 2) those on the 
> line itself  and within it (incomplete). 
> 
> In your example, a 200x200 circle has a resolution where it’s practically 
> negligible from regular mathematics. However, the resolution at 100x100 and 
> lower starts to flat wildly away from it. If you are measuring using 
> collision and it’s accounting for antialiased pixels it can become even more 
> diverse from standard math as it does not ‘see’ it in percentages of visible, 
> only on or off. 
> 
> So, the difference between measuring only inside of a 200x200 and outside of 
> the 100x100 will throw off considerably any ordinary calculations you might 
> expect. Even a 400x400 PixelWise ‘circle’. 
> 
> Look up Gauss’ Circle Problem. The same chap we get the name for Gaussian 
> blur from. 
> 
>> On 7 Sep 2020, at 05:26, Roger Guay via use-livecode 
>>  wrote:
>> 
>> I’m sorry, I don’t understand your terminology. Could you please elaborate? 
>> 
>> Thanks,
>> Roger
>> 
>>> On Sep 6, 2020, at 10:54 AM, Pi Digital via use-livecode 
>>>  wrote:
>>> 
>>> Pixel math:
>>> 
>>> Counting incomplete pixels within a circle outline (%Pass)(%Fail):
>>> 10x10 = 88 (88%)(12%)
>>> 20x20 = 344 (86%)(14%)
>>> 100x100 = 8012 (80%)(20%)
>>> 
>>> Counting complete pixels:
>>> 10x10 = 48 (48%)(52%)
>>> 20x20 = 276 (69%)(31%)
>>> 100x100 = 7444 (74.4%)(26%)
>>> 
>>> Your conclusion here: _
>>> 
>>> ___
>>> use-livecode mailing list
>>> use-livecode@lists.runrev.com
>>> Please visit this url to subscribe, unsubscribe and manage your 
>>> subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>> 
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription 
>> preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
> 
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Contesting for Idiot du Jour

[Pi Digital via use-livecode]

Sure. Draw a circle on a 10x10, 20x20, 100x100, etc grid. Only Whole pixels get 
counted (Pass or 1 in digital binary). Depending on the methodology, either 1) 
only those within the circle line (complete) or 2) those on the line itself  
and within it (incomplete). 

In your example, a 200x200 circle has a resolution where it’s practically 
negligible from regular mathematics. However, the resolution at 100x100 and 
lower starts to flat wildly away from it. If you are measuring using collision 
and it’s accounting for antialiased pixels it can become even more diverse from 
standard math as it does not ‘see’ it in percentages of visible, only on or 
off. 

So, the difference between measuring only inside of a 200x200 and outside of 
the 100x100 will throw off considerably any ordinary calculations you might 
expect. Even a 400x400 PixelWise ‘circle’. 

Look up Gauss’ Circle Problem. The same chap we get the name for Gaussian blur 
from. 

> On 7 Sep 2020, at 05:26, Roger Guay via use-livecode 
>  wrote:
> 
> I’m sorry, I don’t understand your terminology. Could you please elaborate? 
> 
> Thanks,
> Roger
> 
>> On Sep 6, 2020, at 10:54 AM, Pi Digital via use-livecode 
>>  wrote:
>> 
>> Pixel math:
>> 
>> Counting incomplete pixels within a circle outline (%Pass)(%Fail):
>> 10x10 = 88 (88%)(12%)
>> 20x20 = 344 (86%)(14%)
>> 100x100 = 8012 (80%)(20%)
>> 
>> Counting complete pixels:
>> 10x10 = 48 (48%)(52%)
>> 20x20 = 276 (69%)(31%)
>> 100x100 = 7444 (74.4%)(26%)
>> 
>> Your conclusion here: _
>> 
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription 
>> preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Contesting for Idiot du Jour

[Roger Guay via use-livecode]

I’m sorry, I don’t understand your terminology. Could you please elaborate? 

Thanks,
Roger

> On Sep 6, 2020, at 10:54 AM, Pi Digital via use-livecode 
>  wrote:
> 
> Pixel math:
> 
> Counting incomplete pixels within a circle outline (%Pass)(%Fail):
> 10x10 = 88 (88%)(12%)
> 20x20 = 344 (86%)(14%)
> 100x100 = 8012 (80%)(20%)
> 
> Counting complete pixels:
> 10x10 = 48 (48%)(52%)
> 20x20 = 276 (69%)(31%)
> 100x100 = 7444 (74.4%)(26%)
> 
> Your conclusion here: _
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Contesting for Idiot du Jour

[Pi Digital via use-livecode]

Pixel math:

Counting incomplete pixels within a circle outline (%Pass)(%Fail):
10x10 = 88 (88%)(12%)
20x20 = 344 (86%)(14%)
100x100 = 8012 (80%)(20%)

Counting complete pixels:
10x10 = 48 (48%)(52%)
20x20 = 276 (69%)(31%)
100x100 = 7444 (74.4%)(26%)

Your conclusion here: _

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Contesting for Idiot du Jour

[Roger Guay via use-livecode]

I’m having trouble understanding this last message or how you got these 
results, but I guess you’re right about this topic being somewhat straying from 
LC. 
So, I want to say I really appreciate your help and ideas. I will continue to 
attempt to push back the frontiers of my ignorance.

Thanks and cheers,
Roger 

> On Sep 5, 2020, at 1:19 PM, Thomas von Fintel via use-livecode 
>  wrote:
> 
> f you divide the circle in four equal parts using two diagonal lines, you 
> find that 25 percent of all points have a x-value of more than 70 percent of 
> the radius. Using 200 as radius, 25% of all points x > 141,42 (= 
> cos(45°)*200). But using your method only 60/400 = 15% of points have value x 
> greater than 141,42. So there ecertainly is a bias towards points in the 
> upper and lower quarter.
> 
> I have no idea why this bias isn't influencing your results. Maybe because 
> the second point is also influenced by this bias. But how?
> 
> I wonder whether it's okay to keep this discussion on the list. We are 
> straying far from matters LiveCode.

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Contesting for Idiot du Jour

[Thomas von Fintel via use-livecode]

I am officially puzzled and out of my waters.

If you divide the circle in four equal parts using two diagonal lines, 
you find that 25 percent of all points have a x-value of more than 70 
percent of the radius. Using 200 as radius, 25% of all points x > 141,42 
(= cos(45°)*200). But using your method only 60/400 = 15% of points have 
value x greater than 141,42. So there ecertainly is a bias towards 
points in the upper and lower quarter.


I have no idea why this bias isn't influencing your results. Maybe 
because the second point is also influenced by this bias. But how?


I wonder whether it's okay to keep this discussion on the list. We are 
straying far from matters LiveCode.


Thomas


Am 05.09.2020 um 20:28 schrieb Roger Guay via use-livecode:

Aha, in prepping my code to send to you, I found an error! Now the Cartesian 
Coord code is consistent with the Polar Coord code producing a ratio of about 
⅓. Here is the code:

on mouseDown

getStuff

end mouseDown


local tR, tX0, tY0, txl, tX1, tY1, tconstL, tTotCount, tL, tLongCount, tLocA, 
tLocB


on getStuff

put item 1 of the loc of grc OuterCircle into tX0

put item 2 of the loc of grc OuterCircle into tY0

put the width of grc OuterCircle/2 into tR

put the left of grc outerCircle into tXl

put 2*tR*cos(Pi/6) into tconstL

put "" into tTotCount

put "" into tLongCount

emptyFlds

end getStuff


on mouseUp

lock screen

repeat 1

add 1 to tTotCount

PickApointA

PickApointB

set the points of grc theChord to tLocA, tLocB

GetLength tLocA, tLocB

end repeat

put tTotCount into fld "totcountFld"

put tLongCount/tTotCount into fld "RatioFld"

unlock screen

end mouseUp


on PickApointA

set the numberFormat to "#."

put tXl + random(400) into X

put sqrt(tR^2 - (X-tX0)^2) - tY0 into y

get random(2)

if it is 1 then put x, + y+2*tY0 into tLocA

else put x, - y into tLocA

end PickApointA


on PickApointB

set the numberFormat to "#."

put tXl + random(400) into X

put sqrt(tR^2 - (X-tX0)^2) - tY0 into y

get random(2)

if it is 1 then put x, + y+2*tY0 into tLocB

else put x, - y into tLocB

end PickApointB


on GetLength pLocA, pLocB

put item 1 of pLocA into PX1

put item 2 of pLocA into Py1

put item 1 of pLocB into PX2

put item 2 of pLocB into Py2

set the numberFormat to "#.0"

put (pX2- pX1)^2 + (pY2- pY1)^2 into Lsquared

put Sqrt(Lsquared) into tL

if tL > tconstL then add 1 to tLongCount ---

put tLongCount into fld "LongCountFld"

end GetLength


Thanks,
Roger



On Sep 5, 2020, at 11:07 AM, Thomas von Fintel via use-livecode 
 wrote:

„I am known for making many more mistakes than not!“
Aren‘t we all?
I guess using Cartesian coordinates for choosing points on a circle could 
produce some bias, though I have no clear idea how.
So, what is your code?

Thomas


Am 05.09.2020 um 19:15 schrieb Roger Guay via use-livecode 
:

I am known for making many more mistakes than not!


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Contesting for Idiot du Jour

[Roger Guay via use-livecode]

Aha, in prepping my code to send to you, I found an error! Now the Cartesian 
Coord code is consistent with the Polar Coord code producing a ratio of about 
⅓. Here is the code:

on mouseDown

getStuff

end mouseDown


local tR, tX0, tY0, txl, tX1, tY1, tconstL, tTotCount, tL, tLongCount, tLocA, 
tLocB


on getStuff

put item 1 of the loc of grc OuterCircle into tX0

put item 2 of the loc of grc OuterCircle into tY0

put the width of grc OuterCircle/2 into tR

put the left of grc outerCircle into tXl

put 2*tR*cos(Pi/6) into tconstL

put "" into tTotCount

put "" into tLongCount

emptyFlds

end getStuff


on mouseUp

lock screen

repeat 1

add 1 to tTotCount

PickApointA

PickApointB

set the points of grc theChord to tLocA, tLocB

GetLength tLocA, tLocB

end repeat

put tTotCount into fld "totcountFld"

put tLongCount/tTotCount into fld "RatioFld"

unlock screen

end mouseUp


on PickApointA

set the numberFormat to "#."

put tXl + random(400) into X

put sqrt(tR^2 - (X-tX0)^2) - tY0 into y

get random(2)

if it is 1 then put x, + y+2*tY0 into tLocA

else put x, - y into tLocA

end PickApointA


on PickApointB

set the numberFormat to "#."

put tXl + random(400) into X

put sqrt(tR^2 - (X-tX0)^2) - tY0 into y

get random(2)

if it is 1 then put x, + y+2*tY0 into tLocB

else put x, - y into tLocB

end PickApointB


on GetLength pLocA, pLocB

put item 1 of pLocA into PX1

put item 2 of pLocA into Py1

put item 1 of pLocB into PX2

put item 2 of pLocB into Py2

set the numberFormat to "#.0"

put (pX2- pX1)^2 + (pY2- pY1)^2 into Lsquared

put Sqrt(Lsquared) into tL

if tL > tconstL then add 1 to tLongCount ---

put tLongCount into fld "LongCountFld"

end GetLength


Thanks,
Roger


> On Sep 5, 2020, at 11:07 AM, Thomas von Fintel via use-livecode 
>  wrote:
> 
> „I am known for making many more mistakes than not!“
> Aren‘t we all?
> I guess using Cartesian coordinates for choosing points on a circle could 
> produce some bias, though I have no clear idea how.
> So, what is your code?
> 
> Thomas
> 
>> Am 05.09.2020 um 19:15 schrieb Roger Guay via use-livecode 
>> :
>> 
>> I am known for making many more mistakes than not!
> 
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Contesting for Idiot du Jour

[Thomas von Fintel via use-livecode]

„I am known for making many more mistakes than not!“
Aren‘t we all?
I guess using Cartesian coordinates for choosing points on a circle could 
produce some bias, though I have no clear idea how.
So, what is your code?

Thomas

> Am 05.09.2020 um 19:15 schrieb Roger Guay via use-livecode 
> :
> 
> I am known for making many more mistakes than not!


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Contesting for Idiot du Jour

[Roger Guay via use-livecode]

You’re absolutely right. I should have been more careful in describing what I 
did:

In addition to your method, using polar coordinates, which results in a ratio 
of ⅓, I also did a random selection of 2 points on the circle in cartesian 
coordinates which produces the ½. Very curious! I am now wondering if I did the 
math right? I am known for making many more mistakes than not!

Roger



> On Sep 5, 2020, at 9:34 AM, Thomas von Fintel via use-livecode 
>  wrote:
> 
> That is strange. Choosing two points „at random“ should give a ratio of 1/3. 
> 
> At least if you choose them by generating two random numbers between 0 and 
> 360 and use this numbers as angles between a fixed line connecting  the 
> centre (e.g. the x-axis) and the line between the centre and the chosen 
> point. 
> Something like (without access to any LiveCode)
> put Random(360) *pi / 180 into angle1. 
> put sin (angle1) * radius into p1y
> put cos (angle1) * radius into p1x
> That’s the method I would choose. 
> How do you choose the two points?
> 
> Thomas
> 
> 
> 
>> Am 05.09.2020 um 17:11 schrieb Roger Guay via use-livecode 
>> :
>> 
>> My intent was not to suggest that math is “really’ broken in the Bertrand 
>> Paradox, but it did make me wonder what is going on. 
>> Enter LC. I built a simulation of your description where each of two points 
>> on a circle are randomly chosen. This kind of chord generation is 
>> consistently producing a ratio of about ½ which, of course, disagrees with 2 
>> of the methods in the BP, but is close to one of them. 
>> I don’t mean to promote controversy here . . . I am just having fun playing 
>> with this and wondering what is indeed going on???
>> Thanks for playing, Thomas.
>> 
>> Roger
>> 
> On Sep 5, 2020, at 12:24 AM, Thomas von Fintel via use-livecode 
>  wrote:
>>> Having had no contact with Bertrand Paradox except reading the Wikipedia 
>>> entries in English and German, my impression is that this is not a case of 
>>> broken math but a case of an ill-defined problem.
>>> Saying that a chord of a circle is chosen at random seems to imply that all 
>>> possible chords are chosen with the same probability. My interpretation 
>>> would be that all points on the circle have the same probability and also 
>>> every combination of two points have the same probability of being chosen. 
>>> Not all methods proposed by Bertrand fulfil this requirement.
>>> My interpretation may be wrong. But the fact that you need an 
>>> interpretation shows that a problem like this needs more clarification.
>>> Thomas
> Am 05.09.2020 um 04:40 schrieb Roger Guay via use-livecode 
> :
 Bertrand Paradox
>>> ___
>>> use-livecode mailing list
>>> use-livecode@lists.runrev.com
>>> Please visit this url to subscribe, unsubscribe and manage your 
>>> subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>> 
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription 
>> preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Contesting for Idiot du Jour

[Thomas von Fintel via use-livecode]

That is strange. Choosing two points „at random“ should give a ratio of 1/3. 

At least if you choose them by generating two random numbers between 0 and 360 
and use this numbers as angles between a fixed line connecting  the centre 
(e.g. the x-axis) and the line between the centre and the chosen point. 
Something like (without access to any LiveCode)
put Random(360) *pi / 180 into angle1. 
put sin (angle1) * radius into p1y
put cos (angle1) * radius into p1x
That’s the method I would choose. 
How do you choose the two points?

Thomas



> Am 05.09.2020 um 17:11 schrieb Roger Guay via use-livecode 
> :
> 
> My intent was not to suggest that math is “really’ broken in the Bertrand 
> Paradox, but it did make me wonder what is going on. 
> Enter LC. I built a simulation of your description where each of two points 
> on a circle are randomly chosen. This kind of chord generation is 
> consistently producing a ratio of about ½ which, of course, disagrees with 2 
> of the methods in the BP, but is close to one of them. 
> I don’t mean to promote controversy here . . . I am just having fun playing 
> with this and wondering what is indeed going on???
> Thanks for playing, Thomas.
> 
> Roger
> 
 On Sep 5, 2020, at 12:24 AM, Thomas von Fintel via use-livecode 
  wrote:
>> Having had no contact with Bertrand Paradox except reading the Wikipedia 
>> entries in English and German, my impression is that this is not a case of 
>> broken math but a case of an ill-defined problem.
>> Saying that a chord of a circle is chosen at random seems to imply that all 
>> possible chords are chosen with the same probability. My interpretation 
>> would be that all points on the circle have the same probability and also 
>> every combination of two points have the same probability of being chosen. 
>> Not all methods proposed by Bertrand fulfil this requirement.
>> My interpretation may be wrong. But the fact that you need an interpretation 
>> shows that a problem like this needs more clarification.
>> Thomas
 Am 05.09.2020 um 04:40 schrieb Roger Guay via use-livecode 
 :
>>> Bertrand Paradox
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription 
>> preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Contesting for Idiot du Jour

[Roger Guay via use-livecode]

My intent was not to suggest that math is “really’ broken in the Bertrand 
Paradox, but it did make me wonder what is going on. 
Enter LC. I built a simulation of your description where each of two points on 
a circle are randomly chosen. This kind of chord generation is consistently 
producing a ratio of about ½ which, of course, disagrees with 2 of the methods 
in the BP, but is close to one of them. 
I don’t mean to promote controversy here . . . I am just having fun playing 
with this and wondering what is indeed going on???
Thanks for playing, Thomas.

Roger

> On Sep 5, 2020, at 12:24 AM, Thomas von Fintel via use-livecode 
>  wrote:
> 
> Having had no contact with Bertrand Paradox except reading the Wikipedia 
> entries in English and German, my impression is that this is not a case of 
> broken math but a case of an ill-defined problem.
> Saying that a chord of a circle is chosen at random seems to imply that all 
> possible chords are chosen with the same probability. My interpretation would 
> be that all points on the circle have the same probability and also every 
> combination of two points have the same probability of being chosen. Not all 
> methods proposed by Bertrand fulfil this requirement.
> My interpretation may be wrong. But the fact that you need an interpretation 
> shows that a problem like this needs more clarification.
> 
> Thomas
> 
>> Am 05.09.2020 um 04:40 schrieb Roger Guay via use-livecode 
>> :
>> 
>> Bertrand Paradox
> 
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Contesting for Idiot du Jour

[Thomas von Fintel via use-livecode]

Having had no contact with Bertrand Paradox except reading the Wikipedia 
entries in English and German, my impression is that this is not a case of 
broken math but a case of an ill-defined problem.
Saying that a chord of a circle is chosen at random seems to imply that all 
possible chords are chosen with the same probability. My interpretation would 
be that all points on the circle have the same probability and also every 
combination of two points have the same probability of being chosen. Not all 
methods proposed by Bertrand fulfil this requirement.
My interpretation may be wrong. But the fact that you need an interpretation 
shows that a problem like this needs more clarification.

Thomas

> Am 05.09.2020 um 04:40 schrieb Roger Guay via use-livecode 
> :
> 
> Bertrand Paradox


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Contesting for Idiot du Jour

[Roger Guay via use-livecode]

Speaking of broken math, you should check out Bertrand Paradox.

Roger

> On Sep 4, 2020, at 1:46 PM, Bob Sneidar via use-livecode 
>  wrote:
> 
> If math breaks, we are all in for a world of hurt.
> 
> Bob S
> 
> 
> On Sep 3, 2020, at 4:46 PM, Roger Guay via use-livecode 
> mailto:use-livecode@lists.runrev.com>> wrote:
> 
> Your suggestion reestablishes my faith in the basic math, while recognizing 
> limitations sometime apply to any particular solution.
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Contesting for Idiot du Jour

[Bob Sneidar via use-livecode]

If math breaks, we are all in for a world of hurt.

Bob S


On Sep 3, 2020, at 4:46 PM, Roger Guay via use-livecode 
mailto:use-livecode@lists.runrev.com>> wrote:

Your suggestion reestablishes my faith in the basic math, while recognizing 
limitations sometime apply to any particular solution.

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Contesting for Idiot du Jour

[Roger Guay via use-livecode]

Great suggestion, Thomas! It works very well. 
Originally, I was flummoxed by my code, using polar coordinates, not working as 
expected. Thanks to you and the others responding to this thread, I now get it. 
Your suggestion reestablishes my faith in the basic math, while recognizing 
limitations sometime apply to any particular solution. FWIW, I am playing 
around with Bertrand Paradox, 
https://en.wikipedia.org/wiki/Bertrand_paradox_(probability) 
, and I'm trying 
to be as precise as possible in simulating the approaches to the problem. Just 
having fun, as it were!

Roger

> On Sep 3, 2020, at 1:42 PM, Thomas von Fintel via use-livecode 
>  wrote:
> 
> I think the easiest way is to adjust the linear random function so that it 
> produces higher numbers more frequently than lower numbers. More precisely, 
> the frequency of 10 must be four times that of 5 (because the area quadruples 
> if you double the radius). Or else the outer points have a lower probability 
> of being found.
> 
> If you replace
> 
> put random(200) into tR -- 200 is half the width of the larger circle
> 
> by
> 
> put sqrt(random(1000^2))/1000*200 into tR -- 200 is half the width of the 
> larger circle
> 
> you get random numbers that fulfil these requirements.
> 
> If you only want to test whether a certain point is within the inner corcle, 
> you only need to look at the radius. But I assume you need this in a more 
> complicated situation.
> 
> I hope this helps
> Thomas
> 
> 
> Am 03.09.2020 um 19:21 schrieb Roger Guay via use-livecode:
>> Or to put it simply, how would one select random point  (e.g. in a circle) 
>> using Polar Coordinates??
>> 
>> Roger
>> 
>>> On Sep 3, 2020, at 8:17 AM, Roger Guay via use-livecode 
>>>  wrote:
>>> 
>>> Jerry,
>>> 
>>> You’ve done a very nice job of describing what’s actually(?) happening in 
>>> my code, but I think you missed the point of my question.
>>> You agree that if you simply sample random pixels then the ratio of a 
>>> random pick inside the smaller circle will depend on the area of the 
>>> circles.
>>> And, if I pick a random x and y within the concentric circles of radius R 
>>> and 2R, ¼ of the time they will lie in the smaller circle and ¾ of the time 
>>> in the bigger.
>>> So, pick any random x and y and convert to radial coordinates. Everything 
>>> should work!
>>> In my code I pick a random angle and a random radius (radial coordinates) 
>>> within the limits of the larger circle, thus picking random points within 
>>> the area of the larger circle, yet I get ½ (which you say is the right 
>>> answer).
>>> My intent was to pick random points (using radial coordinates) for which 
>>> the result should be ¼!
>>> 
>>> What’s wrong with my code?
>>> 
>>> Thanks,
>>> 
>>> Roger
>>> 
 On Sep 2, 2020, at 8:27 PM, Jerry Jensen via use-livecode 
  wrote:
 
 1/2 is the right answer.
 
 Take your drawing of the circles. Cut a veyy thin radial slice from 
 the center to the outside circle. So thin that it is just a line.
 
 Now think of how likely a random point on that line will be in the part of 
 the line that was in the smaller circle. The part that was from the 
 smaller circle is HALF as long as the entire line.
 
 Now add up all the possible positions of that line. Why would that change 
 the answer?
 
 Congratulations, you understand integrals!
 .Jerry
 
> On Sep 2, 2020, at 7:38 PM, Roger Guay via use-livecode 
>  wrote:
> 
> Your chance to be Genius du Jour:
> 
> If I construct 2 concentric circles, one being half the radius of the 
> larger, then simple math shows that the smaller circle has an area ¼ the 
> area of the larger.
> Now if I generate a random point within the radius of the larger circle, 
> I should expect that the probability of it landing in the smaller circle 
> to be ¼.
> But, I must be doing something wrong because I get ½ !
> 
> Here is my script:
> 
> on mouseDown
> 
>   getStuff
> 
> end mouseDown
> 
> 
> local tR, tTheta, tX0, tY0, tX1, tY1, tTotCount, tL, tLongCount
> 
> on getStuff
> 
>   put item 1 of the loc of grc OuterCircle into tx0
> 
>   put item 2 of the loc of grc OuterCircle into tY0
> 
>   put "" into tTotCount
> 
>   put "" into tLongCount
> 
>   emptyFlds
> 
> end getStuff
> 
> 
> on mouseUp
> 
>   lock screen
> 
>   repeat 1000
> 
>   put random(200) into tR -- 200 is half the width of the larger 
> circle
> 
>   if tR > 1 then
> 
>   ## put random(2*pi) into tTheta1
> 
>   get random(360)
> 
>   put it*pi/180 into tTheta1
> 
>   put tR*cos(tTheta1) into tX1
>   put 

Re: Contesting for Idiot du Jour

[Thomas von Fintel via use-livecode]

I think the easiest way is to adjust the linear random function so that 
it produces higher numbers more frequently than lower numbers. More 
precisely, the frequency of 10 must be four times that of 5 (because the 
area quadruples if you double the radius). Or else the outer points have 
a lower probability of being found.


If you replace

put random(200) into tR -- 200 is half the width of the larger circle

by

put sqrt(random(1000^2))/1000*200 into tR -- 200 is half the width of 
the larger circle


you get random numbers that fulfil these requirements.

If you only want to test whether a certain point is within the inner 
corcle, you only need to look at the radius. But I assume you need this 
in a more complicated situation.


I hope this helps
Thomas


Am 03.09.2020 um 19:21 schrieb Roger Guay via use-livecode:

Or to put it simply, how would one select random point  (e.g. in a circle) 
using Polar Coordinates??

Roger


On Sep 3, 2020, at 8:17 AM, Roger Guay via use-livecode 
 wrote:

Jerry,

You’ve done a very nice job of describing what’s actually(?) happening in my 
code, but I think you missed the point of my question.
You agree that if you simply sample random pixels then the ratio of a random 
pick inside the smaller circle will depend on the area of the circles.
And, if I pick a random x and y within the concentric circles of radius R and 
2R, ¼ of the time they will lie in the smaller circle and ¾ of the time in the 
bigger.
So, pick any random x and y and convert to radial coordinates. Everything 
should work!
In my code I pick a random angle and a random radius (radial coordinates) 
within the limits of the larger circle, thus picking random points within the 
area of the larger circle, yet I get ½ (which you say is the right answer).
My intent was to pick random points (using radial coordinates) for which the 
result should be ¼!

What’s wrong with my code?

Thanks,

Roger


On Sep 2, 2020, at 8:27 PM, Jerry Jensen via use-livecode 
 wrote:

1/2 is the right answer.

Take your drawing of the circles. Cut a veyy thin radial slice from the 
center to the outside circle. So thin that it is just a line.

Now think of how likely a random point on that line will be in the part of the 
line that was in the smaller circle. The part that was from the smaller circle 
is HALF as long as the entire line.

Now add up all the possible positions of that line. Why would that change the 
answer?

Congratulations, you understand integrals!
.Jerry


On Sep 2, 2020, at 7:38 PM, Roger Guay via use-livecode 
 wrote:

Your chance to be Genius du Jour:

If I construct 2 concentric circles, one being half the radius of the larger, 
then simple math shows that the smaller circle has an area ¼ the area of the 
larger.
Now if I generate a random point within the radius of the larger circle, I 
should expect that the probability of it landing in the smaller circle to be ¼.
But, I must be doing something wrong because I get ½ !

Here is my script:

on mouseDown

getStuff

end mouseDown


local tR, tTheta, tX0, tY0, tX1, tY1, tTotCount, tL, tLongCount

on getStuff

put item 1 of the loc of grc OuterCircle into tx0

put item 2 of the loc of grc OuterCircle into tY0

put "" into tTotCount

put "" into tLongCount

emptyFlds

end getStuff


on mouseUp

lock screen

repeat 1000

put random(200) into tR -- 200 is half the width of the larger 
circle

if tR > 1 then

## put random(2*pi) into tTheta1

get random(360)

put it*pi/180 into tTheta1

put tR*cos(tTheta1) into tX1
put tR*sin(tTheta1) into tY1

set the loc of grc Ptgrc to tX0 + tX1, tY0 - tY1 --- 
grc Ptgrc is a 2 pixle oval

if intersect(grc Ptgrc, grc InnerCircle, "opaque 
Pixels") then add 1 to tLongCount

add 1 to tTotCount

end if

end repeat
put tTotCount into fld "totcountFld"

put tLongCount into fld “LongCountFld"

put tLongCount/tTotCount into fld "RatioFld"

unlock screen

end mouseUp


Apparently, this does not generate a random point within the larger circle! Can 
someone please tell me what’s wrong here?

Thanks,
Roger
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

___
use-livecode mailing list

Re: Contesting for Idiot du Jour

[chaplais via use-livecode]

There is no simple way, because the infinitesimal area is polar coordinates is 
r dr dtheta where r is the radius and theta is the angle.
More intuitively, the farther you are from the center, the smaller the angle 
that covers a fixed size pixel becomes.
All the best,
François
Le 3 sept. 2020 à 19:22 +0200, Roger Guay via use-livecode 
, a écrit :
> Or to put it simply, how would one select random point (e.g. in a circle) 
> using Polar Coordinates??
>
> Roger
>
> > On Sep 3, 2020, at 8:17 AM, Roger Guay via use-livecode 
> >  wrote:
> >
> > Jerry,
> >
> > You’ve done a very nice job of describing what’s actually(?) happening in 
> > my code, but I think you missed the point of my question.
> > You agree that if you simply sample random pixels then the ratio of a 
> > random pick inside the smaller circle will depend on the area of the 
> > circles.
> > And, if I pick a random x and y within the concentric circles of radius R 
> > and 2R, ¼ of the time they will lie in the smaller circle and ¾ of the time 
> > in the bigger.
> > So, pick any random x and y and convert to radial coordinates. Everything 
> > should work!
> > In my code I pick a random angle and a random radius (radial coordinates) 
> > within the limits of the larger circle, thus picking random points within 
> > the area of the larger circle, yet I get ½ (which you say is the right 
> > answer).
> > My intent was to pick random points (using radial coordinates) for which 
> > the result should be ¼!
> >
> > What’s wrong with my code?
> >
> > Thanks,
> >
> > Roger
> >
> > > On Sep 2, 2020, at 8:27 PM, Jerry Jensen via use-livecode 
> > >  wrote:
> > >
> > > 1/2 is the right answer.
> > >
> > > Take your drawing of the circles. Cut a veyy thin radial slice from 
> > > the center to the outside circle. So thin that it is just a line.
> > >
> > > Now think of how likely a random point on that line will be in the part 
> > > of the line that was in the smaller circle. The part that was from the 
> > > smaller circle is HALF as long as the entire line.
> > >
> > > Now add up all the possible positions of that line. Why would that change 
> > > the answer?
> > >
> > > Congratulations, you understand integrals!
> > > .Jerry
> > >
> > > > On Sep 2, 2020, at 7:38 PM, Roger Guay via use-livecode 
> > > >  wrote:
> > > >
> > > > Your chance to be Genius du Jour:
> > > >
> > > > If I construct 2 concentric circles, one being half the radius of the 
> > > > larger, then simple math shows that the smaller circle has an area ¼ 
> > > > the area of the larger.
> > > > Now if I generate a random point within the radius of the larger 
> > > > circle, I should expect that the probability of it landing in the 
> > > > smaller circle to be ¼.
> > > > But, I must be doing something wrong because I get ½ !
> > > >
> > > > Here is my script:
> > > >
> > > > on mouseDown
> > > >
> > > > getStuff
> > > >
> > > > end mouseDown
> > > >
> > > >
> > > > local tR, tTheta, tX0, tY0, tX1, tY1, tTotCount, tL, tLongCount
> > > >
> > > > on getStuff
> > > >
> > > > put item 1 of the loc of grc OuterCircle into tx0
> > > >
> > > > put item 2 of the loc of grc OuterCircle into tY0
> > > >
> > > > put "" into tTotCount
> > > >
> > > > put "" into tLongCount
> > > >
> > > > emptyFlds
> > > >
> > > > end getStuff
> > > >
> > > >
> > > > on mouseUp
> > > >
> > > > lock screen
> > > >
> > > > repeat 1000
> > > >
> > > > put random(200) into tR -- 200 is half the width of the larger circle
> > > >
> > > > if tR > 1 then
> > > >
> > > > ## put random(2*pi) into tTheta1
> > > >
> > > > get random(360)
> > > >
> > > > put it*pi/180 into tTheta1
> > > >
> > > > put tR*cos(tTheta1) into tX1
> > > > put tR*sin(tTheta1) into tY1
> > > >
> > > > set the loc of grc Ptgrc to tX0 + tX1, tY0 - tY1 --- grc Ptgrc is a 2 
> > > > pixle oval
> > > >
> > > > if intersect(grc Ptgrc, grc InnerCircle, "opaque Pixels") then add 1 to 
> > > > tLongCount
> > > >
> > > > add 1 to tTotCount
> > > >
> > > > end if
> > > >
> > > > end repeat
> > > > put tTotCount into fld "totcountFld"
> > > >
> > > > put tLongCount into fld “LongCountFld"
> > > >
> > > > put tLongCount/tTotCount into fld "RatioFld"
> > > >
> > > > unlock screen
> > > >
> > > > end mouseUp
> > > >
> > > >
> > > > Apparently, this does not generate a random point within the larger 
> > > > circle! Can someone please tell me what’s wrong here?
> > > >
> > > > Thanks,
> > > > Roger
> > > > ___
> > > > use-livecode mailing list
> > > > use-livecode@lists.runrev.com
> > > > Please visit this url to subscribe, unsubscribe and manage your 
> > > > subscription preferences:
> > > > http://lists.runrev.com/mailman/listinfo/use-livecode
> > >
> > >
> > > ___
> > > use-livecode mailing list
> > > use-livecode@lists.runrev.com
> > > Please visit this url to subscribe, unsubscribe and manage your 
> > > subscription preferences:
> > > 

Re: Contesting for Idiot du Jour

[Roger Guay via use-livecode]

Or to put it simply, how would one select random point  (e.g. in a circle) 
using Polar Coordinates??

Roger

> On Sep 3, 2020, at 8:17 AM, Roger Guay via use-livecode 
>  wrote:
> 
> Jerry,
> 
> You’ve done a very nice job of describing what’s actually(?) happening in my 
> code, but I think you missed the point of my question. 
> You agree that if you simply sample random pixels then the ratio of a random 
> pick inside the smaller circle will depend on the area of the circles.
> And, if I pick a random x and y within the concentric circles of radius R and 
> 2R, ¼ of the time they will lie in the smaller circle and ¾ of the time in 
> the bigger.
> So, pick any random x and y and convert to radial coordinates. Everything 
> should work! 
> In my code I pick a random angle and a random radius (radial coordinates) 
> within the limits of the larger circle, thus picking random points within the 
> area of the larger circle, yet I get ½ (which you say is the right answer). 
> My intent was to pick random points (using radial coordinates) for which the 
> result should be ¼!
> 
> What’s wrong with my code?
> 
> Thanks,
> 
> Roger
> 
>> On Sep 2, 2020, at 8:27 PM, Jerry Jensen via use-livecode 
>>  wrote:
>> 
>> 1/2 is the right answer.
>> 
>> Take your drawing of the circles. Cut a veyy thin radial slice from the 
>> center to the outside circle. So thin that it is just a line. 
>> 
>> Now think of how likely a random point on that line will be in the part of 
>> the line that was in the smaller circle. The part that was from the smaller 
>> circle is HALF as long as the entire line.
>> 
>> Now add up all the possible positions of that line. Why would that change 
>> the answer?
>> 
>> Congratulations, you understand integrals!
>> .Jerry
>> 
>>> On Sep 2, 2020, at 7:38 PM, Roger Guay via use-livecode 
>>>  wrote:
>>> 
>>> Your chance to be Genius du Jour:
>>> 
>>> If I construct 2 concentric circles, one being half the radius of the 
>>> larger, then simple math shows that the smaller circle has an area ¼ the 
>>> area of the larger.
>>> Now if I generate a random point within the radius of the larger circle, I 
>>> should expect that the probability of it landing in the smaller circle to 
>>> be ¼.
>>> But, I must be doing something wrong because I get ½ !
>>> 
>>> Here is my script:
>>> 
>>> on mouseDown
>>> 
>>> getStuff
>>> 
>>> end mouseDown
>>> 
>>> 
>>> local tR, tTheta, tX0, tY0, tX1, tY1, tTotCount, tL, tLongCount
>>> 
>>> on getStuff
>>> 
>>> put item 1 of the loc of grc OuterCircle into tx0
>>> 
>>> put item 2 of the loc of grc OuterCircle into tY0
>>> 
>>> put "" into tTotCount
>>> 
>>> put "" into tLongCount
>>> 
>>> emptyFlds
>>> 
>>> end getStuff
>>> 
>>> 
>>> on mouseUp
>>> 
>>> lock screen
>>> 
>>> repeat 1000
>>> 
>>> put random(200) into tR -- 200 is half the width of the larger 
>>> circle
>>> 
>>> if tR > 1 then
>>> 
>>> ## put random(2*pi) into tTheta1
>>> 
>>> get random(360)
>>> 
>>> put it*pi/180 into tTheta1
>>> 
>>> put tR*cos(tTheta1) into tX1
>>> put tR*sin(tTheta1) into tY1
>>> 
>>> set the loc of grc Ptgrc to tX0 + tX1, tY0 - tY1 --- 
>>> grc Ptgrc is a 2 pixle oval
>>> 
>>> if intersect(grc Ptgrc, grc InnerCircle, "opaque 
>>> Pixels") then add 1 to tLongCount
>>> 
>>> add 1 to tTotCount
>>> 
>>> end if
>>> 
>>> end repeat
>>> put tTotCount into fld "totcountFld"
>>> 
>>> put tLongCount into fld “LongCountFld"
>>> 
>>> put tLongCount/tTotCount into fld "RatioFld"
>>> 
>>> unlock screen
>>> 
>>> end mouseUp
>>> 
>>> 
>>> Apparently, this does not generate a random point within the larger circle! 
>>> Can someone please tell me what’s wrong here?
>>> 
>>> Thanks,
>>> Roger
>>> ___
>>> use-livecode mailing list
>>> use-livecode@lists.runrev.com
>>> Please visit this url to subscribe, unsubscribe and manage your 
>>> subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>> 
>> 
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription 
>> preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Contesting for Idiot du Jour

[Roger Guay via use-livecode]

Jerry,

You’ve done a very nice job of describing what’s actually(?) happening in my 
code, but I think you missed the point of my question. 
You agree that if you simply sample random pixels then the ratio of a random 
pick inside the smaller circle will depend on the area of the circles.
And, if I pick a random x and y within the concentric circles of radius R and 
2R, ¼ of the time they will lie in the smaller circle and ¾ of the time in the 
bigger.
So, pick any random x and y and convert to radial coordinates. Everything 
should work! 
In my code I pick a random angle and a random radius (radial coordinates) 
within the limits of the larger circle, thus picking random points within the 
area of the larger circle, yet I get ½ (which you say is the right answer). 
My intent was to pick random points (using radial coordinates) for which the 
result should be ¼!

What’s wrong with my code?

Thanks,

Roger

> On Sep 2, 2020, at 8:27 PM, Jerry Jensen via use-livecode 
>  wrote:
> 
> 1/2 is the right answer.
> 
> Take your drawing of the circles. Cut a veyy thin radial slice from the 
> center to the outside circle. So thin that it is just a line. 
> 
> Now think of how likely a random point on that line will be in the part of 
> the line that was in the smaller circle. The part that was from the smaller 
> circle is HALF as long as the entire line.
> 
> Now add up all the possible positions of that line. Why would that change the 
> answer?
> 
> Congratulations, you understand integrals!
> .Jerry
> 
>> On Sep 2, 2020, at 7:38 PM, Roger Guay via use-livecode 
>>  wrote:
>> 
>> Your chance to be Genius du Jour:
>> 
>> If I construct 2 concentric circles, one being half the radius of the 
>> larger, then simple math shows that the smaller circle has an area ¼ the 
>> area of the larger.
>> Now if I generate a random point within the radius of the larger circle, I 
>> should expect that the probability of it landing in the smaller circle to be 
>> ¼.
>> But, I must be doing something wrong because I get ½ !
>> 
>> Here is my script:
>> 
>> on mouseDown
>> 
>>  getStuff
>> 
>> end mouseDown
>> 
>> 
>> local tR, tTheta, tX0, tY0, tX1, tY1, tTotCount, tL, tLongCount
>> 
>> on getStuff
>> 
>>  put item 1 of the loc of grc OuterCircle into tx0
>> 
>>  put item 2 of the loc of grc OuterCircle into tY0
>> 
>>  put "" into tTotCount
>> 
>>  put "" into tLongCount
>> 
>>  emptyFlds
>> 
>> end getStuff
>> 
>> 
>> on mouseUp
>> 
>>  lock screen
>> 
>>  repeat 1000
>> 
>>  put random(200) into tR -- 200 is half the width of the larger 
>> circle
>> 
>>  if tR > 1 then
>> 
>>  ## put random(2*pi) into tTheta1
>> 
>>  get random(360)
>> 
>>  put it*pi/180 into tTheta1
>> 
>>  put tR*cos(tTheta1) into tX1
>>  put tR*sin(tTheta1) into tY1
>> 
>>  set the loc of grc Ptgrc to tX0 + tX1, tY0 - tY1 --- 
>> grc Ptgrc is a 2 pixle oval
>> 
>>  if intersect(grc Ptgrc, grc InnerCircle, "opaque 
>> Pixels") then add 1 to tLongCount
>> 
>>  add 1 to tTotCount
>> 
>>  end if
>> 
>>  end repeat
>>  put tTotCount into fld "totcountFld"
>> 
>>  put tLongCount into fld “LongCountFld"
>> 
>>  put tLongCount/tTotCount into fld "RatioFld"
>> 
>>  unlock screen
>> 
>> end mouseUp
>> 
>> 
>> Apparently, this does not generate a random point within the larger circle! 
>> Can someone please tell me what’s wrong here?
>> 
>> Thanks,
>> Roger
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription 
>> preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
> 
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Contesting for Idiot du Jour

[Mark Wieder via use-livecode]

On 9/2/20 9:25 PM, Dev via use-livecode wrote:


You do understand math much better than I do obviously!


Better than I do as well.
I was puzzling over that thing until Jerry came through with the answer.

--
 Mark Wieder
 ahsoftw...@gmail.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Contesting for Idiot du Jour

[Jerry Jensen via use-livecode]

Whew !!  

> On Sep 2, 2020, at 9:25 PM, Dev via use-livecode 
>  wrote:
> 
> Me again Jerry
> 
> Changed the setup so that the pellets landing outside the big circle were 
> ignored and just kept going until I had 1000 within the circles in a 
> completely random pattern without Trig. Now the ratio in the smaller circle 
> is 25% or ¼ like the area comparison would suggest. 
> 
> You do understand math much better than I do obviously!
> 
> Kelly
> 
>> On 2Sep, 2020, at 10:10 PM, Dev  wrote:
>> 
>> Hi Jerry
>> 
>> I just tried that because I’m no math wizard and need to see things. When 
>> shooting a random shotgun blast of 1000 pellets into the centre of a target 
>> square that contained the large circle and small circles, the ratio worked 
>> out to around  0.2 - not 0.25. It seems the corners outside the big circle 
>> receive about 20% of the shots, the inner circle gets another 20% and the 
>> outer circle gets 60%. So I don’t understand your thought about ¼.
>> 
>> Kelly
>> 
>>> On 2Sep, 2020, at 9:43 PM, Jerry Jensen via use-livecode 
>>>  wrote:
>>> 
>>> Additional thought:
>>> If you just used random x and y, then ignored points outside the larger 
>>> circle, you would see that  1/4 of the points would be in the smaller 
>>> circle.
>>> 
>>> No trig or integrals involved.
>>> .Jerry
>>> 
 On Sep 2, 2020, at 8:27 PM, Jerry Jensen via use-livecode 
  wrote:
 
 1/2 is the right answer.
 
 Take your drawing of the circles. Cut a veyy thin radial slice from 
 the center to the outside circle. So thin that it is just a line. 
 
 Now think of how likely a random point on that line will be in the part of 
 the line that was in the smaller circle. The part that was from the 
 smaller circle is HALF as long as the entire line.
 
 Now add up all the possible positions of that line. Why would that change 
 the answer?
 
 Congratulations, you understand integrals!
 .Jerry
 
> On Sep 2, 2020, at 7:38 PM, Roger Guay via use-livecode 
>  wrote:
> 
> Your chance to be Genius du Jour:
> 
> If I construct 2 concentric circles, one being half the radius of the 
> larger, then simple math shows that the smaller circle has an area ¼ the 
> area of the larger.
> Now if I generate a random point within the radius of the larger circle, 
> I should expect that the probability of it landing in the smaller circle 
> to be ¼.
> But, I must be doing something wrong because I get ½ !
> 
> Here is my script:
> 
> on mouseDown
> 
>   getStuff
> 
> end mouseDown
> 
> 
> local tR, tTheta, tX0, tY0, tX1, tY1, tTotCount, tL, tLongCount
> 
> on getStuff
> 
>   put item 1 of the loc of grc OuterCircle into tx0
> 
>   put item 2 of the loc of grc OuterCircle into tY0
> 
>   put "" into tTotCount
> 
>   put "" into tLongCount
> 
>   emptyFlds
> 
> end getStuff
> 
> 
> on mouseUp
> 
>   lock screen
> 
>   repeat 1000
> 
>   put random(200) into tR -- 200 is half the width of the larger 
> circle
> 
>   if tR > 1 then
> 
>   ## put random(2*pi) into tTheta1
> 
>   get random(360)
> 
>   put it*pi/180 into tTheta1
> 
>   put tR*cos(tTheta1) into tX1
>   put tR*sin(tTheta1) into tY1
> 
>   set the loc of grc Ptgrc to tX0 + tX1, tY0 - tY1 --- 
> grc Ptgrc is a 2 pixle oval
> 
>   if intersect(grc Ptgrc, grc InnerCircle, "opaque 
> Pixels") then add 1 to tLongCount
> 
>   add 1 to tTotCount
> 
>   end if
> 
>   end repeat
>   put tTotCount into fld "totcountFld"
> 
>   put tLongCount into fld “LongCountFld"
> 
>   put tLongCount/tTotCount into fld "RatioFld"
> 
>   unlock screen
> 
> end mouseUp
> 
> 
> Apparently, this does not generate a random point within the larger 
> circle! Can someone please tell me what’s wrong here?
> 
> Thanks,
> Roger
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your 
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
 
 
 ___
 use-livecode mailing list
 use-livecode@lists.runrev.com
 Please visit this url to subscribe, unsubscribe and manage your 
 subscription preferences:
 http://lists.runrev.com/mailman/listinfo/use-livecode
>>> 
>>> 
>>> ___
>>> use-livecode mailing list
>>> use-livecode@lists.runrev.com
>>> Please visit this url to subscribe, 

Re: Contesting for Idiot du Jour

[Dev via use-livecode]

Me again Jerry

Changed the setup so that the pellets landing outside the big circle were 
ignored and just kept going until I had 1000 within the circles in a completely 
random pattern without Trig. Now the ratio in the smaller circle is 25% or ¼ 
like the area comparison would suggest. 

You do understand math much better than I do obviously!

Kelly

> On 2Sep, 2020, at 10:10 PM, Dev  wrote:
> 
> Hi Jerry
> 
> I just tried that because I’m no math wizard and need to see things. When 
> shooting a random shotgun blast of 1000 pellets into the centre of a target 
> square that contained the large circle and small circles, the ratio worked 
> out to around  0.2 - not 0.25. It seems the corners outside the big circle 
> receive about 20% of the shots, the inner circle gets another 20% and the 
> outer circle gets 60%. So I don’t understand your thought about ¼.
> 
> Kelly
> 
>> On 2Sep, 2020, at 9:43 PM, Jerry Jensen via use-livecode 
>>  wrote:
>> 
>> Additional thought:
>> If you just used random x and y, then ignored points outside the larger 
>> circle, you would see that  1/4 of the points would be in the smaller circle.
>> 
>> No trig or integrals involved.
>> .Jerry
>> 
>>> On Sep 2, 2020, at 8:27 PM, Jerry Jensen via use-livecode 
>>>  wrote:
>>> 
>>> 1/2 is the right answer.
>>> 
>>> Take your drawing of the circles. Cut a veyy thin radial slice from the 
>>> center to the outside circle. So thin that it is just a line. 
>>> 
>>> Now think of how likely a random point on that line will be in the part of 
>>> the line that was in the smaller circle. The part that was from the smaller 
>>> circle is HALF as long as the entire line.
>>> 
>>> Now add up all the possible positions of that line. Why would that change 
>>> the answer?
>>> 
>>> Congratulations, you understand integrals!
>>> .Jerry
>>> 
 On Sep 2, 2020, at 7:38 PM, Roger Guay via use-livecode 
  wrote:
 
 Your chance to be Genius du Jour:
 
 If I construct 2 concentric circles, one being half the radius of the 
 larger, then simple math shows that the smaller circle has an area ¼ the 
 area of the larger.
 Now if I generate a random point within the radius of the larger circle, I 
 should expect that the probability of it landing in the smaller circle to 
 be ¼.
 But, I must be doing something wrong because I get ½ !
 
 Here is my script:
 
 on mouseDown
 
getStuff
 
 end mouseDown
 
 
 local tR, tTheta, tX0, tY0, tX1, tY1, tTotCount, tL, tLongCount
 
 on getStuff
 
put item 1 of the loc of grc OuterCircle into tx0
 
put item 2 of the loc of grc OuterCircle into tY0
 
put "" into tTotCount
 
put "" into tLongCount
 
emptyFlds
 
 end getStuff
 
 
 on mouseUp
 
lock screen
 
repeat 1000
 
put random(200) into tR -- 200 is half the width of the larger 
 circle
 
if tR > 1 then
 
## put random(2*pi) into tTheta1
 
get random(360)
 
put it*pi/180 into tTheta1
 
put tR*cos(tTheta1) into tX1
put tR*sin(tTheta1) into tY1
 
set the loc of grc Ptgrc to tX0 + tX1, tY0 - tY1 --- 
 grc Ptgrc is a 2 pixle oval
 
if intersect(grc Ptgrc, grc InnerCircle, "opaque 
 Pixels") then add 1 to tLongCount
 
add 1 to tTotCount
 
end if
 
end repeat
put tTotCount into fld "totcountFld"
 
put tLongCount into fld “LongCountFld"
 
put tLongCount/tTotCount into fld "RatioFld"
 
unlock screen
 
 end mouseUp
 
 
 Apparently, this does not generate a random point within the larger 
 circle! Can someone please tell me what’s wrong here?
 
 Thanks,
 Roger
 ___
 use-livecode mailing list
 use-livecode@lists.runrev.com
 Please visit this url to subscribe, unsubscribe and manage your 
 subscription preferences:
 http://lists.runrev.com/mailman/listinfo/use-livecode
>>> 
>>> 
>>> ___
>>> use-livecode mailing list
>>> use-livecode@lists.runrev.com
>>> Please visit this url to subscribe, unsubscribe and manage your 
>>> subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>> 
>> 
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription 
>> preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
> 


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please 

Re: Contesting for Idiot du Jour

[Dev via use-livecode]

Hi Jerry

I just tried that because I’m no math wizard and need to see things. When 
shooting a random shotgun blast of 1000 pellets into the centre of a target 
square that contained the large circle and small circles, the ratio worked out 
to around  0.2 - not 0.25. It seems the corners outside the big circle receive 
about 20% of the shots, the inner circle gets another 20% and the outer circle 
gets 60%. So I don’t understand your thought about ¼.

Kelly

> On 2Sep, 2020, at 9:43 PM, Jerry Jensen via use-livecode 
>  wrote:
> 
> Additional thought:
> If you just used random x and y, then ignored points outside the larger 
> circle, you would see that  1/4 of the points would be in the smaller circle.
> 
> No trig or integrals involved.
> .Jerry
> 
>> On Sep 2, 2020, at 8:27 PM, Jerry Jensen via use-livecode 
>>  wrote:
>> 
>> 1/2 is the right answer.
>> 
>> Take your drawing of the circles. Cut a veyy thin radial slice from the 
>> center to the outside circle. So thin that it is just a line. 
>> 
>> Now think of how likely a random point on that line will be in the part of 
>> the line that was in the smaller circle. The part that was from the smaller 
>> circle is HALF as long as the entire line.
>> 
>> Now add up all the possible positions of that line. Why would that change 
>> the answer?
>> 
>> Congratulations, you understand integrals!
>> .Jerry
>> 
>>> On Sep 2, 2020, at 7:38 PM, Roger Guay via use-livecode 
>>>  wrote:
>>> 
>>> Your chance to be Genius du Jour:
>>> 
>>> If I construct 2 concentric circles, one being half the radius of the 
>>> larger, then simple math shows that the smaller circle has an area ¼ the 
>>> area of the larger.
>>> Now if I generate a random point within the radius of the larger circle, I 
>>> should expect that the probability of it landing in the smaller circle to 
>>> be ¼.
>>> But, I must be doing something wrong because I get ½ !
>>> 
>>> Here is my script:
>>> 
>>> on mouseDown
>>> 
>>> getStuff
>>> 
>>> end mouseDown
>>> 
>>> 
>>> local tR, tTheta, tX0, tY0, tX1, tY1, tTotCount, tL, tLongCount
>>> 
>>> on getStuff
>>> 
>>> put item 1 of the loc of grc OuterCircle into tx0
>>> 
>>> put item 2 of the loc of grc OuterCircle into tY0
>>> 
>>> put "" into tTotCount
>>> 
>>> put "" into tLongCount
>>> 
>>> emptyFlds
>>> 
>>> end getStuff
>>> 
>>> 
>>> on mouseUp
>>> 
>>> lock screen
>>> 
>>> repeat 1000
>>> 
>>> put random(200) into tR -- 200 is half the width of the larger 
>>> circle
>>> 
>>> if tR > 1 then
>>> 
>>> ## put random(2*pi) into tTheta1
>>> 
>>> get random(360)
>>> 
>>> put it*pi/180 into tTheta1
>>> 
>>> put tR*cos(tTheta1) into tX1
>>> put tR*sin(tTheta1) into tY1
>>> 
>>> set the loc of grc Ptgrc to tX0 + tX1, tY0 - tY1 --- 
>>> grc Ptgrc is a 2 pixle oval
>>> 
>>> if intersect(grc Ptgrc, grc InnerCircle, "opaque 
>>> Pixels") then add 1 to tLongCount
>>> 
>>> add 1 to tTotCount
>>> 
>>> end if
>>> 
>>> end repeat
>>> put tTotCount into fld "totcountFld"
>>> 
>>> put tLongCount into fld “LongCountFld"
>>> 
>>> put tLongCount/tTotCount into fld "RatioFld"
>>> 
>>> unlock screen
>>> 
>>> end mouseUp
>>> 
>>> 
>>> Apparently, this does not generate a random point within the larger circle! 
>>> Can someone please tell me what’s wrong here?
>>> 
>>> Thanks,
>>> Roger
>>> ___
>>> use-livecode mailing list
>>> use-livecode@lists.runrev.com
>>> Please visit this url to subscribe, unsubscribe and manage your 
>>> subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>> 
>> 
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription 
>> preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
> 
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Contesting for Idiot du Jour

[Jerry Jensen via use-livecode]

Additional thought:
If you just used random x and y, then ignored points outside the larger circle, 
you would see that  1/4 of the points would be in the smaller circle.

No trig or integrals involved.
.Jerry

> On Sep 2, 2020, at 8:27 PM, Jerry Jensen via use-livecode 
>  wrote:
> 
> 1/2 is the right answer.
> 
> Take your drawing of the circles. Cut a veyy thin radial slice from the 
> center to the outside circle. So thin that it is just a line. 
> 
> Now think of how likely a random point on that line will be in the part of 
> the line that was in the smaller circle. The part that was from the smaller 
> circle is HALF as long as the entire line.
> 
> Now add up all the possible positions of that line. Why would that change the 
> answer?
> 
> Congratulations, you understand integrals!
> .Jerry
> 
>> On Sep 2, 2020, at 7:38 PM, Roger Guay via use-livecode 
>>  wrote:
>> 
>> Your chance to be Genius du Jour:
>> 
>> If I construct 2 concentric circles, one being half the radius of the 
>> larger, then simple math shows that the smaller circle has an area ¼ the 
>> area of the larger.
>> Now if I generate a random point within the radius of the larger circle, I 
>> should expect that the probability of it landing in the smaller circle to be 
>> ¼.
>> But, I must be doing something wrong because I get ½ !
>> 
>> Here is my script:
>> 
>> on mouseDown
>> 
>>  getStuff
>> 
>> end mouseDown
>> 
>> 
>> local tR, tTheta, tX0, tY0, tX1, tY1, tTotCount, tL, tLongCount
>> 
>> on getStuff
>> 
>>  put item 1 of the loc of grc OuterCircle into tx0
>> 
>>  put item 2 of the loc of grc OuterCircle into tY0
>> 
>>  put "" into tTotCount
>> 
>>  put "" into tLongCount
>> 
>>  emptyFlds
>> 
>> end getStuff
>> 
>> 
>> on mouseUp
>> 
>>  lock screen
>> 
>>  repeat 1000
>> 
>>  put random(200) into tR -- 200 is half the width of the larger 
>> circle
>> 
>>  if tR > 1 then
>> 
>>  ## put random(2*pi) into tTheta1
>> 
>>  get random(360)
>> 
>>  put it*pi/180 into tTheta1
>> 
>>  put tR*cos(tTheta1) into tX1
>>  put tR*sin(tTheta1) into tY1
>> 
>>  set the loc of grc Ptgrc to tX0 + tX1, tY0 - tY1 --- 
>> grc Ptgrc is a 2 pixle oval
>> 
>>  if intersect(grc Ptgrc, grc InnerCircle, "opaque 
>> Pixels") then add 1 to tLongCount
>> 
>>  add 1 to tTotCount
>> 
>>  end if
>> 
>>  end repeat
>>  put tTotCount into fld "totcountFld"
>> 
>>  put tLongCount into fld “LongCountFld"
>> 
>>  put tLongCount/tTotCount into fld "RatioFld"
>> 
>>  unlock screen
>> 
>> end mouseUp
>> 
>> 
>> Apparently, this does not generate a random point within the larger circle! 
>> Can someone please tell me what’s wrong here?
>> 
>> Thanks,
>> Roger
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription 
>> preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
> 
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Contesting for Idiot du Jour

[Jerry Jensen via use-livecode]

1/2 is the right answer.

Take your drawing of the circles. Cut a veyy thin radial slice from the 
center to the outside circle. So thin that it is just a line. 

Now think of how likely a random point on that line will be in the part of the 
line that was in the smaller circle. The part that was from the smaller circle 
is HALF as long as the entire line.

Now add up all the possible positions of that line. Why would that change the 
answer?

Congratulations, you understand integrals!
.Jerry

> On Sep 2, 2020, at 7:38 PM, Roger Guay via use-livecode 
>  wrote:
> 
> Your chance to be Genius du Jour:
> 
> If I construct 2 concentric circles, one being half the radius of the larger, 
> then simple math shows that the smaller circle has an area ¼ the area of the 
> larger.
> Now if I generate a random point within the radius of the larger circle, I 
> should expect that the probability of it landing in the smaller circle to be 
> ¼.
> But, I must be doing something wrong because I get ½ !
> 
> Here is my script:
> 
> on mouseDown
> 
>   getStuff
> 
> end mouseDown
> 
> 
> local tR, tTheta, tX0, tY0, tX1, tY1, tTotCount, tL, tLongCount
> 
> on getStuff
> 
>   put item 1 of the loc of grc OuterCircle into tx0
> 
>   put item 2 of the loc of grc OuterCircle into tY0
> 
>   put "" into tTotCount
> 
>   put "" into tLongCount
> 
>   emptyFlds
> 
> end getStuff
> 
> 
> on mouseUp
> 
>   lock screen
> 
>   repeat 1000
> 
>   put random(200) into tR -- 200 is half the width of the larger 
> circle
> 
>   if tR > 1 then
> 
>   ## put random(2*pi) into tTheta1
> 
>   get random(360)
> 
>   put it*pi/180 into tTheta1
> 
>   put tR*cos(tTheta1) into tX1
>   put tR*sin(tTheta1) into tY1
> 
>   set the loc of grc Ptgrc to tX0 + tX1, tY0 - tY1 --- 
> grc Ptgrc is a 2 pixle oval
> 
>   if intersect(grc Ptgrc, grc InnerCircle, "opaque 
> Pixels") then add 1 to tLongCount
> 
>   add 1 to tTotCount
> 
>   end if
> 
>   end repeat
>   put tTotCount into fld "totcountFld"
> 
>   put tLongCount into fld “LongCountFld"
> 
>   put tLongCount/tTotCount into fld "RatioFld"
> 
>   unlock screen
> 
> end mouseUp
> 
> 
> Apparently, this does not generate a random point within the larger circle! 
> Can someone please tell me what’s wrong here?
> 
> Thanks,
> Roger
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Contesting for Idiot du Jour

[Roger Guay via use-livecode]

Your chance to be Genius du Jour:

If I construct 2 concentric circles, one being half the radius of the larger, 
then simple math shows that the smaller circle has an area ¼ the area of the 
larger.
Now if I generate a random point within the radius of the larger circle, I 
should expect that the probability of it landing in the smaller circle to be ¼.
But, I must be doing something wrong because I get ½ !

Here is my script:

on mouseDown

getStuff

end mouseDown


local tR, tTheta, tX0, tY0, tX1, tY1, tTotCount, tL, tLongCount

on getStuff

put item 1 of the loc of grc OuterCircle into tx0

put item 2 of the loc of grc OuterCircle into tY0

put "" into tTotCount

put "" into tLongCount

emptyFlds

end getStuff


on mouseUp

lock screen

repeat 1000

put random(200) into tR -- 200 is half the width of the larger 
circle

if tR > 1 then

## put random(2*pi) into tTheta1

get random(360)

put it*pi/180 into tTheta1

put tR*cos(tTheta1) into tX1
put tR*sin(tTheta1) into tY1

set the loc of grc Ptgrc to tX0 + tX1, tY0 - tY1 --- 
grc Ptgrc is a 2 pixle oval

if intersect(grc Ptgrc, grc InnerCircle, "opaque 
Pixels") then add 1 to tLongCount

add 1 to tTotCount

end if

end repeat
put tTotCount into fld "totcountFld"

put tLongCount into fld “LongCountFld"

put tLongCount/tTotCount into fld "RatioFld"

unlock screen

end mouseUp


Apparently, this does not generate a random point within the larger circle! Can 
someone please tell me what’s wrong here?

Thanks,
Roger
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode