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.
Entropy #24
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
Entropy #24
Changes from 15 commits
76986a9
1395859
b741b3d
7b4f6d5
cc221e2
7473815
ea3e81f
2998395
bfc3d22
a69ed91
3d7929b
27dbd00
873871b
dc85e9a
ca95788
d21a0bb
c127428
0106d65
b28f461
ddf358b
afdcf06
28b4efd
8c04f9c
450cfb4
5d45bdf
5c72f55
168ffa5
bb38763
c470a3a
e4be9b9
57537c3
80198bc
93371f8
5f6a004
42c3600
02a63de
05d5c66
99a391e
3a3d1f6
ca31af8
e65ef61
e39025c
99b999f
ac4c159
b429ec7
e9679fa
d2dfe8f
d8583d2
b8ed3ed
c961d9f
e7ec4b4
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.
I agree that it's not good to combine these two cases. A few options:
Result<Option<A>, DimensionMismatch>
would be fine.I think
Result<A, ShapeError>
is a bit cleaner (whereShapeError
is an enum withEmpty
andShapeMismatch
variants).Another approach is
Option<A>
, returningNone
in the empty case and panicking ifq
cannot be broadcast to the shape ofp
. I generally avoid panicking, but I think this is the best option in this case because:ndarray
's methods that operate on two arrays.The question then is why we should return
None
in the empty case instead of panicking. I think this makes sense because it's much more likely than a shape mismatch, doesn't really indicate a bug in the caller, and is more likely to be recoverable.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'd rather go for
Result<A, ShapeError>
- in the end, the caller can choose how to recover from errors (free to callunwrap
orexpect
).I can foresee various scenarios for both failure modes:
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 provide a plausible use case: it might be impossible to recover (let the program resume its expected execution flow) but there might be some actions one might want to perform before panicking for example (logging is the first that comes to my mind or sending a request somewhere in a web application context).
One can always catch the panic using stuff like this but it's less pleasant and not clear at a first glance looking at the function signature.
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.
Okay, that makes sense. We have to return an
Option
/Result
anyway, so we might as well handle all the error cases without panicking. Along the same lines, should we return an error on negative values instead of panicking? I'd expect negative values to be a bigger issue than shape mismatches, and we're already checking if values are zero.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.
On that one I am torn, because the cost of checking for negative values scales with the number of elements given that it's an additional check. Do you think it's worth it?
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.
Thinking over it again,
Result<Option<A>, DimensionMismatch>
is probably the best signature, given that most of our methods return anOption<A>
withNone
when arrays are empty. Consistency is probably worth the double wrap (unless we want to useDimensionMismatch::Empty
instead ofOption
in the rest of the API).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 didn't realize earlier that the
ln
of a negative number isNaN
(except for the noisy float types, which panic). That behavior is fine with me.Fwiw, I did a quick benchmark of the cost of adding a check for negative numbers, and it's pretty negligible (<2%) (the horizontal axis is
arr.len()
, and vertical axis is time to computearr.entropy()
; 'entropy2' is the checked implementation):(Note that I wouldn't actually return an
Option
in this case; I'd return aResult
instead.)Of course, if we check for negative numbers, someone might wonder why we don't check for numbers greater than 1 too.
I could go either way on the negative number checks. The explicit check is nice, but it adds complexity and we aren't checking other things such as values greater than 1 or the sum of values not being 1, so I guess I'd lean towards leaving off negative number checks for right now.
Okay, that's fine.
That wouldn't be too bad, although I don't really like returning an error enum when only one of the variants is possible.
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'd prefer to use
ndarray::Zip
because it should have better performance.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 have always some problems when using

Zip
- can you help me understand what the compiler is complaining about?(
.fold_while
is more appropriate, but I was doing a first step just to getZip
there. I have pushed the code, even if broken, so that you can have a look)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 got it to work by changing
let mut temp = ArrayBase::zeros(self.shape());
into
let mut temp = Array::zeros(self.raw_dim());
but I really want to understand the reason behind the extremely different outcome 😅
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, the issue is that
self.shape()
returns&[usize]
which is a slice of unspecified length, so when you callArray::zeros(anything.shape())
, you get a dynamic-dimensional array. (There have been a few issues about this in thendarray
repository from confused users, and it would be nice to resolve this raw edge of the API at some point.)Zip
requires that all arrays have the same dimensionality, so trying to zip together an array with dimensionIxDyn
and arrays with dimensionD
doesn't work (unless you forceD = IxDyn
).The issue thing is that calling
ArrayBase::zeros()
doesn't specify the storage of the array, so the compiler isn't sure what type of owned array to create (e.g.Array
orArcArray
). WritingArray::zeros()
tells the compiler that you specifically want anArray
instance.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've created rust-ndarray/ndarray#591 to help improve the docs in this area.