5 ms·

Meh I use C# and I rarely need an int bigger than 2147483647, and if I do I use a long which gets me up to 9223372036854775807, and if I need more than THAT the

Meh I use C# and I rarely need an int bigger than 2147483647, and if I do I use a long which gets me up to 9223372036854775807, and if I need more than THAT then I'll use a math library of some sort.

deleted 8y ago
[deleted]
adtac 8y ago
The problem with overflow isn't just needing to store numbers larger than 2 billion. Sometimes, intermediate values are larger than that even if the final result isn't. Take averaging as a very simple example. Doing (a + b) / 2 will overflow if a and b are sufficiently large, even if the average will always fit in 32 bits. Things like this go unseen for years.
- dekhn 8y ago
  don't most people compute the mean iteratively when they need to do this? Sure, it goes unseen, but programmers on systems like this are expected to understand the math model and write tests.
  - xapata 8y ago
    Systems like what? My expectation is no, most people make mistakes.
    - dekhn 8y ago
      I mean, in C and other low-level languages unlike python, it's generally assumed you have a basic understanding of the machine model and the consequences of arithmetic in limited types. If most people make mistakes, they should self-select to languages which have properties that protect them from their ignorance. for example, I mostly program in Python using longs so I don't have to worry about overflow.
      - xapata 8y ago
        What kind of "long" are you referring to? Most programmers would think of a C long, int64, not a Python long, bigint. Maybe people ought to self-select, but that would mean they'd need the training or experience to recognize what they don't know. It's often the most ignorant people that believe they have the most expertise.
- quickthrower2 8y ago
  I get you point. I'd probably go float/double precision for that task.
  - pvg 8y ago
    Then you can lose precision that you might actually need - a bug that's even more annoying to track down than straight overflow.
    - quickthrower2 8y ago
      Yes indeed! But what is the alternative, especially if you are using approximations to transcendental constants?
paulddraper 8y ago
There have been 1,543,530,695,158 milliseconds since epoch.
- quickthrower2 8y ago
  That would fit into a spacious Int64. I typically wouldn't be passing around milliseconds since epoch as an raw number, but then that's C#, I guess you might do that in other languages for performance or out of necessity.
joppy 8y ago
I think the question though is that if “int” were an actual integer, would you still default to using int32/int64, and for what reason? There are valid uses for fixed-width types, but beyond domain-specific number crunching (crypto, image processing, etc) I would argue that the use of these types is technically incorrect, and not what people expect. Even experienced programmers will see “x > x + 1” and mentally replace that with “true”, even though if x is fixed-width, the value of that expression actually depends on x.

Meh I use C# and I rarely need an int bigger than 2147483647, and if I do I use a long which gets me up to 9223372036854775807, and if I need more than THAT then I'll use a math library of some sort.

deleted 8y ago

[deleted]

adtac 8y ago

The problem with overflow isn't just needing to store numbers larger than 2 billion. Sometimes, intermediate values are larger than that even if the final result isn't. Take averaging as a very simple example. Doing (a + b) / 2 will overflow if a and b are sufficiently large, even if the average will always fit in 32 bits. Things like this go unseen for years.

dekhn 8y ago
don't most people compute the mean iteratively when they need to do this? Sure, it goes unseen, but programmers on systems like this are expected to understand the math model and write tests.
- xapata 8y ago
  Systems like what? My expectation is no, most people make mistakes.
  - dekhn 8y ago
    I mean, in C and other low-level languages unlike python, it's generally assumed you have a basic understanding of the machine model and the consequences of arithmetic in limited types. If most people make mistakes, they should self-select to languages which have properties that protect them from their ignorance. for example, I mostly program in Python using longs so I don't have to worry about overflow.
    - xapata 8y ago
      What kind of "long" are you referring to? Most programmers would think of a C long, int64, not a Python long, bigint. Maybe people ought to self-select, but that would mean they'd need the training or experience to recognize what they don't know. It's often the most ignorant people that believe they have the most expertise.
quickthrower2 8y ago
I get you point. I'd probably go float/double precision for that task.
- pvg 8y ago
  Then you can lose precision that you might actually need - a bug that's even more annoying to track down than straight overflow.
  - quickthrower2 8y ago
    Yes indeed! But what is the alternative, especially if you are using approximations to transcendental constants?

paulddraper 8y ago

There have been 1,543,530,695,158 milliseconds since epoch.

quickthrower2 8y ago
That would fit into a spacious Int64. I typically wouldn't be passing around milliseconds since epoch as an raw number, but then that's C#, I guess you might do that in other languages for performance or out of necessity.

joppy 8y ago

I think the question though is that if “int” were an actual integer, would you still default to using int32/int64, and for what reason? There are valid uses for fixed-width types, but beyond domain-specific number crunching (crypto, image processing, etc) I would argue that the use of these types is technically incorrect, and not what people expect. Even experienced programmers will see “x > x + 1” and mentally replace that with “true”, even though if x is fixed-width, the value of that expression actually depends on x.