Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
value2index: convert index to int #2765
value2index: convert index to int #2765
Changes from 5 commits
3f91fe8
72df017
dac2ced
a67980b
5ebe28e
9b6a944
a50e108
74d2afb
c977edd
ef35be2
aa43a08
3644d22
7a55b07
3561a67
0659013
595be28
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks Good To Me.
However, this behaviour is weird because in the
numba_closest_index
functions, the returned array is initialized with"uint"
dtype and argmax / argmin functions should not return anything else thanint
types. I wonder what causes this behaviour...Well, if it works like this then who am I to judge?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree, this is odd, there should be a bug somewhere and from a quick look, it should not return float type and casting explicitly to
int
after calling jitted function shouldn't be necessary...There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought so as well.
However, for some reason a statement such as
s.isig[value2index(x)+1:]
would throw an error forvalue2index(x)+1
not being anint
that can be used as index. It is explicitly for when another integer is added/subtracted to the result ofvalue2index
It is the source of the failure of the tests in LumiSpy/lumispy#78 (comment)As the failure appeared only recently and only for the
non_uniform_axes
branch it must be a result of rewriting thevalue2index
function.Adding the
.astype(int)
fixes this problem. (Note that thevalue2index
function forUniformDataAxis
also explicitly casts toint
.) Therefore, I propose to go for this "workaround".There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I share this opinion
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here the idea is to deal with the case where two identical values are found in
vdiff_array
in which case you want to return the last one to ensure rounding above, I guess.Unfortunately, while this might solve a failing test, this is not a solution for two reasons:
vdiff_array==np.min(vdiff_array)
matches more than 1 value does not typically happens.Here is an example:
As you can see, this performs a rounding below (case 1) and we only have one single value matched in the equality comparison operator (case 2). Of course, the reason for this behaviour is float arithmetics. We have:
which, no matter how you look at it, will still round below in most strategies, I think the best way to deal with it would be to bias very slightly vdiff_array towards upper-rounding. I would advocate something like
np.abs(axis_array - v + MACHINEEPSILON)
andMACHINEEPSILON
would be determined using some relative tolerance, egrtol=1e-10; MACHINEEPSILON = np.min(np.diff(axis))*rtol
.I don't pretend this is the ideal solution. But it can shifts a commonly encountered problem (incorrect value2indexing exactly half the interval between axis points) to a much less commonly encountered one (incorrect value2indexing a value that is very close but not equal to exactly half the interval between axis points)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, the idea was to enforce rounding up for a
0.5
value.I like your idea with the upwards bias, I had thought in a similar direction. I'll implement that to see.
Though, I now realize that numpy also does not necessarily round 0.5 upwards, but it rounds to the next even number: https://github.com/numpy/numpy/blob/e94ed84010c60961f82860d146681d3fd607de4e/numpy/core/fromnumeric.py#L2723-L2789
(explicitly mentioning the issue with machine precision as well).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah exactly.
Actually I wonder why this rounding approach is used in hyperspy. When slicing with a float value, I would personally prefer knowing in advance whether the sliced axis will contain or not the value I input.
I would agree it's not a big deal, but in the end we spend some effort to preserve this functionality.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is python rounding which uses the round-to-even strategy to avoid accumulation of offset: https://realpython.com/python-rounding/#pythons-built-in-round-function
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To be consistent with the behaviour for non-uniform axes, I have used a machineepsilon here as well to have 'round-away-from-zero' instead of 'round-to-even'
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, in the end I think it does not make sense to touch this function,because round is of course used elsewhere in the code as well and we should be consistent there.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure what behaviour you mean. You want a behaviour similar to numpy.rint? https://numpy.org/doc/stable/reference/generated/numpy.rint.html#numpy.rint
In any case, I quickly checked out your branche and I think there still is an issue of uniformity between the Uniform and Non Uniform Axes
I assume the behaviour you desire is the one from NUA?