# fractions.Fraction limit numerator

Dominik, there are exactly 2**64 floats. Apart from two infinities, -0.0

and 9007199254740986 NANs, every one of those corresponds precisely to a

fraction. Apart from those special cases every float can be converted to

a fraction without loss. (The lossless conversion does not go the other

way: many fractions cannot be converted to floats.)

So in a very real sense, every finite float is a fraction.

The topic of this thread is called “fractions.Fraction limit numerator”

so I don’t know why you are telling me off for using fractions instead

of floats, or why you wrote your code to insist on floats.

If we can solve the problem of limiting both the numerator an the

denominator for fractions, then it will automatically work for every

float (provided we convert that float to a fraction of course).

It’s not clear to me exactly what you are trying to do, but maybe I’m

getting confused myself. Sorry.

For example, I think that you might have missed that the point of the

exercise is (as far as I can tell) to start with fractions that are out

of range, and find the closest fraction which is in range. If we start

with fractions that are in range, we don’t need to do anything to them

Hi Steven,

looks a little like that…

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

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.

Not more, not less.

Cheers, Dominik

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
distributed.
“”"

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

# reality
measurement = baseline + noise
``````

Since the noise is always one-sided, it can’t cancel out by taking the
average.