you should probably file a ticket on the DanBurton repo if he's the one doing the uploading<div> :-)<div><br><br><div class="gmail_quote">On Tue, Oct 9, 2012 at 12:55 PM, Michael Orlitzky <span dir="ltr"><<a href="mailto:michael@orlitzky.com" target="_blank">michael@orlitzky.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 10/09/2012 12:29 PM, Chaddaï Fouché wrote:<br>
> On Sun, Oct 7, 2012 at 8:00 PM, Michael Orlitzky <<a href="mailto:michael@orlitzky.com">michael@orlitzky.com</a>> wrote:<br>
>> I'm trying to use,<br>
>><br>
>> <a href="http://hackage.haskell.org/package/numbers-3000.0.0.0" target="_blank">http://hackage.haskell.org/package/numbers-3000.0.0.0</a><br>
>><br>
>> to get better precision "for free" out of some numerical code. I ran<br>
>> into an issue pretty quickly, though. In Data.Number.BigFloat, we have,<br>
>><br>
>> data BigFloat e = BF (Fixed e) Integer<br>
>> deriving (Eq, Ord)<br>
>><br>
>> and the derived Ord is obviously incorrect:<br>
>><br>
>> Prelude Data.Number.BigFloat> let x = 0.1 :: BigFloat Prec50<br>
>> Prelude Data.Number.BigFloat> let y = 0.02 :: BigFloat Prec50<br>
>> Prelude Data.Number.BigFloat> x < y<br>
>> True<br>
>><br>
><br>
> That's pretty strange since the derived Ord should be the same as<br>
> Fixed Ord, which itself is just a newtype over Rational (and 1%10 <<br>
> 2%100 == False), did you try to convert those BigFloat back to<br>
> Rational to see if they're still correct ? That may be worse than a<br>
> misbehaving Ord instance.<br>
><br>
<br>
</div>The BigFloat constructor doesn't do what you think it does... I chose a<br>
bad spot to snip the comments:<br>
<br>
-- This representation is stupid, two Integers makes more sense,<br>
-- but is more work.<br>
-- | Floating point number where the precision is determined by the<br>
-- type /e/.<br>
<div class="im"> data BigFloat e = BF (Fixed e) Integer<br>
</div> deriving (Eq)<br>
<br>
If it was two Integers, I think it would be more clear that this is what<br>
will happen:<br>
<br>
*Data.Number.BigFloat> let x = 0.1 :: BigFloat Prec50<br>
*Data.Number.BigFloat> let y = 0.02 :: BigFloat Prec50<br>
*Data.Number.BigFloat> let BF m1 e1 = x<br>
*Data.Number.BigFloat> let BF m2 e2 = y<br>
*Data.Number.BigFloat> (m1,e1)<br>
(1.00000000000000000000000000000000000000000000000000,-1)<br>
*Data.Number.BigFloat> (m2,e2)<br>
(2.00000000000000000000000000000000000000000000000000,-2)<br>
<br>
The fast way to compare them would be to check the mantissa/exponent<br>
directly, but toRational works just fine. I made a pull request<br>
yesterday that compares them as rationals.<br>
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
</div></div></blockquote></div><br></div></div>