www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Resubmission: std.math. acosh, asinh, atanh, abs, conj.

reply Don Clugston <dac nospam.com.au> writes:
Walter - In the interests of speeding up development, I'm submitting
an altered version of std.math with these functions added, including
ddoc documentation, so that if accepted, they can be incorporated just 
by replacing the file. (And deleting the top three lines, which I had to 
add so that I didn't violate the license agreement :-) ).
Alternatively you can copy and paste the bits you want.

Changes:
Added abs() for int, long, real, ireal, and creal arguments.
Removed iabs() which is now redundant.
Added acosh(), asinh(), atanh() for real arguments.
Added conj() -- complex conjugate.

Fixed typo in ddoc comment in line 959.
Tidied up comments for lgamma and tgamma.
Specified domain limits for sin() and cos(). (on x86, if abs(x)>2^64, 
sin(x), cos(x) return x which is *completely* incorrect).

Some byproducts of the above:
* Defined some useful DDoc macros for definite integrals and sum of series.


POWER = $1<sup>$2</sup>
BIGSUM = $(BIG &Sigma; <sup>$2</sup><sub>$(SMALL $1)</sub>)

* added isPosZero(), isNegZero(), used internally for unit tests.

All these contributions are in the public domain, and do not
require any further acknowledgement. This is trivial stuff.

----------------------------------------------------

I believe this will allow std.math2 to be deprecated.
The only things remaining in std.math2 are:

* the functions avg, sum, min, max, which probably should be implemented
as templates (and not in std.math).
* sec(), cosec(), acoth(), etc, which are deprecated by the mathematical 
community
(it's recommended to only use sin, cos, tan;
  this is why the reciprocal functions are not included in other 
mathematical libraries).
* atof() and toString() which are buggy.
* sgn() which is incorrect for real.nan.
* cycle<->grad<->rad<->deg conversion functions, which are of doubtful 
merit.
Jan 08 2006
next sibling parent reply "Walter Bright" <newshound digitalmars.com> writes:
How can I resist that? I'll fold it in. Thanks!

A couple questions:

1) Why remove the invalid operation column in the results table?

2) Why remove the cephes and Wikipedia references?
Jan 09 2006
parent reply Don Clugston <dac nospam.com.au> writes:
Walter Bright wrote:

 How can I resist that? I'll fold it in. Thanks!
 A couple questions:
 
 1) Why remove the invalid operation column in the results table?


Because I'm not confident that they were correct (I just made them up). 
It's somewhat tied to the uncertainty about how floating point 
exceptions will be dealt with.
My understanding is that that column means that "Invalid Operand" 
exception is raised under those circumstances. (Is that right?)
I think they are not raised if you just write, for example:

     if (x<58.0)  return real.nan;

But I haven't actually tested this.
Or does that column just mean that a NaN was returned,
in which case it is redundant information?



 2) Why remove the cephes and Wikipedia references?


Originally, the word "Cephes" was only in there because DDoc didn't 
accept the "http" in the URL (it tried to create a section called 
"http"). So I didn't think it was possible to make it work.

I just noticed you added a $(LINK ) macro which wasn't there last time I 
checked. So the end of the documentation for tgamma should be:

  *  References:
  * $(LINK http://en.wikipedia.org/wiki/Gamma_function),
  * $(LINK http://www.netlib.org/cephes/ldoubdoc.html#gamma)
Jan 09 2006
parent "Walter Bright" <newshound digitalmars.com> writes:
"Don Clugston" <dac nospam.com.au> wrote in message 
news:dptgkb$224b$1 digitaldaemon.com...

 Walter Bright wrote:

 1) Why remove the invalid operation column in the results table?


 Because I'm not confident that they were correct (I just made them up). 
 It's somewhat tied to the uncertainty about how floating point exceptions 
 will be dealt with.
 My understanding is that that column means that "Invalid Operand" 
 exception is raised under those circumstances. (Is that right?)
 I think they are not raised if you just write, for example:

     if (x<58.0)  return real.nan;

 But I haven't actually tested this.
 Or does that column just mean that a NaN was returned,
 in which case it is redundant information?


Invalid operand means that NaN is returned and the sticky "invalid 
operation" flag is set in the FPU. For math functions, this should happen 
when the arguments are impossible, such as handing a negative value to the 
sqrt function. It also happens whenever the arguments are NaN and the result 
depends on those arguments.


 2) Why remove the cephes and Wikipedia references?


 Originally, the word "Cephes" was only in there because DDoc didn't accept 
 the "http" in the URL (it tried to create a section called "http").


That only happens if "http:" is the first thing on a line. Make it not the 
first thing, and it'll work.


 So I didn't think it was possible to make it work.

 I just noticed you added a $(LINK ) macro which wasn't there last time I 
 checked. So the end of the documentation for tgamma should be:

  *  References:
  * $(LINK http://en.wikipedia.org/wiki/Gamma_function),
  * $(LINK http://www.netlib.org/cephes/ldoubdoc.html#gamma)


Ok.
Jan 09 2006
prev sibling parent Don Clugston <dac nospam.com.au> writes:
 I believe this will allow std.math2 to be deprecated.
 The only things remaining in std.math2 are:


<snip>

 * atof() and toString() which are buggy.


I just discovered that equivalents to atof() are included in std.conv, 
but they are not documented in Phobos. However, DDoc comments for them 
are in place.

You just need to add an extra backslash to the module comments at the 
top of the file. The docs should be converted to use the DDoc output,
because it includes the useful functions toFloat(), toDouble(), toReal()
which are currently undocumented.


A comment:

Conversion functions for ireals and creals are also in that file, but
currently disabled with this note:

     /* These are removed for the moment because of concern about
      * what to do about the 'i' suffix. Should it be there?
      * Should it not? What about 'nan', should it be 'nani'?
      * 'infinity' or 'infinityi'?
      * Should it match what toString(ifloat) does with the 'i' suffix?
      */

I think that the "i" should be mandatory, exactly as is required in 
source code, because
(a) if it isn't present, you should be writing:
            ireal y = toReal(str) * 1i;
    since you are reading a real, and telling the compiler it should be 
interpreted as an imaginary number.
(b) it's necessary to have the "i" suffix on the imaginary part of a 
complex number.

But, I think that since in D there is no such thing as a complex literal
(just add real and imaginary parts), I'm not sure that there should be
a toCreal() function. I think that "2+3i", "2 + 3i" and "3i+2" should
usually (but not always) be valid ways of expressing the number 
2.0+3.0i. I think it's hard to come up with a truly useful library 
function for this.
Jan 09 2006