On 10/07/2012 02:31 PM, Claude Heiland-Allen wrote:

On 07/10/12 19:00, Michael Orlitzky wrote:

...

I'm trying to use,

http://hackage.haskell.org/package/numbers-3000.0.0.0

You might also try my:

http://hackage.haskell.org/package/variable-precision

It's Ord should work, I've used it in anger, otherwise let me know and I'll fix it when I have time!

...

to get better precision "for free" out of some numerical code.

Mine may be unacceptably slow due to the dependent libraries.

I sent some "make it turbo" patches to the maintainer of 'type-level-natural-number' but got no response, would it be ok for me to do a non-maintainer-upload that contains purely performance enhancements and no functionality changes?

I gave it a try -- the speed isn't an issue for me, but I need the trig functions (which look like they pass through Double). These are basically homework problems and related experiments for which I'm trying to avoid MATLAB at all costs, so sin and cos show up a lot.

you should probably file a ticket on the DanBurton repo if he's the one doing the uploading :-) On Tue, Oct 9, 2012 at 12:55 PM, Michael Orlitzky wrote:

On 10/09/2012 12:29 PM, Chaddaï Fouché wrote:

...

On Sun, Oct 7, 2012 at 8:00 PM, Michael Orlitzky wrote:

...

I'm trying to use,

http://hackage.haskell.org/package/numbers-3000.0.0.0

to get better precision "for free" out of some numerical code. I ran into an issue pretty quickly, though. In Data.Number.BigFloat, we have,

data BigFloat e = BF (Fixed e) Integer deriving (Eq, Ord)

and the derived Ord is obviously incorrect:

Prelude Data.Number.BigFloat> let x = 0.1 :: BigFloat Prec50 Prelude Data.Number.BigFloat> let y = 0.02 :: BigFloat Prec50 Prelude Data.Number.BigFloat> x < y True

That's pretty strange since the derived Ord should be the same as Fixed Ord, which itself is just a newtype over Rational (and 1%10 < 2%100 == False), did you try to convert those BigFloat back to Rational to see if they're still correct ? That may be worse than a misbehaving Ord instance.

The BigFloat constructor doesn't do what you think it does... I chose a bad spot to snip the comments:

-- This representation is stupid, two Integers makes more sense, -- but is more work. -- | Floating point number where the precision is determined by the -- type /e/. data BigFloat e = BF (Fixed e) Integer deriving (Eq)

If it was two Integers, I think it would be more clear that this is what will happen:

*Data.Number.BigFloat> let x = 0.1 :: BigFloat Prec50 *Data.Number.BigFloat> let y = 0.02 :: BigFloat Prec50 *Data.Number.BigFloat> let BF m1 e1 = x *Data.Number.BigFloat> let BF m2 e2 = y *Data.Number.BigFloat> (m1,e1) (1.00000000000000000000000000000000000000000000000000,-1) *Data.Number.BigFloat> (m2,e2) (2.00000000000000000000000000000000000000000000000000,-2)

The fast way to compare them would be to check the mantissa/exponent directly, but toRational works just fine. I made a pull request yesterday that compares them as rationals.

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe