[Haskell-cafe] Why no Floating instance for Data.Fixed / Data.Fixed.Binary
douglas.mcclean at gmail.com
Wed Apr 15 00:25:59 UTC 2015
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
On first look, the second one probably is the best match for my target
applications, which are ultimately embedded.
On Tue, Apr 14, 2015 at 12:19 AM, Scott Turner <2haskell at pkturner.org>
> 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 <trebla at 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.
> To return the correct value (0) from each of these examples, and their
> successors, requires an implementation able to calculate pi to an unbounded
> 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.
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
J. Douglas McClean
(781) 561-5540 (cell)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe