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

81–90 of 173 posts

Re: Rust: 128 bit integers preparing to be released

#81

Post by daenney »

LeonidBugaev wrote: post #66
barsonme wrote: post #50

Earlier quoted context omitted.

So does Go, so a net.IP could be [16]byte or [4]byte, but I'm sure you can see the obvious problems that might occur there (with having two separate IP types). Most UUID libraries I've seen and written use [16]byte as the concrete UUID type.

If you are using default library IPv4 addresses stores as [16]byte: https://golang.org/src/net/ip.go

I don't think that's what the Godoc says. The IP type is defined as []byte

  type IP []byte
That is not the same as [16]byte.

  // Note that in this documentation, referring to an
  // IP address as an IPv4 address or an IPv6 address
  // is a semantic property of the address, not just the
  // length of the byte slice: a 16-byte slice can still
  // be an IPv4 address.
What I believe that comment is saying is that something that is [16]byte can still be an IPv4 address, but that doesn't mean that all IPv4 addresses are stored as [16]byte. At least that would be my interpretation based on the comment above it:

  // An IP is a single IP address, a slice of bytes.
  // Functions in this package accept either 4-byte (IPv4)
  // or 16-byte (IPv6) slices as input.

Re: Rust: 128 bit integers preparing to be released

#82

Post by fulafel »

kevhito wrote: post #39
steveklabnik wrote: post #23

Earlier quoted context omitted.

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…

I wasn't able to find any real justification beyond (a) one vague mention of "some algorithms... such as certain cryptographic algorithms" and (b) the fact that clang supports it. Can you point to something more specific? Justification (b) in particular smells bad to me.

The x86-64 64x64->128 instructions.

Re: Rust: 128 bit integers preparing to be released

#83

Post by Manishearth »

drfuchs wrote: post #75
the_duke wrote: post #71

Earlier quoted context omitted.

I what drfuchs might be getting at is that 128bit integers would need two registers on a 64bit architecture. Or four on a 32 bit one. LLVM supports arbitrary length integer types, regardless of the platform. Rust already has u64 and i64 on 32bit architectures. But even if something fits in one register, a variable isn't thread safe anyway. Rust DOES NOT allow a mutable reference to exist simultaneously with non-mutab…

Thanks, but to be even more explicit, I'm thinking of a lower level than thread safety and the nice atomic references Rust provides in "safe" code: Consider a systems-y program that handles signals, or even hardware interrupts, or mmaps a chunk of shared memory. Any Read of a 32-bit variable will produce a value that was Written previously, no matter what; the hardware guarantees it. But a Read of a 128-bit variable…

All the Rust OSes written right now use pretty tightly scoped unsafe code. The OS isn't just unsafe-blocks-everywhere.

The compiler would force you to use an atomic. Once you realize no AtomicUint128 atomic exists, you may try to explicitly use unsafe to make things work, but even then that requires a lot more explicitness than just an unsafe block. You will realize your mistake some point here.

Unsafe in Rust doesn't just turn off all the checks. It gives you the power to circumvent the checks, but these circumventions are still individually explicit.

Anyway, u128 doesn't worsen this situation. You could already make thread safety mistakes with wider value types if you really really wanted to, just like u128.

Re: Rust: 128 bit integers preparing to be released

#84

Post by lifthrasiir »

kevhito wrote: post #48
kevhito wrote: post #39

Earlier quoted context omitted.

I wasn't able to find any real justification beyond (a) one vague mention of "some algorithms... such as certain cryptographic algorithms" and (b) the fact that clang supports it. Can you point to something more specific? Justification (b) in particular smells bad to me.

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.

It is closely related to "native" time representation, where you can frequently have u64 seconds in the API. Being able to represent them without a trap would be beneficial.

Re: Rust: 128 bit integers preparing to be released

#86

Post by wott »

leereeves wrote: post #30
gravypod wrote: post #13

Earlier quoted context omitted.

For finance probably but it's mostly useful for statistics from what I understand. I know fortran and Cobol code that banks use and is used for science (tm) often defines numbers this large for certain operations. One such i can think of is a map reduce of large datasets. Let's say you want to find as a result a huge sum. 2^128 is a bit bigger then 2^64 and that difference may be big enough to provide the computation…

What number in finance is bigger than 2^64?

Riches are getting richer.

Re: Rust: 128 bit integers preparing to be released

#87

Post by Senji »

Manishearth wrote: post #83
drfuchs wrote: post #75

Earlier quoted context omitted.

Thanks, but to be even more explicit, I'm thinking of a lower level than thread safety and the nice atomic references Rust provides in "safe" code: Consider a systems-y program that handles signals, or even hardware interrupts, or mmaps a chunk of shared memory. Any Read of a 32-bit variable will produce a value that was Written previously, no matter what; the hardware guarantees it. But a Read of a 128-bit variable…

All the Rust OSes written right now use pretty tightly scoped unsafe code. The OS isn't just unsafe-blocks-everywhere. The compiler would force you to use an atomic. Once you realize no AtomicUint128 atomic exists, you may try to explicitly use unsafe to make things work, but even then that requires a lot more explicitness than just an unsafe block. You will realize your mistake some point here. Unsafe in Rust doesn'…

What stops you from manually entering a critical region yourself before you do the assignment?

Re: Rust: 128 bit integers preparing to be released

#89

Post by petters »

frozenport wrote: post #34
searealist wrote: post #20

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

As a side note, what are some use cases for 128 floats?

Some numerically unstable problem require a lot of precision of solve successfully. Similarily, well-behaved problems can be solve with 32-bit floats, but many require 64-bit floats.

Re: Rust: 128 bit integers preparing to be released

#90

Post by Keyframe »

foota wrote: post #25
gravypod wrote: post #13

Earlier quoted context omitted.

For finance probably but it's mostly useful for statistics from what I understand. I know fortran and Cobol code that banks use and is used for science (tm) often defines numbers this large for certain operations. One such i can think of is a map reduce of large datasets. Let's say you want to find as a result a huge sum. 2^128 is a bit bigger then 2^64 and that difference may be big enough to provide the computation…

Fun fact: there are ~2^50 millimetres from here to mars

128i[3] would be enough for 390x observable universe discrete grid in Euclidean space with nanometer precision. Or 0.39 observable universe with picometer resolution.
Post reply on HN