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

[Michal J Gajda]

It would be very kind if You contributed an example code for these. I do
not think anybody else in the discussion knows RTS as well as You.
  Cheers
    M

czw., 12 sie 2021, 16:59 użytkownik Carter Schonwald <
carter.schonwald at gmail.com> napisał:

> 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/c92ae493/attachment.html>