<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Thanks Michał,<div class=""><br class=""></div><div class="">I feel less confused as I realized the non-halting possibility per bottoms, from your hint.</div><div class=""><br class=""></div><div class="">I too think the signaling NaN is dreadful enough, so fortunately it's rarely seen nowadays.</div><div class=""><br class=""></div><div class="">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 <a href="https://gitlab.haskell.org/ghc/ghc/-/blob/master/libraries/base/GHC/Float.hs" class="">https://gitlab.haskell.org/ghc/ghc/-/blob/master/libraries/base/GHC/Float.hs</a></div><div class=""><br class=""></div><div class=""><div class="">> Note that due to the presence of @NaN@, not all elements of 'Float' have an additive inverse.</div><div class=""><br class=""></div><div class="">> Also note that due to the presence of -0, Float's 'Num' instance doesn't have an additive identity</div><div class=""><br class=""></div><div class="">> Note that due to the presence of @NaN@, not all elements of 'Float' have an multiplicative inverse.</div></div><div class=""><br class=""></div><div class="">So it should have been another family of `Num` classes, within which, various NaN related semantics can be legal, amongst which I'd think:</div><div class=""><br class=""></div><div class="">* Silent propagation of NaN in arithmetics, like `Maybe` monad does, seems quite acceptable</div><div class="">* Identity test, namely `NaN` /= `NaN` - this lacks theoretical ground or not?</div><div class="">* 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?</div><div class=""><br class=""></div><div class="">No such family of `Num` classes exists to my aware by now, I just can't help wondering why.</div><div class=""><br class=""></div><div class="">Cheers,</div><div class="">Compl</div><div class=""><br class=""></div><div class=""><div><blockquote type="cite" class=""><div class="">On 2021-08-04, at 02:38, Michał J Gajda <<a href="mailto:mjgajda@gmail.com" class="">mjgajda@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="auto" class="">Dear Yue,<div dir="auto" class=""><br class=""></div><div dir="auto" class="">Bottom has much weaker semantics than an exception: it means You may never get a result and thus will never handle it!</div><div dir="auto" class=""><br class=""></div><div dir="auto" class="">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.</div><div dir="auto" class=""><br class=""></div><div dir="auto" class="">Finally IEEE special values have clear propagation semantics: they are basically Maybe on steroids.</div><div dir="auto" class=""><br class=""></div><div dir="auto" class="">The problem with this approach is indeed a silent handling.</div><div dir="auto" class=""><br class=""></div><div dir="auto" class="">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: <a href="https://skillsmatter.com/skillscasts/14905-agile-functional-data-pipeline-in-haskell-a-case-study-of-multicloud-api-binding" target="_blank" rel="noreferrer" class="">https://skillsmatter.com/skillscasts/14905-agile-functional-data-pipeline-in-haskell-a-case-study-of-multicloud-api-binding</a></div><div dir="auto" class=""><br class=""></div><div dir="auto" class="">Never throw an error without telling exactly why it happened and exactly where to fix it :-). Using bottom is last resort; exceptions likewise.</div><div dir="auto" class="">--</div><div dir="auto" class=""> Cheers</div><div dir="auto" class=""> Michał</div></div>
</div></blockquote></div><br class=""></div></body></html>