6 ms·

I suppose because that’s what “atan(1) * 4” casts to double? - I wonder if this cast is always correct in C [ie.: math.h], no matter the datatype and/or the

I suppose because that’s what “atan(1) * 4” casts to double? - I wonder if this cast is always correct in C [ie.: math.h], no matter the datatype and/or the number base?

constantcrying 2y ago
>- I wonder if this cast is always correct in C [ie.: math.h], no matter the datatype and/or the number base? Floating point arithmetic is deterministic. As long as it is implemented as specified atan(1) has to give the floating point number which is the closest approximation to the real number pi/4 (in the current rounding mode), the multiplication by 4 means that precision can be lost and potentially your result is no longer the closest possible approximation to pi.
- adgjlsfhk1 2y ago
  this isn't true. the standard only recommends correct rounding, but does not actually set any limits on acceptable error. also, no OS provided libm produces correctly rounded results for all inputs.
  - constantcrying 2y ago
    > the standard only recommends correct rounding What? This is not true at all. The standards specifies adherence to IEEE 754 arithmetic. You can read the standard here: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf Page 507 for adherence to number formats. Page 517 for atan adhering to IEEE 754 specification for the functions defined therein, which guarantees best possible results for individual operations. Any C implementation where atan gives a result which is inconsistent with IEEE 754 specification does not adhere to the standard. > also, no OS provided libm produces correctly rounded results for all inputs. Every IEEE 754 conforming library does adhere to the best possible rounding guarantee. If you have any evidence to the contrary that would be a disaster and should be reported to the vendor of that library ASAP. Can you provide some function and some input which violates the IEEE 754 guarantee together with the specific library and version? Or are you just making stuff up?
    - AlotOfReading 2y ago
      In the interests of moving this discussion in a positive direction, the comment you're replying to is correct. IEEE 754 doesn't specify correct rounding except for a small subset of elementary functions. In the 1985 version, this was the core +, -, *, /, and sqrt, but it was updated to include a few of the other functions when they were added. arctan is one of those functions which is not always correctly rounded due to the tablemaker's dilemma. If you read the latest standard (2019), they actually cite some of the published literature giving specific worst case examples for functions like arctan. Even beyond transcendental functions, 754 isn't deterministic in practice because implementations have choices that aren't always equivalent. Using FMA vs separate multiplication and addition leads to different results in real programs, even though both methods are individually deterministic.
      - constantcrying 2y ago
        >arctan is one of those functions which is not always correctly rounded due to the tablemaker's dilemma. But then it doesn't conform to the standard. It is pretty unambiguous on that point. From Section 9.2: "A conforming operation shall return results correctly rounded for the applicable rounding direction for all operands in its domain." I do not see how two conforming implementations can differ in results. >Using FMA vs separate multiplication and addition leads to different results in real programs, even though both methods are individually deterministic. Obviously. I never claimed that the arithmetic was invariant under transformations which change floating point operations, but are equivalent for real numbers. That would be ridiculous. Is there actually an example of two programs performing identical operations under the same environment that give different results where both implementations conform to the standard? >Even beyond transcendental functions, 754 isn't deterministic in practice because implementations have choices that aren't always equivalent. Could you give an example? Where are implementations allowed to differ? And are these cases relevant, in the sense that identical operations lead to differing results? Or do they just relate to error handling and signaling.
        Extigy 2y ago
        That section is recommended but not required for a conforming implementation: > 9. Recommended operations > Clause 5 completely specifies the operations required for all supported arithmetic formats. This clause specifies additional operations, recommended for all supported arithmetic formats. Hyperbolic tan is in the list of recommended functions, and yet: https://github.com/numpy/numpy/issues/9187 https://github.com/numpy/numpy/issues/9187
- adgjlsfhk1 2y ago
  also multiplication by 4 doesn't round since 4 is a power of 2
  - constantcrying 2y ago
    That just is not true. It is a bit shift to the right, so where do the new bits come from? Why would the two new bits be the correct ones?
    - dasyatidprime 2y ago
      In binary floating point, 4.0 = 1.0×2^2, so the mantissa of the multiplicand will stay the same (being multiplied by 1.0) and the exponent will be incremented by 2. Scaling by exact integer powers of 2 preserves the relative accuracy of the input so long as you stay in range. The increase in absolute error is inherent to the limited number of mantissa bits and not introduced by any rounding from the multiplication; there are no additional bits.
      - constantcrying 2y ago
        Who cares? This is about the approximation to pi not the approximation to float(atan(1))*4, it is exact (but irrelevant) for the later, for the former you loose two bits, so you have a 25% chance of correctly rounding towards pi.
        adgjlsfhk1 2y ago
        this is incorrect. float(pi)/4 exactly equals float(atan(1)). multiplication by 4 doesn't touch the mantisa. it just increments the exponent by 2

I suppose because that’s what “atan(1) * 4” casts to double? - I wonder if this cast is always correct in C [ie.: math.h], no matter the datatype and/or the number base?

constantcrying 2y ago

>- I wonder if this cast is always correct in C [ie.: math.h], no matter the datatype and/or the number base? Floating point arithmetic is deterministic. As long as it is implemented as specified atan(1) has to give the floating point number which is the closest approximation to the real number pi/4 (in the current rounding mode), the multiplication by 4 means that precision can be lost and potentially your result is no longer the closest possible approximation to pi.

adgjlsfhk1 2y ago
this isn't true. the standard only recommends correct rounding, but does not actually set any limits on acceptable error. also, no OS provided libm produces correctly rounded results for all inputs.
- constantcrying 2y ago
  > the standard only recommends correct rounding What? This is not true at all. The standards specifies adherence to IEEE 754 arithmetic. You can read the standard here: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf Page 507 for adherence to number formats. Page 517 for atan adhering to IEEE 754 specification for the functions defined therein, which guarantees best possible results for individual operations. Any C implementation where atan gives a result which is inconsistent with IEEE 754 specification does not adhere to the standard. > also, no OS provided libm produces correctly rounded results for all inputs. Every IEEE 754 conforming library does adhere to the best possible rounding guarantee. If you have any evidence to the contrary that would be a disaster and should be reported to the vendor of that library ASAP. Can you provide some function and some input which violates the IEEE 754 guarantee together with the specific library and version? Or are you just making stuff up?
  - AlotOfReading 2y ago
    In the interests of moving this discussion in a positive direction, the comment you're replying to is correct. IEEE 754 doesn't specify correct rounding except for a small subset of elementary functions. In the 1985 version, this was the core +, -, *, /, and sqrt, but it was updated to include a few of the other functions when they were added. arctan is one of those functions which is not always correctly rounded due to the tablemaker's dilemma. If you read the latest standard (2019), they actually cite some of the published literature giving specific worst case examples for functions like arctan. Even beyond transcendental functions, 754 isn't deterministic in practice because implementations have choices that aren't always equivalent. Using FMA vs separate multiplication and addition leads to different results in real programs, even though both methods are individually deterministic.
    - constantcrying 2y ago
      >arctan is one of those functions which is not always correctly rounded due to the tablemaker's dilemma. But then it doesn't conform to the standard. It is pretty unambiguous on that point. From Section 9.2: "A conforming operation shall return results correctly rounded for the applicable rounding direction for all operands in its domain." I do not see how two conforming implementations can differ in results. >Using FMA vs separate multiplication and addition leads to different results in real programs, even though both methods are individually deterministic. Obviously. I never claimed that the arithmetic was invariant under transformations which change floating point operations, but are equivalent for real numbers. That would be ridiculous. Is there actually an example of two programs performing identical operations under the same environment that give different results where both implementations conform to the standard? >Even beyond transcendental functions, 754 isn't deterministic in practice because implementations have choices that aren't always equivalent. Could you give an example? Where are implementations allowed to differ? And are these cases relevant, in the sense that identical operations lead to differing results? Or do they just relate to error handling and signaling.
      - Extigy 2y ago
        That section is recommended but not required for a conforming implementation: > 9. Recommended operations > Clause 5 completely specifies the operations required for all supported arithmetic formats. This clause specifies additional operations, recommended for all supported arithmetic formats. Hyperbolic tan is in the list of recommended functions, and yet: https://github.com/numpy/numpy/issues/9187 https://github.com/numpy/numpy/issues/9187
adgjlsfhk1 2y ago
also multiplication by 4 doesn't round since 4 is a power of 2
- constantcrying 2y ago
  That just is not true. It is a bit shift to the right, so where do the new bits come from? Why would the two new bits be the correct ones?
  - dasyatidprime 2y ago
    In binary floating point, 4.0 = 1.0×2^2, so the mantissa of the multiplicand will stay the same (being multiplied by 1.0) and the exponent will be incremented by 2. Scaling by exact integer powers of 2 preserves the relative accuracy of the input so long as you stay in range. The increase in absolute error is inherent to the limited number of mantissa bits and not introduced by any rounding from the multiplication; there are no additional bits.
    - constantcrying 2y ago
      Who cares? This is about the approximation to pi not the approximation to float(atan(1))*4, it is exact (but irrelevant) for the later, for the former you loose two bits, so you have a 25% chance of correctly rounding towards pi.
      - adgjlsfhk1 2y ago
        this is incorrect. float(pi)/4 exactly equals float(atan(1)). multiplication by 4 doesn't touch the mantisa. it just increments the exponent by 2