Gabriel Dos Reis wrote:
>
> remove.haberg@matematik.su.se (Hans Aberg) writes:
>
> [...]
>
> | For example, complex<T>::exp is defined in terms of T::exp, T::sin, and
> | T::cos, so if T has the latter ones, complex<T> should have exp.
>
> That's is *one* way to do things.  Another is to use sequences (which
> in effect don't require sin nor cos).
>

And that's how it's typically implemented, because it's far easier to
minimize the error in a sequence than in a combination of three
different transcendentals, each of which can contribute to the error.
Not to mention faster...

--
Pete Becker
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.research.att.com/~austern/csc/faq.html                ]

In article <dilsnb8uiec.fsf@isolde.research.att.com>, Matthew Austern
<austern@research.att.com> wrote:
>> remove.haberg@matematik.su.se (Hans Aberg) writes:
...
>> | One logical picture that comes to my mind is that std::complex<T> would
>> | require T::exp, T::sin, T::cos to exist. If they do exist, one would get a
>> | function named std::complex<T>::exp.
...
>...I think that this problem can be
>solved.  ...  The main
>issue here is just that there are multiple ways of solving it, each
>with advantages and disadvantages.  We need to make a choice, and it's
>not an obvious one.

One variation might be that T is required to have T::exp, T::sin, T::cos
as types, say each with an T::exp::operator(), so that they can be treated
as functions. Then, std::complex<T>::exp has the generic formula
  (*) exp(z) = exp(Re z)(cos(Im(z)) + i sin(Im(z)))
which can be overridden by specializations.

In article <flsnb8cnva.fsf@riz.cmla.ens-cachan.fr>, Gabriel Dos Reis
<dosreis@cmla.ens-cachan.fr> wrote:
>...Another is to use sequences (which
>in effect don't require sin nor cos).

So in this approach (as I pointed out before), the presence of T::exp,
T::sin, T::cos just indicate that std::complex<T>::exp can be defined, but
if an implementor finds a better way, that is okay.

In article <floflwcno6.fsf@riz.cmla.ens-cachan.fr>, Gabriel Dos Reis
<dosreis@cmla.ens-cachan.fr> wrote:
>...I don't think you can
>solve it by simply hand waving like you did above. Let's get real.

Let's get complex: :-)

One problem with the approach above is that standard C types like double,
etc. are not class like.

But as for the namespace problem, one gets an object named
std::complex<T>::exp. Then one would expect the argument type ("Koenig")
lookup system from a defined object std::exp to identify the suitable
std::complex<T>::exp, or std::U::exp or whatever.

And, an argument lookup should be able from "exp" to identify the suitable
namespace object std::exp.

So, if you just flip in some suitable C++ language extensions, this might
just do the trick.

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Wonderful; I commend P.J. Plauger for pursuing this, and you for bringing it
up here.

Another excellent resource is David Tribble's discussion of
Incompataibilities between C99 and C++:

http://david.tribble.com/text/cdiffs.htm

I've had long history with the C99 extensions, having documented their
earliest form when they were being developed by the Numerical C Extensions
Group. If memory serves, Rex Jaeschke was one of the directors of that
effort, which started back in '89 or '90.

If this is the best forum for in-depth discussion, I'll work up some of my
comments over the next day or so and post them. I do quite a bit of
numerical work, and would like to see strong mathematical support in C++0X.

Thanks.

--
Scott Robert Ladd
Master of Complexity, Destroyer of Order and Chaos
  Visit CoyoteGulch at http://www.coyotegulch.com
    No ads -- just info, algorithms, and very free code.


---
[ 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.research.att.com/~austern/csc/faq.html                ]

Paris (U.E.), le 18/11/2001

Matthew Austern <austern@research.att.com> wrote in message news:<dild72j1x31.fsf@isolde.research.att.com>...
> Kevin Lynch <krlynch@bu.edu> writes:
>
> > -> Extend <complex>: The current C++ Standard [26.2.2] does not permit
> > complex<T> to be instantiated for any T other than {float, double,
> > long double}.  The standard should be modified to allow instantiation
> > for any type that has the semantics of the built-in floating-point
> > types (for example, a user defined unlimited precision floating point
> > type, but not, for example, int).
>
> This is controversial, or at least needs more work.
>
> The reason complex<T> isn't instantiable for any types other float,
> double, and long double is that we didn't know what to do about the
> complex transcendentals.  After all, something like sin(complex<T>) is
> probably implemented in terms of various exponential and trigonometric
> functions defined on T.  What requirements do we place there?  (And
> note that this can start getting *very* tricky when you start
> thinkinga about namespace issues.)
>
> I'm not saying that this question has no answer.  The standardization
> committee just wasn't able to think of a good enough answer in time.
>
> Here are three possible answers---none of them is precise enough, but
> they're at least three lines we imagine working along.
>  - complex<T> is instantiable for any T that looks enough like a
>    field (I'm sure lots of people would like to see gaussian
>    integers), but the transcendental functions, and sqrt and abs,
>    are only instantiable for float, long, and long double.
>  - complex<T> is instantiable for any T that looks like a field
>    and that has conversions to and from long double.
>  - complex<T> is instantiable for any T that has the same semantics
>    as the built-in floating-point types.  This requirement means
>    that sqrt, sin, cos, exp,... must be defined for T and must
>    have the same meanings as for the built-in types.

 I would favour yet another approach:

- complex<T> is instantiable for any T that has the same semantics as
the built-in floating-point types, as far as arithmetic and order
behaviour is concerned. Transcendentals may or may not be supported on
a case by case basis, which must be documented, but is within the
realm of QoI.

 It is not really proper to instantiate complex<T> as it currently
defined on any field, as in that case we may want to add "structural
constants" (which add nothing interesting in case the field in
question is R; I can further document; above option 1).

 It might of course be interesting to have complex<wow_is_this_long>,
but might perhaps not be feasible, on a given platform, to implement
all one's favorite transcendentals. We should not therefore impose the
presence of all transcendentals (above option 3). Then we might want
to use a finite-precision, "exact" class, for which the full gamut of
transcendentals should be present, but do not rely on a true floating
point type (above option 2).

 As these are rather special, if perfectly legitimate, uses,
provisions should me made for them in the standard, but, I believe,
only loose ones.

[I had promissed a formal write-up about that to Boost members a few
month back, but, well, as usual, I am running after time...]

  Hubert Holin
  Hubert.Holin@Bigfoot.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.research.att.com/~austern/csc/faq.html                ]

In article <dild72j1x31.fsf@isolde.research.att.com>, Matthew Austern
<austern@research.att.com> wrote:
>The reason complex<T> isn't instantiable for any types other float,
>double, and long double is that we didn't know what to do about the
>complex transcendentals.  After all, something like sin(complex<T>) is
>probably implemented in terms of various exponential and trigonometric
>functions defined on T.  What requirements do we place there?

I think that complex functions are defined in terms of functions on T and
the complex unit. So it the type T has those defining functions, the
complex<T> should have the corresponding function. (I do not knwi how this
works out in C++, though).

For example, complex<T>::exp is defined in terms of T::exp, T::sin, and
T::cos, so if T has the latter ones, complex<T> should have exp. And
complex<T>::log is defined in terms of T::log and T::arg, so if the latter
ones are defined, complex<T> should have log.

One also has complex<T>::norm, the square of complex<T>::abs, which will
always work (assuming that T has the ring operations), whereas
complex<T>::abs will only work if T::sqrt exists.

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ 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.research.att.com/~austern/csc/faq.html                ]

remove.haberg@matematik.su.se (Hans Aberg) writes:

> In article <dild72j1x31.fsf@isolde.research.att.com>, Matthew Austern
> <austern@research.att.com> wrote:
> >The reason complex<T> isn't instantiable for any types other float,
> >double, and long double is that we didn't know what to do about the
> >complex transcendentals.  After all, something like sin(complex<T>) is
> >probably implemented in terms of various exponential and trigonometric
> >functions defined on T.  What requirements do we place there?
>
> I think that complex functions are defined in terms of functions on T and
> the complex unit. So it the type T has those defining functions, the
> complex<T> should have the corresponding function. (I do not knwi how this
> works out in C++, though).
>
> For example, complex<T>::exp is defined in terms of T::exp, T::sin, and
> T::cos, so if T has the latter ones, complex<T> should have exp. And
> complex<T>::log is defined in terms of T::log and T::arg, so if the latter
> ones are defined, complex<T> should have log.

That's workable, but there are two things we'd have to keep in mind.

First, the standard would effectively have to specify how the complex
transcendentals are implemented.  At present, nothing in the standard
says that std::exp(std::complex<double>) is implemented in terms of
std::sin(double), std::cos(double), and std::exp(double).  Yes, that's
the implementation you get from the straightforward expression exp(i
z) = exp(Re(z)) (cos(Im z) + i sin(Im z)), but the standard doesn't
currently require that implementation.  There are other reasonable
algorithms, at least if you restrict yourself to the built-in
floating-point types.

Second, as I alluded to in an earlier message, there are namespace
issues.  If the intent is that std::exp(std::complex<T>) invoke a
user's sin(T), then the standard will have to specify that it must
specifically call "sin(x)", as opposed to "std::sin(x)" or "::sin(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.research.att.com/~austern/csc/faq.html                ]

In article <dilsnbazmdh.fsf@isolde.research.att.com>, Matthew Austern
<austern@research.att.com> wrote:
>> I think that complex functions are defined in terms of functions on T and
>> the complex unit. So it the type T has those defining functions, the
>> complex<T> should have the corresponding function. (I do not knwi how this
>> works out in C++, though).
>>
>> For example, complex<T>::exp is defined in terms of T::exp, T::sin, and
>> T::cos, so if T has the latter ones, complex<T> should have exp. And
>> complex<T>::log is defined in terms of T::log and T::arg, so if the latter
>> ones are defined, complex<T> should have log.
>
>That's workable, but there are two things we'd have to keep in mind.
>
>First, the standard would effectively have to specify how the complex
>transcendentals are implemented.  At present, nothing in the standard
>says that std::exp(std::complex<double>) is implemented in terms of
>std::sin(double), std::cos(double), and std::exp(double).  Yes, that's
>the implementation you get from the straightforward expression exp(i
>z) = exp(Re(z)) (cos(Im z) + i sin(Im z)), but the standard doesn't
>currently require that implementation.  There are other reasonable
>algorithms, at least if you restrict yourself to the built-in
>floating-point types.

If you want to capture the situation where complex<T> sometimes have exp,
and sometimes don't, you probably have to rely on algebraic formulations,
like saying that
  T::exp, T::sin, T::cos defined => complex<T>::exp defined
I think that C++ can allow special instantiations, so the requirement would that
    exp(z) = exp(Re(z)) (cos(Im z) + i sin(Im z))
holds up to a suitable approximation, but not that it is necessarily
implemented by that formula. Then the implementor can choose whatever
method is best for each particular instantiation.

>Second, as I alluded to in an earlier message, there are namespace
>issues.  If the intent is that std::exp(std::complex<T>) invoke a
>user's sin(T), then the standard will have to specify that it must
>specifically call "sin(x)", as opposed to "std::sin(x)" or "::sin(x)".

I think you are running into problems with C++'s heritage from C here,
which does not properly specify what "sin" might mean:

One logical picture that comes to my mind is that std::complex<T> would
require T::exp, T::sin, T::cos to exist. If they do exist, one would get a
function named std::complex<T>::exp.

I am not sure how to fit that into C++'s reality. The functions above
might be class static functions. One other problem is that C++ allows both
sin(T) and T::sin() to be used side by side.

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Hubert.Holin@Bigfoot.com (Hubert HOLIN) writes:

[...]

| - complex<T> is instantiable for any T that has the same semantics as
| the built-in floating-point types, as far as arithmetic and order
| behaviour is concerned.

In concrete, what does that mean in Standardese?

--
Gabriel Dos Reis, dosreis@cmla.ens-cachan.fr

---
[ 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.research.att.com/~austern/csc/faq.html                ]

remove.haberg@matematik.su.se (Hans Aberg) writes:

[...]

| For example, complex<T>::exp is defined in terms of T::exp, T::sin, and
| T::cos, so if T has the latter ones, complex<T> should have exp.

That's is *one* way to do things.  Another is to use sequences (which
in effect don't require sin nor cos).

--
Gabriel Dos Reis, dosreis@cmla.ens-cachan.fr

---
[ 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.research.att.com/~austern/csc/faq.html                ]

remove.haberg@matematik.su.se (Hans Aberg) writes:

[...]

| >Second, as I alluded to in an earlier message, there are namespace
| >issues.  If the intent is that std::exp(std::complex<T>) invoke a
| >user's sin(T), then the standard will have to specify that it must
| >specifically call "sin(x)", as opposed to "std::sin(x)" or "::sin(x)".
|
| I think you are running into problems with C++'s heritage from C here,
| which does not properly specify what "sin" might mean:
|
| One logical picture that comes to my mind is that std::complex<T> would
| require T::exp, T::sin, T::cos to exist. If they do exist, one would get a
| function named std::complex<T>::exp.

I think you're missing Matt's point here.

| I am not sure how to fit that into C++'s reality.

That precisely is the issue raised by Matt.  I don't think you can
solve it by simply hand waving like you did above. Let's get real.

--
Gabriel Dos Reis, dosreis@cmla.ens-cachan.fr

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Gabriel Dos Reis <dosreis@cmla.ens-cachan.fr> writes:

> remove.haberg@matematik.su.se (Hans Aberg) writes:
>
> [...]
>
> | >Second, as I alluded to in an earlier message, there are namespace
> | >issues.  If the intent is that std::exp(std::complex<T>) invoke a
> | >user's sin(T), then the standard will have to specify that it must
> | >specifically call "sin(x)", as opposed to "std::sin(x)" or "::sin(x)".
> |
> | I think you are running into problems with C++'s heritage from C here,
> | which does not properly specify what "sin" might mean:
> |
> | One logical picture that comes to my mind is that std::complex<T> would
> | require T::exp, T::sin, T::cos to exist. If they do exist, one would get a
> | function named std::complex<T>::exp.
>
> I think you're missing Matt's point here.
>
> | I am not sure how to fit that into C++'s reality.
>
> That precisely is the issue raised by Matt.  I don't think you can
> solve it by simply hand waving like you did above. Let's get real.

I should make it clear, though: I think that this problem can be
solved.  I don't view this as an insuperable objection.  The main
issue here is just that there are multiple ways of solving it, each
with advantages and disadvantages.  We need to make a choice, and it's
not an obvious 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.research.att.com/~austern/csc/faq.html                ]

Migrating C99 math functionality to Standard C++

Beman Dawes recently posted to the boost mailing list a summary of the
recent C++ Standards Committee meeting in Redmond; that post mentioned
that P. J. Plauger plans to propose migrating appropriate portions of
the C99 library (and language) forward into the C++ TR.  Beman
suggested that I post my few cents on a subset of the functionality
that I would like to see move forward into C++ so that the committee
could see it early on in the process.  I've also included some other
non-C99 migration items below.  I've divided it into "Things that
shouldn't be controversial" and "Things that might/could/will be
controversial".  Of course, I'll probably put some things in the
former category that should be in the latter :-) But from my view as a
practicing physicist that uses code as a (very) important tool in my
daily work, these are the directions I would like to see support for
my uses of the language/library.  Warning:  the post is long, and I
apologize if I've missed discussion of any of these items.



"Things that shouldn't be controversial"

-> long long: the "long long int" type should be added to the
language, and the appropriate functions in the math library (those
that currently have int and long overloads) should get overloaded on
long long as well.

-> Add <cfenv>: Floating-point environment control in <fenv.h> can be
added without any changes that I can think of. [7.6 Floating-point
Environment]

-> tgmath.h [7.22 Type-generic math] should NOT be brought into C++;
tgmath exists (IMHO) only to mitigate the fact that C does not support
function overloads.  C++ overload support more than suffices.

-> Extend <cmath>: All of the various functionality (but not
necessarily the functions) in math.h [7.12 Mathematics] should be
migrated into C++; just as in the current version of the standard, all
of the functions should be overloaded on the appropriate types (acosh
-> float acosh(float), double acosh(double), long double acosh(long
double), for example).  See below for the argument that many of the
actual _functions_ should not be migrated "as is".  Further, the new
"floatin-point exception" error mechanism should also be migrated
forward as is.

-> Extend <complex>: There is new functionality in complex.h [7.3
Complex Arithmetic and 7.26.1 Future Library Directions - Complex
Arithmetic] that is not available in <complex>.  Many of the missing
functions should be added to <complex> (things like acosh, but not
things that are already properly supported by the operator syntax,
cadd, cmult, etc).  Additionally, all of the functions in C99 math.h
that would not be in the intersection of <complex.h> and <complex> and
that apply to complex numbers should also be added to <complex> (for
example, erf, gamma, etc.).  Again, these should be overloaded on the
appropriate built-in floating point types, and there should be no
"suffix functions" (see below).

-> Extend <complex>: The current C++ Standard [26.2.2] does not permit
complex<T> to be instantiated for any T other than {float, double,
long double}.  The standard should be modified to allow instantiation
for any type that has the semantics of the built-in floating-point
types (for example, a user defined unlimited precision floating point
type, but not, for example, int).


"Things that might/could/will be controversial"

-> Extend <cmath>: All of the various functions added to math.h to
overcome the lack of overloading in C (such as cosf, cosl, the "suffix
functions"), should NOT be added to the library: the functionality is
more correctly supported within the C++ language by overloading the
base name.  The addition of these names pollutes not only the
namespace with extra names, but also pollutes and confuses the
interface of the library making it harder to teach and learn.

-> Extend <cmath>: All of the various function-like macros added to
math.h by C99 should be added to C++.  However, these function-like
macros (fpclassify, isgreater, etc), again, have to be macros in C
because of the lack of overloading.  In C++, these should be promoted
to appropriately overloaded functions, and the macros should not
appear in the standard.

-> Extend <cmath> and <complex>: As long as we're adding functionality
from C99 to C++, why not go it one better, and add some more missing
functionality?  In particular, since we're going to have gamma
functions and error functions, let's complete the family: the
incomplete gamma function, the beta function, the incomplete beta
function, and their logarithms.  (I'd also like to see all the other
special functions: the bessel functions, the legendre functions, etc,
but I don't think I'll win that one :-)

-> Macros -> constants: It would be nice if all of the "macro
constants" in C99/C++ (NAN, INFINITY, HUGE_VAL, etc.), since they
can't be eliminated, could be replaced with constant variables ala
boost's cstdlib replacement of EXIT_SUCCESS with (const int
exit_success).  Macro constants are icky, and the standard should
strive to abandon them whereever and whenever possible.

-> Precision and Cost Documentation: It would also be nice if a
conforming implementation could be required to document in detail the
precision and runtime guarantees for its math functions.  For example,
consider three implementations of sqrt(x): one which has high precision
around x=1.0 with high speed, but lousy precision elsewhere with low
speed, a second with equally lousy precision everywhere, but which
is very fast, and a third which has good precision everywhere, but
lousy performance.  It is often necessary to know such information
when implementing numerically intensive code, but the standard should
not dictate those guarantees, which would substantially limit special
purpose implementations that would otherwise be conforming.  This
would be the inverse of the complexity guarantees in the algorithm
library: there, the standard guarantees a certain complexity and
documents it; here the standard would not guarantee performance or
runtime implications, but would require that the choices be
documented.

-> Constant Optimization: I haven't fully figured this one out, but
I'll put it here anyway.  Most of the times that standard library math
functions are called with constant arguments, there is no reason
(conceptually anyway) that any code needs to be generated.  For
example, there is no reason that sqrt(2.) can't be determined at
compilation time, eliminating the expensive runtime call.  Widespread
implementation of this sort of optimization would make C++ a much more
powerful language for numerical and scientific applications.  I don't
know if the current standard would allow this behavior: basically, if
the compiler can determine the return value and all of the side
effects of a call at compile time (it's the side effects that worry me
:-), you can precompute the results and eliminate the runtime cost.
For a restricted set of functionality like the math library,
implementing this type of optimization shouldn't be too difficult (ok,
I admit that I'm guessing here; I don't write compilers :-) Supporting
this may require no action on the part of the Committee (ie. it is an
optimization that vendors are already allowed to perform if they felt
like it), or it may require action in the form of standard wording
changes or even some language mechanism; I'm really not sure.  This
type of optimization may have wider applicability than just to the
math library.

-> restrict keyword: Migrate the restrict keyword [6.7.3 Type
Qualifiers and 6.7.3.1 Formal Definition of Restrict].  restrict
allows the translator to ignore potential aliasing issues for
pointers.  This is important for optimization purposes, but it isn't
clear to me how to go about integrating this into the language:
certainly, it won't be difficult to make restrict work the same way in
C++ that it works in C (for example, void somefunc(double *restrict
in, double *restrict out, size_t n) ), but this probably doesn't go
far enough.  It would be nice if it could be applied to other types of
functions to indicate to the compiler that more general argument types
don't overlap: template <typename T> void somefunc(Array<T>& restrict
In, Array<t>& restrict Out) for example; here, we see that restrict
needs to apply to references as well as pointers.

-> For the future, I'd like to see some support for parallel
processing (not threading, parallel processing) and a fortran like
array language find their way into the language, but I don't expect
that I'll see that in the TR :-)

--
-------------------------------------------------------------------------------
Kevin Lynch    voice:  (617) 353-6065
Physics Department   Fax: (617) 353-6062
Boston University   office:  PRB-565
590 Commonwealth Ave.   e-mail:  krlynch@bu.edu
Boston, MA 02215 USA   http://physics.bu.edu/~krlynch
-------------------------------------------------------------------------------

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Kevin Lynch <krlynch@bu.edu> writes:

> -> Extend <complex>: The current C++ Standard [26.2.2] does not permit
> complex<T> to be instantiated for any T other than {float, double,
> long double}.  The standard should be modified to allow instantiation
> for any type that has the semantics of the built-in floating-point
> types (for example, a user defined unlimited precision floating point
> type, but not, for example, int).

This is controversial, or at least needs more work.

The reason complex<T> isn't instantiable for any types other float,
double, and long double is that we didn't know what to do about the
complex transcendentals.  After all, something like sin(complex<T>) is
probably implemented in terms of various exponential and trigonometric
functions defined on T.  What requirements do we place there?  (And
note that this can start getting *very* tricky when you start
thinkinga about namespace issues.)

I'm not saying that this question has no answer.  The standardization
committee just wasn't able to think of a good enough answer in time.

Here are three possible answers---none of them is precise enough, but
they're at least three lines we imagine working along.
 - complex<T> is instantiable for any T that looks enough like a
   field (I'm sure lots of people would like to see gaussian
   integers), but the transcendental functions, and sqrt and abs,
   are only instantiable for float, long, and long double.
 - complex<T> is instantiable for any T that looks like a field
   and that has conversions to and from long double.
 - complex<T> is instantiable for any T that has the same semantics
   as the built-in floating-point types.  This requirement means
   that sqrt, sin, cos, exp,... must be defined for T and must
   have the same meanings as for the built-in types.


---
[ 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.research.att.com/~austern/csc/faq.html                ]

Matthew Austern wrote:

> Kevin Lynch <krlynch@bu.edu> writes:
>
>
>>-> Extend <complex>: The standard should be modified to allow instantiation
>>for any type that has the semantics of the built-in floating-point
>>types
>>
>
> This is controversial, or at least needs more work.
>


See, I knew I'd put something in the wrong category  :-)


> The reason complex<T> isn't instantiable for any types other float,
> double, and long double is that we didn't know what to do about the
> complex transcendentals.  [.....snip.....]

 >

It hadn't occurred to me that this was the issue, but that just points
to my lack of imagination  :-)

> I'm not saying that this question has no answer.  The standardization
> committee just wasn't able to think of a good enough answer in time.
>
> Here are three possible answers---none of them is precise enough, but
> they're at least three lines we imagine working along.

> [.....snip.....]
>  - complex<T> is instantiable for any T that has the same semantics
>    as the built-in floating-point types.  This requirement means
>    that sqrt, sin, cos, exp,... must be defined for T and must
>    have the same meanings as for the built-in types.


This is my clear favorite; in my work at least, a floating point type
that _doesn't_ have (most of) the transcendental functions defined is a
pretty useless beast (yes, it isn't often that you need
lgamma(complex<T>), and requiring that to be defined might upset some
people, but if you don't have cos(T) and you call T a floating-point
type, you haven't got much of anything useful).  I realize that there
are serious issues that need to be addressed here, but I would hope the
Committee could be convinced that this is the "right" direction to go
in, and then figure out how to get there.

Still and all, this part of my post probably isn't that important in the
grand scheme of things; if you really need complex<T> for T not a built
in type, you are going to find a way to provide it for yourself anyway,
even if it isn't through std::complex<T>.  But I hope that some solution
along these lines can be reached.

--
-------------------------------------------------------------------------------
Kevin Lynch    voice:  (617) 353-6065
Physics Department   Fax: (617) 353-6062
Boston University   office:  PRB-565
590 Commonwealth Ave.   e-mail:  krlynch@bu.edu
Boston, MA 02215 USA   http://physics.bu.edu/~krlynch
-------------------------------------------------------------------------------

---
[ 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.research.att.com/~austern/csc/faq.html                ]