Alexander is right. Also as Integer has more sense than Int, I would suggest for the future standard Haskell library to have Integer as default. For example: length :: [a] -> Integer smallLength :: [a] -> Int ----------------- Serge Mechveliani mechvel@botik.ru On Sun, Apr 25, 2004 at 03:18:20PM -0400, S. Alexander Jacobson wrote:
[..] Dell's Poweredge servers address up to 32GB of memory today! There are already 5.7 billion people on the planet (>2^31) and 741 million phone lines. In my mind, there is NO QUESTION that 2^31 keys is a reasonable size for a FiniteMap or will be in the very very near future.
Moreover, it is not clear that the CPU/memory overhead of returning Integer rather than Int for sizeFM is sufficiently high to be worth bothering the programmer about.
On Sun, 2004-04-25 Serge D. Mechveliani wrote to glasgow-haskell-users
Dear GHC developers,
Probably, it is better to provide Integer or Integral a => a instead of Int in the function sizeFM :: FiniteMap k e -> Int
Am Montag, 26. April 2004 17:06 schrieb Philippa Cowderoy:
[...]
To ask a silly question, is Int defined as 32 bits or is it defined in a similar vein to C's int?
I think it is defined to cover at least the numbers from -(2 ^ 27) + 1 to 2 ^ 27 - 1. So its exact range is implementation/platform dependent but sufficient for many/most problems. Wolfgang
Wolfgang Jeltsch <wolfgang@jeltsch.net> writes:
To ask a silly question, is Int defined as 32 bits or is it defined in a similar vein to C's int?
I think it is defined to cover at least the numbers from -(2 ^ 27) + 1 to 2 ^ 27 - 1.
Actually, according to section 6.4 of the Report: -(2 ^ 29) + 1 to 2 ^ 29 - 1. i.e. a minimum of 30 bits wide. Also, the Bounded class methods, maxBound and minBound, can be used to determine the exact Int range defined in a particular implementation. (I believe all current implementations actually use 32 bits.) Regards, Malcolm
On Mon, Apr 26, 2004 at 04:06:22PM +0100, Philippa Cowderoy wrote:
On Mon, 26 Apr 2004, Serge D. Mechveliani wrote:
Alexander is right.
Also as Integer has more sense than Int,
To ask a silly question, is Int defined as 32 bits or is it defined in a similar vein to C's int?
-- flippa@flippac.org
Probably, as in C. Anyway, the program using Int will run into an overflow or not depending on the task and on the machine.
mechvel:
On Mon, Apr 26, 2004 at 04:06:22PM +0100, Philippa Cowderoy wrote:
On Mon, 26 Apr 2004, Serge D. Mechveliani wrote:
Alexander is right.
Also as Integer has more sense than Int,
To ask a silly question, is Int defined as 32 bits or is it defined in a similar vein to C's int?
Well, you can all look this up, at least in GHC's implementation: $fptools/libraries/base/GHC/Base.lhs: data Int = I# Int# -- ^A fixed-precision integer type with at least the range @[-2^29 -- .. 2^29-1]@. The exact range for a given implementation can be -- determined by using 'minBound' and 'maxBound' from the 'Bounded' -- class. $fptools/ghc/compiler/prelude/primops.txt.pp: section "The word size story." {Haskell98 specifies that signed integers (type {\tt Int}) must contain at least 30 bits. GHC always implements {\tt Int} using the primitive type {\tt Int\#}, whose size equals the {\tt MachDeps.h} constant {\tt WORD\_SIZE\_IN\_BITS}. This is normally set based on the {\tt config.h} parameter {\tt SIZEOF\_HSWORD}, i.e., 32 bits on 32-bit machines, 64 bits on 64-bit machines. However, it can also be explicitly set to a smaller number, e.g., 31 bits, to allow the possibility of using tag bits. Currently GHC itself has only 32-bit and 64-bit variants, but 30 or 31-bit code can be exported as an external core file for use in other back ends. ... #if WORD_SIZE_IN_BITS < 32 #define INT32 Int32# #define WORD32 Word32# #else #define INT32 Int# #define WORD32 Word# #endif #if WORD_SIZE_IN_BITS < 64 #define INT64 Int64# #define WORD64 Word64# #else #define INT64 Int# #define WORD64 Word# #endif -- Don
Am Dienstag, 27. April 2004 07:09 schrieb Donald Bruce Stewart:
[...]
To ask a silly question, is Int defined as 32 bits or is it defined in a similar vein to C's int?
Well, you can all look this up, at least in GHC's implementation:
It seems that people sometimes tend to think that GHC is the norm which is, of course, not the case. Such things as the range of Int should be looked up in The Haskell Report.
[...]
Wolfgang
wolfgang:
Am Dienstag, 27. April 2004 07:09 schrieb Donald Bruce Stewart:
To ask a silly question, is Int defined as 32 bits or is it defined in a similar vein to C's int?
Well, you can all look this up, at least in GHC's implementation:
It seems that people sometimes tend to think that GHC is the norm which is, of course, not the case. Such things as the range of Int should be looked up in The Haskell Report.
Definately. I agree. And inspecting source code is often very useful too. -- Don
On Sun, Apr 25, 2004 at 03:18:20PM -0400, S. Alexander Jacobson wrote:
[..] Dell's Poweredge servers address up to 32GB of memory today! There are already 5.7 billion people on the planet (>2^31) and 741 million phone lines. In my mind, there is NO QUESTION that 2^31 keys is a reasonable size for a FiniteMap or will be in the very very near future.
I understand the Int type to be as large as pointers on each kind of hardware. So one cannot possible have any data structure whose size doesn't fit in an Int.
Moreover, it is not clear that the CPU/memory overhead of returning Integer rather than Int for sizeFM is sufficiently high to be worth bothering the programmer about.
Well, Int is built-in to any hardware, while Integer isn't. Since Int/Integer is one of the most used data types in almost any program, the difference would be _very_ big. Robert
Robert Will wrote:
I understand the Int type to be as large as pointers on each kind of hardware. [...]
... excluding "unimportant" architectures like DEC Alpha (at least with one of DEC's early C compilers), x86 in real mode, tons of embedded processors in hundreds of millions of mobile phones, digital cameras, microwave ovens, etc. :-] This assumption is simply not true in general, and that's why e.g. C99 has intptr_t and friends. And my guess is that even if the Haskell language was designed today, we would have a "bare-bones" integer type at a very prominent place. Losing a factor of 2-5 (wild guess) in terms of performance is simply not an option for some applications. Of course one can always wait about a year until that performance gap is filled by newer hardware, but I wouldn't want to tell that my boss... :-) And even then the factor would still exists, of course. Perhaps one could drop the Int/Integer distinction altogether if there was a global switch for what "Int" should mean. But separate compilation and the FFI would complicate things quite a bit then, I guess. Cheers, S.
On Mon, 26 Apr 2004 20:20:10 +0200, Sven Panne <Sven.Panne@aedion.de> wrote:
Perhaps one could drop the Int/Integer distinction altogether if there was a global switch for what "Int" should mean. But separate compilation and the FFI would complicate things quite a bit then, I guess.
Hello, Haskell newbie here. Some languages handle the Int/Integer question automatically, determined by the size of the integer in question. Int is used until the integer excedes what the underlying architecture can handle, then the switch is made to Integer (bignum). Is this something that could be handled similarly by the Haskell compiler without violating anything? Just thinking out loud... -- Don Groves
Am Montag, 26. April 2004 20:45 schrieb Don Groves:
[...]
Hello, Haskell newbie here.
Some languages handle the Int/Integer question automatically, determined by the size of the integer in question. Int is used until the integer excedes what the underlying architecture can handle, then the switch is made to Integer (bignum). Is this something that could be handled similarly by the Haskell compiler without violating anything? Just thinking out loud... -- Don Groves
Hello Don, strictly speaking, you cannot choose between Int or Integer depending on the actual value of your number because the type of an expression has to be known at compile time while the exact value is mostly known only at runtime. But you can have a type which uses a "small int" representation for small numbers and a "big int" representation for big numbers. This is probably what you mean, and this is AFAIK exactly what at least GHC's Integer does. So GHC's Integer uses a fast representation for small numbers. But a program still needs time for testing if a given Integer is represented the "small" or the "big" way, it needs time for testing, if a calculation results in a number representable by the "small" representation etc. So Integer will always be a bit slower than Int. Wolfgang
On Mon, Apr 26, 2004 at 08:58:53PM +0200, Wolfgang Jeltsch wrote:
Am Montag, 26. April 2004 20:45 schrieb Don Groves:
Some languages handle the Int/Integer question automatically, determined by the size of the integer in question. Int is used until the integer excedes what the underlying architecture can handle, then the switch is made to Integer (bignum). Is this something that could be handled similarly by the Haskell compiler without violating anything? Just thinking out loud...
But you can have a type which uses a "small int" representation for small numbers and a "big int" representation for big numbers. This is probably what you mean, and this is AFAIK exactly what at least GHC's Integer does.
indeed: (Using GHC "unboxed types" with -fglasgow-exts) data Integer = S# Int# | J# Int# ByteArray# Prelude GHC.Exts> case 2^20::Integer of S# i -> S# i 1048576 Prelude GHC.Exts> case 2^200::Integer of S# i -> S# i *** Exception: <interactive>:1: Non-exhaustive patterns in case Have a nice day, Remi -- Nobody can be exactly like me. Even I have trouble doing it.
On Mon, 26 Apr 2004 21:21:09 +0200, Remi Turk <rturk@science.uva.nl> wrote:
On Mon, Apr 26, 2004 at 08:58:53PM +0200, Wolfgang Jeltsch wrote:
Am Montag, 26. April 2004 20:45 schrieb Don Groves:
Some languages handle the Int/Integer question automatically, determined by the size of the integer in question. Int is used until the integer excedes what the underlying architecture can handle, then the switch is made to Integer (bignum). Is this something that could be handled similarly by the Haskell compiler without violating anything? Just thinking out loud...
But you can have a type which uses a "small int" representation for small numbers and a "big int" representation for big numbers. This is probably what you mean, and this is AFAIK exactly what at least GHC's Integer does.
indeed: (Using GHC "unboxed types" with -fglasgow-exts)
data Integer = S# Int# | J# Int# ByteArray#
Prelude GHC.Exts> case 2^20::Integer of S# i -> S# i 1048576 Prelude GHC.Exts> case 2^200::Integer of S# i -> S# i *** Exception: <interactive>:1: Non-exhaustive patterns in case
Wolfgang and Remi, Thanks to you both for the explanation. Yes, the GHC Integer type does what I was referring to and clearly anything done at runtime will slow execution. For future reference, if I know an integer will never exceed an Int, I should type it that way to optimize speed; but using Integer will optimize safety - right? -- Don
Am Dienstag, 27. April 2004 00:55 schrieb Don Groves:
[...]
Wolfgang and Remi,
Thanks to you both for the explanation. Yes, the GHC Integer type does what I was referring to and clearly anything done at runtime will slow execution.
For future reference, if I know an integer will never exceed an Int, I should type it that way to optimize speed; but using Integer will optimize safety - right?
Right. If performance is not such a big concern it would also be appropriate to always use Integer. Then you would always be on the safe side.
Don
Wolfgang
On Mon, 26 Apr 2004, Robert Will wrote:
I understand the Int type to be as large as pointers on each kind of hardware. So one cannot possible have any data structure whose size doesn't fit in an Int.
If my data structure is created/destroyed lazily, I don't see why not. Trivially, [0..2^128]. Or, if my data structure maps to a file in some way....See my prior post on the annoyance of hFileSize vs take.
Moreover, it is not clear that the CPU/memory overhead of returning Integer rather than Int for sizeFM is sufficiently high to be worth bothering the programmer about.
Well, Int is built-in to any hardware, while Integer isn't. Since Int/Integer is one of the most used data types in almost any program, the difference would be _very_ big.
I'll cite that hoary Hoare quotation here. "Premature optimization is the root of all evil." People who need high performance can use specialized int functions where it is truly necessary. Everywhere else it is a waste of programmer time to force futzing. -Alex- _________________________________________________________________ S. Alexander Jacobson mailto:me@alexjacobson.com tel:917-770-6565 http://alexjacobson.com
G'day all. Quoting "S. Alexander Jacobson" <alex@i2x.com>:
I'll cite that hoary Hoare quotation here. "Premature optimization is the root of all evil."
Agreed! In particular, functions meant for general use, especially in the standard library, should not optimise for a specific case and pessimise for all other cases. Much evil has budded from library implementors who thought they knew better than application programmers about what performance models were appropriate. (If you don't believe me, ask a C++ developer about reference-counted strings and multi- threading some time.) Making sizeFM return Integer optimises the operation for cases where the FiniteMaps are extremely huge and pessimises it for all cases where the FiniteMaps are not extremely huge. Not only is this premature optimisation, it's optimising for the empirically LEAST likely case. Now that I think of it, it would make far more sense for the type to be completely general: sizeFM :: (Ord key, Integral size) => FiniteMap key elt -> size This way, sizeFM can optimise itself for the situation at hand. Cheers, Andrew Bromage
"Serge D. Mechveliani" <mechvel@botik.ru> writes:
Alexander is right.
Also as Integer has more sense than Int, I would suggest for the future standard Haskell library to have Integer as default. For example: length :: [a] -> Integer smallLength :: [a] -> Int
Hmm...isn't it possible to use a class here? Perhaps even Num? class Num a where .... : length :: [b] -> a : -kzm -- If I haven't seen further, it is by standing in the footprints of giants
On Mon, Apr 26, 2004 at 10:09:18PM +0200, Ketil Malde wrote:
"Serge D. Mechveliani" <mechvel@botik.ru> writes:
Alexander is right.
Also as Integer has more sense than Int, I would suggest for the future standard Haskell library to have Integer as default. For example: length :: [a] -> Integer smallLength :: [a] -> Int
Hmm...isn't it possible to use a class here? Perhaps even Num?
class Num a where .... : length :: [b] -> a :
I think, for many functions, like length, it is most natural to return Integer only. And it is also natural for many instances (domains) D to provide maps like toInteger, fromInteger. Just follow mathematics. Example: length xs :: (Rational, Rational) looks unnatural, but fromInteger (length xs) :: (Rational, Rational) looks natural. ----------------- Serge Mechveliani mechvel@botik.ru
participants (12)
-
ajb＠spamcop.net -
Don Groves -
dons＠cse.unsw.edu.au -
Ketil Malde -
Malcolm Wallace -
Philippa Cowderoy -
Remi Turk -
Robert Will -
S. Alexander Jacobson -
Serge D. Mechveliani -
Sven Panne -
Wolfgang Jeltsch