Hi Toby,
so there's one last thing before I can get a release out that's been
bugging me for the last couple of days: I can't seem to get the
iterative solvers to work, for either dense or sparse matrices. I've
tried an implementation of the 'mat65k.mtx' example, I've tried using
the
Hi Karl,
Karl Rupp r...@iue.tuwien.ac.at writes:
I'm on it. A couple of notes on the setup:
* The manual checkouts of external/boost_numpy and
external/viennacl-dev don't work for me (git 1.7.9.5). Is this supposed
to be automatic? If not, there should be instructions in the README.
Hmm,
Hey,
I'm on it. A couple of notes on the setup:
* The manual checkouts of external/boost_numpy and
external/viennacl-dev don't work for me (git 1.7.9.5). Is this supposed
to be automatic? If not, there should be instructions in the README.
Hmm, yes -- the README as it is at the moment
Hey Philippe,
Philippe Tillet phil.til...@gmail.com
writes:
Concerning the Norm, I have made minor changes in the
operator/operator-subfamily for a new version of the generator. Maybe your
statement parsing relies on the former family? The type
(OPERATION_UNARY_NORM_*_TYPE) has not changed,
Hi again,
back to the original problem: The RHS is not passed correctly. Use the
sample system attached, it is just 4x4 and should converge nicely. If I
print the RHS vector passed to the iterative solver, it is all zero.
Therefore, the solver doesn't even start to iterate, but instead
Hi,
Argl, the reason is that I had to do a manual clone of your Boost.NumPy
repo and did not change the branch. I don't think it's good to have a
patched repo for Boost.NumPy around...
Ah -- if you do the git submodule update --init command, I think it does
that for you. In any case, I
Hey,
Concerning the Norm, I have made minor changes in the
operator/operator-subfamily for a new version of the generator. Maybe your
statement parsing relies on the former family? The type
(OPERATION_UNARY_NORM_*_TYPE) has not changed, though...
Do you have a link to a diff I can read?
Hi Toby,
For most of the PyViennaCL functions, where the prototypes are
compatible, I pass vector_base objects to ViennaCL, because that way I
don't have to have a large number of identical functions for vector,
vector_proxy, etc. In this case, I was passing the vector as a
vector_base
Hi Toby,
That would explain why the vector mysteriously disappears. Notably, when
I put the print commands in my C++ code, I put them *after* the solver
call (probably a mistake to put them there, in hindsight, but
nonetheless it seems to have been useful!).
Why does *_base need a copy
Hi all,
The time has finally (almost) come. I'd like to make a 1.0.0 release
tomorrow (or rather, later today), but first of all, there are three
things I'd like to happen.
Firstly, I need to move pyviennacl into its own repository under
viennacl-dev on GitHub. I don't know how to do that, but
10 matches
Mail list logo
