[Haskell-cafe] Why not some subclass of Floating to model NaNs as some handleable bottom?

[YueCompl]

Thanks Michał,

I feel less confused as I realized the non-halting possibility per bottoms, from your hint.

I too think the signaling NaN is dreadful enough, so fortunately it's rarely seen nowadays.

Actually what's on my mind was roughly something like "Maybe on steroids", I'm aware that NaN semantics breaks `Num` (or descendants) laws, as seen at https://gitlab.haskell.org/ghc/ghc/-/blob/master/libraries/base/GHC/Float.hs <https://gitlab.haskell.org/ghc/ghc/-/blob/master/libraries/base/GHC/Float.hs>

> Note that due to the presence of @NaN@, not all elements of 'Float' have an additive inverse.

> Also note that due to the presence of -0, Float's 'Num' instance doesn't have an additive identity

> Note that due to the presence of @NaN@, not all elements of 'Float' have an multiplicative inverse.

So it should have been another family of `Num` classes, within which, various NaN related semantics can be legal, amongst which I'd think:

* Silent propagation of NaN in arithmetics, like `Maybe` monad does, seems quite acceptable
* Identity test, namely `NaN` /= `NaN` - this lacks theoretical ground or not?
* Comparison, neither `NaN` > 1 nor `NaN` <= 1 - whether or not there's a theoretical framework for this to hold? Maybe `Boolean` type needs enhancement too to do it?

No such family of `Num` classes exists to my aware by now, I just can't help wondering why.

Cheers,
Compl

> On 2021-08-04, at 02:38, Michał J Gajda <mjgajda at gmail.com> wrote:
> 
> Dear Yue,
> 
> Bottom has much weaker semantics than an exception: it means You may never get a result and thus will never handle it!
> 
> Another reason is convenience: it is frequently the case that giving NaN in a row of numbers is much more informative than crashing a program with an exception and never printing the result anyway.
> 
> Finally IEEE special values have clear propagation semantics: they are basically Maybe on steroids.
> 
> The problem with this approach is indeed a silent handling.
> 
> But in order to fix this, it is better to add preconditions to specific algorithms that do not allow IEEE special value on input (`isFinite` or `isNotNaN`) and then track the origin of the special value with the methods like those described here: https://skillsmatter.com/skillscasts/14905-agile-functional-data-pipeline-in-haskell-a-case-study-of-multicloud-api-binding <https://skillsmatter.com/skillscasts/14905-agile-functional-data-pipeline-in-haskell-a-case-study-of-multicloud-api-binding>
> 
> Never throw an error without telling exactly why it happened and exactly where to fix it :-). Using bottom is last resort; exceptions likewise.
> --
>   Cheers
>     Michał

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210804/0ac712ce/attachment.html>