That is not how I understood the task Peter has described.
And it does not make sense to “approximate” e.g. the float “2**64” by a fraction of two 32-bit integers, if you ask me.
If your nominator is limited to 32-bit, the biggest number such a fraction can represent sensibly is said (2^31-1), right ? (when the belonging denominator is 1)
The function Peter proposed initially with the question
takes floats as the argument:
And Peters hint
seems to describe the constraints of the general task quite well, if you ask me?
Our discussion was about algorithms resp. mathematical approaches to solve Peters requirements best. At least this was what I was trying to discuss.
With your post, where you feed out-of-range numbers and numbers of the wrong type to the test functions, you seem to have left that path.
You at least seem to evade the answer to some of my statements, which refuted your previous argumentations, e.g.:
as well as
You instead say
which is not appropriate, if you ask me. We were discussing the algorithms / mathematical approaches, not whether the function should have some additional if statements to ensure, that it can handle border cases.
It is quite obvious, that the function YOU proposed:
does not work well with 0 ==>
ZeroDivisionError: Fraction(1, 0)
But this is not what we were discussing. It is quite clear, that any function proposed would need some polishment in this sense - at the end.
But this does not render my Monte-Carlo test senseless at all. My test shows, that some proposed functions seem to return fractions, which approximate the floats to be approximated quite well under the wished constraints (nominator, denominator <=> 32-bit) - for more than 500 000 random floats in the range to be considered.
Sorry for the weird line spacing of my post, Discuss seems to have
trouble dealing with emails.
A couple of corrections. I wrote:
To get that, we need the “critical values”. The critical values tell us
that, if the data is actually normally distributed, and so
symmetrical, 90% of the time we will get a skewness between the two
critical values. If we get a skewness outside of those two values, then
there is only a 5% chance that the data actually was normally
Oops, that’s a ten percent chance of getting a skewness values outside
of the critical values. Five percent chance of being below the lower
value, and five percent for being above the upper value.
Then I wrote:
The value that we actually got, 0.614, was way out of that range,
suggesting very strongly that our data was normally distributed, and so
probably not symmetrical.
That should be “our data was NOT normally distributed”.
This of course matches the common-sense physical understanding of the
process. Whatever random things are going on to introduce noise to the
measurement, that can only add time to the benchmark by slowing the
code down. You can’t speed up the code from it’s baseline:
# normal distribution, or any other symmetric distribution
measurement = baseline ± noise
measurement = baseline + noise
Since the noise is always one-sided, it can’t cancel out by taking the