Re: Straw Poll (name)
On 08-Sep-1998, Emery Berger [EMAIL PROTECTED] wrote: I personally lean towards Haskell 98 myself, but just for grins (and to hopefully offload this topic from the list): = STRAW POLL Send to [EMAIL PROTECTED] with the subject "Straw Poll". Results will be tabulated and announced on September 15, 1998. Assuming that the Haskell standard will be announced in 1998, I'd prefer that the language specification be called... (pick ONE of the following): ... Reason for your vote: If you're going to have a poll, it would be better to let everyone list their order of preferences, rather than just their first preference. Voting systems based on a single non-transferable vote are fundamentally flawed (see the quote below, from information on the Proportional Representation Society of Australia home page http://www.cs.mu.oz.au/~lee/prsa/pr.html). Software for computing a winner from a preferential votes using the Quota Preferential method is available at http://www.cs.mu.oz.au/~lee/prsa/count/count_form.html. -- Fergus Henderson [EMAIL PROTECTED] | "I have always known that the pursuit WWW: http://www.cs.mu.oz.au/~fjh | of excellence is a lethal habit" PGP: finger [EMAIL PROTECTED]| -- the last words of T. S. Garp. Marking X is not sufficient If voters only indicate their first preference there is simply not enough information for a good selection of representatives. Votes may be split across several candidates with similar views, leading to all those candidates losing while another candidate with opposing views wins with fewer votes in total. Votes for candidates who are not successful must be wasted since there is no indication of the voter's second and subsequent preferences. Systems that lead to votes being wasted encourage insincere voting: rather than waste a vote on the genuine first preference who may be unlikely to be elected, the vote is cast for a lower preference who has a chance of getting elected. Often this results in people voting for the "lesser of two evils" and makes it very difficult for smaller parties to gain ground. Systems based on marking multiple X's do not solve the problem and sometimes make things even worse. See also Tom Round's thesis "A matter of preference? Defending the Single Transferable Vote"; http://www.cs.mu.oz.au/~lee/prsa/tround/
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. Therefore, i often set Integral i = i instead of clear Integer. For the compiler is expected to specialize this to Int or to Integer depending on what is needed in the task described in `main'. Only ** Int has to break-report on overflow ** - so the user would know when to set :: Integer rather than Int for the next compile-run. -- Sergey Mechveliani [EMAIL PROTECTED]
MISC'99: Final Call for Papers
MISC'99 Workshop on Applications of Interval Analysis to Systems and Control with special emphasis on recent advances in Modal Interval Analysis February 24-26, 1999, Universitat de Girona, Girona, Spain Dear colleague, Remember that the deadline for full paper submissions is SEPTEMBER 30, 1998. If you want detailed information about MISC'99, please visit its WWW page: http://eia.udg.es/~misc99 Best regards, Dr. Josep Vehi
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 in Standard Haskell, and I'm sure that none of us really wants to debate the whole thing again! -Paul
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 arithmetic) library. So, while we may not have taken Integer performance too seriously, we made a point of hanging around with people who did. (Hey, Lennart made much the same choice, and he's not one to give away speed for nothing :-) 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 cost of doing Int sized arithmetic in Integers is the cost of detecting overflow. -- Jon Fairbairn [EMAIL PROTECTED] 18 Kimberley Road[EMAIL PROTECTED] Cambridge CB4 1HH +44 1223 570179 (pm only, please)
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 taken Integer performance too seriously, we made a point of hanging around with people who did. (Hey, Lennart made much the same choice, and he's not one to give away speed for nothing :-) Will (ex-GHC person)
