Giuseppe Carleo
Giuseppe Carleo
Yes OK, I see the point now, but in my opinion the sparse*vector implementation will be always faster than our own version (even in c++). Sure there's some initial overhead...
It's worth checking if The ARNN you are using is holomorphic, if it is not then the QGT is not well defined and different methods might give some inconsistent results...
For non holomorphic complex functions the QGT of size N*N is just not well defined, I think that if te QGT method of the variational state is called in that...
> I believe that the application is well defined even in the non holonorphic case. I am not sure though this is a well defined operation, the well-defined thing is...
sorry I am confused: if the application to an **arbitrary** vector is exact, how come the matrix elements are wrong? (I can imagine to do
if I apply it to (1,0,...0) or to (i,0,...), in the second case I expect the result to be i*the_first_output, otherwise the operator is not even linear?
I think the point here is that the matrix*vector operation is not well defined (at least not in the usual sense of a linear operator acting on a vector space...
great, do we also agree that the matrix * vector product in the non-holomorphic case then is not a **standard** matrix vector product ? :) (again, the case given above...
you copied the same comment ? It seems to me that the conclusion is that in the non-holo case the object returned is not a linear operator, since what the...
if you want, I would just not support non-holomorphic complex parameters, since it is just too contrived