pbristow@hetp.u-net.com ("Paul A Bristow") wrote in message news:<4z6Kc.123$5_.50@newsr2.u-net.net>...
> I am presenting a draft of proposals for math functions which are needed for
> even most elementary statistics.
..
> 3  The choice of functions, espcially if there are any you feel strongly are
> missing, or are not needed (say why).

I didn't see density functions listed in your proposal.

> 4  The choice of names.  Clarity is preferred to curtness.

Consistency is important too. The most consistent naming system I've
seen is in
the R system (R Project for Statistical Computing:
http://www.r-project.org/).
Example: For the normal distribution,
  dnorm(x) is the density function, dnorm(x)=exp(-x*x/2)/sqrt(2*pi)
  pnorm(x) is the CDF, integral of dnorm() from -INF to x
  qnorm(p) is the quantile function, i.e. inverse of the CDF function,
                     qnorm(pnorm(x))==x and pnorm(qnorm(p))==p, 0 <= p
<= 1.
[There is also rnorm() which generates random numbers from the normal
distribution, but that is not a "math function" of the type being
discused here]
These functions have optional arguments with default values.

bq

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

pjp@dinkumware.com ("P.J. Plauger") wrote in message news:<E1Bnyd8-0006qN-00@chx400.switch.ch>...
> ""Paul A Bristow"" <pbristow@hetp.u-net.com> wrote in message
> news:lrLLc.158$5_.84@newsr2.u-net.net...
>
> > I note too that the existing Library Standards make no requirements about
> > accuracy.
> > This is entirely sensible, but I would welcome more encouragement to
>  library
> > implementers to
> > provide 'quality of implementation' information in the next standard
> > revision.  To my knowledge, none of the commerical libraries provides
>  much,
> > if anything, about the accuracy of pow and exp.
>
> We're working on it. Our next release *will* be accompanied by detailed
> accuracy reports of all math functions, including the basic ones required
> by Standard C++ and all the new ones added by TR1 (which includes all the
> ones added by C99, and then some). We've developed tests that can report
> errors in ulp (units in the least-significant place) even for extreme
> values. And we'll be doing competitive comparisons with popular existing
> math libraries.

Sounds interesting! Please consider publishing the results somewhere
(CUJ?) where lots of people can get a chance to look at them.

--Beman

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

""P.J. Plauger"" <pjp@dinkumware.com> wrote in message
news:200407241158.i6OBwgUT029910@horus.isnic.is...

>
> > > > I note too that the existing Library Standards make no requirements
> > about
> > > > accuracy or speed.
> > But of course, some may prefer quicker and dirtier implementations, so
> info
> > on speed is also a 'Quality of Implementation' issue.
>
> True, but I'm not sure we'll have time to do that for our next release.
> Meaningful timing information is almost as hard to develop as correct
> accuracy information.
>
> > Some methods of controlling the compromise between accuracy and speed
may
> be
> > useful, but I am not clear if the Standard should try to make any
> > recommendations for this.
>
> Well, there's float/double/long double. We're pretty consistent about
> doing all our float arithmetic in float, all our double in double, and
> all our long double in long double. That means that float generally
> goes pretty fast -- for an embedded system with *only* float support
> it goes *really* fast. You get nearly all the precision you ask for,
> and *only* the precision you ask for.

Excellent.

> > Should we consider ways of indicating a desired accuracy - for future
> > standards?
>
> I'm still a bit leery, having read the handful of attempts that have
> made it into past standards. But I also agree that "do a nice job"
> is a tad weak.
>
> P.J. Plauger

OK - getting the functions available is the first priority.

Paul

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Matt Austern" <austern@well.com> wrote in message
news:m2k6wumwa8.fsf@Matt-Austerns-Computer.local...
> pbristow@hetp.u-net.com ("Paul A Bristow") writes:
>
> > My personal view is that the benefit of 'aliases' in clarity to users is
> > greater than the cost of filling the std:: namespace.
>
> I have the opposite view: I think that aliases hurt clarity.  If I see
> source code using two different functions with similar names that
> obviously do similar things, the first thing I'll wonder is what kind
> of subtle difference there is between the two functions, and why the
> programmer sometimes chose one and sometimes chose the other.  This
> extra mental effort is only justified if there really is some good
> reason to have two functions instead of one.

I accept your reaction - but the name erf may mean nothing to those many
users who are only seeking a normal_distribution function, so they are not
merely puzzled but may fail to find their function completely.

This is a battle I am willing to lose, but I feel the Standard documentation
could and should be more helpful (without reducing the opportunity for
authors to write informative books too much!).

Paul


--
Paul A Bristow
Prizet Farmhouse, Kendal LA8 8AB   UK



>
> ---
> [ comp.std.c++ is moderated.  To submit articles, try just posting with ]
> [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
> [              --- Please see the FAQ before posting. ---               ]
> [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]
>

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Beman Dawes wrote:
>
> > We're working on it. Our next release *will* be accompanied by detailed
> > accuracy reports of all math functions, including the basic ones required
> > by Standard C++ and all the new ones added by TR1 (which includes all the
> > ones added by C99, and then some). We've developed tests that can report
> > errors in ulp (units in the least-significant place) even for extreme
> > values. And we'll be doing competitive comparisons with popular existing
> > math libraries.
>
> Sounds interesting! Please consider publishing the results somewhere
> (CUJ?) where lots of people can get a chance to look at them.

I have a test suite for the numerics and floating-point parts of C99.
I have
used it to test math libraries, I/O routines (binary <-> decimal
conversions),
and code generation involving floating-point of many implementations.
I have a
paper that has many of the weird results I have found, as well as the
worst case
errors, that I would be happy to email to anyone wanting it.  Four of
the
standalone tests can be found on the public FTP site mentioned below.
The
files are:  tsin.c  tbin2dec.c  tflt2int.c  tint2flt.c
---
Fred J. Tydeman        Tydeman Consulting
tydeman@tybor.com      Programming, testing, numerics
+1 (775) 287-5904      Vice-chair of J11 (ANSI "C")
Sample C99+FPCE tests: ftp://jump.net/pub/tybor/
Savers sleep well, investors eat well, spenders work forever.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

dsp@bdal.de ("Daniel Kr   gler (ne Spangenberg)") writes:

> I don't think that a standard can give a more precise description,
> because any exact comparison is both depending on the corresponding
> floating point representation and the value of x.

It is possible for a standard to give precision constraints to
floating point operations without imposing a particular
representation.  For exemple Ada standard does so by demanding that
for some operations, the result is one of the two possible
representations bracketting the true result (well, it's a little more
complex than that).

Yours,

--
Jean-Marc

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Fred J. Tydeman" <tydeman@tybor.com> a    crit dans le message de
news:41044DA1.7B91222E@tybor.com...
> Beman Dawes wrote:
> >
> I have a test suite for the numerics and floating-point parts of C99.
> I have
> used it to test math libraries, I/O routines (binary <-> decimal
> conversions),
> and code generation involving floating-point of many implementations.
> I have a
> paper that has many of the weird results I have found, as well as the
> worst case
> errors, that I would be happy to email to anyone wanting it.  Four of
> the
> standalone tests can be found on the public FTP site mentioned below.
> The
> files are:  tsin.c  tbin2dec.c  tflt2int.c  tint2flt.c

The lcc-win32 compiler passed all those tests except... the
sin(355) test.

I just generate a fsin assembly instruction without reducing the range
This bug is present in MSVC and gcc too, that return exactly the same value
as lcc-win32.

The fdlibm library (compiled with lcc-win32) produces exactly the expected
result but is MUCH slower.

I have the choice now:
1) Do as everyone else does: the argument to sin should be in range, if not,
   large loss of precision ensues
2) Use fdlibm and have a very slow implementation of a fundamental function.
   All users that give sin() in range results would be penalized.

I really do not know what to do.



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

jacob navia wrote:
>
> The lcc-win32 compiler passed all those tests except... the
> sin(355) test.
>
> I just generate a fsin assembly instruction without reducing the range
> This bug is present in MSVC and gcc too, that return exactly the same value
> as lcc-win32.
>
> The fdlibm library (compiled with lcc-win32) produces exactly the expected
> result but is MUCH slower.
>
> I have the choice now:
> 1) Do as everyone else does: the argument to sin should be in range, if not,
>    large loss of precision ensues
> 2) Use fdlibm and have a very slow implementation of a fundamental function.
>    All users that give sin() in range results would be penalized.
>
> I really do not know what to do.

Some implementors have two math "libraries":
  one is fast and not very accurate
  other is slow and accurate
and let the user pick which one they want.

I did "libraries" as some math functions could be done as single
instructions inline (fsin, fsqrt, ...), instead of a call to a
true function.
---
Fred J. Tydeman        Tydeman Consulting
tydeman@tybor.com      Programming, testing, numerics
+1 (775) 287-5904      Vice-chair of J11 (ANSI "C")
Sample C99+FPCE tests: ftp://jump.net/pub/tybor/
Savers sleep well, investors eat well, spenders work forever.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

""jacob navia"" <jacob@jacob.remcomp.fr> wrote in message
news:ce3dds$qio$1@news-reader4.wanadoo.fr...

> "Fred J. Tydeman" <tydeman@tybor.com> a =E9crit dans le message de
> news:41044DA1.7B91222E@tybor.com...
> > Beman Dawes wrote:
> > >
> > I have a test suite for the numerics and floating-point parts of C99.
> > I have
> > used it to test math libraries, I/O routines (binary <-> decimal
> > conversions),
> > and code generation involving floating-point of many implementations.
> > I have a
> > paper that has many of the weird results I have found, as well as the
> > worst case
> > errors, that I would be happy to email to anyone wanting it.  Four of
> > the
> > standalone tests can be found on the public FTP site mentioned below.
> > The
> > files are:  tsin.c  tbin2dec.c  tflt2int.c  tint2flt.c
>
> The lcc-win32 compiler passed all those tests except... the
> sin(355) test.
>
> I just generate a fsin assembly instruction without reducing the range
> This bug is present in MSVC and gcc too, that return exactly the same
value
> as lcc-win32.
>
> The fdlibm library (compiled with lcc-win32) produces exactly the expec=
ted
> result but is MUCH slower.
>
> I have the choice now:
> 1) Do as everyone else does: the argument to sin should be in range, if
not,
>    large loss of precision ensues
> 2) Use fdlibm and have a very slow implementation of a fundamental
function.
>    All users that give sin() in range results would be penalized.
>
> I really do not know what to do.

How about:

3) Compute the sine of small arguments relatively fast, larger
ones more slowly, and very large ones slowest of all -- but
get the correct answer in all cases.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

===================================== MODERATOR'S COMMENT:
 Please don't overrquote.


===================================== END OF MODERATOR'S COMMENT
pbristow@hetp.u-net.com ("Paul A Bristow") wrote in message news:<lrLLc.158$5_.84@newsr2.u-net.net>...
> Sadly, according to my experiments, this would rule out log, pow and exp
> which
> many people find quite useful!  (Even though they don't provide a result
> within 1 epsilon).
>
> And of course you can't expect to get the same answer with different
> floating point formats, for example between 32, 64, 80 and 128 bit doubles
> and /or long doubles, and even the IEEE format isn't _required_ (& VAX
> formats still widely used.).
>
> There are also quite reasonable potential for compromises between speed and
> accuracy.
>
> I note too that the existing Library Standards make no requirements about
> accuracy.
> This is entirely sensible, but I would welcome more encouragement to library
> implementers to
> provide 'quality of implementation' information in the next standard
> revision.  To my knowledge, none of the commerical libraries provides much,
> if anything, about the accuracy of pow and exp.
>
> What matters in the Standard, is the signature in the namespace, not the
> exact value you get.
>
> Paul
>
> --
> Paul A Bristow
> Prizet Farmhouse, Kendal LA8 8AB   UK
>
> "John Nagle" <nagle@animats.com> wrote in message
> news:OFyLc.24544$j_5.17131@newssvr27.news.prodigy.com...
> > Paul A Bristow wrote:
> >
> > > I am presenting a draft of proposals for math functions which are needed
>  for
> > > even most elementary statistics.
> >
> >     The standard should encompass only math functions for
> > which there is a definitive correct answer out to the
> > limit of machine precision.  Don't standardize anything
> > for which one might need to choose which library is
> > appropriate.
> >
> > John Nagle
> > Animats
> >
> > ---
> > [ comp.std.c++ is moderated.  To submit articles, try just posting with ]
> > [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
> > [              --- Please see the FAQ before posting. ---               ]
> > [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]
> >
>
>
>
> ---
> [ comp.std.c++ is moderated.  To submit articles, try just posting with ]
> [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
> [              --- Please see the FAQ before posting. ---               ]
> [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

I do not understand why making no requirements about accuracy makes
sense.

Clearly one basic requirement for such a library of functions, is a
consistent naming system and a decent selection of functions. This
seems to give a programmer some guarantee of portability. However,
without some accuracy/behaviour requirements surely this gain is
immediately lost. What good is a library of functions which can
satisfy the standards simply by returning 0 whenever they are called?

I would have thought you'd be better off mandating that a library
generated from some specific code must be available. At least this
would provide portability and the more unpleasant features of the code
could be improved in time.

I wouldn't have thought the accuracy requirements had to be that
complicated. For example, for the Gamma Distribution you might have
64-bit double functions must provide results with relative errors of
less than 1e-10 for values of a in the range 1e-7..1e7 unless the true
result is less than 1e-100 when it is acceptable to return 0.

Leo Knuesel's "Numerical Accuracy of Distributions in Statistical
Packages" (see http://www.stat.fi/isi99/proceedings/arkisto/varasto/knse0330.pdf)
discusses what you would like to see in terms of accuracy for
implementations of statistical functions.

The only other real issue I have with the document it that it wanders
into guidance? on implementation as the following paragraph shows.
"Both arguments a and x must be positive. The integral is evaluated by
either a power series or continued fraction expansion, depending on
the relative values of a and x."

Apart from the fact that it is not the business of a requirements
document to specify how an implementation should calculate the
"incomplete gamma integral", it isn't even very good advice. Even for
quite small values of a & x, asymptotic methods can be used which are
faster and more accurate (see
http://members.aol.com/iandjmsmith/PoissonApprox.htm).

The same applies to "This can be accomplished starting with..." and
many other similar notes.

If the remarks of this type were removed and some requirements on
accuracy were added I think it could be a useful document.


Ian Smith

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D MODERATOR'S COMMENT:=20

This thread is heading away from the topic(s) of this newsgroup; please
ensure that followups are suitable for comp.std.c++.


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D END OF MODERATOR'S COMMENT
On Mon, 26 Jul 2004 21:31:59 GMT in comp.std.c, jacob@jacob.remcomp.fr
("jacob navia") wrote:

>
>"Fred J. Tydeman" <tydeman@tybor.com> a =E9crit dans le message de
>news:41044DA1.7B91222E@tybor.com...
>> Beman Dawes wrote:
>> >
>> I have a test suite for the numerics and floating-point parts of C99.
>> I have
>> used it to test math libraries, I/O routines (binary <-> decimal
>> conversions),
>> and code generation involving floating-point of many implementations.
>> I have a
>> paper that has many of the weird results I have found, as well as the
>> worst case
>> errors, that I would be happy to email to anyone wanting it.  Four of
>> the
>> standalone tests can be found on the public FTP site mentioned below.
>> The
>> files are:  tsin.c  tbin2dec.c  tflt2int.c  tint2flt.c
>
>The lcc-win32 compiler passed all those tests except... the
>sin(355) test.
>
>I just generate a fsin assembly instruction without reducing the range
>This bug is present in MSVC and gcc too, that return exactly the same va=
lue
>as lcc-win32.
>
>The fdlibm library (compiled with lcc-win32) produces exactly the expect=
ed
>result but is MUCH slower.
>
>I have the choice now:
>1) Do as everyone else does: the argument to sin should be in range, if =
not,
>   large loss of precision ensues
>2) Use fdlibm and have a very slow implementation of a fundamental funct=
ion.
>   All users that give sin() in range results would be penalized.
>
>I really do not know what to do.

Don't know how you decide to generate the FP instruction instead of a
library function call, but possible suggestion: always call the
library function, whose first job is to check: if the argument is in
range for the machine instruction, then use that and return the value,
otherwise do the slower table lookup based argument reduction, then
call the library function e.g.=20

    if (|x| < 2**63) return _sin(x);
    ...
    return _sin(x);

which test could be implemented as integer ops:

    if (_EXPD(x) < _BIAS_EXPD(63)) return _sin(x);
    ...
    return _sin(x);

where the implementation defined macros for variables only mask
bytes/words and the macros for constants operate on, shift, and mask
only values.=20

--=20
Thanks. Take care, Brian Inglis  Calgary, Alberta, Canada

Brian.Inglis@CSi.com  (Brian dot Inglis at SystematicSw dot ab dot ca)
    fake address  use address above to reply

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

A first, very tentative implementation is available with the
latest version of lcc-win32:
http://www.cs.virginia.edu/~lcc-win32

For the documention see the inline documentation
section statistics.

You need to include <stats.h> to get the prototypes.

By the way, it would be nice if the specification would tell the name
of the include file.

Only long double precision is provided, others will follow with the
same overloaded name.

The implementation is based on the CEPHES mathematical library
by Stephen Moshier.


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

P.J. Plauger wrote:

> Adding pow(double, int) causes all sorts of problems. (It was in the
> C++ Standard, and in the field, for a spell.) But it's easy enough
> to pick up this optimization without that overload.

Can you elaborate on this, please?

--
Seungbeom Kim

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

P.J. Plauger wrote:
>=20
> Adding pow(double, int) causes all sorts of problems.

Specifically...?

> (It was in the=20
> C++ Standard, and in the field, for a spell.)

I haven't heard about any change to the standard to remove it, and it's
certainly still in the latest release of GCC's libstdc++. If there has
been, or is going to be, some change to this, I'd like to know about
it, because I have code that makes use of it.

--=20
Ross Smith ......... r-smith@ihug.co.nz ......... Auckland, New Zealand
          "The=A0plug-compatible=A0hot-swap=A0nature=A0of=A0wallabies=A0
          came=A0in=A0very=A0useful..."         -- Robert Sneddon

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Ross Smith" <r-smith@ihug.co.nz> wrote in message
news:cdmj53$aga$1@lust.ihug.co.nz...

P.J. Plauger wrote:
>
> Adding pow(double, int) causes all sorts of problems.

Specifically...?

> (It was in the
> C++ Standard, and in the field, for a spell.)

I haven't heard about any change to the standard to remove it, and it's
certainly still in the latest release of GCC's libstdc++. If there has
been, or is going to be, some change to this, I'd like to know about
it, because I have code that makes use of it.

[pjp] I was wrong.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In message <3064b51d.0407210439.20e50827@posting.google.com>
          beliavsky@aol.com wrote:

> Why should functions such as
>
> double log1p (double x); // log1p(x) = log(1+x) in C99.
> double exp1m (double x); // expm1(x) = exp(x) - 1 in C99.
> double cos1m (double x); // cosm1(x) = cos(x) - 1 in C99.
>
> be in C or C++? They are obviously not essential, and a programmer
> should not have to remember the names of too many obscure functions
> specific to C and C++. In almost any imperative language one can write
> 'y = cos(x) - 1', and one should not write "C-only" code without a
> good reason.
>
> If one wanted to parody a committee that was adding needless language
> features, it would be hard to beat defining a function 'cos(x) - 1'.

log1p and exp1m are vital fundamental building blocks for many other
functions; they're arguably more important than log and exp. The briefest of
Google searches and a tiny amount of knowledge of floating point should
explain why substituting "log(1+x)" is no use.

And of course, cos1m doesn't exist; you just made it up.

--
Kevin Bracey, Principal Software Engineer
Tematic Ltd                                   Tel: +44 (0) 1223 503464
182-190 Newmarket Road                        Fax: +44 (0) 1728 727430
Cambridge, CB5 8HE, United Kingdom            WWW: http://www.tematic.com/

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Falk Tannh=E4user wrote:

>>If one wanted to parody a committee that was adding needless language
>>features, it would be hard to beat defining a function 'cos(x) - 1'.
>=20
>=20
> What do you expect to be the result of, let's say 'cos(1e-50) - 1.0'?
> (Hint: on usual implementations, it yields 0.0)
> Are you sure the precision of the result is sufficient for anybody?

What I am not sure of is whether there are more than a handfull of=20
programmers for which the difference is important.

It seems to me that people aware enough of the problem to know these=20
functions exist are also aware enough of the problem to be able to=20
implement their own function that does the right thing.

--=20
Lo=EFc

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Hello Lo=EFc Joly,

Lo=EFc Joly schrieb:

> Falk Tannh=E4user wrote:
>
>>> If one wanted to parody a committee that was adding needless language
>>> features, it would be hard to beat defining a function 'cos(x) - 1'.
>>
>>
>>
>> What do you expect to be the result of, let's say 'cos(1e-50) - 1.0'?
>> (Hint: on usual implementations, it yields 0.0)
>> Are you sure the precision of the result is sufficient for anybody?
>
>
> What I am not sure of is whether there are more than a handfull of=20
> programmers for which the difference is important.=20

If you are not sure, why do you fight against them? Programmers working=20
in scientific environment to realize
reliable number crunching (think of CERN and others) do really need=20
these facilities. I myself have academic
background and missed those functionalities a lot during my work.

> It seems to me that people aware enough of the problem to know these=20
> functions exist are also aware enough of the problem to be able to=20
> implement their own function that does the right thing.

No, because its nearly impossible to write portable programs with=20
self-written functions of that type. Either because
you would have to use special assembler directives or you have a=20
welltested library at your hands. Its quite easy
to implement those "hardware-near" functions wrong.

Greetings from Bremen,

Daniel Kr=FCgler

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

jacob@jacob.remcomp.fr ("jacob navia") wrote:

> <beliavsky@aol.com> a    crit dans le message de
> news:3064b51d.0407200633.53619e6b@posting.google.com...
> > For numerical work, what C and C++ really need is multdimensional
> > array functionality comparable to Fortran 90/95/2003 or Matlab. This
>
> I would underline this. The arrays of C are completely broken. There is no
> concept of rank of arrays, compatibility of arrays, extending scalar to
> arrays,
> etc!
>
> It would be a BIG step forward if we got a reasonable array implementation
> in the language.
>
> The same could be done for lists, and other data structures.

Pfff... If you want C++, you know where to find it. They've got an STL.
Use it - that's what it's for.

Richard

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

My personal view is that the benefit of 'aliases' in clarity to users is
greater than the cost of filling the std:: namespace.

What else would you want to use these names for?

(Of course, it would be nicer if the languages had a real 'alias'
mechanism).

But ultimately whether to have aliases or not is an issue for the Standards
group to decide.

Paul

Paul Bristow

""jacob navia"" <jacob@jacob.remcomp.fr> wrote in message
news:cdlb0i$11k$1@news-reader2.wanadoo.fr...
> In the proposal the function "normal_distribution" and the function
> "normal_probability" are identical. Is this intended?
>
> Besides, they are the same as the C99 function "erf". The intention was
> to add an alias?
>
> Thanks for clarifying
>
> jacob
>
>
>
> ---
> [ comp.std.c++ is moderated.  To submit articles, try just posting with ]
> [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
> [              --- Please see the FAQ before posting. ---               ]
> [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]
>

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

""Paul A Bristow"" <pbristow@hetp.u-net.com> a    crit dans le message de
news:jrLLc.157$5_.89@newsr2.u-net.net...
> My personal view is that the benefit of 'aliases' in clarity to users is
> greater than the cost of filling the std:: namespace.
>
> What else would you want to use these names for?
>
> (Of course, it would be nicer if the languages had a real 'alias'
> mechanism).
>
> But ultimately whether to have aliases or not is an issue for the
Standards
> group to decide.
>
> Paul

No problem Paul. Lcc-win32 has aliases:

int __declspec(naked) MyFnALias1(int a)
{
}
int __declspec(naked) MyFnALias2(int a)
{
}
int TheRealFunction(int a)
{
    return sqrt(a+1)/(1-sqrt(a-2));
}

The __declspec(naked) construct means that no prologue
epilogue sequence will be generated for the function.
This supposes functions written in assembly or mostly in assembly.

The first two functions will not have any body
They will be just labels that will be placed
just before the real function starts.

This aliases are exactly like real functions, you can take
their address, assign a fn pointer, etc.

The generated assembly is:

_MyFnAlias1:
_MyFnAlias2:
_TheRealFunction:
    push    %ebp
    ... etc



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Sadly, according to my experiments, this would rule out log, pow and exp
which
many people find quite useful!  (Even though they don't provide a result
within 1 epsilon).

And of course you can't expect to get the same answer with different
floating point formats, for example between 32, 64, 80 and 128 bit doubles
and /or long doubles, and even the IEEE format isn't _required_ (& VAX
formats still widely used.).

There are also quite reasonable potential for compromises between speed and
accuracy.

I note too that the existing Library Standards make no requirements about
accuracy.
This is entirely sensible, but I would welcome more encouragement to library
implementers to
provide 'quality of implementation' information in the next standard
revision.  To my knowledge, none of the commerical libraries provides much,
if anything, about the accuracy of pow and exp.

What matters in the Standard, is the signature in the namespace, not the
exact value you get.

Paul

--
Paul A Bristow
Prizet Farmhouse, Kendal LA8 8AB   UK

"John Nagle" <nagle@animats.com> wrote in message
news:OFyLc.24544$j_5.17131@newssvr27.news.prodigy.com...
> Paul A Bristow wrote:
>
> > I am presenting a draft of proposals for math functions which are needed
for
> > even most elementary statistics.
>
>     The standard should encompass only math functions for
> which there is a definitive correct answer out to the
> limit of machine precision.  Don't standardize anything
> for which one might need to choose which library is
> appropriate.
>
> John Nagle
> Animats
>
> ---
> [ comp.std.c++ is moderated.  To submit articles, try just posting with ]
> [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
> [              --- Please see the FAQ before posting. ---               ]
> [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]
>



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"John Nagle" <nagle@animats.com> wrote in message
news:OFyLc.24544$j_5.17131@newssvr27.news.prodigy.com...
> Paul A Bristow wrote:
>
> > I am presenting a draft of proposals for math functions which are needed
for
> > even most elementary statistics.
>
>     The standard should encompass only math functions for
> which there is a definitive correct answer out to the
> limit of machine precision.  Don't standardize anything
> for which one might need to choose which library is
> appropriate.

The problem with this is that for almost all functions (with the exception
of sqrt()), there are "pathological" cases where you must calculate the
function to precision much higher than the machine precision in order to get
a properly-rounded result. This is known as the "table-maker's dilemma",
and - barring better numerical calculation methods - will always be with us.


Daniel Pfeffer


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Daniel Kr=FCgler (ne Spangenberg) wrote:

> Hello Lo=EFc Joly,
>=20
> Lo=EFc Joly schrieb:
>=20
>> Falk Tannh=E4user wrote:
>>
>>>> If one wanted to parody a committee that was adding needless languag=
e
>>>> features, it would be hard to beat defining a function 'cos(x) - 1'.
>>>
>>>
>>> What do you expect to be the result of, let's say 'cos(1e-50) - 1.0'?
>>> (Hint: on usual implementations, it yields 0.0)
>>> Are you sure the precision of the result is sufficient for anybody?
>>
>> What I am not sure of is whether there are more than a handfull of=20
>> programmers for which the difference is important.=20
>=20
> If you are not sure, why do you fight against them?

Where have you seen me fighting ?

> Programmers working=20
> in scientific environment to realize
> reliable number crunching (think of CERN and others) do really need=20
> these facilities. I myself have academic
> background and missed those functionalities a lot during my work.
>=20
>> It seems to me that people aware enough of the problem to know these=20
>> functions exist are also aware enough of the problem to be able to=20
>> implement their own function that does the right thing.
>=20
> No, because its nearly impossible to write portable programs with=20
> self-written functions of that type.=20

Well , writing :
double log1p (double x)
{
   return log(1+x);
}

Is a quite portable way of defining this function. ;)
And I am not sure this function is not conformant to the standard.=20
Unless someone wants to fix some constraints on the way floating point=20
numbers should be represented, I am not even sure it is possible to=20
specify it in a way that ensures that users can trust it to be more=20
precise for small values of x than log(1+x). That is part of why a=20
beleived people who need this function would need more information about=20
it than a C or C++ standard can specify.

> Either because
> you would have to use special assembler directives or you have a=20
> welltested library at your hands. Its quite easy
> to implement those "hardware-near" functions wrong.

In fact, my angst is not specially targeted toward those functions, but=20
more broadly to the fact that quite many functions seem to be required=20
to fullfill the needs of special user groups. I was wondering aloud=20
whether we did not go to far. A line has to be drawned between functions=20
that should be part of the standard, and functions that should not. I=20
could find in 5 minutes 10 functions useful in my working domain for=20
which I could ask for introduction in the standard.

Too many funtions can have some drawbacks. It can take time away from=20
the comitee members and compiler implementers, thus disturbing the=20
introduction of other more usefull (from my point of view) features.

It looks that you criterions are usefullness and difficulty to=20
implement. Those are I believe quite relevent. I did not know whether=20
the second applied to those functions before your intervention. The aim=20
of my post was to emphasized that other criterions exist, such as the=20
range of programmers for which the feature is usefull, some level of=20
orthogonality (why log1p and not log2p ?), and the ability to specify=20
the feature in a way that ensures it is usefull.

--=20
Lo=EFc

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Good morning Lo=EFc Joly,

Lo=EFc Joly schrieb:

> Daniel Kr=FCgler (ne Spangenberg) wrote:

[snip]

>> If you are not sure, why do you fight against them?
>
> Where have you seen me fighting ?

Maybe be language was somewhat strong. I apologize for that.


>> No, because its nearly impossible to write portable programs with=20
>> self-written functions of that type.=20
>
>
> Well , writing :
> double log1p (double x)
> {
>   return log(1+x);
> }
>
> Is a quite portable way of defining this function. ;)
> And I am not sure this function is not conformant to the standard.=20
> Unless someone wants to fix some constraints on the way floating point=20
> numbers should be represented, I am not even sure it is possible to=20
> specify it in a way that ensures that users can trust it to be more=20
> precise for small values of x than log(1+x). That is part of why a=20
> beleived people who need this function would need more information=20
> about it than a C or C++ standard can specify.=20

Your implementation example is not very helpful in our discussion. While=20
it might be problematic to define
**exactly** the behaviour of that function (at least compared to the=20
effect of log(1 + x), that should not prevent
the standard to incorporate that function, because it is well-known that=20
the normal log function in the general
case can't return a result with a significant precision if x << 1.=20
Please note that the current C standard already
incorporates that forementioned function and mentions in a footnote:

"For small magnitude x, log1p(x) is expected to be more accurate than=20
log(1 + x)."

I don't think that a standard can give a more precise description,=20
because any exact comparison is both depending
on the corresponding floating point representation and the value of x.=20
Of course I would wellcome any more
precise requirements, like

"The function is guaranteed to return a result with a maximum relative=20
error of XX * std::numeric<FloatType>::epsilon()
 if x is the range between AA and BB", but I assume that this very=20
difficult to realize in a general standard. But I strongly
assume that such guarantees could be provided for special circumstances,=20
like IEEE.

>> Either because
>> you would have to use special assembler directives or you have a=20
>> welltested library at your hands. Its quite easy
>> to implement those "hardware-near" functions wrong.
>
>
> In fact, my angst is not specially targeted toward those functions,=20
> but more broadly to the fact that quite many functions seem to be=20
> required to fullfill the needs of special user groups. I was wondering=20
> aloud whether we did not go to far. A line has to be drawned between=20
> functions that should be part of the standard, and functions that=20
> should not. I could find in 5 minutes 10 functions useful in my=20
> working domain for which I could ask for introduction in the standard.
>
> Too many funtions can have some drawbacks. It can take time away from=20
> the comitee members and compiler implementers, thus disturbing the=20
> introduction of other more usefull (from my point of view) features.
>
> It looks that you criterions are usefullness and difficulty to=20
> implement. Those are I believe quite relevent. I did not know whether=20
> the second applied to those functions before your intervention. The=20
> aim of my post was to emphasized that other criterions exist, such as=20
> the range of programmers for which the feature is usefull, some level=20
> of orthogonality (why log1p and not log2p ?), and the ability to=20
> specify the feature in a way that ensures it is usefull.=20

I understand your concerns. Its quite easy to demand, that "I personally=20
need that function, so we should demand
that its part of the standard". But C++ has found to be a quite useful=20
language in domains of number crunchers and
those here discussed functions are well-known to be

(1) often needed especially in scientific and business areas.
(2) hard to implement trivially in terms of other standard functions=20
thereby providing enough precision in the specified
domain of argument values to be useful in any way.

If you wonder concerning the importance of (2), you should be aware that=20
there do exist honest scientific papers
which have discussed the impact of numerical worthless results from=20
unreliable evaluations of such functions,
which lead to absolute nonsensical conclusions.

Greetings from Bremen,

Daniel Kr=FCgler




---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

""Paul A Bristow"" <pbristow@hetp.u-net.com> wrote in message
news:lrLLc.158$5_.84@newsr2.u-net.net...

> I note too that the existing Library Standards make no requirements about
> accuracy.
> This is entirely sensible, but I would welcome more encouragement to
library
> implementers to
> provide 'quality of implementation' information in the next standard
> revision.  To my knowledge, none of the commerical libraries provides
much,
> if anything, about the accuracy of pow and exp.

We're working on it. Our next release *will* be accompanied by detailed
accuracy reports of all math functions, including the basic ones required
by Standard C++ and all the new ones added by TR1 (which includes all the
ones added by C99, and then some). We've developed tests that can report
errors in ulp (units in the least-significant place) even for extreme
values. And we'll be doing competitive comparisons with popular existing
math libraries.

You may or may not be surprised at some of the errors that are out there,
particularly in difficult functions such as pow.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

loic.actarus.joly@wanadoo.fr (Lo   c Joly) wrote in message news:<cdp5eu$r2i$1@news-reader2.wanadoo.fr>...
..
> orthogonality (why log1p and not log2p ?), and the ability to specify

Because log(1+x) for x near 0 is almost exactly 0, which means that
the small round-off errors inherent in the naive implementation are
enourmous relative to the quantity being calculated. The same is true
of cos(x)-1 and exp(x)-1; it's not true of log(2+x).

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

pbristow@hetp.u-net.com ("Paul A Bristow") writes:

> My personal view is that the benefit of 'aliases' in clarity to users is
> greater than the cost of filling the std:: namespace.

I have the opposite view: I think that aliases hurt clarity.  If I see
source code using two different functions with similar names that
obviously do similar things, the first thing I'll wonder is what kind
of subtle difference there is between the two functions, and why the
programmer sometimes chose one and sometimes chose the other.  This
extra mental effort is only justified if there really is some good
reason to have two functions instead of one.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Excellent.

But of course, some may prefer quicker and dirtier implementations, so info
on speed is also a 'Quality of Implementation' issue.

Some methods of controlling the compromise between accuracy and speed may be
useful, but I am not clear if the Standard should try to make any
recommendations for this.  At present, I don't think any do, probably
because for the original C functions, it was possible to get close ot a few
ulp, but with many of the newer functions this is just not possible.

Should we consider ways of indicating adesired accuracy - for future
standards?

Paul Bristow

""P.J. Plauger"" <pjp@dinkumware.com> wrote in message
news:E1Bnyd8-0006qN-00@chx400.switch.ch...
> ""Paul A Bristow"" <pbristow@hetp.u-net.com> wrote in message
> news:lrLLc.158$5_.84@newsr2.u-net.net...
>
> > I note too that the existing Library Standards make no requirements
about
> > accuracy.
> > This is entirely sensible, but I would welcome more encouragement to
> library
> > implementers to
> > provide 'quality of implementation' information in the next standard
> > revision.  To my knowledge, none of the commerical libraries provides
> much,
> > if anything, about the accuracy of pow and exp.
>
> We're working on it. Our next release *will* be accompanied by detailed
> accuracy reports of all math functions, including the basic ones required
> by Standard C++ and all the new ones added by TR1 (which includes all the
> ones added by C99, and then some). We've developed tests that can report
> errors in ulp (units in the least-significant place) even for extreme
> values. And we'll be doing competitive comparisons with popular existing
> math libraries.
>
> You may or may not be surprised at some of the errors that are out there,
> particularly in difficult functions such as pow.
>
> P.J. Plauger
> Dinkumware, Ltd.
> http://www.dinkumware.com
>
>
> ---
> [ comp.std.c++ is moderated.  To submit articles, try just posting with ]
> [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
> [              --- Please see the FAQ before posting. ---               ]
> [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]
>

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

""Paul A Bristow"" <pbristow@hetp.u-net.com> wrote in message
news:qzoMc.192$5_.144@newsr2.u-net.net...
[top-posting rearranged]

> > > I note too that the existing Library Standards make no requirements
> about
> > > accuracy.
> > > This is entirely sensible, but I would welcome more encouragement to
> > library
> > > implementers to
> > > provide 'quality of implementation' information in the next standard
> > > revision.  To my knowledge, none of the commerical libraries provides
> > much,
> > > if anything, about the accuracy of pow and exp.
> >
> > We're working on it. Our next release *will* be accompanied by detailed
> > accuracy reports of all math functions, including the basic ones
required
> > by Standard C++ and all the new ones added by TR1 (which includes all
the
> > ones added by C99, and then some). We've developed tests that can report
> > errors in ulp (units in the least-significant place) even for extreme
> > values. And we'll be doing competitive comparisons with popular existing
> > math libraries.
> >
> > You may or may not be surprised at some of the errors that are out
there,
> > particularly in difficult functions such as pow.

> Excellent.
>
> But of course, some may prefer quicker and dirtier implementations, so
info
> on speed is also a 'Quality of Implementation' issue.

True, but I'm not sure we'll have time to do that for our next release.
Meaningful timing information is almost as hard to develop as correct
accuracy information.

> Some methods of controlling the compromise between accuracy and speed may
be
> useful, but I am not clear if the Standard should try to make any
> recommendations for this.

Well, there's float/double/long double. We're pretty consistent about
doing all our float arithmetic in float, all our double in double, and
all our long double in long double. That means that float generally
goes pretty fast -- for an embedded system with *only* float support
it goes *really* fast. You get nearly all the precision you ask for,
and *only* the precision you ask for.

>                         At present, I don't think any do, probably
> because for the original C functions, it was possible to get close ot a
few
> ulp, but with many of the newer functions this is just not possible.

Agreed. For functions with multiple zeros, in particular, it's nearly
impossible to get good relative accuracy near all the zeros. In those
cases, we're generally settling for absolute accuracy, as does everybody
else I know. (Exception: we aim for 2 ulp worst-case accuracy for all
argument values in the case of sin/cos/tan.)

> Should we consider ways of indicating adesired accuracy - for future
> standards?

I'm still a bit leery, having read the handful of attempts that have
made it into past standards. But I also agree that "do a nice job"
is a tad weak.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

I am presenting a draft of proposals for math functions which are needed for
even most elementary statistics.

I have been encouraged to submit this to both the C and C++ Standard Library
groups at the same time.  (They seem to speaking more than in the past).

These are additions to the list drawn up by Walter Brown accepted into TR-1.
The style and format follows his closely even though there were some
opposition to them from the C++ community.  However I think we have to
accept that C and C++ compatibility are valued more than C++ 'ideality', and
not try to re-open this area of dissent.

The draft has been uploaded as "MoreMathFunctions.pdf" 220 kb to several
locations:

1  Boost Yahoo groups (requires Yahoo groups membership)

http://f3.grp.yahoofs.com/v1/gBLwQJA1uNRMqdORVu9i0YNtHZ_ip9BL9UBRj4z9T372IUCvfR7sATpadQip9ZAgWdzedUNRhaeLQ7J6sTtvqgBkQ3qs7DrMGw/Math%20functions/More%20Mathematical%20Functions.pdf

aka   http://tinyurl.com/357a6

2  Boost CVS sandbox

http://cvs.sourceforge.net/viewcvs.py/boost-sandbox/boost-sandbox/libs/math_functions/

aka http://tinyurl.com/6hjqs

3  My personal web site  www.hetp.u-net.com

http://www.hetp.u-net.com/public/moremathfunctions.pdf

aka

http://tinyurl.com/45xk3

It would be useful to have comments on

1  Typographical mistakes.
2  Mathematical mistakes (prepared by someone with seriously rusty math!).
3  The choice of functions, espcially if there are any you feel strongly are
missing, or are not needed (say why).
4  The choice of names.  Clarity is preferred to curtness.
5  The choice of names for derivatives like the inverse and complement. I
have added suffixes _inc and _c (or _com?).
 (for C there will be suffixes f and l for the float and long double
versions).

and of course any other issues.

Thank you.

Paul

Paul A Bristow
Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB
+44 1539 561830  +44 7714 330204
mailto: pbristow@hetp.u-net.com


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Paul A Bristow wrote:

> I am presenting a draft of proposals for math functions which are needed for
> even most elementary statistics.

> 2  Boost CVS sandbox [...] aka http://tinyurl.com/6hjqs
>
> 3  My personal web site [...] aka http://tinyurl.com/45xk3
>
> It would be useful to have comments on
>
> 1  Typographical mistakes.

On p6.

Presumably your fisher_distribution_cinv() should end _c_inv as stated
in the principles section and confirmed by gamma_incomplete_c_inv(),
amongst others.

The entry for 'double gamma(double x);' is tagged onto the end of the
comment of the prior function, gamma_incomplete_c_inv().

> 2  Mathematical mistakes (prepared by someone with seriously rusty math!).
> 3  The choice of functions, espcially if there are any you feel strongly are
> missing, or are not needed (say why).
> 4  The choice of names.  Clarity is preferred to curtness.

I have a feeling that a consistent set of abbreviations - such as
'dist' for 'distribution' - might be better, but (even if I were in
voting position) I would not vote it down for the longer names.

> 5  The choice of names for derivatives like the inverse and complement. I
> have added suffixes _inc and _c (or _com?).
>  (for C there will be suffixes f and l for the float and long double
> versions).

Leading to fisher_distribution_c_invf() and
fisher_distribution_c_invl().  I guess that is necessary because of
the precedents - it is much easier to be systematic about it and live
with any infelicities than to document (and eventually remember) the
deviations from the system.

> and of course any other issues.

Is this to be a core requirement, or would an implementation be
permitted to advertise somehow whether or not it supports this.
Judging from the preamble, the Cephes implementation by Moshier
provides a sufficiently good working prototype that it is assumed that
the implementation cost is not so great as to make the addition an
unreasonable burden on implementors?

I have a feeling that I will not be using many of these.  It just
doesn't impact my line of work.  That's not to say it is not important
to some constituencies - just that I'm not in one of those
constituencies.  OTOH, having the functions readily available would
permit people to write simple commands to access them - replacing
books of statistical tables.  (I answered a question on a Student's T
test in comp.databases.informix last week; I had to go to the web to
get the correct values - roll on Google!  That, however, was the first
time in (ugh) 15+ years I've needed to get that serious about statistics.)

--
Jonathan Leffler                   #include <disclaimer.h>
Email: jleffler@earthlink.net, jleffler@us.ibm.com
Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Paul A Bristow wrote:
> I am presenting a draft of proposals for math functions which are needed for
> even most elementary statistics.

There are of course many statistics software packages
already in existence, including one that I generally
use whenever I'm doing heavy-duty data analysis.
These packages typically provide entire environments,
such as higher-level programming languages, graphics,
and data bases.  I'm wondering how big the "customer"
base would be for a standardized C statistical
function library.  If there is indeed sufficient
interest then it might be pursued as a work project
with production of a technical report as its first
main goal.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

""Paul A Bristow"" <pbristow@hetp.u-net.com> wrote in message
news:4z6Kc.123$5_.50@newsr2.u-net.net...
> I am presenting a draft of proposals for math functions which are needed
for
> even most elementary statistics.
>
> I have been encouraged to submit this to both the C and C++ Standard
Library
> groups at the same time.  (They seem to speaking more than in the past).
>
> These are additions to the list drawn up by Walter Brown accepted into
TR-1.
> The style and format follows his closely even though there were some
> opposition to them from the C++ community.  However I think we have to
> accept that C and C++ compatibility are valued more than C++ 'ideality',
and
> not try to re-open this area of dissent.

The functions you propose appear to concentrate on those needed for
statistics.  Which is fine, but there are other special functions that might
also be good to add, if we're going to add math functions.

One that I have in mind is the modified Bessel function I0.  This function
is occasionally useful in digital filter design and digital signal analysis,
and is relatively easy to compute.  Is there any chance this could be added?

--
Eric Backus
R&D Design Engineer
Agilent Technologies, Inc.
425-356-6010 Tel


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

pbristow@hetp.u-net.com ("Paul A Bristow") wrote in message news:<4z6Kc.123$5_.50@newsr2.u-net.net>...
> I am presenting a draft of proposals for math functions which are needed for
> even most elementary statistics.

I am skeptical of the whole idea. Where does it stop? In the future,
will singular value decomposition and Fast Fourier Transforms be built
in to the language? The compiler should not try to do what can easily
be done with external source code. Also, the more tricky the function
is to calculate, the more I want to be able to see the source code,
rather than trust a compiler "black box".

Instead of adding the "asymmetric Student t" distribution and other
esoteric functions that less than 1% of C or C++ programmers will ever
use, why not improve some of the functions that already exist? For
example, could the 'pow' function be overloaded so that pow(x,4) where
'n' is an integer gives exactly x*x*x*x? I almost always use integer,
not real, powers, and I find that the Fortran ** operator works well,
handling either real or integer powers correctly.

For numerical work, what C and C++ really need is multdimensional
array functionality comparable to Fortran 90/95/2003 or Matlab. This
is a nontrivial feature that SHOULD be implemented by the compiler,
not the application programmer. The absence of convenient
multdimensional arrays, not the lack of some special functions that I
can grab from Netlib when needed, is what make C and C++ cumbersome
languages for numerical work IMO.

Btw, many of the links were broken when I tried them.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

""Eric Backus"" <eric_backus@alum.mit.edu> wrote in message
news:1090276123.587320@cswreg.cos.agilent.com...

> The functions you propose appear to concentrate on those needed for
> statistics.  Which is fine, but there are other special functions that
might
> also be good to add, if we're going to add math functions.
>
> One that I have in mind is the modified Bessel function I0.  This function
> is occasionally useful in digital filter design and digital signal
analysis,
> and is relatively easy to compute.  Is there any chance this could be
added?

Already in TR1, for arbitrary n, not just n == 0. (But we do handle
this case specially, for greater speed and precision.)

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

<beliavsky@aol.com> wrote in message
news:3064b51d.0407200633.53619e6b@posting.google.com...

> Instead of adding the "asymmetric Student t" distribution and other
> esoteric functions that less than 1% of C or C++ programmers will ever
> use, why not improve some of the functions that already exist? For
> example, could the 'pow' function be overloaded so that pow(x,4) where
> 'n' is an integer gives exactly x*x*x*x? I almost always use integer,
> not real, powers, and I find that the Fortran ** operator works well,
> handling either real or integer powers correctly.

Adding pow(double, int) causes all sorts of problems. (It was in the
C++ Standard, and in the field, for a spell.) But it's easy enough
to pick up this optimization without that overload.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

pbristow@hetp.u-net.com ("Paul A Bristow") wrote in message news:<4z6Kc.123$5_.50@newsr2.u-net.net>...
> I am presenting a draft of proposals for math functions which are needed for
> even most elementary statistics.

Why should functions such as

double log1p (double x); // log1p(x) = log(1+x) in C99.
double exp1m (double x); // expm1(x) = exp(x) - 1 in C99.
double cos1m (double x); // cosm1(x) = cos(x) - 1 in C99.

be in C or C++? They are obviously not essential, and a programmer
should not have to remember the names of too many obscure functions
specific to C and C++. In almost any imperative language one can write
'y = cos(x) - 1', and one should not write "C-only" code without a
good reason.

If one wanted to parody a committee that was adding needless language
features, it would be hard to beat defining a function 'cos(x) - 1'.

I am glad to see that 'pow' will be extended to handle integer powers.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

<beliavsky@aol.com> a    crit dans le message de
news:3064b51d.0407200633.53619e6b@posting.google.com...
> pbristow@hetp.u-net.com ("Paul A Bristow") wrote in message
news:<4z6Kc.123$5_.50@newsr2.u-net.net>...
> > I am presenting a draft of proposals for math functions which are needed
for
> > even most elementary statistics.
>
> For numerical work, what C and C++ really need is multdimensional
> array functionality comparable to Fortran 90/95/2003 or Matlab. This
> is a nontrivial feature that SHOULD be implemented by the compiler,
> not the application programmer. The absence of convenient
> multdimensional arrays, not the lack of some special functions that I
> can grab from Netlib when needed, is what make C and C++ cumbersome
> languages for numerical work IMO.
>

I would underline this. The arrays of C are completely broken. There is no
concept of rank of arrays, compatibility of arrays, extending scalar to
arrays,
etc!

It would be a BIG step forward if we got a reasonable array implementation
in the language.

The same could be done for lists, and other data structures.

Of course there are many libraries that implement lists, but all of them
are incompatible and there exist millions of separated list implementations

If there was a single API list usage, data structures usage would be
simplified.
The portability of the language would reach a more elaborate level.



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In the proposal the function "normal_distribution" and the function
"normal_probability" are identical. Is this intended?

Besides, they are the same as the C99 function "erf". The intention was
to add an alias?

Thanks for clarifying

jacob



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In <cdjq6e$jn4$1@news-reader1.wanadoo.fr> jacob@jacob.remcomp.fr ("jacob navia") writes:

>It would be a BIG step forward if we got a reasonable array implementation
>in the language.                                            ^^^^^^^^^^^^^^

You must be talking about getting reasonable array support in the language
not about an array implementation.

C being what it currently is, I guess that the only reasonable solution
is adding a new array type to the language, while leaving the existing one
as it is.

One possible syntax for this new type could be:

    int arr{2, 3};

which defines arr as a "new array" with 2 lines and 3 columns.  For better
Fortran compatibility, the indexing should be 1-based by default but
the user should be able to specify his own indexing ranges, as in:

    int arr{0:1, 0:2};

OTOH, people who need Fortran know where to find it...

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

> Why should functions such as
>
> double log1p (double x); // log1p(x) = log(1+x) in C99.
> double exp1m (double x); // expm1(x) = exp(x) - 1 in C99.
> double cos1m (double x); // cosm1(x) = cos(x) - 1 in C99.
>
> be in C or C++? They are obviously not essential, and a programmer
> should not have to remember the names of too many obscure functions
> specific to C and C++. In almost any imperative language one can write
> 'y = cos(x) - 1', and one should not write "C-only" code without a
> good reason.
>
> If one wanted to parody a committee that was adding needless language
> features, it would be hard to beat defining a function 'cos(x) - 1'.

What do you expect to be the result of, let's say 'cos(1e-50) - 1.0'?
(Hint: on usual implementations, it yields 0.0)
Are you sure the precision of the result is sufficient for anybody?
'cos1m(1e-50)' hopefully yields a more precise result (something
close to -0.5e-100). Same for the other aforementioned functions.
Depending on the context, the difference between 0.0 and -0.5e-100
may be quite significant...

Falk

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <3064b51d.0407210439.20e50827@posting.google.com> beliavsky@aol.com writes:
>pbristow@hetp.u-net.com ("Paul A Bristow")
wrote in message news:<4z6Kc.123$5_.50@newsr2.u-net.net>...
>> I am presenting a draft of proposals for math functions which are needed for
>> even most elementary statistics.
>
>Why should functions such as
>
>double log1p (double x); // log1p(x) = log(1+x) in C99.
>double exp1m (double x); // expm1(x) = exp(x) - 1 in C99.
>double cos1m (double x); // cosm1(x) = cos(x) - 1 in C99.
>
>be in C or C++? They are obviously not essential, and a programmer
>should not have to remember the names of too many obscure functions
>specific to C and C++. In almost any imperative language one can write
>'y = cos(x) - 1', and one should not write "C-only" code without a
>good reason.

    These are needed to avoid big cancellation errors
when the argument is near zero.

    Recall the Taylor series

        log(1 + x) = x - x^2/2 + x^3/3 - x^4/4 + ...

when |x| < 1.  If x is tiny, say 10^(-20), then a floating point
add 1 + x will give 1 with 53-bit precision.
Then log(1) will return zero, whereas log(1 + 10^(-20))
should be near 10^(-20).  Writing log(1 + x)
rather than log1p(x) loses all precision for this small argument.

    Suppose one wants to implement sinh(x) = (exp(x) - exp(-x))/2.
Here too we must avoid cancellation.  If we start with t = exp(x), and use

        sinh(x) = (t - 1/t)/2 = (t - 1)*(t + 1)/(2*t),

then the subtraction t - 1 can lose much precision.
But if we start with t = expm1(x), then we use

        sinh(x) = t*(t + 2)/(2*(t + 1)).

Now all values are nonegative when t >= 0, which corresponds to x >= 0.
Since sinh(x) = -sinh(-x), negative arguments are easily handled.
[A robust implementation should also avoid floating point
overflow in the t*(t + 2) product, such as using

        sinh(x) = (t/2) * (1 + 1/(t + 1)) .  ]

>If one wanted to parody a committee that was adding needless language
>features, it would be hard to beat defining a function 'cos(x) - 1'.
>
      This function is less important, since  cos(x) - 1 = -2 * sin(x/2)^2 .

>I am glad to see that 'pow' will be extended to handle integer powers.
>

--
John Adams served two terms as Vice President and one as President, but lost
reelection.  Later his son became President despite losing the popular vote.
That son lost his reelection attempt badly.  Now history is repeating itself.
pmontgom@cwi.nl    Microsoft Research and CWI      Home: Bellevue, WA

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

<beliavsky@aol.com> wrote in message
news:3064b51d.0407210439.20e50827@posting.google.com...
> pbristow@hetp.u-net.com ("Paul A Bristow") wrote in message
news:<4z6Kc.123$5_.50@newsr2.u-net.net>...

> > I am presenting a draft of proposals for math functions which are needed
for
> > even most elementary statistics.
>
> Why should functions such as
>
> double log1p (double x); // log1p(x) = log(1+x) in C99.
> double exp1m (double x); // expm1(x) = exp(x) - 1 in C99.
> double cos1m (double x); // cosm1(x) = cos(x) - 1 in C99.
>
> be in C or C++? They are obviously not essential, and a programmer
> should not have to remember the names of too many obscure functions
> specific to C and C++. In almost any imperative language one can write
> 'y = cos(x) - 1', and one should not write "C-only" code without a
> good reason.
>
> If one wanted to parody a committee that was adding needless language
> features, it would be hard to beat defining a function 'cos(x) - 1'.

That may be true, but cos1m *is not* in C99. The other two are,
because:

a) they're useful to serious math programmers, and

b) they're recommended as part of IEEE arithmetic support

If one wanted to parody a newsgroup poster shooting from the hip
with inadequate knowledge...

> I am glad to see that 'pow' will be extended to handle integer powers.

pow(T, int) is *already in* C++. (I misspoke in my previous posting,
but it has caused trouble on more than one occasion to unsuspecting
programmers.)

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Paul A Bristow wrote:

> I am presenting a draft of proposals for math functions which are needed for
> even most elementary statistics.

    The standard should encompass only math functions for
which there is a definitive correct answer out to the
limit of machine precision.  Don't standardize anything
for which one might need to choose which library is
appropriate.

    John Nagle
    Animats

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]