[Haskell-cafe] Re: RealFrac methods for Double and Float

[Antoine Latter]

On Sun, Oct 10, 2010 at 7:02 PM, Daniel Fischer
<daniel.is.fischer at web.de> wrote:
> Greetings,
>
> I have put together a package to test possible implementations of the
> RealFrac methods for Double and Float (base-2 IEEE754) and uploaded a
> .tar.gz bundle to http://hackage.haskell.org/trac/ghc/ticket/2271 .
>
> On the one hand, pure Haskell implementations, on the other hand
> implementations calling out to rint[f], trunc[f], floor[f] and ceil[f] from
> math.h.
>
> Both ways go via Integer by default, with a specialised faster
> implementation for Int (and narrower types, but those RULES haven't yet
> been written) enabled by a rewrite rule.
>
> Overall, the pure Haskell implementations don't fare badly on my computer.
> All give a speedup compared to the current implementation, for most
> conversions, pure Haskell is on par with or faster than the C-call
> (although that would probably change if the C functions were made primops).
>
> The FFI calls are significantly faster for
> properFraction :: Double -> (Integer, Double)
> and for round (except round :: Integral a => Float -> a when compiled
> via C, then native and FFI are on par).
>
> Sample results for the speedups against the current implementation (note:
> for truncate :: x -> Int, the Prelude value is fst . properFraction, not
> the rewritten float2Int or double2Int) are included in the tarball.
>
> I would appreciate feedback from your tests/benchmarks on other platforms,
> especially 64-bit platforms (mine is x86 linux, 32 bit).
>
> To run the QuickCheck tests, you need QuickCheck-2.*, to run the
> benchmarks, criterion.
>
> More instructions in the README.
>
> Thanks,
> Daniel
>

I got a lot of errors (or warnings?) during compilation. Is it
something I should worry about?

I'm using GHC 6.12.1 on 64-bit Linux.

Antoine

+++++
$sh build.sh
[1 of 1] Compiling Main             ( getSummary.hs, getSummary.o )
Linking getSummary ...
building with the NCG
[1 of 1] Compiling RFDouble         ( RFDouble.hs, RFDouble.o )

RFDouble.hs:88:31: Not in scope: `negateInt64#'

RFDouble.hs:89:33: Not in scope: `negateInt64#'

RFDouble.hs:92:37: Not in scope: `minusInt64#'

RFDouble.hs:111:31: Not in scope: `negateInt64#'

RFDouble.hs:112:33: Not in scope: `negateInt64#'

RFDouble.hs:146:40: Not in scope: `minusInt64#'
[1 of 1] Compiling RFFloat          ( RFFloat.hs, RFFloat.o )
[1 of 2] Compiling RFDouble         ( RFDouble.hs, RFDouble.o )

RFDouble.hs:88:31: Not in scope: `negateInt64#'

RFDouble.hs:89:33: Not in scope: `negateInt64#'

RFDouble.hs:92:37: Not in scope: `minusInt64#'

RFDouble.hs:111:31: Not in scope: `negateInt64#'

RFDouble.hs:112:33: Not in scope: `negateInt64#'

RFDouble.hs:146:40: Not in scope: `minusInt64#'
[2 of 2] Compiling Main             ( benchFloat.hs, benchFloat.o )
Linking benchFloat ...
building via C
[1 of 1] Compiling RFDouble         ( RFDouble.hs, RFDouble.o )

RFDouble.hs:88:31: Not in scope: `negateInt64#'

RFDouble.hs:89:33: Not in scope: `negateInt64#'

RFDouble.hs:92:37: Not in scope: `minusInt64#'

RFDouble.hs:111:31: Not in scope: `negateInt64#'

RFDouble.hs:112:33: Not in scope: `negateInt64#'

RFDouble.hs:146:40: Not in scope: `minusInt64#'
[1 of 1] Compiling RFFloat          ( RFFloat.hs, RFFloat.o )
[1 of 2] Compiling RFDouble         ( RFDouble.hs, RFDouble.o )

RFDouble.hs:88:31: Not in scope: `negateInt64#'

RFDouble.hs:89:33: Not in scope: `negateInt64#'

RFDouble.hs:92:37: Not in scope: `minusInt64#'

RFDouble.hs:111:31: Not in scope: `negateInt64#'

RFDouble.hs:112:33: Not in scope: `negateInt64#'

RFDouble.hs:146:40: Not in scope: `minusInt64#'
Linking cbenchFloat ...
[1 of 2] Compiling RFDouble         ( RFDouble.hs, RFDouble.o )

RFDouble.hs:88:31: Not in scope: `negateInt64#'

RFDouble.hs:89:33: Not in scope: `negateInt64#'

RFDouble.hs:92:37: Not in scope: `minusInt64#'

RFDouble.hs:111:31: Not in scope: `negateInt64#'

RFDouble.hs:112:33: Not in scope: `negateInt64#'

RFDouble.hs:146:40: Not in scope: `minusInt64#'
+++++