On 12 May 2006 00:47, John Meacham wrote:
On Thu, May 11, 2006 at 02:57:30PM +0100, Simon Marlow wrote:
On the other hand, keeping intermediate Doubles to 80-bit precision
is both (a) non-portable and (b) unpredictable (the programmer
doesn't know which intermediates are going to be stored in
simonmar:
On 12 May 2006 00:47, John Meacham wrote:
On Thu, May 11, 2006 at 02:57:30PM +0100, Simon Marlow wrote:
On the other hand, keeping intermediate Doubles to 80-bit precision
is both (a) non-portable and (b) unpredictable (the programmer
doesn't know which intermediates are going
Donald Bruce Stewart wrote:
simonmar:
On 12 May 2006 00:47, John Meacham wrote:
On Thu, May 11, 2006 at 02:57:30PM +0100, Simon Marlow wrote:
On the other hand, keeping intermediate Doubles to 80-bit precision
is both (a) non-portable and (b) unpredictable (the programmer
doesn't know
john:
On Fri, May 12, 2006 at 10:19:18AM +0100, Simon Marlow wrote:
Especially since even:
checking Haskell type for intmax_t... not supported
checking Haskell type for uintmax_t... not supported
aren't universal :)
Well, yes. Any suggestions for what to do here? Make
John Meacham wrote:
also, incidentally, for anyone on x86 that cares about math performance,
use -optc-fsse2 to make it use the much nicer math coprocessor available
on modern x86 cpus.
I object to its characterization as nicer. It's faster, but *lower
precision*. It worries me that people
Ben Rudiak-Gould wrote:
John Meacham wrote:
also, incidentally, for anyone on x86 that cares about math performance,
use -optc-fsse2 to make it use the much nicer math coprocessor available
on modern x86 cpus.
I object to its characterization as nicer. It's faster, but *lower
precision*. It
On Thu, 2006-05-11 at 14:57 +0100, Simon Marlow wrote:
On the other hand, keeping intermediate Doubles to 80-bit precision is
both (a) non-portable and (b) unpredictable (the programmer doesn't know
which intermediates are going to be stored in 80 bits, and turning on
optimisation will
Simon Marlow wrote:
I suppose you might argue that extra precision is always good.
Well... I'm having a hard time thinking of a situation where it isn't. I
realize that people want reproducibility, I'm just not convinced that they
should. The situations where optimization flags make a
On Thu, May 11, 2006 at 02:57:30PM +0100, Simon Marlow wrote:
On the other hand, keeping intermediate Doubles to 80-bit precision is
both (a) non-portable and (b) unpredictable (the programmer doesn't know
which intermediates are going to be stored in 80 bits, and turning on
optimisation
On Fri, 2006-05-12 at 00:34 +0100, Ben Rudiak-Gould wrote:
Simon Marlow wrote:
I suppose you might argue that extra precision is always good.
Well... I'm having a hard time thinking of a situation where it isn't.
Wastes space in the cache tree, slowing down the program
and limiting the max
skaller wrote:
On Fri, 2006-05-12 at 00:34 +0100, Ben Rudiak-Gould wrote:
Simon Marlow wrote:
I suppose you might argue that extra precision is always good.
Well... I'm having a hard time thinking of a situation where it isn't.
Wastes space in the cache tree, slowing down the program
and
John Meacham wrote:
On Thu, Apr 06, 2006 at 04:28:01PM -0700, John Meacham wrote:
I was curious if ghc could support the following basic types, they will
likely just be aliases of existing types.
WordPtr uintptr_t
WordMax uintmax_t
IntPtr intptr_t
IntMax intmax_t
all these C types are
John Meacham:
On Tue, May 02, 2006 at 03:29:16AM +, Aaron Denney wrote:
On 2006-04-29, Manuel M T Chakravarty [EMAIL PROTECTED] wrote:
Am Donnerstag, den 06.04.2006, 16:37 -0700 schrieb John Meacham:
On Thu, Apr 06, 2006 at 04:28:01PM -0700, John Meacham wrote:
I was curious if
On Tue, May 02, 2006 at 03:29:16AM +, Aaron Denney wrote:
On 2006-04-29, Manuel M T Chakravarty [EMAIL PROTECTED] wrote:
Am Donnerstag, den 06.04.2006, 16:37 -0700 schrieb John Meacham:
On Thu, Apr 06, 2006 at 04:28:01PM -0700, John Meacham wrote:
I was curious if ghc could support the
On 2006-04-29, Manuel M T Chakravarty [EMAIL PROTECTED] wrote:
Am Donnerstag, den 06.04.2006, 16:37 -0700 schrieb John Meacham:
On Thu, Apr 06, 2006 at 04:28:01PM -0700, John Meacham wrote:
I was curious if ghc could support the following basic types, they will
likely just be aliases of
Am Donnerstag, den 06.04.2006, 16:37 -0700 schrieb John Meacham:
On Thu, Apr 06, 2006 at 04:28:01PM -0700, John Meacham wrote:
I was curious if ghc could support the following basic types, they will
likely just be aliases of existing types.
WordPtr uintptr_t
WordMax uintmax_t
IntPtr
On Thu, Apr 06, 2006 at 04:28:01PM -0700, John Meacham wrote:
I was curious if ghc could support the following basic types, they will
likely just be aliases of existing types.
WordPtr uintptr_t
WordMax uintmax_t
IntPtr intptr_t
IntMax intmax_t
all these C types are defined by ISO C so
17 matches
Mail list logo
