5 ms·

>NaN breaks x==x which is a pretty fundamental relationship for numbers to have NaN is not a number, so it should NOT satisfy "fundamental relationships for nu

>NaN breaks x==x which is a pretty fundamental relationship for numbers to have NaN is not a number, so it should NOT satisfy "fundamental relationships for numbers to have". >+-Inf sound useful in theory, but in practice they rarely give you a more useful resu There are algorithms that are more performant using infs, and without having a way to denote overflow, you'd have to pre-check evedry operation to do serious numerical work, which basically cuts your performance in half. >Once you've gotten rid of -Inf, it becomes clear that -0.0 is a mistake >It breaks the identity 0+x==x and 0-x==-x. No, you have some fundamental misunderstanding. IEEE explicitly guarantees these hold, even for -0. > Furthermore, IEEE specifies sqrt(-0.0)==-0.0 and log(-0.0)==-Inf which are both nonsensical if you consider -0.0 as a limit from the negatives. You're making up strawmen. -0 is not a "limit from the negatives" any more than +0 is a limit form the positives, which would break other made up requirements. That is why making up stuff that has zero bearing on what IEEE 754 specifies is arguing strawmen. >Floats also have the unfortunate property that inv(x) can be infinite for finite x. Integers have the same property: -(X) can not be the negative of X. So this is not a problem except in made up goofiness. Every objection you post is a lack of understanding numerical analysis and the needs of actual scientific software. So you're skeptical- do you write numerical software professionally? I do, and have, and will do it in the future. There are very, very good reasons for all of those pieces you don't see the need for. There's a reason unums have not caught on with the field of numerical software or numerical analysis - they simply don't allow writing robust, performant software, they solve no real issues, and add significant problems.

adgjlsfhk1 4y ago
>so it should NOT satisfy "fundamental relationships for numbers to have". If you have a list with a NaN in it, how should you make sort terminate (and where should the NaN end up)? I understand that in theory it is kind of arguable that NaN should be different, but breaking the total order is a really dumb decision. >you'd have to pre-check evedry operation to do serious numerical work, which basically cuts your performance in half. Can you give an example? Saturating overflow tends to do the same thing. >IEEE explicitly guarantees these hold This is kind of true. -0.0+0.0==0.0 and 0.0-0.0==0.0. IEEE does define -0.0==0.0 so IEEE does technically make this hold, but only by redefining == so that two different numbers are == > -0 is not a "limit from the negatives" Then what is it? it's not a real number, and Kahan's justification of them comes from branch cuts of analytic functions which is only makes sense in the context of limits https://homes.cs.washington.edu/~ztatlock/599z-17sp/papers/branch-cuts-kahan-87.pdf https://homes.cs.washington.edu/~ztatlock/599z-17sp/papers/b... > Integers have the same property Yeah and it sucks there too. In the fp case it makes it really annoying to do things like calculate divide an array by a float quickly and accurately. You would want to take the inverse of the divisor and multiply by that, but doing so isn't safe if the divisor is subnormal. Yes. My day job is in solving Differential Algebraic equations, but I also have written a bunch of Julia's Libm.
- SideQuark 4y ago
  >If you have a list with a NaN in it, how should you make sort terminate Do whatever you want. If you're sorting floats, sort them to the front. Every language I've ever used for developing numerical software has a trivial IsNaN equivalent. So that's not a complaint worthy of claiming NaNs are not useful. I've written lots of numerical software and not once has this been an issue for me. What value do you assign sqrt of a negative without some NaN type item? Or any of tons of other "not a number" results? >so IEEE does technically make this hold, but only by redefining == There's no "redefining ==" here. You are upset that bit patterns are different, but == is not for bit patterns. You are confusing == for floats with == for bit patterns, which are not and need not be the same thing. I've never seen a language that gets these confused. If you want float ==, simply use language ==. If you want bitwise ==, then you usually have to do (often not portable) fiddling to convert to a bit pattern. It's like claiming reference == and structure field == should be the same, but both have uses. So languages have all sorts of ways to use the concept of equality, and they are all useful. Confusing them does not make the ones you don't like invalid or not extremely useful for people that do understand and use them. >Yes. My day job is in solving Differential Algebraic equations, but I also have written a bunch of Julia's Libm. Good. Then you should understand why, as an example, C++ std lib has a massive amount of functions like fma, expm1, log1p, hypot, and many more. Sure you can simply write log(1+x) instead of using log1p, but log1p is vastly better in this case because properties of IEEE 754 allow more precision. instead of hypot(x,y) you could write sqrt(xx+yy), but hypot is much better. These functions exist since IEEE provides tools to analyze these and make much better versions than the naive way to write them. Unums, with varying precision, make this vastly harder (and losing precision over the domain, making it hard to analyze anything). So unums, with varying precision, violate fundamental properties for scientific computing, namely, they lose precision in really messy ways. You cannot start with P digits of precision and do even simple math and get an answer with P digits of precision. IEEE does allow this. For example, sqrt(x^2)=|x| in IEEE (for no under/overflow). This does not work in unums, since they lose precision. Square something and lose digits. Fundamental to lots of scientific computation is the requirement to maintain precision throughout a calculation. Unums fail this spectacularly, making it incredibly messy to do correct scientific work.
  - 4y ago
adgjlsfhk1 4y ago
Also to be clear, unums v1 and v2 were (mostly) dumb ideas that haven't gone anywhere. Unums v3 (aka posits) are a (IMO) really good idea for how to generate a better floating point standard (see https://posithub.org/docs/posit_standard-2.pdf https://posithub.org/docs/posit_standard-2.pdf)

adgjlsfhk1 4y ago

>so it should NOT satisfy "fundamental relationships for numbers to have". If you have a list with a NaN in it, how should you make sort terminate (and where should the NaN end up)? I understand that in theory it is kind of arguable that NaN should be different, but breaking the total order is a really dumb decision. >you'd have to pre-check evedry operation to do serious numerical work, which basically cuts your performance in half. Can you give an example? Saturating overflow tends to do the same thing. >IEEE explicitly guarantees these hold This is kind of true. -0.0+0.0==0.0 and 0.0-0.0==0.0. IEEE does define -0.0==0.0 so IEEE does technically make this hold, but only by redefining == so that two different numbers are == > -0 is not a "limit from the negatives" Then what is it? it's not a real number, and Kahan's justification of them comes from branch cuts of analytic functions which is only makes sense in the context of limits https://homes.cs.washington.edu/~ztatlock/599z-17sp/papers/branch-cuts-kahan-87.pdf https://homes.cs.washington.edu/~ztatlock/599z-17sp/papers/b... > Integers have the same property Yeah and it sucks there too. In the fp case it makes it really annoying to do things like calculate divide an array by a float quickly and accurately. You would want to take the inverse of the divisor and multiply by that, but doing so isn't safe if the divisor is subnormal. Yes. My day job is in solving Differential Algebraic equations, but I also have written a bunch of Julia's Libm.

SideQuark 4y ago
>If you have a list with a NaN in it, how should you make sort terminate Do whatever you want. If you're sorting floats, sort them to the front. Every language I've ever used for developing numerical software has a trivial IsNaN equivalent. So that's not a complaint worthy of claiming NaNs are not useful. I've written lots of numerical software and not once has this been an issue for me. What value do you assign sqrt of a negative without some NaN type item? Or any of tons of other "not a number" results? >so IEEE does technically make this hold, but only by redefining == There's no "redefining ==" here. You are upset that bit patterns are different, but == is not for bit patterns. You are confusing == for floats with == for bit patterns, which are not and need not be the same thing. I've never seen a language that gets these confused. If you want float ==, simply use language ==. If you want bitwise ==, then you usually have to do (often not portable) fiddling to convert to a bit pattern. It's like claiming reference == and structure field == should be the same, but both have uses. So languages have all sorts of ways to use the concept of equality, and they are all useful. Confusing them does not make the ones you don't like invalid or not extremely useful for people that do understand and use them. >Yes. My day job is in solving Differential Algebraic equations, but I also have written a bunch of Julia's Libm. Good. Then you should understand why, as an example, C++ std lib has a massive amount of functions like fma, expm1, log1p, hypot, and many more. Sure you can simply write log(1+x) instead of using log1p, but log1p is vastly better in this case because properties of IEEE 754 allow more precision. instead of hypot(x,y) you could write sqrt(xx+yy), but hypot is much better. These functions exist since IEEE provides tools to analyze these and make much better versions than the naive way to write them. Unums, with varying precision, make this vastly harder (and losing precision over the domain, making it hard to analyze anything). So unums, with varying precision, violate fundamental properties for scientific computing, namely, they lose precision in really messy ways. You cannot start with P digits of precision and do even simple math and get an answer with P digits of precision. IEEE does allow this. For example, sqrt(x^2)=|x| in IEEE (for no under/overflow). This does not work in unums, since they lose precision. Square something and lose digits. Fundamental to lots of scientific computation is the requirement to maintain precision throughout a calculation. Unums fail this spectacularly, making it incredibly messy to do correct scientific work.
- 4y ago

adgjlsfhk1 4y ago

Also to be clear, unums v1 and v2 were (mostly) dumb ideas that haven't gone anywhere. Unums v3 (aka posits) are a (IMO) really good idea for how to generate a better floating point standard (see https://posithub.org/docs/posit_standard-2.pdf https://posithub.org/docs/posit_standard-2.pdf)