[GiNaC-devel] [PATCH 1/8] inifcns_nstdsums.cpp: S_num takes cl_N as an argument instead of numeric.

[Richard B. Kreckel]

Dear Alexei,

Alexei Sheplyakov wrote:
>>> 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?
> 
> $ cat numconv2.cpp
> 
> #include <cln/cln.h>
> #include <ginac/ginac.h>
> #include <iostream>
> using namespace GiNaC;
> 
> int main(int argc, char** argv)
> {
> 	symbol a("a");
> 	cln::cl_N x = cln::cl_float(2), y = cln::pi()/6;
> 	ex e = a*(1 + log(x + y)*y + x*cos(y));
> 	std::cout << e << std::endl;
> 	return 0;
> }
> 
> $ g++ -Wall -O0 -g numconv2.cpp -lginac -lcln
> 
> numconv2.cpp: In function ‘int main(int, char**)’:
> numconv2.cpp:10: error: no match for ‘operator*’ in ‘a * cln::operator+(const cln::cl_N&, const cln::cl_N&)(((const cln::cl_N&)(& cln::operator*(const cln::cl_
> N&, const cln::cl_N&)(((const cln::cl_N&)(& cln::cos(const cln::cl_N&)()))))))’
> /usr/include/ginac/operators.h:37: note: candidates are: const GiNaC::ex GiNaC::operator*(const GiNaC::ex&, const GiNaC::ex&)
> /usr/include/ginac/operators.h:43: note:                 const GiNaC::numeric GiNaC::operator*(const GiNaC::numeric&, const GiNaC::numeric&)
> /usr/include/cln/univpoly_modint.h:188: note:                 const cln::cl_UP_MI cln::operator*(const cln::cl_UP_MI&, const cln::cl_MI&)
> [skipped the rest]
> 
> But my analysis seems to be wrong.

Well, the example is calling for an operator*(symbol, cl_N) and the 
compiler's only matches are operator*(ex, ex) and operator*(cl_<type1>, 
cl_<type2>). Class numeric isn't involved and making that ctor explicit 
won't help.

> Anyway, I'd like to get rid of implicit
> conversion, since it's very confusing.

That conversion seems to be rarely used except inside GiNaC proper. At 
least Orsa, nestedsums, and xloops do not use it. I don't think anyone 
would miss its removal.

   -richy.
-- 
Richard B. Kreckel
<http://www.ginac.de/~kreckel/>