Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Python rounds float values by converting them to string and then back

github.com

Post reply on HN
Print view View original

81–90 of 152 posts

Re: Python rounds float values by converting them to string and then back

#81

Post by ben509 »

ben509 wrote: post #19
Jenz wrote: post #3

I dunno, how efficient is this?

Compared to base=10^places, multiply, truncate, divide? Horriby inefficient.

It's slower than native python.

    %timeit round(12335423552.33, -6)
    %timeit int(12335423552.33 / 1_000_000.0) * 1_000_000.0
    500 ns ± 3.88 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each)
    219 ns ± 1.1 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each)

Re: Python rounds float values by converting them to string and then back

#82

Post by tehlike »

benj111 wrote: post #45
fs111 wrote: post #6

Apples libc used to shell-out to perl in a function: https://github.com/Apple-FOSS-Mirror/Libc/blob/2ca2ae7464771...

Which raises the question what libc functions perl calls... And imagine the debug errors: >perl error X "But I'm just calling libc ?!?"

Or unintended stackoverflows.

Re: Python rounds float values by converting them to string and then back

#83

Post by messe »

bhouston wrote: post #35

In my experience there are few things slower that float to string and string to float. And it seems so unnecessary. I always implemented round to a specific digit based on the built-in roundss/roundsd functions which are native x86-64 assembler instructions (i.e. https://www.felixcloutier.com/x86/roundsd ). I do not understand why this would not be preferable to the string method. float round( float x, int digits, in…

Using native x86_64 instructions isn't portable.

Re: Python rounds float values by converting them to string and then back

#84

Post by ben509 »

dagw wrote: post #31
ben509 wrote: post #19

Earlier quoted context omitted.

Compared to base=10^places, multiply, truncate, divide? Horriby inefficient.

Sure, but their approach is on the other hand more correct. All numerical code reaches a point where you have to balance performance vs. correctness, and here cpython has chosen correctness over speed.

They're creating a sequence of digits and then truncating. If you want to replicate that precisely, you could use an accumulator and a loop to do the same thing. At least then you could break early.

Re: Python rounds float values by converting them to string and then back

#85

Post by jharger »

messe wrote: post #83
bhouston wrote: post #35

In my experience there are few things slower that float to string and string to float. And it seems so unnecessary. I always implemented round to a specific digit based on the built-in roundss/roundsd functions which are native x86-64 assembler instructions (i.e. https://www.felixcloutier.com/x86/roundsd ). I do not understand why this would not be preferable to the string method. float round( float x, int digits, in…

Using native x86_64 instructions isn't portable.

Why not have optimized versions that use native instructions when available, and then fall back to the portable version when they are not?

Re: Python rounds float values by converting them to string and then back

#86

Post by dagw »

ben509 wrote: post #81
ben509 wrote: post #19

Earlier quoted context omitted.

Compared to base=10^places, multiply, truncate, divide? Horriby inefficient.

It's slower than native python. %timeit round(12335423552.33, -6) %timeit int(12335423552.33 / 1_000_000.0) * 1_000_000.0 500 ns ± 3.88 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each) 219 ns ± 1.1 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each)

Well obviously the approach round() takes is slower than the naive approach. The whole point of doing it the way round() does it is that it gives the correct answer in cases where the naive approach fails.

Re: Python rounds float values by converting them to string and then back

#87

Post by tyingq »

Dylan16807 wrote: post #34
tyingq wrote: post #22

Earlier quoted context omitted.

It seems to just be layman shorthand for storing (not huge) integers as binary isn't lossy.

Storing integers as decimal (which computers can do easily) isn't lossy either.

I meant as opposed to floats, precision loss, etc.

Re: Python rounds float values by converting them to string and then back

#88

Post by lathiat »

ImNotTheNSA wrote: post #80
peterwwillis wrote: post #72

Earlier quoted context omitted.

What if Perl uses libc ?????

then it calls the Perl implementation... is there some nuance of perl that would cause a problem with that?

So if Perl uses libc, which shells put to perl, which uses libc... get it? :)

Re: Python rounds float values by converting them to string and then back

#89

Post by zerocrates »

ImNotTheNSA wrote: post #80
peterwwillis wrote: post #72

Earlier quoted context omitted.

What if Perl uses libc ?????

then it calls the Perl implementation... is there some nuance of perl that would cause a problem with that?

They're jokingly positing a loop: libc shells to perl, perl implements the function via libc call, which shells to perl... and so on.

Re: Python rounds float values by converting them to string and then back

#90

Post by bloomer »

xamuel wrote: post #66
CogitoCogito wrote: post #20

Earlier quoted context omitted.

> I don't know that it is "wrong", just unexpected. I suspect most people expect all math functions to be purely implemented in numerical terms, so finding string manipulation is surprising/interesting. You kind of got me thinking now. The decimal representation of a number is really a string representation (in the sense of a certain sequence of characters). Hence rounding to a certain decimal is essentially a string…

>The decimal representation of a number is really a string representation It is incorrect to speak of "the" decimal representation of a number, as many numbers have non-unique decimal representations, the most famous example being 1.000...=0.999...

The definition that makes it unique is the shortest representation where trailing zeros are bout included. In your example that would be 1 note that this definition comes up in binary floating point where there are infinite decimal representations that will round back to a given binary64 float but the decimal representation chosen is the shortest (and closest to the binary64 float in the case of ties for length).
Post reply on HN