121–130 of 173 posts
Earlier quoted context omitted.
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.
What sorts of applications/domains need or benefit from having 128 bit integers?
At least on x86-64, the 64x64->128 bit multiplication is a single instruction, like the 32x32->64 bit and the 16x16->32 bit multiplications. Doing the calculation with only three limbs is clearly faster than doing it with five limbs; to start with, using 3 limbs you need 9 multiplies, while with 5 limbs you have to do 25 multiplies. The carry propagation and reduction steps also take time proportional to the number of limbs.
Earlier quoted context omitted.
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…
Right - I get that the compiler ensures it is only accessed by one thread at a time. But what I was asking was at runtime, when ownership transfers how does Rust ensure that writes to the value by the previous owner appear to the new owner before the transfer of ownership appears to the new owner? You can statically guarantee that only one thread owns the object, but you can't statically guarantee the order in which…
To add to/clarify this: I don't think you can transfer an object to another thread in safe Rust code without a primitive that will handle the barriers for you. Static ownership tracing doesn't actually know what threads are, because it doesn't even need to.
Earlier quoted context omitted.
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 a…
You're not adding addresses together, that doesn't make sense. You're adding ints to addresses, it's a completely different property, even if the representation happens to fit into the same amount of bits. Nothing more than a convenient coincidence.
It's like saying a pointer to RAM isn't an integer. Of course it is, and you add to them every time you de-reference an array in C. That it has additional semantic meaning doesn't mean it stops being a integer. The pedantry you're peddling doesn't fly.
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).
if ip >= IP(10.34.12.3) && ip if abs(atk1.ip - atk2.ip) Sweet! IPv6 perfection. besides GPUs, does anyone have experience with any processors that support 128 natively?
Perhaps a stupid question, but can't this be generalized to arbitrary size integers?
Types that have fixed size at compile time are more useful in Rust and can be optimized much better.
Perhaps a stupid question, but can't this be generalized to arbitrary size integers?
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.
Earlier quoted context omitted.
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? =)
It's more an argument for floating point.