6 ms·

If zig supports + for floating point addition, then it is already fine with ‘+’ being non commutative. The rest of the argument can also be applied to functions

If zig supports + for floating point addition, then it is already fine with ‘+’ being non commutative. The rest of the argument can also be applied to functions. What does product(a, b) do?

webstrand 5y ago
Aside from `NaN`, how is floating point addition non-commutative? It's not associative, but `a+b` will have the same value as `b+a`.
- ReleaseCandidat 5y ago
  > `a+b` will have the same value as `b+a` No, as IEEE754 doesn't even guarantee that `a + b` == `a + b`. You always need to compare the absolute difference of two values against an ε. So a == b <=> |a - b| < ε But for sensible comparison of floats, the addition is commutative.
  - zokier 5y ago
    > No, as IEEE754 doesn't even guarantee that `a + b` == `a + b` What? I'm pretty sure that is plain incorrect. Can you back that claim up with references?
    - deleted 5y ago
      [deleted]
    - futharkshill 5y ago
      Of course it is incorrect, the system is of course not stochastic, not even floating points.
      - c-cube 5y ago
        What if a is nan? You don't have that nan == nan...
    - anonymoushn 5y ago
      Floating point addition is not commutative if you're adding negative zero to positive zero, but you won't be able to check that with `a + b == a + b`
    - ReleaseCandidat 5y ago
      The rounding can depend 'where' (e.g. the width of the register) the float is stored in the CPU ('destination' in IEEE 754 speak). So, if you compare the result stored in two different 'destinations' (because one has been computed in another register or at a GPU or ....), they can differ even in the same program with the same optimizations. See for example: int main() { double q; q = 3.0/7.0; if (q == 3.0/7.0) printf("Equal\n"); else printf("Not Equal\n"); return 0; } On an extended-based system, even though the expression 3.0/7.0 has type double, the quotient will be computed in a register in extended double format, and thus in the default mode, it will be rounded to extended double precision. When the resulting value is assigned to the variable q, however, it may then be stored in memory, and since q is declared double, the value will be rounded to double precision. In the next line, the expression 3.0/7.0 may again be evaluated in extended precision yielding a result that differs from the double precision value stored in q, causing the program to print "Not Equal". Of course, other outcomes are possible, too: the compiler could decide to store and thus round the value of the expression 3.0/7.0 in the second line before comparing it with q, or it could keep q in a register in extended precision without storing it. An optimizing compiler might evaluate the expression 3.0/7.0 at compile time, perhaps in double precision or perhaps in extended double precision. (With one x86 compiler, the program prints "Equal" when compiled with optimization and "Not Equal" when compiled for debugging.) Finally, some compilers for extended-based systems automatically change the rounding precision mode to cause operations producing results in registers to round those results to single or double precision, albeit possibly with a wider range. Thus, on these systems, we can't predict the behavior of the program simply by reading its source code and applying a basic understanding of IEEE 754 arithmetic. The relevant conclusion: Neither can we accuse the hardware or the compiler of failing to provide an IEEE 754 compliant environment; the hardware has delivered a correctly rounded result to each destination, as it is required to do, and the compiler has assigned some intermediate results to destinations that are beyond the user's control, as it is allowed to do. https://grouper.ieee.org/groups/msc/ANSI_IEEE-Std-754-2019/background/addendum.html https://grouper.ieee.org/groups/msc/ANSI_IEEE-Std-754-2019/b...
      - zokier 5y ago
- dnautics 5y ago
  i believe there are strange corner cases around x87, but that may have changed since IEE754 got revised last year
  - ReleaseCandidat 5y ago
    For example, yes.
ReleaseCandidat 5y ago
> The rest of the argument can also be apply to functions. Of course it is, but you can use other functions names than `product`. If the language doesn't let you use any other symbol for the operator but `*`, you're out of luck.

If zig supports + for floating point addition, then it is already fine with ‘+’ being non commutative. The rest of the argument can also be applied to functions. What does product(a, b) do?

webstrand 5y ago

Aside from `NaN`, how is floating point addition non-commutative? It's not associative, but `a+b` will have the same value as `b+a`.

ReleaseCandidat 5y ago
> `a+b` will have the same value as `b+a` No, as IEEE754 doesn't even guarantee that `a + b` == `a + b`. You always need to compare the absolute difference of two values against an ε. So a == b <=> |a - b| < ε But for sensible comparison of floats, the addition is commutative.
- zokier 5y ago
  > No, as IEEE754 doesn't even guarantee that `a + b` == `a + b` What? I'm pretty sure that is plain incorrect. Can you back that claim up with references?
  - deleted 5y ago
    [deleted]
  - futharkshill 5y ago
    Of course it is incorrect, the system is of course not stochastic, not even floating points.
    - c-cube 5y ago
      What if a is nan? You don't have that nan == nan...
  - anonymoushn 5y ago
    Floating point addition is not commutative if you're adding negative zero to positive zero, but you won't be able to check that with `a + b == a + b`
  - ReleaseCandidat 5y ago
    The rounding can depend 'where' (e.g. the width of the register) the float is stored in the CPU ('destination' in IEEE 754 speak). So, if you compare the result stored in two different 'destinations' (because one has been computed in another register or at a GPU or ....), they can differ even in the same program with the same optimizations. See for example: int main() { double q; q = 3.0/7.0; if (q == 3.0/7.0) printf("Equal\n"); else printf("Not Equal\n"); return 0; } On an extended-based system, even though the expression 3.0/7.0 has type double, the quotient will be computed in a register in extended double format, and thus in the default mode, it will be rounded to extended double precision. When the resulting value is assigned to the variable q, however, it may then be stored in memory, and since q is declared double, the value will be rounded to double precision. In the next line, the expression 3.0/7.0 may again be evaluated in extended precision yielding a result that differs from the double precision value stored in q, causing the program to print "Not Equal". Of course, other outcomes are possible, too: the compiler could decide to store and thus round the value of the expression 3.0/7.0 in the second line before comparing it with q, or it could keep q in a register in extended precision without storing it. An optimizing compiler might evaluate the expression 3.0/7.0 at compile time, perhaps in double precision or perhaps in extended double precision. (With one x86 compiler, the program prints "Equal" when compiled with optimization and "Not Equal" when compiled for debugging.) Finally, some compilers for extended-based systems automatically change the rounding precision mode to cause operations producing results in registers to round those results to single or double precision, albeit possibly with a wider range. Thus, on these systems, we can't predict the behavior of the program simply by reading its source code and applying a basic understanding of IEEE 754 arithmetic. The relevant conclusion: Neither can we accuse the hardware or the compiler of failing to provide an IEEE 754 compliant environment; the hardware has delivered a correctly rounded result to each destination, as it is required to do, and the compiler has assigned some intermediate results to destinations that are beyond the user's control, as it is allowed to do. https://grouper.ieee.org/groups/msc/ANSI_IEEE-Std-754-2019/background/addendum.html https://grouper.ieee.org/groups/msc/ANSI_IEEE-Std-754-2019/b...
    - zokier 5y ago
dnautics 5y ago
i believe there are strange corner cases around x87, but that may have changed since IEE754 got revised last year
- ReleaseCandidat 5y ago
  For example, yes.

ReleaseCandidat 5y ago

> The rest of the argument can also be apply to functions. Of course it is, but you can use other functions names than `product`. If the language doesn't let you use any other symbol for the operator but `*`, you're out of luck.