Why aren't Float and Double Bounded?

newer
RFI: HDBC-1.1.3 build error

older
A tale of Project Euler

Jason Dusek

26 Nov 2007 26 Nov '07

9:20 p.m.

Among numeric types, it seems that only integer types are Bounded. -- _jsn

Show replies by date

Henning Thielemann

27 Nov 27 Nov

10:52 a.m.

On Mon, 26 Nov 2007, Jason Dusek wrote:

...

Among numeric types, it seems that only integer types are Bounded.

Maybe because IEEE format supports Infinity?

Isaac Dupree

2:41 p.m.

Henning Thielemann wrote:

...

On Mon, 26 Nov 2007, Jason Dusek wrote:

...
Among numeric types, it seems that only integer types are Bounded.

Maybe because IEEE format supports Infinity?

therefore, maxBound is Infinity and minBound negative infinity? Isaac

Josh Lee

3:16 p.m.

On Tue, 27 Nov 2007 14:41:59 -0500 Isaac Dupree wrote:

...

Henning Thielemann wrote:

...
On Mon, 26 Nov 2007, Jason Dusek wrote:

...
Among numeric types, it seems that only integer types are Bounded.

Maybe because IEEE format supports Infinity?

therefore, maxBound is Infinity and minBound negative infinity?

Using Infinity would go against the meaning of Enum. In the Double/Float types, succ and pred mean "add/subtract 1.0", as opposed to the unit of least precision. In fact, succ and pred lose meaning once the precision of the floats exceeds a certain value.

...

until (\x -> x == succ x) succ 1.0 :: Float 1.6777216e7

It would be interesting to have an enumeration for Double/Float that goes from -Infinity to Infinity, reaching every single number on the way. Josh Lee

Andrew Coppin

3:25 p.m.

Josh Lee wrote:

...

On Tue, 27 Nov 2007 14:41:59 -0500 Isaac Dupree wrote:

...
Henning Thielemann wrote:

...
On Mon, 26 Nov 2007, Jason Dusek wrote:

...
Among numeric types, it seems that only integer types are Bounded.

Maybe because IEEE format supports Infinity?

therefore, maxBound is Infinity and minBound negative infinity?

Using Infinity would go against the meaning of Enum.

Perhaps. But we're talking about Bounded, not Enum. ;-)

Henning Thielemann

3:28 p.m.

On Tue, 27 Nov 2007, Josh Lee wrote:

...

On Tue, 27 Nov 2007 14:41:59 -0500 Isaac Dupree wrote:

...
Henning Thielemann wrote:

...
On Mon, 26 Nov 2007, Jason Dusek wrote:

...
Among numeric types, it seems that only integer types are Bounded.

Maybe because IEEE format supports Infinity?

therefore, maxBound is Infinity and minBound negative infinity?

Using Infinity would go against the meaning of Enum. In the Double/Float types, succ and pred mean "add/subtract 1.0", as opposed to the unit of least precision. In fact, succ and pred lose meaning once the precision of the floats exceeds a certain value.

...
until (\x -> x == succ x) succ 1.0 :: Float 1.6777216e7

It would be interesting to have an enumeration for Double/Float that goes from -Infinity to Infinity, reaching every single number on the way.

Actually, IEEE numbers are designed in such a way, that if you interpret their bits as integer number, then 'succ' leads you to the next larger representable number. Thus you only have to cast from Float or Double to Int32 or Int64 respectively, call enumFromTo, then cast back to Float or Double, respectively. :-]

Bit Connor

3:54 p.m.

...

Actually, IEEE numbers are designed in such a way, that if you interpret their bits as integer number, then 'succ' leads you to the next larger representable number. Thus you only have to cast from Float or Double to Int32 or Int64 respectively, call enumFromTo, then cast back to Float or Double, respectively. :-]

How do you cast from Float to Int32(or Word32), and back again? I couldn't find an appropriate function. Only thing I can see is going through the Storable interface, but that seems cumbersome and I imagine slow. Also, a related question: How do you convert from Float -> Double, and the reverse? Only thing I could find is (fromRational . toRational) which I also imagine to be slow, and I also wonder about accuracy. Thanks, Bit

Henning Thielemann

4:11 p.m.

On Tue, 27 Nov 2007, Bit Connor wrote:

...

...
Actually, IEEE numbers are designed in such a way, that if you interpret their bits as integer number, then 'succ' leads you to the next larger representable number. Thus you only have to cast from Float or Double to Int32 or Int64 respectively, call enumFromTo, then cast back to Float or Double, respectively. :-]

How do you cast from Float to Int32(or Word32), and back again? I couldn't find an appropriate function. Only thing I can see is going through the Storable interface, but that seems cumbersome and I imagine slow.

As Don pointed out correctly I'm evil. Storable is a fine way, since it makes a hack look like a hack. Or you might use castSTUArray.

...

Also, a related question: How do you convert from Float -> Double, and the reverse? Only thing I could find is (fromRational . toRational) which I also imagine to be slow, and I also wonder about accuracy.

Rational keeps full precision. Performance - I don't know, maybe it's fused away? When I started with Haskell I regularly needed conversion between Float and Double. I don't know why. I haven't needed it for a long time now.

Yitzchak Gale

4:15 p.m.

Bit Connor wrote:

...

Also, a related question: How do you convert from Float -> Double, and the reverse? Only thing I could find is (fromRational . toRational) which I also imagine to be slow, and I also wonder about accuracy.

realToFrac -Yitz

Henning Thielemann

4:27 p.m.

On Tue, 27 Nov 2007, Yitzchak Gale wrote:

...

Bit Connor wrote:

...
Also, a related question: How do you convert from Float -> Double, and the reverse? Only thing I could find is (fromRational . toRational) which I also imagine to be slow, and I also wonder about accuracy.

realToFrac

added to http://www.haskell.org/haskellwiki/Converting_numbers

Jules Bean

28 Nov 28 Nov

8:03 a.m.

Josh Lee wrote:

...

On Tue, 27 Nov 2007 14:41:59 -0500 Isaac Dupree wrote:

...
...
On Mon, 26 Nov 2007, Jason Dusek wrote:

...
Among numeric types, it seems that only integer types are Bounded. Maybe because IEEE format supports Infinity?

Henning Thielemann wrote: therefore, maxBound is Infinity and minBound negative infinity?

Using Infinity would go against the meaning of Enum. In the Double/Float types, succ and pred mean "add/subtract 1.0", as opposed to the unit of least precision. In fact, succ and pred lose meaning once the precision of the floats exceeds a certain value.

That's not the meaning of Enum. That's brokenness :) It's there so that [1..10] :: [Double] works, but it's a horrible horrible thing. The overloaded [a..b] notation should not be in Enum but some other class (I suggest ICanHazInturval as the class name). Oh well. Jules

Lennart Augustsson

27 Nov 27 Nov

8:19 p.m.

But IEEE can be run with projective infinity in which case there is only one of them. On Nov 27, 2007 7:41 PM, Isaac Dupree wrote:

...

Henning Thielemann wrote:

...
On Mon, 26 Nov 2007, Jason Dusek wrote:

...
Among numeric types, it seems that only integer types are Bounded.

Maybe because IEEE format supports Infinity?

therefore, maxBound is Infinity and minBound negative infinity?

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

Isaac Dupree

8:37 p.m.

...

...
...
...
Among numeric types, it seems that only integer types are Bounded. Maybe because IEEE format supports Infinity? therefore, maxBound is Infinity and minBound negative infinity? But IEEE can be run with projective infinity in which case there is only one of them.

Well, if Double becomes a proper member of Ord (which it already almost never is, because of NaN), then, since it is defined by a finite number of bits, it can be Bounded. Maybe this means "projective infinity" breaks Ord like NaN does. Any of this potential variation in Double obviously breaks referential transparency too, if it depends on what implementation you're using. succ/pred are odd for Double too; even if Bounded and defined by a finite number of bits, you would not be able to have a finite [minBound..0] or [minBound..maxBound]. Basically, it's not Bounded, not for a particular reason, but just because it's rather broken from a Haskell point of view anyway, IMHO. Isaac

6384

Age (days ago)

6385

Last active (days ago)

List overview

Download

12 comments

9 participants

participants (9)

Andrew Coppin
Bit Connor
Henning Thielemann
Isaac Dupree
Jason Dusek
Josh Lee
Jules Bean
Lennart Augustsson
Yitzchak Gale