I think this is all of the cases. These cases arise because pow(a,b) is limited
to real valued results, if the argument and result were complex valued then
these cases would disappear.
NOTE: Since there is so much special casing here, it is worth checking to see
if cpow() is implemented in terms of pow(), and what might be the consequences
of using cpow() on the type std::complex<Jet<double, N> >. It is *possible*
that a separate implementation of cpow might be required also.
Also some comment fixes.
Change-Id: Ia1e38df4cdcb548f778304c2854cacba6e1556ff
Since Ceres is moving to using GitHub for issues, and the Google
Code URL in the current copyright header will soon become invalid,
update all the headers.
Change-Id: I1fce70375d1bcf098591f07b4d8f01a5c1e0789c
This is a preliminary, but full, port of Ceres to Windows.
Currently all tests compile and run, with only system_test
failing to work correctly due to a path issue.
Change-Id: I4152c1588bf51ffd7f4d9401ef9759f5d28c299c
Ceres has traditionally battled with portability issues
when trying to classify floating point values as one
type or another. For example, in C99 'isnan' is a
macro. Since it is a macro, it is impossible to
override the name in other namespaces.
Instead of trying to use preprocessor hacks to work
around the issue, define our own set of camel-case
names for use internally and by Ceres clients. For
example do this:
template<typename T>
void MyFunction(T x, T y) {
if (ceres::IsNaN(x)) {
...
}
}
instead of using "isnan" or "std::isnan". Note that
while GCC and Apple GCC both import 'isnan' into
the std namespace, it is not standard until C++11
which Ceres will not require for some years.
Change-Id: Ibcc96a8bb4ba63aa67cbbc58658b2e5671cd5824
Russell Smith