4 ms·

> any reasonable programmer FTFY

Joker_vD 4y ago
No, it's exactly an unreasonable programmer who'd expect that, being conditioned to such ridiculous extravagancies by an inadequate language, which was the point of my another comment in this thread. Multiplication of intX_t by intX_t should produce int2X_t which is btw is what actually happens in hardware! And detection of overflow of addition/multiplication in a sane language should not require ridiculous algebraic acrobatics that involve additional additions/multiplications (or a division, yeah, I've seen that too).
- Koshkin 4y ago
  But in a (typed) language, types are constraints that must be respected (regardless of what hardware does), and integer precision (as specified in code) is one of them.
  - Joker_vD 4y ago
    Sorry, what does "respect" means? Ruby and Pascal have division operator that takes two integers and returns a real — is this disrespectful? Is it disrespectful for multiplication to have signature template<size_t N> operator*(int<N>, int<N>) -> int<2*N> instead of template<size_t N> operator*(int<N>, int<N>) -> int<min(numeric_limits<int>::width, N)> ? Why or why not?
    - Koshkin 4y ago
      Types exist for a reason, and one is the desire for consistency (or uniformity) of representation: say, I want to be able to store the result of an operation in the storage element which looks the same as those where the operands came from (think of an array, for example).
      - naniwaduni 4y ago
        int-n * int-n -> int-n (n > 1) is fundamentally the wrong type logically for a multiplication, though, so something has to give. Sure, some languages have chosen for the arithmetic to be broken in order to maintain type, but that's certainly not clearly the right choice when others have chosen auto-promotion and most hardware has chosen a (limited selection of) int-n * int-n -> int-2n multiplication primitives to work with.
        Koshkin 4y ago
        The rule int<N> * int<N> —> int<2*N> breaks one of important expectations from a type, which is the property on being “closed” with respect to certain operations. Even if an arithmetical operation increases the length of the result, it has to stop somewhere, so there’s little justification for such increase in the first place, if one is to be logical about this.
        naniwaduni 4y ago
        Nobody expects subtraction to be closed on the naturals, nor division on the integers. Why would be expect multiplication defined to be closed over fixed-width integers to coincide with the general arithmetic operation?
        Koshkin 4y ago
        Well, by your definition even division of reals is not closed - which means that your definition is not a correct one. A closed operation is allowed to have an "undefined" result. (And, by the way, division of integers is perfectly closed, if you ignore the remainder.)
        deleted 4y ago
        [deleted]
        naniwaduni 4y ago
        Division on the reals is indeed is not normally considered closed. The implied closure properties you want are not customary.

No, it's exactly an unreasonable programmer who'd expect that, being conditioned to such ridiculous extravagancies by an inadequate language, which was the point of my another comment in this thread. Multiplication of intX_t by intX_t should produce int2X_t which is btw is what actually happens in hardware! And detection of overflow of addition/multiplication in a sane language should not require ridiculous algebraic acrobatics that involve additional additions/multiplications (or a division, yeah, I've seen that too).

Koshkin 4y ago
But in a (typed) language, types are constraints that must be respected (regardless of what hardware does), and integer precision (as specified in code) is one of them.
- Joker_vD 4y ago
  Sorry, what does "respect" means? Ruby and Pascal have division operator that takes two integers and returns a real — is this disrespectful? Is it disrespectful for multiplication to have signature template<size_t N> operator*(int<N>, int<N>) -> int<2*N> instead of template<size_t N> operator*(int<N>, int<N>) -> int<min(numeric_limits<int>::width, N)> ? Why or why not?
  - Koshkin 4y ago
    Types exist for a reason, and one is the desire for consistency (or uniformity) of representation: say, I want to be able to store the result of an operation in the storage element which looks the same as those where the operands came from (think of an array, for example).
    - naniwaduni 4y ago
      int-n * int-n -> int-n (n > 1) is fundamentally the wrong type logically for a multiplication, though, so something has to give. Sure, some languages have chosen for the arithmetic to be broken in order to maintain type, but that's certainly not clearly the right choice when others have chosen auto-promotion and most hardware has chosen a (limited selection of) int-n * int-n -> int-2n multiplication primitives to work with.
      - Koshkin 4y ago
        The rule int<N> * int<N> —> int<2*N> breaks one of important expectations from a type, which is the property on being “closed” with respect to certain operations. Even if an arithmetical operation increases the length of the result, it has to stop somewhere, so there’s little justification for such increase in the first place, if one is to be logical about this.
        naniwaduni 4y ago
        Nobody expects subtraction to be closed on the naturals, nor division on the integers. Why would be expect multiplication defined to be closed over fixed-width integers to coincide with the general arithmetic operation?
        Koshkin 4y ago
        Well, by your definition even division of reals is not closed - which means that your definition is not a correct one. A closed operation is allowed to have an "undefined" result. (And, by the way, division of integers is perfectly closed, if you ignore the remainder.)
        deleted 4y ago
        [deleted]
        naniwaduni 4y ago
        Division on the reals is indeed is not normally considered closed. The implied closure properties you want are not customary.