You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We had a (very) long discussion about this, and I don't think I'd want to include this by default (try to do tab-completion on q after doing the above example... len(dir(q)) gives 628...), since in typical usage one would (hopefully) never want to convert to straight arrays, especially once speed considerations have largely disappeared (which they will have with numpy 1.13, with long-delayed introduction of __array_ufunc__; see my PR #2583). Though one option would be to make the default configurable or allow enabling within a context.
What might be a better option is to expose the getter for the .value property, and define it such that one can give a unit. This could then even be used within the .to method. It would be something like:
def get_value(unit=None, equivalencies=[]):
value = self.view(np.ndarray)
if unit is not None:
new_val = self.unit.to(unit, value,
equivalencies=equivalencies)
if self.shape:
return value
else:
return value.item()
value = property(get_value)
def to(self, unit, equivalencies=[]):
return self._new_view(self.get_value(unit, equivalencies), unit)
I particularly like that this would just reorganize code, not introduce more. Would this be a solution?
A final alternative, depending on what exactly you want this for, is the function decorator that was discussed some time ago, to help with general code that uses arrays internally, which, like quantity_input, allows you to define what units input should be in, but returns array views of quantities converted to that unit instead of just checking that the input has a consistent unit.
p.s. for the property getter solution, of course we're free to call the getter anything we want. I'd use in if it weren't a reserved keyword; perhaps to_value(unit) or value_in(unit) is clearer than get_value(unit).
@taldcroft - with the many replacements that suddenly became possible (see #6137), it is quite clear that this is useful to have, despite my initial doubts; a few things will even become faster! And, of course, with this the decorator should be even simpler to implement.
Activity
mhvk commentedon May 28, 2017
There is a mechanism to access values in a given unit by a corresponding attribute; this is turned off by default but used in
Angle:We had a (very) long discussion about this, and I don't think I'd want to include this by default (try to do tab-completion on
qafter doing the above example...len(dir(q))gives 628...), since in typical usage one would (hopefully) never want to convert to straight arrays, especially once speed considerations have largely disappeared (which they will have with numpy 1.13, with long-delayed introduction of__array_ufunc__; see my PR #2583). Though one option would be to make the default configurable or allow enabling within a context.What might be a better option is to expose the
getterfor the.valueproperty, and define it such that one can give a unit. This could then even be used within the.tomethod. It would be something like:I particularly like that this would just reorganize code, not introduce more. Would this be a solution?
A final alternative, depending on what exactly you want this for, is the function decorator that was discussed some time ago, to help with general code that uses arrays internally, which, like
quantity_input, allows you to define what units input should be in, but returns array views of quantities converted to that unit instead of just checking that the input has a consistent unit.mhvk commentedon May 28, 2017
p.s. for the property getter solution, of course we're free to call the getter anything we want. I'd use
inif it weren't a reserved keyword; perhapsto_value(unit)orvalue_in(unit)is clearer thanget_value(unit).taldcroft commentedon May 29, 2017
Sounds good, thanks! 👍 for
value_inas that will be close in the tab-completion list.mhvk commentedon May 30, 2017
@taldcroft - with the many replacements that suddenly became possible (see #6137), it is quite clear that this is useful to have, despite my initial doubts; a few things will even become faster! And, of course, with this the decorator should be even simpler to implement.