Thanks, I noticed that mistake in the example tests but forgot to fix it in the description.

Fixed

This is not OK anymore (on my part)
I'll check it

im sorry about this, my tests does not dump additional information yet, i'll fix this soon.

update: now you should be able to see exactly what went wrong.

Going to change it into a string once I have some spare time.

Rounding is one thing, but the place where potential problems are introcuded are calls to str(d). Stringification of doubles works in Python in a very specific way, and str does a lot of magic trying to come up with a very specific representation. This behavior is not inherent for IEEE-754 floats in general, and is not portable between languages (i.e. is not easily translatable). Without additional specification, users do not know that the reference solution uses str(d), and they do not know how to handle precision in a way considered correct by the tests.

The point is that there is no way of handling precision of floats, and representation of floats, which is considered "canonical". You made an assumption that the correct way is to use str(d) and rounding, but it is just one of possible assumptions, which is not universal. Without knowing this, users are missing some information necessary to come up with a correct solution.

Like natan said in the post above, float is not the best type to represent input for this problem. Something what represents "a sequence of digits" would be much better.

@PurrBunny

float does not represent decimal numbers. when you choose a type, make sure that it can encode the information you mean to convey.

if you consider it to be text, something you can write down, then the type for that is string.

some languages have a type to represent decimal numbers, that would kind of work, in that it's able to encode your values. however, what you're really conveying is the abbreviated number, not the number - so it probably shouldn't be a number type at all

if it is not text, but rather "many digits", then that's a list of integers

I have a workable solution by rounding everything. It is not theoretically 100% perfect, however practically there are no errors.

Its impossible to fix this issue and keep using floats. As long as floats are anywhere there, in solution or in tests, this challenge will be incorrect.

Fixed!!

I think this is due to floating point shenanigans. I am looking into fixing this.

right and what about:
test.assert_equals(makeFraction(.27351), (183370381288423, 670427215036416))

why isn't answer (3039, 11111) ?

Fixed, reference solution now uses integer division

fixed everything try now

i think all issues is fixed now, try again