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

[Alexei Sheplyakov]

Dear Richard,

On Sat, Mar 22, 2008 at 12:28:07AM +0100, Richard B. Kreckel 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. Anyway, I'd like to get rid of implicit
conversion, since it's very confusing.

> Is there a reason you haven't committed it somewhere?

Yes. It's a good idea to discuss a patch before commiting it to a public
branch.

> I'm a beginner with git, but it would appear to me that this could
> be handled easily with a branch, right?

Actually, it is handled with a branch. But this brunch is not public
(so I can rebase it, delete wrong commits, etc., without confusing people
who cloned my repository). 

Best regards,
	Alexei

-- 
All science is either physics or stamp collecting.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: Digital signature
Url : http://www.cebix.net/pipermail/ginac-devel/attachments/20080324/b4c3ec79/attachment.sig