Michael Orlitzky | 7 Oct 20:00 2012

Ordering of BigFloats in numbers-3000.0.0.0

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

But, I'm not sure who I should contact as the maintainer. The LICENSE
file has,

  Copyright (c) 2007-2012
  Lennart Augustsson, Russell O'Connor, Richard Smith,
  Daniel Wagner, Dan Burton

The cabal file says (no email address),

  Maintainer: Lennart Augustsson

And the repo is at,

(Continue reading)

Claude Heiland-Allen | 7 Oct 20:31 2012
Picon

Re: Ordering of BigFloats in numbers-3000.0.0.0

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?

Claude
--

-- 
http://mathr.co.uk
Michael Orlitzky | 8 Oct 02:31 2012

Re: Ordering of BigFloats in numbers-3000.0.0.0

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.
Claude Heiland-Allen | 8 Oct 08:16 2012
Picon

Re: Ordering of BigFloats in numbers-3000.0.0.0

On 08/10/12 01:31, Michael Orlitzky wrote:
>> http://hackage.haskell.org/package/variable-precision
>> Mine may be unacceptably slow due to the dependent libraries.
>
> 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.

Ah thanks for the reminder that its implementation is incomplete so far 
- I do plan to implement the remaining algorithms properly but lack time 
right now, sorry.

Claude
--

-- 
http://mathr.co.uk
Chaddaï Fouché | 9 Oct 18:29 2012
Picon

Re: Ordering of BigFloats in numbers-3000.0.0.0

On Sun, Oct 7, 2012 at 8:00 PM, Michael Orlitzky <michael <at> orlitzky.com> 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.

--

-- 
Jedaï

_______________________________________________
Haskell-Cafe mailing list
(Continue reading)

Michael Orlitzky | 9 Oct 18:55 2012

Re: Ordering of BigFloats in numbers-3000.0.0.0

On 10/09/2012 12:29 PM, Chaddaï Fouché wrote:
> On Sun, Oct 7, 2012 at 8:00 PM, Michael Orlitzky <michael <at> orlitzky.com> 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:

(Continue reading)

Carter Schonwald | 10 Oct 07:20 2012
Picon

Re: Ordering of BigFloats in numbers-3000.0.0.0

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 <michael <at> orlitzky.com> wrote:
On 10/09/2012 12:29 PM, Chaddaï Fouché wrote:
> On Sun, Oct 7, 2012 at 8:00 PM, Michael Orlitzky <michael <at> orlitzky.com> 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 <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Michael Orlitzky | 12 Oct 01:11 2012

Re: Ordering of BigFloats in numbers-3000.0.0.0

On 10/10/2012 01:20 AM, Carter Schonwald wrote:
> you should probably file a ticket on the DanBurton repo if he's the one
> doing the uploading
>  :-)

Yep, and he was nice enough to merge the fix and release a new version:

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

Gmane