[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