On Fri, 18 Jul 2008, stefan kersten wrote:
On 17.07.2008, at 21:46, Lennart Augustsson wrote:
If scaleFloat and exponent are implemented with bit twiddling
they can
be quite fast.
is there a way in ghc to 'cast' between float/int32 and double/
int64 (without going through memory)?
I
On Jul 20, 2008, at 8:11 PM, Richard A. O'Keefe wrote:
I read this as
Is there any way to take a 32-bit float in a register and end up
with a 32-bit int
in a register, without going through memory, in GHC?
How about the other way around?
How about 64-bit floats
On 17.07.2008, at 21:46, Lennart Augustsson wrote:
If scaleFloat and exponent are implemented with bit twiddling they can
be quite fast.
is there a way in ghc to 'cast' between float/int32 and double/int64
(without going through memory)?
sk
___
On 18.07.2008, at 13:05, Henning Thielemann wrote:
On Fri, 18 Jul 2008, stefan kersten wrote:
On 17.07.2008, at 21:46, Lennart Augustsson wrote:
If scaleFloat and exponent are implemented with bit twiddling
they can
be quite fast.
is there a way in ghc to 'cast' between float/int32 and
On Fri, 18 Jul 2008, stefan kersten wrote:
On 17.07.2008, at 21:46, Lennart Augustsson wrote:
If scaleFloat and exponent are implemented with bit twiddling they can
be quite fast.
is there a way in ghc to 'cast' between float/int32 and double/int64 (without
going through memory)?
What
On Fri, 18 Jul 2008, stefan kersten wrote:
for implementing scaleFloat and exponent on the bitlevel as lennart
suggested, it would be preferable if the cast would be compiled to a register
move/reinterpretation, rather than a store/load through several layers of
abstraction (such as
On Thu, Jul 17, 2008 at 06:56:52PM +0200, stefan kersten wrote:
c_magnitude0 (Complex.Data.magnitude) 0m7.249s
c_magnitude1 (non-scaling version) 0m1.176s
c_magnitude2 (scaling version, strict square) 0m3.278s
Thanks!
I've filed a bug here:
sk:
On 17.07.2008, at 21:46, Lennart Augustsson wrote:
If scaleFloat and exponent are implemented with bit twiddling they can
be quite fast.
is there a way in ghc to 'cast' between float/int32 and double/int64
(without going through memory)?
Yeah,
fromIntegral/Int-Float
On 18.07.2008, at 19:47, Don Stewart wrote:
sk:
On 17.07.2008, at 21:46, Lennart Augustsson wrote:
If scaleFloat and exponent are implemented with bit twiddling
they can
be quite fast.
is there a way in ghc to 'cast' between float/int32 and double/int64
(without going through memory)?
sk:
On 18.07.2008, at 19:47, Don Stewart wrote:
sk:
On 17.07.2008, at 21:46, Lennart Augustsson wrote:
If scaleFloat and exponent are implemented with bit twiddling
they can
be quite fast.
is there a way in ghc to 'cast' between float/int32 and double/int64
(without going through
hi,
i've attached an example program which seems to indicate that the
magnitude function from Data.Complex is very slow compared to a more
naive implementation (for Complex Float). on my machine (intel core2
duo, osx 10.4) the CPU time using the library function is about 6-7
times as
On Thu, 17 Jul 2008, stefan kersten wrote:
i've attached an example program which seems to indicate that the magnitude
function from Data.Complex is very slow compared to a more naive
implementation (for Complex Float). on my machine (intel core2 duo, osx 10.4)
the CPU time using the library
On Thu, Jul 17, 2008 at 05:18:01PM +0200, Henning Thielemann wrote:
On Thu, 17 Jul 2008, stefan kersten wrote:
i've attached an example program which seems to indicate that the
magnitude function from Data.Complex is very slow compared to a more naive
implementation (for Complex Float).
On 17.07.2008, at 17:42, Ian Lynagh wrote:
On Thu, Jul 17, 2008 at 05:18:01PM +0200, Henning Thielemann wrote:
Complex.magnitude must prevent overflows, that is, if you just square
1e200::Double you get an overflow, although the end result may be
also
around 1e200. I guess, that to this end
On 17.07.2008, at 17:18, Henning Thielemann wrote:
i've attached an example program which seems to indicate that the
magnitude function from Data.Complex is very slow compared to a
more naive implementation (for Complex Float). on my machine
(intel core2 duo, osx 10.4) the CPU time using
If scaleFloat and exponent are implemented with bit twiddling they can
be quite fast.
I have a feeling that they involve slow FFI calls in GHC (being the
original author of a lot of the code involved).
On Thu, Jul 17, 2008 at 8:21 PM, stefan kersten [EMAIL PROTECTED] wrote:
On 17.07.2008, at
On Thu, 17 Jul 2008, Ian Lynagh wrote:
On Thu, Jul 17, 2008 at 05:18:01PM +0200, Henning Thielemann wrote:
Complex.magnitude must prevent overflows, that is, if you just square
1e200::Double you get an overflow, although the end result may be also
around 1e200. I guess, that to this end
On Thu, 17 Jul 2008, stefan kersten wrote:
On 17.07.2008, at 17:18, Henning Thielemann wrote:
i've attached an example program which seems to indicate that the
magnitude function from Data.Complex is very slow compared to a more naive
implementation (for Complex Float). on my machine (intel
18 matches
Mail list logo
