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

Rust: 128 bit integers preparing to be released

github.com

Post reply on HN
Print view View original

101–110 of 173 posts

Re: Rust: 128 bit integers preparing to be released

#101

Post by eropple »

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

Yes, really. I mean, I add to IP addresses regularly. How else do you enumerate a subnet (like, what do you think nmap does)? How else do you place, say, twelve machines at 172.17.0.120 through .131? If you're doing string concatenation, you are screwing up. Perhaps it's not enough of a screwup to impact what you do--but definitely wrong enough to impact what I do unless I were to do a lot of extra work in modeling an IP address just for the sake of somebody else's spherical cow of uniform density. (And I do mean work I'd have to do--the lack of a decent IP addressing library on the JVM is a recurring pain in my ass, but since they're just integers...)

If you have internalized an IP address as a dotted set of octets expressed in ASCII digits, that's a problem of comprehension. When you don't, it's pretty natural to just use this stuff like any other integer.

Re: Rust: 128 bit integers preparing to be released

#102

Post by fnj »

calanya wrote: post #85
aroman wrote: post #3

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

Measuring time in picoseconds. The current unix timestamp is roughly 2^70 picoseconds, so won't fit in 64 bits.

Can you present any imaginable situation where resolution of arbitrary time/dates to a billionth of a second is not adequate?

Re: Rust: 128 bit integers preparing to be released

#103

Post by stjepang »

chrisseaton wrote: post #98
dbaupp wrote: post #51

Earlier quoted context omitted.

One of Rust's strongest features is its ability to outlaw data races. In this case, the 128-bit types only provide mutations that take &mut self, that is, a unique unaliased pointer, meaning there's no way to concurrently mutate and hence they are automatically atomic, in a sense.

Does Rust run a memory barrier when ownership is transferred? How does it ensure that the previous owner has finished all its writes when a new owner take over?

To transfer ownership, you would wrap the object in Mutex, send it via Sender, use some other synchronization primitive, or simply pass it over at the moment the thread is spawned.

It's up to the synchronization primitives to ensure memory barriers are executed, not the language. So e.g. a Mutex would execute a memory barrier when locking and unlocking. Rust then allows you to pass ownership in a trusted manner only, i.e. through those primitives.

Of course, you can also create an unsafe block and say: "Rust, trust me, I know what I'm doing, don't bother me, and these are the invariants I want you to enforce in safe code..." Mutexes are implemented this way.

Re: Rust: 128 bit integers preparing to be released

#104

Post by pettou »

steveklabnik wrote: post #23
searealist wrote: post #20

Why was this feature accepted whereas 128 bit floats were removed from Rust?

128 bit floats were removed years ago (June of 2014), here's the meeting notes from the time: https://github.com/rust-lang/meeting-minutes/blob/master/wee... (as with all old Rust stuff, please remember that details very much might have changed between then and now.) In other words, they weren't removed because we fundamentally didn't want them. They were removed because of maintainability, usability, and usefulness…

When you say "details very much might have changed between then and now", are there any news on bringing in the float128 type? I mean, do you happen to know whether there is any reasonable chance of having it in Rust at all?

Re: Rust: 128 bit integers preparing to be released

#105

Post by youjiuzhifeng »

the_duke wrote: post #94
amelius wrote: post #88

Perhaps a stupid question, but can't this be generalized to arbitrary size integers?

LLVM supports arbitrarily sized integer types, but sadly it's not exposed in Rust. The only language I've seen where this is possible is Julia (which uses LLVM too).

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

Re: Rust: 128 bit integers preparing to be released

#106

Post by dardie »

chrisseaton wrote: post #98
dbaupp wrote: post #51

Earlier quoted context omitted.

One of Rust's strongest features is its ability to outlaw data races. In this case, the 128-bit types only provide mutations that take &mut self, that is, a unique unaliased pointer, meaning there's no way to concurrently mutate and hence they are automatically atomic, in a sense.

Does Rust run a memory barrier when ownership is transferred? How does it ensure that the previous owner has finished all its writes when a new owner take over?

It's built into the type system and checked statically at compile time. In rust, there can only be one 'owner' of a stored value. Ownership can be transferred, borrowed by multiple readers, or borrowed by a single writer. This ensures (at compile time) that there at any given time there is only ever one single writer OR multiple readers. Rust programs are guaranteed to be free of race conditions at compile-time. The above covers the vast majority of situations, but for cases where this is too restrictive their are other language constructs such as reference-counted types.

Re: Rust: 128 bit integers preparing to be released

#107

Post by Veedrac »

eropple wrote: post #80
kevhito wrote: post #48

Earlier quoted context omitted.

Oh, just found this: > The Duration type could be simplified with this: instead of using a u64 for seconds with a seperate u32 for nanoseconds, it could just be a single u128/i128 count of nanoseconds. Of course, just a single u64 at ns precision would get you 500+ years of range. But ok.

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.

Re: Rust: 128 bit integers preparing to be released

#109

Post by astrobe_ »

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…

Or more generally fixed point with big numbers and lots of decimals.

Re: Rust: 128 bit integers preparing to be released

#110

Post by eropple »

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.

I can think of astronomical measures from a couple hundred years ago that are at least second-accurate. Do you want to have DurationSecondsOnly and Duration as types? =)
Post reply on HN