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' and >replace Int with Int32

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 Wor

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

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 18:09 +0100 98/10/04, 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

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 Haskell 2.000 (or

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

> 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. > >2) Stay with the current situation. > Following quite a bit of discussion a

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.

Re: Int vs Integer

>It might be worthy to point out that the both ideas have been >implemented in Smalltalk for ages. I think this is just a standard technique to speed up small objects a little. Dynamic languages often distinguishes between "unboxed" and "boxed" elements; I think the latter is the one that has a

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

> > >Plus "double dispatching" for > >mixed type arithmetic. > > I use a variation of "double dispatch" 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

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 something like > > dat

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

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

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 -

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

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