91–100 of 173 posts
A fun rule of thumb is that 1 decimal digit is roughly 3 binary digits (because 2^3 is eight, which is almost ten.)
That's terribly far off. On the other hand, 2^10 and 10^3 are reasonably close at 1024 and 1000. That's good enough for many things. But it's also the difference between a Kibibyte and a Kilobyte, and so forth.
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…
The good thing about Rust is that you actively have to circumvent the languages safety checks with unsafe code to run into those problems.
And if you are using unsafe code, you should be aware of such low level considerations anyway, and would refrain from using types when not appropriate.
The consistency problems you describe apply to any datastructure after all.
A fun rule of thumb is that 1 decimal digit is roughly 3 binary digits (because 2^3 is eight, which is almost ten.)
Perhaps a stupid question, but can't this be generalized to arbitrary size integers?
The only language I've seen where this is possible is Julia (which uses LLVM too).
Earlier quoted context omitted.
Neither one is used like an integer though. As in, you don't really add GUIDs together¹, so there's no real benefit over a byte array or struct. 1. I guess having bit mask operations for IPv6 addresses could be useful.
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.)
In my world integer is a mathematical construct with no particular representation, making things like bitmasks and or shifts nonsensical.
If you really want to work with fixed length bitstrings why not just have a type for that? Operating on a string of 128-bits should be valid on all such bitstrings no matter wether those represent a number or a string of code points.
And equally operations on integers should not care about particular bitstrings representations of the number in question.
What sorts of applications/domains need or benefit from having 128 bit integers?
But I don't think rust has support for the Emotion Engine in any case.
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.
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.)
I realize integer has rather specific meaning in this context. But really, your comment just highlights the issue. In my world integer is a mathematical construct with no particular representation, making things like bitmasks and or shifts nonsensical. If you really want to work with fixed length bitstrings why not just have a type for that? Operating on a string of 128-bits should be valid on all such bitstrings no…
Your world doesn't map to the reality of silicon and registers, whereas Rust does. As it happens, you can be fixed much more easily than the whole of modern computing.
> If you really want to work with fixed length bitstrings why not just have a type for that?
I don't. I want to work with integers. An IPv6 address is not the hex format that you read--it is a 128-bit integer. You can go read RFC 2460 if you don't believe me, but it's true. It is an integer that I can add and subtract from; I don't add 1 to an octet of an IP address and then do a bunch of carries if I want the next IP address in my network, I add 1 to the IP address. I don't perform some magic operation to determine what a subnet looks like, I bitand the integer. They are inescapably based on the representation used both by my computer and by my network hardware. (As is the performance of both my network hardware and yours. There's a reason that your router doesn't use BCD or whatever.)
There are programming languages that do not represent the underlying system. They are, for the most part, bad at dealing with the kinds of problems Rust is tailored to effectively represent. You can use those. It's pretty presumptuous to suggest that languages designed for lower-level problems accommodate your peculiarity.
Earlier quoted context omitted.
Neither one is used like an integer though. As in, you don't really add GUIDs together¹, so there's no real benefit over a byte array or struct. 1. I guess having bit mask operations for IPv6 addresses could be useful.
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.)
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).