Markus Neher wrote:
Dear colleagues,
we have finished a beta version of CoStLy 0.3 that should take care of the problems you experienced with CoStLy 0.2.
Concerning the power function z^p, the library has been redesigned and enhanced. The details of the new implementation can be found in the preliminary draft of a documentation which is also attached.
We have extensively tested the library and eliminated all errors that we detected. Please report any bugs that occur with your computations.
Best regards,
Ingo and Markus
Dear Ingo and Markus,
thanks for the beta. In order to be able to use it we had to make the corrections you will find in the attached patch. They fall into 5 categories:
1) namespace errors whereby some std:: qualifications were missing; 2) namespace errors when compiling (as we have to) with FILIB_NAMESPACES defined; 3) incorrect uses of abs() (an int -> int function) instead of fabs() (double -> double); 4) undefined type `Complex'; 5) unused variables (causing annoying warnings).
We are now using the revised beta version. However, we could not disable our wrapper around the pow() function, since CoStLy still throws an exception for invocations like, e.g., pow(([-0.5, -0.5],[0, 0]), ([-1, -1],[0, 0])). Do you plan to address also this case? Thanks a lot
Roberto
Dear Roberto,
thanks for the beta. In order to be able to use it we had to make the corrections you will find in the attached patch. They fall into 5 categories:
Thank you very much. We have updated our code accordingly.
- namespace errors whereby some std:: qualifications were missing;
- namespace errors when compiling (as we have to) with FILIB_NAMESPACES defined;
- incorrect uses of abs() (an int -> int function) instead of fabs() (double -> double);
- unused variables (causing annoying warnings).
Thank you for the information and for the elimnation of the unused variables. Our compiler (gcc 2.95) did not show us any errors. Which compiler are you using? It seems to be better than ours.
- undefined type `Complex';
This error is puzzling. The Complex data type is contained in the C++ standard (see File Complex.h). It is simply the double version of the complex data type: typedef complex<double> Complex;
We are now using the revised beta version. However, we could not disable our wrapper around the pow() function, since CoStLy still throws an exception for invocations like, e.g., pow(([-0.5, -0.5],[0, 0]), ([-1, -1],[0, 0])).
In CoStLy 0.3, we have several power functions (see documentation) which perform differently. There is a special function for integer exponents, namely
power(Z,n) (Z: cinterval, n: integer)
Here, the logarithm is not used. power( ([-0.5, -0.5],[0, 0]), -1 ) is well defined. There are also new root functions that compute all roots, even for intervals that intersect the negative real axis.
Do you have a priori information on the type of exponents that occur in your computations? For example, if you knew that only integer exponents occurred then you could replace all calls of pow(Z,P) (Z,P: cintervals) by calls of power(Z,n) (Z: cinterval; n:integer). Or, for real or complex interval exponents, you could use pow_all instead of pow. pow_all computes an enclosure of all solutions of Z^P. pow_all never throws an exception, but sometimes a list of intervals (which cover the solution set) and sometimes the whole complex plane is returned.
The pow function is implemented as pow(Z,P) = e^(P*ln(Z)) with the principal branch of the logarithm. For our applications, we need this function to be analytic on its domain. That's why Z must not intersect the negative real axis.
Best regards,
Ingo Eble and Markus Neher
Markus Neher wrote:
- namespace errors whereby some std:: qualifications were missing;
- namespace errors when compiling (as we have to) with FILIB_NAMESPACES defined;
- incorrect uses of abs() (an int -> int function) instead of fabs() (double -> double);
- unused variables (causing annoying warnings).
Thank you for the information and for the elimnation of the unused variables. Our compiler (gcc 2.95) did not show us any errors. Which compiler are you using? It seems to be better than ours.
Hi Markus and Ingo,
I am using gcc 3.2.1. Other members of the team use other versions, but all above version 3.0 (which is the first one implementing enough standard C++ for our purposes).
- undefined type `Complex';
This error is puzzling. The Complex data type is contained in the C++ standard (see File Complex.h). It is simply the double version of the complex data type: typedef complex<double> Complex;
The header `Complex.h' is not part of the C++ standard. And, as far as I can tell, it is not part of CoStLy 0.3 beta. Perhaps a packaging problem? Or else, do you mean that `Complex.h' is part of the GCC 2.95 distribution? If so it was a non-standard feature that has been removed. Maybe the solution is simply to
1) #include <complex> in the appropriate CoStLy sources; and 2) use std::complex<double> instead of Complex.
We are now using the revised beta version. However, we could not disable our wrapper around the pow() function, since CoStLy still throws an exception for invocations like, e.g., pow(([-0.5, -0.5],[0, 0]), ([-1, -1],[0, 0])).
In CoStLy 0.3, we have several power functions (see documentation) which perform differently. There is a special function for integer exponents, namely
power(Z,n) (Z: cinterval, n: integer)
Here, the logarithm is not used. power( ([-0.5, -0.5],[0, 0]), -1 ) is well defined. There are also new root functions that compute all roots, even for intervals that intersect the negative real axis.
Do you have a priori information on the type of exponents that occur in your computations? For example, if you knew that only integer exponents occurred then you could replace all calls of pow(Z,P) (Z,P: cintervals) by calls of power(Z,n) (Z: cinterval; n:integer).
No, we do not have this knowledge a priori. Of course we can test the type of the exponent at run-time and then invoke the appropriate function.
Or, for real or complex interval exponents, you could use pow_all instead of pow. pow_all computes an enclosure of all solutions of Z^P. pow_all never throws an exception, but sometimes a list of intervals (which cover the solution set) and sometimes the whole complex plane is returned.
The pow function is implemented as pow(Z,P) = e^(P*ln(Z)) with the principal branch of the logarithm. For our applications, we need this function to be analytic on its domain. That's why Z must not intersect the negative real axis.
Thanks a lot. Please let us know when it is time to beta-test a new version of CoStLy. Cheers
Roberto
Dear Roberto,
do you mean that `Complex.h' is part of the GCC 2.95 distribution? If so it was a non-standard feature that has been removed.
Exactly.
Maybe the solution is simply to
- #include <complex> in the appropriate CoStLy sources; and
- use std::complex<double> instead of Complex.
That has been implemented in cinterval.h. You can use the two attached patches to make the changes.
Do you have a priori information on the type of exponents that occur in your computations? For example, if you knew that only integer exponents occurred then you could replace all calls of pow(Z,P) (Z,P: cintervals) by calls of power(Z,n) (Z: cinterval; n:integer).
No, we do not have this knowledge a priori. Of course we can test the type of the exponent at run-time and then invoke the appropriate function.
At the moment, we do not plan to change the pow function.
Regards,
Ingo and Markus
Markus Neher wrote:
That has been implemented in cinterval.h. You can use the two attached patches to make the changes.
Thanks! I have applied them without problems.
Do you have a priori information on the type of exponents that occur in your computations? For example, if you knew that only integer exponents occurred then you could replace all calls of pow(Z,P) (Z,P: cintervals) by calls of power(Z,n) (Z: cinterval; n:integer).
No, we do not have this knowledge a priori. Of course we can test the type of the exponent at run-time and then invoke the appropriate function.
At the moment, we do not plan to change the pow function.
Well, OK. Thanks again
Roberto
participants (2)
-
Markus Neher -
Roberto Bagnara