[Haskell-cafe] Why no Floating instance for Data.Fixed / Data.Fixed.Binary

[Douglas McClean]

I'm wondering why the decision was made not to have a Floating instance for Data.Fixed.

I understand that -- being a fixed point number type -- it doesn't line up with the name of the Floating typeclass.

But it also seems that Floating is misnamed, because none of the functions there really have anything to do with floating point representation. This is why we still have Floating instances for, say, exact reals or symbolic numbers, neither of which has a floating point representation.

It seems that the actual criterion for membership in Floating is something like "has a canonical choice for degree of approximation". Double and Float are in because we round to the nearest value. Exact reals are in because we don't have to approximate, symbolic numbers too. Rational is out because there's no clear choice of how to approximate.

But by this criterion, Data.Fixed should be in. And indeed it would be useful for it to be in. If I choose to represent values from the real world by a fixed point approximation instead of a floating point approximation, shouldn't I still be able to take sines and cosines etc?

Obviously I can fix this by using a newtype. I'm just curious if am I missing a reason why the current definition is more desirable?

-Doug McClean

[Albert Y. C. Lai]

On 2015-04-13 11:31 AM, Douglas McClean wrote:
> I'm wondering why the decision was made not to have a Floating
> instance for Data.Fixed.

I have always found economics to be a powerful answer to this kind of
questions. That is, perhaps simply, there has not been sufficient
incentive for anyone to do the work. For example, do you want to do it?
_______________________________________________
Haskell-Cafe mailing list
Haskel...@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

[Douglas McClean]

I'd certainly be happy to do it, I'm just concerned that it would be actively unwanted for a reason that I can't see.

I will look in to what the procedures are for contributing to base.

It wasn't my intention to beg the internet to do it for me.

--

J. Douglas McClean

(781) 561-5540 (cell)

[Scott Turner]

On 2015-04-13 22:08, Douglas McClean wrote:

I'd certainly be happy to do it, I'm just concerned that it would be actively unwanted for a reason that I can't see.

I will look in to what the procedures are for contributing to base.

It wasn't my intention to beg the internet to do it for me.

On Mon, Apr 13, 2015 at 5:49 PM, Albert Y. C. Lai <tre...@vex.net> wrote:

On 2015-04-13 11:31 AM, Douglas McClean wrote:

I'm wondering why the decision was made not to have a Floating instance for Data.Fixed.

I have always found economics to be a powerful answer to this kind of questions. That is, perhaps simply, there has not been sufficient incentive for anyone to do the work. For example, do you want to do it?

It looks hairy to me. The big-number cases would need approaches quite different from floating point.
    sin(31415926.535897932384::Pico)
    sin(31415926535897932384.626433832795::Pico)
    sin(314159265358979323846264338327950288419.716939937510::Pico)
To return the correct value (0) from each of these examples, and their successors, requires an implementation able to calculate pi to an unbounded precision.

The value of exp(50::Uni) requires more precision than a double can provide. How far do you go? exp(100::Uni)?

I hope this doesn't scare you off. Perhaps there's literature on acceptable limitations when implementing/using such fixed point transcendental functions. In any case an implementation would be interesting even if it doesn't provide correct results in the extreme cases.

[Douglas McClean]

Great point, thanks Scott. I will investigate that.

Possible avenues include:

• living with it, as you say, and identifiying bounds
• moving forward only with Data.Fixed.Binary where the values have bounded size, and imposing contexts that verify that the values can't be too large/small for the implementation to work
• moving forward with a newtype around Fixed and an arbitrary precision implementation

On first look, the second one probably is the best match for my target applications, which are ultimately embedded.

Cheers,
Doug

_______________________________________________
Haskell-Cafe mailing list
Haskel...@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

[Dyson Wilkes]

Doug

I am interested to learn what version of Data.Fixed.Binary you are using and with which version of base.  I find that 0.5.0.1 fails to load in ghci 7.6.3 with:

Fixed/Binary.hs:89:14: Not in scope: data constructor `L.Int'

Fixed/Binary.hs:90:14: Not in scope: data constructor `L.Rat'

If I try, as an experiment, commenting out the offending lines to see what other problems there might be I get:

Fixed/Binary.hs:176:15:

    Could not deduce (Num a) arising from a use of `withResolution'

...

Thanks in advance for any pointers you might give,

 - Dyson