Re: Haskell 98 - Standard Prelude - Floating Class

[Brian Boutel]

[EMAIL PROTECTED] wrote:
> 
> 
> How about making default method for asin
> 
> asin x = atan(x/sqrt(1-x^2))
> 
> Can't be worse than the default for (**) ;-)
> 

Oh, it can. As well as its own problems when x is close to 1, it
inherits, through the default definition of sqrt, the problems of (**)
when x is near 0.

--brian

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: Haskell 98 - Standard Prelude - Floating Class

[roconnor]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

How about making default method for asin

asin x = atan(x/sqrt(1-x^2))

Can't be worse than the default for (**) ;-)

- -- 
Russell O'Connor[EMAIL PROTECTED]
   
``This is not a time, as it is never a time, to seek vengeance, but a
time to seek the courage to forgive'' -- George W. Bush
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (SunOS)
Comment: For info see http://www.gnupg.org

iD8DBQE71gyFZG3em5NXM14RAsTUAKCfalnIJ/JsBDak0V7jhgesMGrg0ACg1mJr
3Yx6mHcAQ7nyy02UMTdG/L0=
=oJdQ
-END PGP SIGNATURE-


___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: Haskell 98 - Standard Prelude - Floating Class

[Simon Peyton-Jones]

An apparently-innocuous suggestion about adding default methods for
sinh and cosh led to a flood of mail.  Since no consensus emerged, I
plan to leave things as they are in the Haskell 98 Report.  Namely, 
the following default methods for the Floating class are there:

x**y = exp (log x * y)
logBase x y = log x / log y
sqrt x = x ** 0.5
tan x = sin x / cos x
tanh x = sinh x / cosh x

but there are no default methods for sinh, cosh.

If someone feels strongly that this is wrong, perhaps they could
try to form consensus among those who responded to the earlier
mail flurry (without bothering the list as a whole), and then put
forward
a proposal.  But I'm not a numerical expert, and the default method here
is definitely "no-op".

Simon


| -Original Message-
| From: George Russell [mailto:[EMAIL PROTECTED]] 
| Sent: 15 October 2001 17:28
| To: [EMAIL PROTECTED]
| > | 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
| > | 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.
|
| 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.  

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: Haskell 98 - Standard Prelude - Floating Class

[Marcin 'Qrczak' Kowalczyk]

Thu, 18 Oct 2001 13:49:11 +0200, Karl-Filip Faxen <[EMAIL PROTECTED]> pisze:

> There are two solutions that I can see: Annotate classes in class 
> constraints with exactly which methods were used. Thus for the
> expression "x+y" the inference algorithm would record the constraint
> "Num{+} a" if x and y has type a in the type environment. Then if
> an instance declaration for type Wurble omitted +, that instance 
> declaration would not allow us to simplify "Num{+} Wurble".

This is equivalent to putting all methods in separate classes.

IMHO missing method definitions should be detected where the instance
is defined, not when it's used. You can still define diverging
methods explicitly or manually split the class if you really want
partial instances.

-- 
 __("<  Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
 \__/
  ^^  SYGNATURA ZASTÊPCZA
QRCZAK


___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: Haskell 98 - Standard Prelude - Floating Class

[Karl-Filip Faxen]

Hi!

Jon Fairbairn wrote:
> I agree too, but being able to omit method definitions is
> sometimes useful -- would it be possible to make calls to
> those methods a /static/ error? I suspect this would be hard
> to do.

Yes, quite tricky. The problem is that the class constraints (in an 
inference algorithm or a semantics) only record that some method
was used, not which one. And at the method invocation site it is not
known which instance declaration the method will come from (that's
the point of the Haskell class system, after all).

There are two solutions that I can see: Annotate classes in class 
constraints with exactly which methods were used. Thus for the
expression "x+y" the inference algorithm would record the constraint
"Num{+} a" if x and y has type a in the type environment. Then if
an instance declaration for type Wurble omitted +, that instance 
declaration would not allow us to simplify "Num{+} Wurble".

The second possibility would be to use a separate dataflow analysis
after dictionary conversion to find out if some incomplete dictionary
could flow to a dangerous place. For compilers which use partial 
evaluation to eliminate overloading, this would be particularly
easy. But I think that, given the stylized way dictionaries are
inserted in the code, that this solution is viable in general.

Cheers,

   /kff




___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: Haskell 98 - Standard Prelude - Floating Class

[Jon Fairbairn]

> On Tuesday 16 October 2001 07:29, Fergus Henderson wrote:
> > [...]
> > The whole idea of letting you omit method definitions for methods with
> > no default and having calls to such methods be run-time errors is IMHO
> > exceedingly odd in a supposedly strongly typed language, and IMHO ought
> > to be reconsidered in the next major revision of Haskell.
> 
> This is exactly what I think.

I agree too, but being able to omit method definitions is
sometimes useful -- would it be possible to make calls to
those methods a /static/ error? I suspect this would be hard
to do.

-- 
Jón Fairbairn [EMAIL PROTECTED]
31 Chalmers Road [EMAIL PROTECTED]
Cambridge CB1 3SZ+44 1223 570179 (after 14:00 only, please!)



___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: Haskell 98 - Standard Prelude - Floating Class

[Wolfgang Jeltsch]

On Tuesday 16 October 2001 07:29, Fergus Henderson wrote:
> [...]
> The whole idea of letting you omit method definitions for methods with
> no default and having calls to such methods be run-time errors is IMHO
> exceedingly odd in a supposedly strongly typed language, and IMHO ought
> to be reconsidered in the next major revision of Haskell.

This is exactly what I think.

Wolfgang

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: Haskell 98 - Standard Prelude - Floating Class

[Marcin 'Qrczak' Kowalczyk]

Tue, 16 Oct 2001 15:29:36 +1000, Fergus Henderson <[EMAIL PROTECTED]> 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 * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
 \__/
  ^^  SYGNATURA ZASTÊPCZA
QRCZAK


___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: Haskell 98 - Standard Prelude - Floating Class

[Fergus Henderson]

On 15-Oct-2001, Simon Peyton-Jones <[EMAIL PROTECTED]> wrote:
> 
> The proposal is only to give "default declarations"
> in the class defn for sinh, cosh, and perhaps as Lennart suggests
> asinh, acosh, atanh. They give a reasonable first cut if you
> don't write definitions yourself.  But you can overrride them at will.
> The only reason not to do this (which amounts to giving a default
> decl of "error") is if the default decl is so awful that it's badly
> misleading to provide it.  Which doesn't look true in this case.

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.
With the latter, compilers can't issue such warnings without getting
too many false positives.

The whole idea of letting you omit method definitions for methods with
no default and having calls to such methods be run-time errors is IMHO
exceedingly odd in a supposedly strongly typed language, and IMHO ought
to be reconsidered in the next major revision of Haskell.

-- 
Fergus Henderson <[EMAIL PROTECTED]>  | "... it seems to me that 15 years of
The University of Melbourne | email is plenty for one lifetime."
WWW:   | -- Prof. Donald E. Knuth

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: Haskell 98 - Standard Prelude - Floating Class

[George Russell]

Dylan Thurston wrote:
[snip]
> > 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.
> 
> Err, what?  Surely sinh x is at least 1/2 of exp x, leaving only a
> very narrow range for this to happen.  Behaviour of sinh x near 0 is
> more important, unless I'm missing something?
If we are planning to introduce bugs into the Haskell standard, I am not
going to argue about which bug is more important than which other bug. 
Personally I think we should avoid all bugs.
> 
> > I suggest saying as little about the transcendental functions as
> > possible, rather than forcing incorrect rules on the implementor.
> 
> The suggestions are for default methods, which force nothing on
> anybody.  They would be suggestions, in case anyone writes their own
> instances of these classes; the question should be whether they are
> useful suggestions.  For instance, if you have a class of computable
> reals (increasingly good approximations), the default definitions of
> sinh and cosh are excellent.
I would like to see such an implementation.  The definition of sinh/cosh
requires the number to be an instance of Floating, which requires
Fractional, which requires Num, which requires Eq.  Testing equality for
computable reals is equivalent to solving the Turing Halting Problem, which
would have wide-ranging applications for computer science . . .

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 . . . 
> 
> I don't think it's worth worrying about much.
This is a good argument for leaving things as they are.
[snip]

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: Haskell 98 - Standard Prelude - Floating Class

[Dylan Thurston]

On Mon, Oct 15, 2001 at 06:27:52PM +0200, George Russell wrote:
> 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.

Err, what?  Surely sinh x is at least 1/2 of exp x, leaving only a
very narrow range for this to happen.  Behaviour of sinh x near 0 is
more important, unless I'm missing something?

> I suggest saying as little about the transcendental functions as
> possible, rather than forcing incorrect rules on the implementor.

The suggestions are for default methods, which force nothing on
anybody.  They would be suggestions, in case anyone writes their own
instances of these classes; the question should be whether they are
useful suggestions.  For instance, if you have a class of computable
reals (increasingly good approximations), the default definitions of
sinh and cosh are excellent.

I don't think it's worth worrying about much.

(They don't work for floating point numbers because of the special
behaviour near 0.)

Best,
Dylan Thurston

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: Haskell 98 - Standard Prelude - Floating Class

[George Russell]

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 . . .

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: Haskell 98 - Standard Prelude - Floating Class

[Lennart Augustsson]

> That's a good idea too.
> Is there a reason for defining acosh as above instead of
> acosh x = log(x + sqrt(x*x-1))
If there is one I can't remember it. :-)

-- Lennart

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: Haskell 98 - Standard Prelude - Floating Class

[roconnor]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, 15 Oct 2001, Lennart Augustsson wrote:

> 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))

That's a good idea too.
Is there a reason for defining acosh as above instead of

acosh x = log(x + sqrt(x*x-1))

- -- 
Russell O'Connor[EMAIL PROTECTED]
   
``This is not a time, as it is never a time, to seek vengeance, but a
time to seek the courage to forgive'' -- George W. Bush
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (SunOS)
Comment: For info see http://www.gnupg.org

iD8DBQE7yv8aZG3em5NXM14RAqO2AJ4hsVYSbtFYgDmjturcQOr/AUbH0ACfTYKw
IZA2w18pSxdMAvZrLPoOJLM=
=+Pkw
-END PGP SIGNATURE-


___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: Haskell 98 - Standard Prelude - Floating Class

[Simon Peyton-Jones]

| > 1. Actually, I wouldn't even call that "default 
| definitions". These ARE
| >definitions of sinh and cosh.
| 
| Mathematically, yes.  Numerically, no.  Even if 'exp' is 
| implemented with high accuracy, the suggested defaults may 
| return a very inaccurate (in ulps) result.  Take sinh near 
| zero.  sinh(x) with x very close to 0 should return x.  With 
| the above 'default' sinh(x) will return exactly 0 for a 
| relatively wide interval around 0, which is the wrong result 
| except for 0 itself.

Indeed.  The proposal is only to give "default declarations"
in the class defn for sinh, cosh, and perhaps as Lennart suggests
asinh, acosh, atanh. They give a reasonable first cut if you
don't write definitions yourself.  But you can overrride them at will.
The only reason not to do this (which amounts to giving a default
decl of "error") is if the default decl is so awful that it's badly
misleading
to provide it.  Which doesn't look true in this case.

I don't propose to change any of the actual instance declarations,
because (as Lennart says) it's entirely possible that they have better
numerical properties than the default declarations.

Simon

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: Haskell 98 - Standard Prelude - Floating Class

[Kent Karlsson]

- Original Message - 
From: "Jerzy Karczmarczuk" <[EMAIL PROTECTED]>
...
> Simon Peyton-Jones:
> > 
> > Russell O'Connor suggests:
> 
> > | 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
> 
> > | 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?
> 
> Three.
> 
> 1. Actually, I wouldn't even call that "default definitions". These ARE
>definitions of sinh and cosh.

Mathematically, yes.  Numerically, no.  Even if 'exp' is implemented
with high accuracy, the suggested defaults may return a very inaccurate
(in ulps) result.  Take sinh near zero.  sinh(x) with x very close to 0 should
return x.  With the above 'default' sinh(x) will return exactly 0 for a relatively
wide interval around 0, which is the wrong result except for 0 itself.

In general, this is why LIA-2 (Language Independent Arithmetic, part 2,
"Elementary numerical functions", ISO/IEC 10967-2:2001) rarely attempts to
define one numerical operation in terms of other numerical operations.  That
is done only when the relationship is exact (even if the operations themselves
are inexact).  That is not the case for the abovementioned operations. But
it is the case for the relationship between the complex sin operation and the
complex sinh operation, for instance. (Complex will be covered by LIA-3.)

Kind regards
/Kent Karlsson



___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: Haskell 98 - Standard Prelude - Floating Class

[Lennart Augustsson]

> | 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

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: Haskell 98 - Standard Prelude - Floating Class

[Lennart Augustsson]

> 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

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: Haskell 98 - Standard Prelude - Floating Class

[Jerzy Karczmarczuk]

Simon Peyton-Jones:
> 
> Russell O'Connor suggests:

> | 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

> | 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?

Three.

1. Actually, I wouldn't even call that "default definitions". These ARE
   definitions of sinh and cosh.

2. So, they hold for the Complex numbers as well. The gymnastics with
   complex sinh and cosh seems to be redundant.

3. The above code is less than useful for a person who
   really needs it. I would propose rather the most obvious

   sinh x = (u-recip u)/2 where u=exp x

   etc.

Jerzy Karczmarczuk

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: Haskell 98 - Standard Prelude - Floating Class

[Simon Peyton-Jones]

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

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell