fractions.Fraction limit numerator

[steven.daprano]

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

[Blackward (Dominik Niedenzu)]

Hi Steven,

@steven.daprano

but maybe I’m

getting confused myself. Sorry.

looks a little like that…

@steven.daprano

to start with fractions that are out

of range

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

@petersuter

Is there a better way?

takes floats as the argument:

@petersuter

def limit_32bit_rational(f: float) -> Fraction:

And Peters hint

@petersuter

because TIFF files store fractions as two 32-bit integers

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.:

@Blackward

But concerning my code / test, it should not matter, which kind of distribution is underlying (or how “skew” it is) - as long as it is the very same for the test branches of all tested algorithms - or in other terms: as long as the mean offsets do not differ too much.

as well as

@Blackward

But please note, that I do not agree with your assumption, that the minimal execution time is the better statistics in our case.

Your assumption might be a good one, if you are talking about algorithms with a fixed execution time. In our case, the execution time depends on the number of iterations / recursions necessary for the algorithms to find each result. It obviously varies heavily with the random float given to the function as the parameter.

It is similar with your timeit approach. If you use timeit, you determine the execution time by thousands of test runs WITH THE SAME PARAMETER, means: with the same number of iterations / recursions. The belonging statement then is, ummm, let’s say, a little limited…

You instead say

@steven.daprano

I think you may need to test your code a little better before
worrying about which is fastest

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:

@steven.daprano

def limit_fraction(frac, limit):
    prev = None
    while frac != prev:
        print(frac)
        prev = frac
        a = (1/frac).limit_denominator(limit)
        frac = (1/a).limit_denominator(limit)
    assert abs(frac.numerator) <= limit
    assert abs(frac.denominator) <= limit
    return frac

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

[steven.daprano]

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.