Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

change return type for get_item #15

Open
ofloveandhate opened this issue Feb 23, 2018 · 2 comments
Open

change return type for get_item #15

ofloveandhate opened this issue Feb 23, 2018 · 2 comments

Comments

@ofloveandhate
Copy link
Contributor

the return type for VectorVisitor's get_item is as in this line of code:

static Scalar get_item(const VectorT& self, Index ix){ IDX_CHECK(ix,dyn()?(Index)self.size():(Index)Dim); return self[ix]; }

However, for numeric types which need heap allocation (multiprecision types), this causes the return of a brand-new object. But the problem is not limited to the heap allocation, which could possibly be benign. In my case, the contents of the vectors for multiprecision types are in fact of variable precision. Observe:

import pybertini
pybertini.default_precision() # gives 16
v = pybertini.multiprec.Vector(2) # make a vector of default-constructed multiprecision complex numbers (0's)
pybertini.default_precision(20) # change precision of future-made objects.  does not affect current objects.
v[0].precision() # erroneously gives 20, should give 16

So, if I make a vector of multiprecision numbers at one precision, then change the default precision to something else, and then get an element of that same vector -- which has not changed precision -- i get

  1. a new copy of that entry
  2. at the wrong precision (doesn't actually match the internal precision of the vector).

I hence propose a modification to the VectorVisitor's get_item -- that it return an internal reference. However, perhaps this is not the desired behaviour -- should I modify minieigen so that the decision of internal reference vs copy is a policy?

Pull request will be incoming..

@ofloveandhate
Copy link
Contributor Author

I think this one stands as needing attention.

@eudoxos
Copy link
Owner

eudoxos commented Apr 27, 2023

Go ahead and fork. Minieigen was developed with plain (machine) numeric types where this was never an issue. I think there must have been some reason for not returning internal references for plain numeric types. Perhaps you find a way to return internal reference for multiprecision types and keep the current behavior for plain numeric types.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants