October 2001 - Haskell

Re: Haskell 98 - Standard Prelude - Floating Class
by Marcin 'Qrczak' Kowalczyk 16 Oct '01

16 Oct '01

Tue, 16 Oct 2001 15:29:36 +1000, Fergus Henderson <fjh(a)cs.mu.oz.au> pisze: > Not giving a default definition is *not* the same as giving a default > definition that calls "error". It's significantly safer. The difference > is that the former makes it much easier for compilers to issue warnings > when you forget to define a class method in an instance declaration. There are no warnings when default definitions are expressed in terms of themselves such that when no explicit definition is present, they will diverge. In practice this is analogous to not having a definition at all. But the compiler sees this as if they had a good definition. If we are serious about ensuring that definitions are not omitted, we should handle this case too. It can be done with a pragma which tells the compiler and a programmer who wants to make instances what are possible sets of methods to be provided by instances (in terms of conjunctions and alternatives). This is often already specified in comments. An optimizing compiler could detect most of such "incomplete" instances itself, with the help of strictness analysis. -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

1 0

Re: Standard Prelude - Floating Class
by George Russell 16 Oct '01

16 Oct '01

I wrote > I'm afraid that I have very little faith in the numerical analysis > expertise of the typical Haskell implementor, so I think it is dangerous > to give them an incorrect "default" implementation. I am reminded of > the notorious ASCII C (very)-pseudo-random number generator . . . Dylan wrote > > I don't think it's worth worrying about much. I wrote > This is a good argument for leaving things as they are. Jerzy Karczmarczuk wrote > Absolutely NO. Unless you don't care at all about the potential scientific > users of the language. Leaving the details which are of utmost importance for > professional applications is killing the language. Most readers of this forum > are very far away from numerics, and this is normal. But languages live through > their libraries. At least 4 times a year somebody on this list complains about > lack of such a support even if the actual libraries are already quite > impressive. The potential scientific users of the language are not going to be well served if the language includes *incorrect* implementations of mathematical functions. This is my point. > > So, I would encourage to organize one day a group - not necessarily a "task > force" > like the GUI people - of people who would test all the numerics, and at least > give to the freshmen some implementation prototypes, e.g. Padés for small > arguments > of sinh, etc Yes, in the ideal world, we would form a group of numerically-knowledgable Haskell people who would test things out properly. Well, perhaps. I would like to be on this group. I at least know what a Pad'e approximation is, and perhaps I could even remember how you find them. I have implemented sinh properly in ML based on the netlib specification. Still, I am not a numerical analyst, and I am not sure we are going to be able to find it easy to assemble a group of numerical analysts willing to give time to define the transcendental functions properly. I also doubt if this is going to be possible. At the moment for example, Haskell cannot even require IEEE arithmetic, because virtually no platform supports it completely. (Intel has too much precision which needs to be artificially clobbered if we want IEEE, Alpha doesn't do underflows properly unless you are very careful with inserting traps to fix things up.) So getting a standard which specifies exactly what Haskell transcendental functions should do (be accurate within 0.8ULP for example, though when you think about it that is horrendously complicated to guarantee in some instances . . .) is going to be tricky, to say the least. > > And what is this: "typical Haskell implementor"? Do you know many of them? Do > you > think really that some fellow totally inconscious in the domain of STANDARD > numeric > maths, somebody who never heard about IEEE etc. will NOW engage in implementing > Haskell? What is the rationale behind your little faith, Man of Little Faith? I think numerical analysis is a prime example of "A little learning is a dangerous thing". I think I would like a Haskell implementor to be either totally ignorant of numerical analysis, and simply call out to C routines written by an expert, such as the excellent ones available at netlib. Or else a Haskell implementor should be a skilled numerical analyst. Unfortunately expecting writers of functional compilers to be an s.n.a. seems to me rather like expecting them to be brain surgeons; it just isn't so. On the other hand, they have enough mathematical learning to know about sinh(x)=(exp(x)-exp(-x))/2, so they erroneously introduce it into their code, having forgotten whatever they learnt in bright college days about never subtracting two nearly-equal floating-point numbers. Standard ML/NJ and Microsoft Excel (when I tested it a couple of years ago) both get sinh wrong, so I think my pessimism is well-grounded. Incidentally, another fruitful example of ALLIADT is random number generators. I have yet to see a language standard which defined a random number generator which wasn't completely pathetic.

1 0

RE: Haskell 98 - Standard Prelude - Floating Class
by George Russell 16 Oct '01

16 Oct '01

Simon PJ wrote: > Fpr the Revised Haskell 98 report, Russell O'Connor suggests: > =20 > | Also, I understand you are reluctant to make library changes,=20 > | but sinh and cosh can easily be defined in terms of exp > |=20 > | sinh x =3D (exp(x) - exp(-x))/2 > | cosh x =3D (exp(x) + exp(-x))/2 > |=20 > | (source: Calculus Third Edition by Michael Spivak, page 349,=20 > | or any decent calculus book) > |=20 > | I suggest removing sinh and cosh from the minimal complete=20 > | definition, and add the above defaults. > > This looks pretty reasonable to me. We should have default methods > for anything we can. > > Comments? No. As has been pointed out, this is a bad idea numerically because it will give the wrong answer for sinh x for very small values of x. As a matter of fact, you will also get the wrong answer for very large values of x, where exp(x) can overflow even though sinh x and cosh x don't, meaning you get an incorrect answer of positive infinity. I suggest saying as little about the transcendental functions as possible, rather than forcing incorrect rules on the implementor. I imagine most Haskell implementors do not want to waste time writing their own transcendental function routines, but simply call out to one of the various high-quality C implementations. (Netlib has a good free one, for example.) This will probably produce better results than suggesting buggy code to the implementor. Technically, you would probably be able to define all the functions sinh/cosh/tanh/exp functions with reasonable precision in terms of expm1, defined mathematically as expm1(x) = exp(x) - 1. But please don't . . .

4 4

RE: Harmful spammers
by Simon Marlow 15 Oct '01

15 Oct '01

> There are a couple things to do that can at least cut down on spam. > > 1) Make sure that your mail gateway, or (in this case) the mailing > list host is not an open relay site. It isn't. > 2) Every time you get spam, locate all the hosts it came through > in the header. Or alternatively just report it using Spamcop (http://spamcop.net) or some other reporting tool. Life is just too short to do this by hand every time you get spam. On the Haskell mailing list we have a good compromise at the moment: the mailing list software's auto-filtering catches most of the spam (not allowing Bcc's to the list is a good one), and for any spam that gets through I just add it to the list of disallowed addresses. I asked recently if we should move to allowing subscriber-only posting, and I got a small number of responses, which were split roughly 50/50 so no action was taken. Cheers, Simon

2 1

RE: Haskell 98 - Standard Prelude - Floating Class
by Lennart Augustsson 15 Oct '01

15 Oct '01

> | sinh x = (exp(x) - exp(-x))/2 > | cosh x = (exp(x) + exp(-x))/2 ... > This looks pretty reasonable to me. We should have default methods > for anything we can. Why not provide defaults for the inverse functions as well? asinh x = log (x + sqrt (1+x*x)) acosh x = log (x + (x+1) * sqrt ((x-1)/(x+1))) atanh x = log ((x+1) / sqrt (1 - x*x)) -- Lennart

2 1

RE: Haskell 98 - Standard Prelude - Floating Class
by Simon Peyton-Jones 15 Oct '01

15 Oct '01

Fpr the Revised Haskell 98 report, Russell O'Connor suggests: | Also, I understand you are reluctant to make library changes, | but sinh and cosh can easily be defined in terms of exp | | sinh x = (exp(x) - exp(-x))/2 | cosh x = (exp(x) + exp(-x))/2 | | (source: Calculus Third Edition by Michael Spivak, page 349, | or any decent calculus book) | | I suggest removing sinh and cosh from the minimal complete | definition, and add the above defaults. This looks pretty reasonable to me. We should have default methods for anything we can. Comments? Simon

3 2

Re: Haskell 98 - Standard Prelude - Floating Class
by Lennart Augustsson 15 Oct '01

15 Oct '01

> 2. So, they hold for the Complex numbers as well. The gymnastics with > complex sinh and cosh seems to be redundant. Well, I would be a little careful changing these. Some of the definitions in numerical part of the Prelude look more convoluted than they need to be, but it's because they have better numerical properties. I know Joe Fasel spent a lot of work on getting definitions that are numerically well behaved. But we should definitely have the "default definitions" for sinh and cosh. Any decent implementation will of course override these for speed and accuracy. -- Lennart

1 0

Re: bracket_
by Marcin 'Qrczak' Kowalczyk 15 Oct '01

15 Oct '01

Sun, 14 Oct 2001 23:25:40 -0400, Ken Shan <ken(a)digitas.harvard.edu> pisze: > In Haskell's standard IO module, bracket_ is defined to have type > > IO a -> (a -> IO b) -> IO c -> IO c > > However, in the Exception module in hslibs, bracket_ has type > > IO a -> IO b -> IO c -> IO c > > which IMHO is much less useful, not to mention confusing. Why less useful? There is already bracket which provides the value produced by initialization. IMHO Exception.bracket_ is more useful when there is really no initialization, only closing. -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

1 0

RTA 2002 Call for papers
by Pierre Lescanne 15 Oct '01

15 Oct '01

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ CALL FOR PAPERS RTA 2002 13th International Conference on Rewriting Techniques and Applications July 22--24, Copenhagen, Denmark as part of FLoC'02 (http://floc02.diku.dk) ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ TOPICS: RTA is the major forum for the presentation of research on all aspects of rewriting. The 13th International Conference on Rewriting Techniques and Applications solicits original papers on theoretical and practical topics related to rewriting in a broad sense. Suggested, but not exclusive, topics include: * Applications: case studies; rule-based programming; symbolic and algebraic computation; theorem proving; functional and logic programming; proof checking. * Foundations: matching and unification; completion techniques; strategies; constraint solving; explicit substitutions; tree automata. * Frameworks: string, term, and graph rewriting; lambda-calculus and higher-order rewriting; conditional rewriting; constrained rewriting and deduction; proof nets; categorical and infinitary rewriting. * Implementation: compilation techniques; parallel execution; rewriting tools. * Semantics: equational logic; rewriting logic. INVITED SPEAKERS Franz Baader (RWTH Aachen, Germany ) John Mitchell (Stanford, USA) Natarajan Shankar (SRI, USA) (joint FME-LICS-RTA) SUBMISSIONS: Submissions must be original and not submitted for publication elsewhere. Submissions should fall into one of the following categories: 1. Regular research papers describing new results; they will be judged on correctness and significance. 2. Papers describing the experience of applying rewriting techniques in other areas; they will be judged on relevance and comparison with other approaches. 3. Problem sets that provide realistic and interesting challenges in the field of rewriting. 4. System descriptions; they should contain a link to a working system and will be judged on usefulness and design. Submissions in the first three categories can be up to 15 proceedings pages long, system descriptions 4 proceedings pages. Authors are strongly encouraged to use LaTeX2e and the Springer llncs class file, available at http://www.springer.de/comp/lncs/authors.html. The title page should include the submission category. Submission is by email: Send a self-contained postscript file and an ASCII version of the paper's cover page (title, authors, submission category, abstract, contact information) to rta2002(a)lifl.fr CONFERENCE CHAIR: Thomas Arts Ericsson Computer Science Laboratory Box 1505 125 25 Alvsjo SWEDEN <thomas(a)cslab.ericsson.se> PROGRAM CHAIR: Sophie Tison LIFL Université de Lille I Cité Scientifique -- Bat.M3 59655 Villeneuve d'Ascq Cedex France <rta2002(a)lifl.fr> PROGRAM COMMITTEE: Andrea Corradini (Pisa) Daniel J. Dougherty (Wesleyan University) Jürgen Giesl (Aachen) Bernhard Gramlich (Wien) Thérèse Hardin (Paris) Christopher Lynch (Postdam) Jerzy Marcinkowski (Wroclaw) Aart Middeldorp (Tsukuba) Joachim Niehren (Saarbrucken) Femke van Raamsdonk (Amsterdam) Albert Rubio (Barcelona) Sophie Tison (Lille) Ralf Treinen (Paris-Sud) BEST PAPER AWARD: A prize of 500 EUR will be given to the best paper as judged by the program committee. The program committee may decline to make the award or may split it among several papers. IMPORTANT DATES: Submission: January 15, 2002 Notification: March 22, 2002 Final Version: April 25, 2002 RTA 2002 WEB SITE: http://www.ericsson.com/cslab/rta2002/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ PostScript version: http://www.ens-lyon.fr/~plescann/CONTRIBUTIONS/RTA_2002.ps

1 0

RE: let-floating
by Simon Peyton-Jones 15 Oct '01

15 Oct '01

| Is there a compiler (which version?) that optimizes qsort1 to | (essentially) qsort2 ? | | Any hints concerning the possibility/impossibility of this | would be helpful. Thanks and regards, Janis. Alas, (still) not yet. As you say, the transformation depends on spotting a one-shot lambda, and our plan was to use Keith Wansbrough's usage-type work to do that. But Keith has another job, and is busy writing up his thesis. I'm still hoping to get his stuff into GHC though, but it's not imminent. A possible stop-gap would be a simpler analysis to catch common cases like the one you give. Any volunteers? Simon

1 0