Re: Int vs Integer

At 15:47 +0100 98/10/07, Simon Marlow wrote: >On the subject of Int vs. Integer, have folk actually looked at the >GHC/Hugs libraries for fixed-size integers and words, namely Int and >Word respectively? ... >If Int were to disappear, most people could just 'import Int'

Re: Int vs Integer

[please use the following URL instead http://www.dcs.gla.ac.uk/fp/software/ghc/lib/hg-libs.html as it contains a more up-to-date version. -moderator] On the subject of Int vs. Integer, have folk actually looked at the GHC/Hugs libraries for fixed-size integers and words, namely Int and

Re: Int vs Integer

At 09:40 +0100 98/10/07, S.J.Thompson wrote: >1. There is a meta argument that we simply have not reached a consensus on >this issue: there are options -- such as a `word' view of Int -- which need >to be looked at, and there are details to do with libraries which need to be >niggled over. It ther

Int vs. Integer

Hi Simon, This really seems to have touched off a firestorm! I think the meta-argument made by Simon T (and by you) is sensible, so I don't object to maintaining the status quo. But you implied that changing the libraries led to `a ball of spaghetti', and I don't see that, can you please explain

Int vs Integer

I would like to support Simon PJ's suggestion about Ints and Integers for three reasons. 1. There is a meta argument that we simply have not reached a consensus on this issue: there are options -- such as a `word' view of Int -- which need to be looked at, and there are details to do with librar

Re: Int vs Integer

> I'm confused. I thought at the ICFP Haskell meeting we agreed > on the following types: > >length :: Integral i => [a] -> i >take, drop :: Integeral i => i -> [a] -> [a] >showsPrec :: (Show a, Integral i) => i -> a -> ShowS > I'm not against adopting a conservative de

Re: Int vs Integer

at Yale, >I must say that I am now strongly inclined to adopt (2); that is, >to make Haskell 98 be the same as Haskell 1.4 on Int vs Integer matter. >(This differs from the view put forth on the "state of play" web page.) > >The more this topic gets discussed the more I that

Int vs Integer & others

> Following quite a bit of discussion at a meeting at ICFP, > and subsequent discussion with a smaller group at Yale, > I must say that I am now strongly inclined to adopt (2); that is, > to make Haskell 98 be the same as Haskell 1.4 on Int vs Integer matter. > (This differs fr

Re: Int vs Integer

> I must say that I am now strongly inclined to adopt (2); that is, > to make Haskell 98 be the same as Haskell 1.4 on Int vs Integer matter. Thank you Simon for those sensible words. I'm for a very conservative design for Haskell 98; we can always play around with new ideas in Haskel

Re: Int vs Integer

> I don't understand this. For old programmes, the right thing to do > would surely be to use the compiler to determine which modules require > the addition of "import Int", and if the standard prelude has the > above declaration, wouldn't it make it harder? Probably one would put > an explicit

Re: Int vs Integer

Simon proposes not to change the prelude to support Integer, giving this argument: The more this topic gets discussed the more I that it's like other Prelude things: you pull on one thing and the plate of spaghetti ends up in your lap. I'm confused. I thought at the ICFP Haskell meeting w

RE: Int vs Integer

uite a bit of discussion at a meeting at ICFP, and subsequent discussion with a smaller group at Yale, I must say that I am now strongly inclined to adopt (2); that is, to make Haskell 98 be the same as Haskell 1.4 on Int vs Integer matter. (This differs from the view put forth on the "state

Re: Int vs Integer

On 4 Oct, Chris Dornan wrote: > As a plain, ordinary punter could I ask for one of two things: > >1) More or less kill Int as a general-purpose type and adopt unbounded > integers (Integer) as the standard integral type. If you do this then > please put > > type Int =

Re: Int vs Integer

As a plain, ordinary punter could I ask for one of two things: 1) More or less kill Int as a general-purpose type and adopt unbounded integers (Integer) as the standard integral type. If you do this then please put type Int = Integer into the standard prelude.

Re: Int vs Integer

At 19:54 +0100 98/09/24, [EMAIL PROTECTED] wrote: >> The generalization of the Int type, as I see it, is a binary type, a >> sequence of bit of fixed length, which has special operations such as >> right/left shift with under/overflow, rotations, signed/unsigned arithmetic >> and Boolean bit ope

Re: Int vs Integer

At 19:54 +0100 98/09/24, [EMAIL PROTECTED] wrote: >> The generalization of the Int type, as I see it, is a binary type, a >> sequence of bit of fixed length, which has special operations such as >> right/left shift with under/overflow, rotations, signed/unsigned arithmetic >> and Boolean bit ope

Re: Int vs Integer

On 15 Sep, Hans Aberg wrote: > The generalization of the Int type, as I see it, is a binary type, a > sequence of bit of fixed length, which has special operations such as > right/left shift with under/overflow, rotations, signed/unsigned arithmetic > and Boolean bit operations. agreed, though

Re: Int vs Integer

Hans Aberg <[EMAIL PROTECTED]> writes: > At 09:35 +0100 98/09/15, Simon Marlow wrote: > >I don't think the overflow checks will be particularly expensive. > >After all, it's just a test/branch sequence, with the branch not taken > >in the common case. This is dwarfed by the costs of boxing/unbox

Re: Int vs Integer

At 11:16 -0400 98/09/15, Philip Wadler wrote: >If the goal is to make life easy for beginners (and to make it easy to >avoid overflow errors), shouldn't we generalise *all* uses of Int, so >that a beginner can use Integer uniformly everywhere, and need never >know about Int? The principle I see

Fwd: Re: Int vs Integer

Bother! Sent this only to Simon... -- Forwarded message -- From: [EMAIL PROTECTED] Subject: Re: Int vs Integer Date: Tue, 15 Sep 1998 18:15:01 +0100 (BST) To: [EMAIL PROTECTED] On 15 Sep, Simon Peyton-Jones wrote: > I think there is one powerful argument for retaining

Re: Int vs Integer

At 09:35 +0100 98/09/15, Simon Marlow wrote: >I don't think the overflow checks will be particularly expensive. >After all, it's just a test/branch sequence, with the branch not taken >in the common case. This is dwarfed by the costs of boxing/unboxing, >heap checks, and testing whether each obje

Re: Int vs Integer

At 10:26 + 98/09/15, S. Achterop IWI-120 3932 wrote: >Wouldn't it be better if Standard Haskell had "save" Int's, that is a >version that simply >would abort the program when encountering a overflow. >This can be implemented without too much of a penalty on the more relevant >benchmarks. If

Re: Int vs Integer

At 10:58 +0100 98/09/15, Keith S. Wansbrough wrote: >The binary operations (*), (+) etc are not commutative on >all types, notably Float. Are you sure you are not mixing up the words "commutative" and "associative" here? Hans Aberg * Email: Hans Aberg

Re: Int vs Integer

Simon PJ writes: > I think we should > - generalise length, splitAt, drop, take, replicate > - generalise toEnum, fromEnum > - leave (!!) alone (arrays must fit in an address space) > I don't know what to do about RealFloat. Sigh If the goal is to make life easy for beginners (

Re: Int vs Integer

> Double dispatching in Smalltalk model, as I understand it, > goes like this (using Haskell keywords for integers): > > Int, being a more primitive type, does not have to know how to > cope with Integer in the situations like this: Int * Integer. > So the method (*)

Re: Int vs Integer

Hans Aberg <[EMAIL PROTECTED]> writes: > The real difficulty to upper the Integer/Int ratio of 4.5 for integers > fitting into a word is to minimize those overflow checks. So this part > should be written in assembler, I think. I don't think the overflow checks will be particularly expensive.

Int vs Integer

There's been quite a bit of mail about the Int vs Integer thing. Here's what I conclude: * Integer should be the *default* integral type. That is, if you say (length xs > length ys), where the type at which length is computed is ambiguous, then that type should default to Intege

Re: Int vs Integer

ch" myself (in a C++ program I wrote) where one can return function pointers as a replacement for the function returning it. But I do not think "double dispatch" has anything to do with the Int vs. Integer question. Hans Aberg * Email: Hans Aberg &

Re: Int vs Integer

> "Jan" == Jan Skibinski <[EMAIL PROTECTED]> writes: > One of the myths was that Smalltalk was notoriously slow for > math. I checked this last time four years ago in a context > of comparative tests between Smalltalk and Eiffel interpreter Speed comparison of interpreters is pretty much poin

Re: Int vs Integer

t I do not think "double dispatch" has anything to do with the Int vs. > Integer question. > In a sense it has, I think - unless we are talking about two different things. Sooner or later, if one wants to marry speed with safety, one has to admit operations

Re: Int vs Integer

At 11:14 +0400 98/09/14, S.D.Mechveliani wrote: >Here is some simple benchmark for Int vs Integer performance. > >In the system i use, it gives the time ratio Integer/Int >(for the whole task) = 4.5. At 23:13 +0100 98/09/13, Simon Marlow wrote: >The plan is to use

Re: Int vs Integer

Hello! On Sun, Sep 13, 1998 at 11:13:35PM +0100, Simon Marlow wrote: > [...] > The plan is to use something like > data Integer = Small Int# | Big { ... } > where '...' is the GMP representation. You then need a full set of > [...] Sounds fine. Just a question, will there remain an Int

Re: Int vs Integer

Felix Schroeter writes: > Hello! > > On Sun, Sep 13, 1998 at 11:13:35PM +0100, Simon Marlow wrote: > > [...] > > > The plan is to use something like > > > data Integer = Small Int# | Big { ... } > > > where '...' is the GMP representation. You then need a full set of > > [...] > > Soun

Re: Int vs Integer

On 13 Sep, Simon Marlow wrote: > The common case of applying a dyadic operation to small Integers would > then be pretty close in performance to that of Int (a couple of > indirect jumps, and a test/branch for the overflow detection, to be > precise). Now that's more like what I had in mind. Isn

Int vs Integer benchmark

Here is some simple benchmark for Int vs Integer performance. In the system i use, it gives the time ratio Integer/Int (for the whole task) = 4.5. The difference is obtained only by switching Z = Integer, Int. -- Sergey Mechveliani [EMAIL PROTECTED

Re: Int vs Integer

> At 23:13 +0100 98/09/13, Simon Marlow wrote: > >The plan is to use something like > > > > data Integer = Small Int# | Big { ... } > The real difficulty to upper the Integer/Int ratio of 4.5 for integers > fitting into a word is to minimize those overflow checks. So this part > should b

Re: Int vs Integer

[EMAIL PROTECTED] (Carl R. Witty) writes: > Sigbjorn Finne <[EMAIL PROTECTED]> writes: > > Clearly there's a range of optimisations possible here; using an > > efficiently implemented bignum library being one (not irrelevant) way > > to improve matters. Changing the representation of Integer is a

Int vs Integer

Will Partain <[EMAIL PROTECTED]> wrote on 11 September > ... > *If* it is true that the Integer-vs-Int speed penalty is 5x > (sounds plausible to me...), then I agree that (perhaps) > 2x-3x of that can be clawed back, with good engineering > effort. But I'll be surprised if you're not still l

Re: Int vs Integer

At 21:05 +0100 98/09/10, [EMAIL PROTECTED] wrote: .. >The question is of performance for Int sized things in Integer, so the >fact that you call a good library isn't relevant; what's important is >what you do when you don't _need_ to use GMP to get the answer. My >guess is that most of the real c

Re: Int vs Integer

Carl R. Witty writes: > Will Partain <[EMAIL PROTECTED]> writes: > > > [EMAIL PROTECTED] writes: > > > > > ... The question is of performance for Int sized things in > > > Integer, so the fact that you call a good library isn't > > > relevant; what's important is what you do when you don't > >

Re: Int vs Integer

Sigbjorn Finne <[EMAIL PROTECTED]> writes: > > This wants to add two 1-word numbers in a fast, unrolled loop. > > It sets up various registers (size, and pointers to > > source1, source2, and destination). > > It computes the number of complete times to go through the > >

Re: Int vs Integer

Will Partain <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] writes: > > > ... The question is of performance for Int sized things in > > Integer, so the fact that you call a good library isn't > > relevant; what's important is what you do when you don't > > _need_ to use GMP to get the answer.

Re: Int vs Integer

[EMAIL PROTECTED] writes: > ... The question is of performance for Int sized things in > Integer, so the fact that you call a good library isn't > relevant; what's important is what you do when you don't > _need_ to use GMP to get the answer. It is relevant, because (unless my memory has faded b

Re: Int vs Integer

On 10 Sep, Will Partain wrote: > [EMAIL PROTECTED] writes: > >> As far as I know, none of the existing implementations >> takes the speed of Integer seriously (ghc certainly doesn't), ... > > The GHC implementation has always been a thin wrapper on top > of the GMP (GNU multi-precision arit

Re: Int vs Integer

[EMAIL PROTECTED] writes: > As far as I know, none of the existing implementations > takes the speed of Integer seriously (ghc certainly doesn't), ... The GHC implementation has always been a thin wrapper on top of the GMP (GNU multi-precision arithmetic) library. So, while we may not have

Re: Int vs Integer

At: http://www.cs.uu.nl/groups/ST/haskell.pdf you may find a pdf version of the current haskell 1.4 report. You may read and browse through it with the Acrobat redaer. Some of you might find this more pleasing than the html version, Doaitse Swierstra -

Int vs Integer

Jon Fairbairn says: On 9 Sep, John Launchbury wrote: > When we discussed this before I appealed for someone to try it out and > report on the results: > * What slowdowns (?speedups) can be expected in practice using Integer > rather than Int? > * Do existing programs break wildly wi

Re: Int vs Integer

On 9 Sep, John Launchbury wrote: > When we discussed this before I appealed for someone to try it out and > report on the results: > * What slowdowns (?speedups) can be expected in practice using Integer > rather than Int? > * Do existing programs break wildly with this more general type, or >

Re: Int vs Integer

> Standard Haskell is supposed to be a conservative bugfix of 1.4, IMHO, the use of Int is a BUG, and we should fix it in Standard Haskell, for all of the reasons that Jon mentions. Haven't we had this discussion (umpteen times) before?? I thought that we had already agreed to make this change

Re: Int vs Integer

> So I don't think either of these experiments would be helpful. > Changing to Integer improves the design of the language and increases > the chance that programmes will give correct results. It's not as if > we are asking for Int to be banned! I agree! -Paul

Int vs Integer. Reply

John Launchbury <[EMAIL PROTECTED]> asked recently about the Int performance vs Integer one. In my experience with ghc-2.10 Int was 4-5 times faster than Integer on the tasks with large amount of integer arithmetic. Some Haskell, Hugs implementors confirm that this is not an occasion. Therefo

Re: Int vs Integer

> > In the Libraries: state of play document, the sixth point is > > about Int: > > 1. There are other library functions in a similar vein to > > take and drop, such as splitAt, !!, elemIndex, findIndex; > > I take it that these are also covered. > > I hope so When we discussed this before I app

Int vs Integer

In the Libraries: state of play document, the sixth point is about Int: > Make Integer be the default integral type instead of Int. This > means that >o If you don't give an explicit default declaration, then an > ambiguous integral type constraint defaults to Integer. >o l