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

[Carter Schonwald]

Well said.

I do think signalling nans as a runtime flag option that converts them into
exceptions is still a pretty viable option.  The right hooks in the rts are
there !

On Thu, Aug 5, 2021 at 12:28 AM Richard O'Keefe <raoknz at gmail.com> wrote:

> You quoted
> "> Note that due to the presence of @NaN@, not all elements of 'Float'
> have an additive inverse."
>
> Let x y and z be finite floating-point numbers such that x + y ==> z.
> Does there always exist neg(y) such that z + neg(y) ==> x?
> NO.
>
> And the presence or absence of NaN in the system makes no difference.
> If, for example, you add 1.0e-18 to 1.0e0, the answer is 1.0e0 exactly.
> That is, (x + y) - y == 0, but x is not 0.
>
> In the presence of rounding, additive inverses do not in general exist.
> Neither do multiplicative inverses.
>
> Also addition and multiplication are not associative, but you knew that.
> The only reason Float and Double are in Num is because Haskell doesn't
> offer ad hoc overloading.  People have been saying that the Prelude needs
> refactoring for years.
>
> The main thing that NaN wrecks that wasn't already broken is Eq.  I would
> argue that the right decision there would have been to rule that x == y
> (when x and y are floating point numbers) precisely when x and y are
> represented by the same bit pattern, with a separate operation for IEEE
> "ordered and equal".
>
> At some point, Haskell should make provision for decimal floating point,
> as the current versions of IEEE 754 and C do, and that might be a good
> reorganisation time.
>
>
> On Thu, 5 Aug 2021 at 02:05, YueCompl via Haskell-Cafe
> <haskell-cafe at haskell.org> wrote:
> >
> > 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
> >
> > > 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
> >
> > 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ł
> >
> >
> > _______________________________________________
> > Haskell-Cafe mailing list
> > To (un)subscribe, modify options or view archives go to:
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> > Only members subscribed via the mailman list are allowed to post.
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210812/8438dd78/attachment.html>