Rust: 128 bit integers preparing to be released • Hacker News Board

Re: Rust: 128 bit integers preparing to be released

#131

Post by pornel » Sun, Dec 04, 2016, 2:17 PM UTC

amelius wrote: post #129

pornel wrote: post #128

Earlier quoted context omitted.

It could (there are 3rd party Rust libraries for arbitrary-size integers), but Rust focuses more on low-level features. Types that have fixed size at compile time are more useful in Rust and can be optimized much better.

I didn't mean dynamically sized integers. I meant at-compile-time-arbitrarily-sized-integers ;)

Ah, in that case I suppose it's blocked by lack of type parametrization with integers: https://github.com/rust-lang/rfcs/issues/1038 https://github.com/ticki/rfcs/blob/pi-types/text/0000-pi-typ...

Re: Rust: 128 bit integers preparing to be released

#132

Post by m0th87 » Sun, Dec 04, 2016, 2:18 PM UTC

SolarNet wrote: post #118

youjiuzhifeng wrote: post #105

Earlier quoted context omitted.

However, Julia is a dynamic language and Rust is a static one.

I find your usage of the word static ambiguous. Also Julia is more static than you might expect, and besides it's still a compiled language, it just has a `dynamic` type (ala C# for example) as it's default type. It seems dynamic - like most lisps do - because it supports recompiling a function in a running session (however it doesn't change already compiled code, so not that dynamic).

Yeah, Julia and lisps demand more nuance than static or dynamic labels. This goes into the details for Julia: http://stackoverflow.com/a/28096079

Compilation strategy and code hotswapping are independent of static vs dynamic types. Java is statically typed, however its implementations support interpreted execution and code hotswapping.

Re: Rust: 128 bit integers preparing to be released

#133

Post by leereeves » Sun, Dec 04, 2016, 2:20 PM UTC

wtallis wrote: post #60

leereeves wrote: post #30

Earlier quoted context omitted.

What number in finance is bigger than 2^64?

The sum of the whole planet's annual GDPs, expressed as US dollars with a precision of cents, requires about 53 bits. Choose a smaller unit or start considering long time spans, and you can easily get uncomfortably close to overflow.

Why would you express GDPs, which are estimated to an accuracy of millions of US dollars, with a precision of US cents?

Re: Rust: 128 bit integers preparing to be released

#134

Post by halomru » Sun, Dec 04, 2016, 2:24 PM UTC

Veedrac wrote: post #107

eropple wrote: post #80

Earlier quoted context omitted.

Five hundred years and eighty-four years? Recorded human history is almost ten times that range and history to which we can get precise dates is nearly five times that range. There are financial debts being paid, today, that exist from nearly the limit of that range (Dutch debts dating from 1624) even if you left a mere quarter of it for the future. So why are you middlebrowing at this?

To be fair, you basically never need scale and precision at the same time. Debts from 400 years ago aren't known down to the nanosecond.

You usually don't need scale and precision at the same time, but a lot of algorithms get a lot simpler if you don't have to worry about rounding errors that get worse with every operation.

Floating point errors are hard to reason about and often makes equality a very fuzzy concept. If your not starved for bandwidth or memory, large fixed precision numbers are incredibly useful.

Re: Rust: 128 bit integers preparing to be released

#135

Post by Someone » Sun, Dec 04, 2016, 2:32 PM UTC

0xcde4c3db wrote: post #21

aroman wrote: post #3

What sorts of applications/domains need or benefit from having 128 bit integers?

The main operation I can think of is multiplying by a ratio without losing precision. If all your values are specified in 64-bit fixed point, a 128-bit integer type gives you something with enough bits for the intermediate product. It's not something I've really dealt with myself, but I seem to remember reading that this is really handy to have in some physics simulations and control system algorithms that do numeric…

That's less of a concern for 64-bit (even for signed arithmetic, intermediary results can be close to 1.0E19) than for the typical 16-bit values and intermediary 32-bit result that Forth was designed for.

It also is a lot less of a concern on modern systems, where floating point operations aren't much slower than integer ones.

Re: Rust: 128 bit integers preparing to be released

#136

Post by hroi » Sun, Dec 04, 2016, 2:38 PM UTC

fnj wrote: post #100

eropple wrote: post #77

Earlier quoted context omitted.

IP addresses are used like integers all the time. Ask your friendly neighborhood sysadmin how a network mask works. (Maybe you want to foreach over an array every time you want to apply one. I'd rather not.)

Not really. They are never added, subtracted, multiplied, or divided. They are never compared for greater-than or less-than. Possibly they are compared for equality. About the only mathematical operations I can think of which are ever done to them are bitwise-anding, bitwise-inclusive-oring, and testing for zero (and, as mentioned, equality).

What is your point? u32/u128 are not mathematical integers. They are actually bit strings, just like IP addresses and unlike mathematical integers.

Re: Rust: 128 bit integers preparing to be released

#137

Post by Ericson2314 » Sun, Dec 04, 2016, 2:45 PM UTC

aroman wrote: post #3

What sorts of applications/domains need or benefit from having 128 bit integers?

128-bit atomics for small structs—very convenient

Re: Rust: 128 bit integers preparing to be released

#138

Post by Veedrac » Sun, Dec 04, 2016, 2:47 PM UTC

TillE wrote: post #130

Veedrac wrote: post #115

Earlier quoted context omitted.

It's more an argument for floating point.

Floating point is awful if you care about precision.

What scenario would you need more than 53 bits of precision in a time variable for? Even eropple's somewhat excessive subsecond-accurate timing for an event several hundred years ago has plenty of room to spare with 53 bits.

Re: Rust: 128 bit integers preparing to be released

#139

Post by Ericson2314 » Sun, Dec 04, 2016, 2:48 PM UTC

hroi wrote: post #136

fnj wrote: post #100

Earlier quoted context omitted.

Not really. They are never added, subtracted, multiplied, or divided. They are never compared for greater-than or less-than. Possibly they are compared for equality. About the only mathematical operations I can think of which are ever done to them are bitwise-anding, bitwise-inclusive-oring, and testing for zero (and, as mentioned, equality).

What is your point? u32/u128 are not mathematical integers. They are actually bit strings, just like IP addresses and unlike mathematical integers.

They are mathematical cyclic groups!

Re: Rust: 128 bit integers preparing to be released

#140

Post by Veedrac » Sun, Dec 04, 2016, 2:50 PM UTC

halomru wrote: post #134

Veedrac wrote: post #107

Earlier quoted context omitted.

To be fair, you basically never need scale and precision at the same time. Debts from 400 years ago aren't known down to the nanosecond.

You usually don't need scale and precision at the same time, but a lot of algorithms get a lot simpler if you don't have to worry about rounding errors that get worse with every operation. Floating point errors are hard to reason about and often makes equality a very fuzzy concept. If your not starved for bandwidth or memory, large fixed precision numbers are incredibly useful.

Although a large, fixed precision type is probably an easier default, in practice a floating point variable will work at least as well as a 53 bit fixed integer scaled to the range you're interested in. Inexactness through rounding isn't a big deal, because you rarely care about exact equality for inexact measures like time.