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!
>
>
>
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
… 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,
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
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
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
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:
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
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
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,
„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
> :
>
>
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
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
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
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
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
>
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.
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
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
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 à
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
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
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
___
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
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
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
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
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
28 matches
Mail list logo
