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

Re: Rust: 128 bit integers preparing to be released

#61

Post by barsonme » Sun, Dec 04, 2016, 7:24 AM UTC

dbaupp wrote: post #52

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.

I don't see the obvious problem (fwiw, I really dislike such rhetorical devices): presumably net.IP could a struct that contains a [16]byte and an isV4 flag.

The problem is [16]byte would always be wasting 12 bytes for IPv4 addresses if you only used one type for both. So, two types must be made which requires extra code and doesn't allow for == comparison which is what OP (GP? whomever...) was complaining about not being able to do since net.IP is []byte.

Sorry for the rhetorical device.

Re: Rust: 128 bit integers preparing to be released

#62

Post by spladug » Sun, Dec 04, 2016, 7:32 AM UTC

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

There are? It looks closer to 2^14. 2^50mm is around 7.5 au. Sorry to nitpick, but I thought this was a super interesting point!

Re: Rust: 128 bit integers preparing to be released

#63

Post by ant6n » Sun, Dec 04, 2016, 7:48 AM UTC

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?

how about bit look up tables.

Re: Rust: 128 bit integers preparing to be released

#64

Post by Dylan16807 » Sun, Dec 04, 2016, 7:59 AM UTC

spladug wrote: post #62

foota wrote: post #25

Earlier quoted context omitted.

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

There are? It looks closer to 2^14. 2^50mm is around 7.5 au. Sorry to nitpick, but I thought this was a super interesting point!

I assume you meant to type 47 rather than 14?

Re: Rust: 128 bit integers preparing to be released

#65

Post by badminton1 » Sun, Dec 04, 2016, 8:02 AM UTC

If you like this subject take a look at gmplib (gnu multiple precision big number library)

Re: Rust: 128 bit integers preparing to be released

#66

Post by LeonidBugaev » Sun, Dec 04, 2016, 8:06 AM UTC

barsonme wrote: post #50

dbaupp wrote: post #37

Earlier quoted context omitted.

Rust offers non-allocating fixed-sized arrays, so a GUID could be a (wrapper around) [u8; 16] and an IPv6 address could be [u16; 8].

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

Re: Rust: 128 bit integers preparing to be released

#67

Post by foota » Sun, Dec 04, 2016, 8:17 AM UTC

spladug wrote: post #62

foota wrote: post #25

Earlier quoted context omitted.

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

There are? It looks closer to 2^14. 2^50mm is around 7.5 au. Sorry to nitpick, but I thought this was a super interesting point!

I rounded a bit over-zealously, thanks for nit picking. It is indeed 2^47.6333. (also assuming you meant 47 not 14.)

Re: Rust: 128 bit integers preparing to be released

#68

Post by [deleted] » Sun, Dec 04, 2016, 8:22 AM UTC

dbaupp wrote: post #51

drfuchs wrote: post #45

Earlier quoted context omitted.

The RFC doesn't seem to mention anything about the atomicity (or lack thereof) of loads and stores of variables of the 128-bit types. From the discussion, it seems that on a number of current architectures, they're not going to be atomic. Does this cause any problems in the Rust view of the world? Will there be unanticipated issues for developers who have been getting along just fine so far unknowingly assuming that…

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.

[deleted]

Re: Rust: 128 bit integers preparing to be released

#69

Post by foota » Sun, Dec 04, 2016, 8:27 AM UTC

A fun rule of thumb is that 1 decimal digit is roughly 3 binary digits (because 2^3 is eight, which is almost ten.)

Re: Rust: 128 bit integers preparing to be released

#70

Post by drfuchs » Sun, Dec 04, 2016, 8:34 AM UTC

aroman wrote: post #3

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

Implementing cryptographic hash functions like SHA-3 (see the original Kaccek paper for specific results under various 32-bit, 64-bit, and 128-bit native integer hardware support). And implementing other, faster but non-cryptographic hash functions like Spooky, etc.