[GiNaC-devel] [PATCH 1/8] inifcns_nstdsums.cpp: S_num takes cl_N as an argument instead of numeric.
Richard B. Kreckel
kreckel at ginac.de
Sat Mar 22 00:28:07 CET 2008
Dear Alexei,
Alexei Sheplyakov wrote:
> Implicit conversion from cl_N to numeric considered harmful.
I agree: It's quite a greedy mechanism that does have its pitfalls.
> Using GiNaC::numeric for numerical computations incurs significant
> overhead, so one might want to do these computations using proper CLN
> types. Unfortunately, it's not easy due to automatic conversion from
> cln::cl_N to GiNaC::numeric. Here is a simple example:
>
> cl_N x, y;
> // initialize them
> return sin(x) + y*exp(y);
>
> The compiler complains about ambigously overloaded of functions, i.e.
> cl_N cln::sin(const cl_N&) versus numeric GiNaC::sin(const numeric&).
Does it? Can you provide a complete example? This program compiles fine:
#include <cln/cln.h>
#include <ginac/ginac.h>
using namespace GiNaC;
using namespace cln;
int main()
{
cl_N x, y;
// initialize them
numeric result = sin(x) + y*exp(y);
}
> Hence, I propose to disable *implicit* conversion from cl_N to numeric
> (this can be done by marking the numeric ctor as `explicit').
Or, alternatively, by making it private! (But I'm not sure if this does
eliminate all ambiguities.)
> However, this change happens to be a bit nontrivial, because that evil
> conversion is used in GiNaC itself. So, I decided to rewrite those fragments
> of code.
Is there a reason you haven't committed it somewhere? I'm a beginner
with git, but it would appear to me that this could be handled easily
with a branch, right?
Best wishes
-richy.
PS: I've pushed your other changes.
--
Richard B. Kreckel
<http://www.ginac.de/~kreckel/>
More information about the GiNaC-devel
mailing list