28 Nov 2012 18:07

## Proposal: add conversion functions to Data.Fixed.

```Hello,
In my work I've run into an annoyance: Data.Fixed.Fixed does not have a
Binary instance in the binary package. This is a result of the
representation of Fixed being hidden, which is understandable. The
problem is that when I want to create a Binary instance for Fixed, I
need to use unsafeCoerce, which is nasty, and there's no built-in way to
safely deal with problems involving the desired resolution being
different when deseralizing.

Today I played around with the source to Fixed, and came up with this
proposed solution:

- | Get a Fixed value's Integer representation and resolution.
fromFixed :: (HasResolution a) => Fixed a -> (Integer,Integer)
fromFixed f <at> (MkFixed i) = (i, resolution f)

-- | Given an Integer representation and resolution of a Fixed value,
-- create a new Fixed value with an arbitrary resolution.
toFixed :: (HasResolution a) => (Integer,Integer) -> Fixed a
toFixed (i,r0) = withResolution (\r1 -> MkFixed \$ (i * r1) `div` r0)

These functions lead to this useful derivation: convertFixed = toFixed .
fromFixed, which leads to the possibility of having many possibly useful
utility functions, such as toUni, fromUni, toDeci, fromDeci, etc.

From fromFixed and toFixed, a safe instance for Binary (Fixed a) can be
built (I haven't tested this, but it looks right):

instance (HasResolution a) => Binary (Fixed a) where
put = put . fromFixed
```

29 Nov 2012 23:43

### Re: Proposal: add conversion functions to Data.Fixed.

Jeff Shaw wrote:
fromFixed :: (HasResolution a) => Fixed a -> (Integer,Integer)
toFixed :: (HasResolution a) => (Integer,Integer) -> Fixed a

+1

I've needed those.
```_______________________________________________
Libraries mailing list
```
1 Dec 2012 10:23

### Re: Proposal: add conversion functions to Data.Fixed.

```On 28/11/12 09:07, Jeff Shaw wrote:
> Hello,
> In my work I've run into an annoyance: Data.Fixed.Fixed does not have a
> Binary instance in the binary package.

Just to be clear, this is a modification of binary, not Data.Fixed in
base, is that correct?

-- Ashley
```
1 Dec 2012 21:11

### Re: Proposal: add conversion functions to Data.Fixed.

Jeff Shaw wrote:
In my work I've run into an annoyance: Data.Fixed.Fixed does not have a
Binary instance in the binary package.

Ashley Yakeley wrote:
Just to be clear, this is a modification of binary, not Data.Fixed in base, is that correct?

Hmm, I had understood just the opposite:
that the proposal was to add fromFixed/toFixed
to Data.Fixed, motivated by the difficulty of things
like writing a Binary instance.

So I hope the proposer responds soon. This proposal
will not get very far unless it is completely clear
what is being proposed.

Thanks,
Yitz
```_______________________________________________
Libraries mailing list
```
1 Dec 2012 23:54

### Re: Proposal: add conversion functions to Data.Fixed.

```On 01/12/12 12:11, Yitzchak Gale wrote:
> Jeff Shaw wrote:
>
>         In my work I've run into an annoyance: Data.Fixed.Fixed does not
>         have a
>         Binary instance in the binary package.
>
> Ashley Yakeley wrote:
>
>     Just to be clear, this is a modification of binary, not Data.Fixed
>     in base, is that correct?
>
>
> Hmm, I had understood just the opposite:
> that the proposal was to add fromFixed/toFixed
> to Data.Fixed, motivated by the difficulty of things
> like writing a Binary instance.

Oh yes, you're right. But I don't think it's necessary.

-- Ashley
```
2 Dec 2012 03:14

### Re: Proposal: add conversion functions to Data.Fixed.

To be frank, I would just rather have access to the constructor to Fixed.

It honestly strikes me as silly to have to pay for a division and/or multiplication every time I want to access one.

There in an ideological distinction being maintained here about the one true usage pattern that has forced me to reimplement Data.Fixed in my own code to avoid the overhead. =(

You can bury it in an Internal module or something and load it with caveats about how it is a bad idea to use and how you reserve the right to change it some day, but without it Data.Fixed remains almost useless to me.

The Binary instance can trivially be implemented on top of that, as we shoudn't be encoding type (precision) information in the Binary data stream.

-Edward

On Sat, Dec 1, 2012 at 5:54 PM, Ashley Yakeley wrote:
On 01/12/12 12:11, Yitzchak Gale wrote:
Jeff Shaw wrote:

In my work I've run into an annoyance: Data.Fixed.Fixed does not
have a
Binary instance in the binary package.

Ashley Yakeley wrote:

Just to be clear, this is a modification of binary, not Data.Fixed
in base, is that correct?

Hmm, I had understood just the opposite:
that the proposal was to add fromFixed/toFixed
to Data.Fixed, motivated by the difficulty of things
like writing a Binary instance.

Oh yes, you're right. But I don't think it's necessary.

-- Ashley

_______________________________________________
Libraries mailing list

```_______________________________________________
Libraries mailing list
```
2 Dec 2012 06:13

### Re: Proposal: add conversion functions to Data.Fixed.

```Might as well, since we already have fromEnum and toEnum (which
unfortunately convert to Int).

-- Ashley

On 01/12/12 18:14, Edward Kmett wrote:
> To be frank, I would just rather have access to the constructor to Fixed.
>
> It honestly strikes me as silly to have to pay for a division and/or
> multiplication every time I want to access one.
>
> There in an ideological distinction being maintained here about the one
> true usage pattern that has forced me to reimplement Data.Fixed in my
> own code to avoid the overhead. =(
>
> You can bury it in an Internal module or something and load it with
> caveats about how it is a bad idea to use and how you reserve the right
> to change it some day, but without it Data.Fixed remains almost useless
> to me.
>
> The Binary instance can trivially be implemented on top of that, as we
> shoudn't be encoding type (precision) information in the Binary data stream.
>
> -Edward
>
> On Sat, Dec 1, 2012 at 5:54 PM, Ashley Yakeley <ashley <at> semantic.org
> <mailto:ashley <at> semantic.org>> wrote:
>
>     On 01/12/12 12:11, Yitzchak Gale wrote:
>
>         Jeff Shaw wrote:
>
>                  In my work I've run into an annoyance: Data.Fixed.Fixed
>         does not
>                  have a
>                  Binary instance in the binary package.
>
>         Ashley Yakeley wrote:
>
>              Just to be clear, this is a modification of binary, not
>         Data.Fixed
>              in base, is that correct?
>
>
>         Hmm, I had understood just the opposite:
>         that the proposal was to add fromFixed/toFixed
>         to Data.Fixed, motivated by the difficulty of things
>         like writing a Binary instance.
>
>
>     Oh yes, you're right. But I don't think it's necessary.
>
>
>     -- Ashley
>
>
>     _________________________________________________
>     Libraries mailing list
>
>
>
>
> _______________________________________________
> Libraries mailing list
>
```
2 Dec 2012 10:25

### Re: Proposal: add conversion functions to Data.Fixed.

```Edward Kmett <ekmett <at> gmail.com> writes:

> To be frank, I would just rather have access to the constructor to Fixed.
>
> It honestly strikes me as silly to have to pay for a division and/or
> multiplication every time I want to access one.
>
> There in an ideological distinction being maintained here about the one
> true usage pattern that has forced me to reimplement Data.Fixed in my own
> code to avoid the overhead. =(

Fwiw, I've sometimes wanted to have 'Int' based fixed-precision
arithmetic, and the current Data.Fixed allows only for "big-num" based
fixed-precision types.

Just a thought: Why does Data.Fixed have to be in 'base' anyway if the
interface doesn't seem to be agreed upon by everyone? Can't we split it
off into a separate package where it can more easily evolve into a
richer API?

I've done a quick head-count over the ~4600 packages on hackage
w.r.t. which import Data.Fixed, and I found the 45 packages below which
directly import it. So splitting Data.Fixed from 'base' would affect

Chart-0.16
complex-generic-0.1.1
configurator-0.2.0.1
deepseq-1.3.0.1
DisTract-0.2.5
ebeats-0.1.0
esotericbot-0.0.6
fixed-point-0.5.0.1
gearbox-1.0.0.1
Geodetic-0.4
gluturtle-0.0.56
gps-1.1
GPX-0.7.0
has-0.5.0.1
HDBC-2.3.1.1
hsc3-0.12
husk-scheme-3.6
lambdabot-4.2.3.3
network-bitcoin-1.0.1
Noise-1.0.5
penny-lib-0.4.0.0
postgresql-simple-0.2.4.1
propane-0.1
QuickCheck-2.5.1.1
quickcheck-instances-0.3.1
random-extras-0.19
random-fu-0.2.3.1
remote-0.1.1
repr-0.4.1.3
RNAwolf-0.4.0.0
rsagl-0.6.0.1
rsagl-math-0.6.0.1
safecopy-0.7.1
sindre-0.4
tamarin-prover-0.8.2.1
time-1.4.0.1
time-http-0.5
time-lens-0.3
timeparsers-0.3.2
time-w3c-0.1.0.1
webdriver-0.4
wxturtle-0.0.1
xturtle-0.1.11

cheers,
hvr
```
2 Dec 2012 10:55

### Re: Proposal: add conversion functions to Data.Fixed.

```On 02/12/12 01:25, Herbert Valerio Riedel wrote:
> Edward Kmett <ekmett <at> gmail.com> writes:
>
>> To be frank, I would just rather have access to the constructor to Fixed.
>>
>> It honestly strikes me as silly to have to pay for a division and/or
>> multiplication every time I want to access one.
>>
>> There in an ideological distinction being maintained here about the one
>> true usage pattern that has forced me to reimplement Data.Fixed in my own
>> code to avoid the overhead. =(
> Fwiw, I've sometimes wanted to have 'Int' based fixed-precision
> arithmetic, and the current Data.Fixed allows only for "big-num" based
> fixed-precision types.
>
> Just a thought: Why does Data.Fixed have to be in 'base' anyway if the
> interface doesn't seem to be agreed upon by everyone? Can't we split it
> off into a separate package where it can more easily evolve into a
> richer API?

+1 to both of these ideas.

-- Ashley
```
3 Dec 2012 16:07

### Re: Proposal: add conversion functions to Data.Fixed.

+1 to splitting off Fixed as well.

On Sun, Dec 2, 2012 at 4:55 AM, Ashley Yakeley wrote:
On 02/12/12 01:25, Herbert Valerio Riedel wrote:
Edward Kmett <ekmett <at> gmail.com> writes:

To be frank, I would just rather have access to the constructor to Fixed.

It honestly strikes me as silly to have to pay for a division and/or
multiplication every time I want to access one.

There in an ideological distinction being maintained here about the one
true usage pattern that has forced me to reimplement Data.Fixed in my own
code to avoid the overhead. =(
Fwiw, I've sometimes wanted to have 'Int' based fixed-precision
arithmetic, and the current Data.Fixed allows only for "big-num" based
fixed-precision types.

Just a thought: Why does Data.Fixed have to be in 'base' anyway if the
interface doesn't seem to be agreed upon by everyone? Can't we split it
off into a separate package where it can more easily evolve into a
richer API?

+1 to both of these ideas.

-- Ashley

```_______________________________________________
Libraries mailing list
```
7 Dec 2012 18:13

### Re: Proposal: add conversion functions to Data.Fixed.

```On Mon, Dec 03, 2012 at 10:07:32AM -0500, Edward Kmett wrote:
> +1 to splitting off Fixed as well.

Note that time uses Data.Fixed, so a split-off 'fixed' package would
still have to come with GHC.

If splitting it off I wonder if there's anything else that would
sensibly go into a 'numeric' package. Data.Ratio and Numeric are the two
that come to mind, but it looks like both have a couple of uses
elsewhere in base.

Thanks
Ian
```
7 Dec 2012 18:18

### Re: Proposal: add conversion functions to Data.Fixed.

```On Mon, Dec 3, 2012 at 4:07 PM, Edward Kmett <ekmett <at> gmail.com> wrote:
> +1 to splitting off Fixed as well.

-1 on this count from me, and a +1 to simply exposing
Data.Fixed.Fixed's constructor.

--
Gregory Collins <greg <at> gregorycollins.net>
```
7 Dec 2012 18:15

### Re: Proposal: add conversion functions to Data.Fixed.

```On Sat, Dec 01, 2012 at 09:14:28PM -0500, Edward Kmett wrote:
> To be frank, I would just rather have access to the constructor to Fixed.

I would prefer this, in Data.Fixed.Internal[s], to the original
proposal.

Thanks
Ian
```
8 Dec 2012 06:49

### Re: Proposal: add conversion functions to Data.Fixed.

```On 07/12/12 09:15, Ian Lynagh wrote:
> On Sat, Dec 01, 2012 at 09:14:28PM -0500, Edward Kmett wrote:
>> To be frank, I would just rather have access to the constructor to Fixed.
>
> I would prefer this, in Data.Fixed.Internal[s], to the original
> proposal.

Is another module really necessary? Note that fromEnum and toEnum

These are the changes I think we should make to Fixed:

1. Make the internal type generic, similar to Ratio/Rational.

2. Make access to the internal type easy and fast. Ratio has
numerator/denominator/(%), but Ratio needs to canonicalise its values to
lowest terms. Fixed doesn't need that, so exposing the constructor
should serve.

3. Move Data.Fixed into a new package, possibly with Data.Ratio and
perhaps other numerics stuff that can be moved out of base.

4. Move div', mod' and divmod' to a more sensible module and maybe
rename them, or have them replace div, mod and divmod.

I am somewhat motivated to 1 by calls to make certain time types
generic, although that's a separate discussion with its own issues.

-- Ashley
```
9 Dec 2012 03:54

### Re: Proposal: add conversion functions to Data.Fixed.

I would be a +1 to any or all of these changes. I, too, don't see the point in hiding the constructor in a separate module. Like you said, the fromEnum/toEnum instances already give away the farm.

-Edward

On Sat, Dec 8, 2012 at 12:49 AM, Ashley Yakeley wrote:

These are the changes I think we should make to Fixed:

1. Make the internal type generic, similar to Ratio/Rational.

2. Make access to the internal type easy and fast. Ratio has numerator/denominator/(%), but Ratio needs to canonicalise its values to lowest terms. Fixed doesn't need that, so exposing the constructor should serve.

3. Move Data.Fixed into a new package, possibly with Data.Ratio and perhaps other numerics stuff that can be moved out of base.

4. Move div', mod' and divmod' to a more sensible module and maybe rename them, or have them replace div, mod and divmod.

I am somewhat motivated to 1 by calls to make certain time types generic, although that's a separate discussion with its own issues.

```_______________________________________________
Libraries mailing list
```
9 Dec 2012 13:39

### Re: Proposal: add conversion functions to Data.Fixed.

```On Fri, Dec 07, 2012 at 09:49:04PM -0800, Ashley Yakeley wrote:
> On 07/12/12 09:15, Ian Lynagh wrote:
> >On Sat, Dec 01, 2012 at 09:14:28PM -0500, Edward Kmett wrote:
> >>To be frank, I would just rather have access to the constructor to Fixed.
> >
> >I would prefer this, in Data.Fixed.Internal[s], to the original
> >proposal.
>
> Is another module really necessary? Note that fromEnum and toEnum

Exporting it from Data.Fixed would also be fine with me.

Thanks
Ian
```
1 Dec 2012 10:37

### Re: Proposal: add conversion functions to Data.Fixed.

```On 28/11/12 09:07, Jeff Shaw wrote:
> - | Get a Fixed value's Integer representation and resolution.
> fromFixed :: (HasResolution a) => Fixed a -> (Integer,Integer)
> fromFixed f <at> (MkFixed i) = (i, resolution f)
>
> -- | Given an Integer representation and resolution of a Fixed value,
> -- create a new Fixed value with an arbitrary resolution.
> toFixed :: (HasResolution a) => (Integer,Integer) -> Fixed a
> toFixed (i,r0) = withResolution (\r1 -> MkFixed \$ (i * r1) `div` r0)

fromFixed f = let r = resolution f in (truncate (f * r),r)

toFixed (i,r) = fromRational (i % r)

-- Ashley
```
10 Dec 2012 07:50

### Re: Proposal: add conversion functions to Data.Fixed.

```OK, I'm seeing consensus for the simple exposure of the constructor of
the Fixed type.

If we want to pursue the project of moving stuff out of base, then
perhaps Data.Fixed, Data.Ratio and Data.Complex could all move to
another package or separate packages. But that would be a different
proposal.

-- Ashley
```
1 Jan 2013 21:01

### Re: Proposal: add conversion functions to Data.Fixed.

```On Sun, Dec 09, 2012 at 10:50:17PM -0800, Ashley Yakeley wrote:
> OK, I'm seeing consensus for the simple exposure of the constructor
> of the Fixed type.