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

Mon Aug 9 10:18:47 UTC 2021

So we have two things here:

* lossy computation that needs  a distance (metric) between points below
epsilon instead of a comparison; in this case we should never ask for exact
equality, but rather ask if a result is within a certain radius from a
result. That means we measure convergence according to a metric, not
equivalence.

```
class Ord m => Metric m a where
   dist :: a -> a -> m

a ~= b = dist a b <= epsilon
```

* handling and propagation of different error values.

That would require a rehash of both standard libraries and most
mathematical algebra libraries for Haskell.

For at least two reasons:

* libraries assume a naive equality works for all types. Holds in a world
of infinte precision and lossless operations, but never holds for
approximations.

* our propagation of universal error values is incomplete, and usually
missing from complex algorithms. In other words `Either String` Monad does
not work: we want collections of error values just like we have collections
of inputs.

Personally I will be overjoyed when our community finally gets the better
type class library for approximated types.

Would You agree to review a teaser if I post it here?
—
  Cheers
    Michał

On Thu, 5 Aug 2021 at 10:41 YueCompl <compl.yue at icloud.com> wrote:

> > 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.
>
>
> Yeah, I think this is the thing I'm anticipating, current standard classes
> favor lossless computation by the laws, but large portion of the computer
> numeric solutions are taking loss of precision for efficiency. And neural
> systems even right following this approach as far as it appears, I
> sincerely hope Haskell can embrace it to some degree.
>
>
> > On 2021-08-05, at 15:26, 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.
>
> --
  Pozdrawiam
    Michał
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210809/37a0edab/attachment.html>