viennacl / pyviennacl-dev

Developer repository for PyViennaCL. Visit http://viennacl.sourceforge.net/ for latest releases.
MIT License
32 stars 6 forks source link

iterative_solve ... did not match C++ signature #32

Open schreibe opened 9 years ago

schreibe commented 9 years ago

Hi, I'm trying out pyviennacl, it sounds great so far. I can run some test code, so the setup seems to be ok. (Py 2.7 on 64bit Windows 7).

But when I try pyviennacl.linalg.solve() I'm getting an error where I'm stuck. Here's the code:

import numpy as n import pyviennacl as p

Amat = n.random.rand(20,20).astype(n.float32) Bvec = n.random.rand(20).astype(n.float32)

pvA = p.Matrix(Amat) pvB = p.Vector(Bvec)

mysolvertag = p.linalg.cg_tag()

mysolvertag = p.linalg.gmres_tag() result = p.linalg.solve(pvA, pvB, mysolvertag)

print(result)

And here's the beginning of the error message:

Traceback (most recent call last): File "", line 1, in runfile('/pvcltest.py', wdir='') File "C:\ANACONDA\lib\site-packages\spyderlib\widgets\externalshell\sitecustomize.py", line 580, in runfile execfile(filename, namespace) File "/pvcltest.py", line 19, in result = p.linalg.solve(pvA, pvB, mysolvertag) File "C:\ANACONDA\lib\site-packages\pyviennacl\linalg.py", line 474, in solve return result_type(tag.vcl_solve_call(A.vcl_leaf, B.vcl_leaf, tag.vcl_tag), File "C:\ANACONDA\lib\site-packages\pyviennacl\linalg.py", line 177, in vcl_solve_call return _v.iterative_solve(*args) ArgumentError: Python argument types in pyviennacl._viennacl.iterative_solve(matrix_row_float, vector_float, gmres_tag) did not match C++ signature: iterative_solve(class viennacl::hyb_matrix {lvalue}, class viennacl::vector {lvalue}, class viennacl::linalg::gmres_tag {lvalue})

Is there some (stupid...) mistake in my code snippet, or is there a problem with pyviennacl?

Thanks, sven

schreibe commented 9 years ago

sorry for the bad formatting of the previous comment, apparently markups and hashtags are treated specially here... -sven

tsmithe commented 9 years ago

No, that looks like a bug, though not one I've seen before. How did you install PyViennaCL?

schreibe commented 9 years ago

Am 17.02.2015 um 14:37 schrieb Toby Smithe:

No, that looks like a bug, though not one I've seen before. How did you install PyViennaCL?

— Reply to this email directly or view it on GitHub https://github.com/viennacl/pyviennacl-dev/issues/32#issuecomment-74668297.

I think I just ran the installer for Windows (pyviennacl_1.0.3.win-amd64-py2.7.exe).

("I think" because I'm experimenting on different systems and cannot rule out 100% that I mixed things up. But as I said, it does run in principle with other simple example code.)

Thanks for looking into this, Sven

schreibe commented 9 years ago

I have now tried the same code also on a different machine with Debian testing (so the packaged version there is 1.0.2 I think) and I get the same error message. So it doesn't seem to be Windows-specific. thanks, sven

tsmithe commented 9 years ago

Hi Sven,

really sorry I haven't got round to sorting this yet. I will try and do so this week.

Best,

Toby

elsdrium commented 9 years ago

Hi, I also get the same error with latest version of pyopencl on github. However, it works after changing to Upper tag.

schreibe commented 8 years ago

Hello again, and thanks to elsdrm for the hint which I've read just now. Trying the various options systematically yields:

Would there be any problem with just using the working options? What I mean is, what are the features or advantages that we are missing because the first three are not working?

thanks, sven

karlrupp commented 8 years ago

@schreibe: The first three are for iterative solvers, while the latter four are for dense triangular solvers. I'm not sure whether @tsmithe fully completed support for sparse matrices and iterative solvers yet - hopefully he will comment.

schreibe commented 8 years ago

Am 08.10.2015 um 10:23 schrieb Karl Rupp:

@schreibe https://github.com/schreibe: The first three are for iterative solvers, while the latter four are for dense triangular solvers. I'm not sure whether @tsmithe https://github.com/tsmithe fully completed support for sparse matrices and iterative solvers yet - hopefully he will comment.

Ok, but if "upper" and "lower" also serve to describe the input matrix (wasn't sure about this), then of course using them would be just wrong for a general non-triangular system matrix.

According to the help on http://viennacl.sourceforge.net/pyviennacl/doc/examples/iterative-solvers.html: "PyViennaCL provides iterative solvers for sparse and dense linear systems."

thanks, sven

kvarun95 commented 8 years ago

i am having the same problem... is it fixed??

tsmithe commented 8 years ago

Hello again all. Alas it is not yet fixed. I expect to remain very busy with my studies until August, at which point I will dedicate some time to bringing PyViennaCL up to date. Please continue to report issues / otherwise complain in any way, if you wish! I am sorry that I do not bring better news.

kvarun95 commented 8 years ago

thank you for your reply. could you suggest an alternative workaround? @schreibe , i would like to know what method you have used finally...

schreibe commented 8 years ago

Am 11.04.2016 um 16:38 schrieb kvarun95:

thank you for your reply. could you suggest an alternative workaround? @schreibe https://github.com/schreibe , i would like to know what method you have used finally...

None. I was testing different tools and haven't used pyviennacl anymore (so far), sorry.

cheers, sven

kvarun95 commented 8 years ago

The solver (iterative, with gmres tag) worked for me when I used float64 instead of float32.

kvarun95 commented 8 years ago

going through util.py was insightful. I used the CompressedMatrix format as in util.py

schreibe commented 8 years ago

Am 12.04.2016 um 04:31 schrieb kvarun95:

The solver (iterative, with gmres tag) worked for me when I used float64 instead of float32.

Interesting! I would have thought that I had tried variations like that as well, but it's too long ago, I don't really remember anymore.

thanks, sven

schreibe commented 8 years ago

Am 12.04.2016 um 04:31 schrieb kvarun95:

The solver (iterative, with gmres tag) worked for me when I used float64 instead of float32.

Well it doesn't work for me. I guess it could also depend on whether the hardware and driver combination supports double precision.

thanks, sven