-
Notifications
You must be signed in to change notification settings - Fork 16
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
operations on Mat.empty #22
Comments
interestingly, |
BLAS semantics is sometimes not exactly well-thought-out when it comes to corner cases. LACAML should not bomb with a Fortran exception here, of course (please keep reporting any such occurrences). But I don't think following the exact BLAS semantics makes sense either. BLAS allows I'm not sure what "sane" behavior should be. I'm actually leaning towards just raising exceptions for empty arguments when BLAS/LAPACK would bomb. Empty matrices can be strange anyway. E.g. Note that @Chris00 what do you think about empty matrix arguments? Any preference for how they should be handled? |
I think you're probably right in most cases. My case was like this: I construct a block matrix from four input matrices by first allocating it, then looping over the inputs and filling rows and column of the block matrix. I was pleased to see that this actually worked out of the box for Its' interesting to think about what a dimension of 0 should behave like for best consistency. Thinking about matrices as maps on vector spaces, I guess the corresponding concept (say on the real numbers) would be the 0-dimensional space R^0 = {\vec{0}} consisting only of the zero vector, which would be I wasn't aware that the binops were separately implemented, I thought they were wrappers. In that case maybe a gemm binop in C is not the way to go. |
For
The problem is that there is no such thing as the empty matrix—dimensions matter! Users would be equally surprised if multiplying a m×n matrix by a n×p one did not give one of size m×p. I only see two ways: either empty matrices are considered a programming error—but that means more work to circumvent that limitation when one actually needs empty matrices (and I do not agree that 0 ∈ ℝ⁰ should be identified with 0 ∈ ℝᵈ for d > 0 (which would imply that |
Thanks for your take on this problem, Chris. I agree that zeroing out the result of multiplying two empty matrices with non-zero dimensions seems like the mathematically right thing to do. In that respect BLAS is also not quite consistent, e.g. The question really is whether we want to give users the freedom to hang themselves. It is probably true that most such occurrences in real code would constitute a bug. My only use case for I think for the while being just raising exceptions is the best solution. Users can always work around this by checking dimensions themselves. Though this is slightly less convenient, it also forces the user to be explicit about the assumption that empty matrices do not constitute an error. Should we ever decide to be more permissive, switching from exceptions to acceptance would not cause issues. The solution is also much easier to implement. Just let me know if you find any objections to this approach. |
I agree of course that Vec.create0 0 should not be equivalent to Vec.create0 n. This idea of identifying the zero elements was probably nonsense, and in any case is unnecessary. The meaningful point is this: Mat.empty is a (the) linear map from R^0 to R^0, that Mat.create 0 n is a map from R^n to R^0, and Mat.create n 0 is a map from R^0 to R^n whose entire image is 0 in R^n - this would require that so i still think that this would be a mathematically consistent story - but of course that does not mean it is the best way to handle empty matrices in lacaml. |
On 2017-01-17, Markus Mottl wrote:
I think for the while being just raising exceptions is the best
solution. Users can always work around this by checking dimensions
themselves. Though this is slightly less convenient, it also forces
the user to be explicit about the assumption that empty matrices do
not constitute an error. Should we ever decide to be more permissive,
switching from exceptions to acceptance would not cause issues. The
solution is also much easier to implement.
I agree that empty vectors & matrices are usually due to programming
bugs. I’d like to suggest:
- We may want to consult the list to have the opinions about the usage
of others (I guess it will likely comfort us in our opinion but maybe
better make sure).
- Mat.create and Vec.create should not allow to create matrices and
vectors with (at least one) null dimension. Only Mat.empty and
Vec.empty vcan by used. (Of course, one can always to it through
Bigarray but Lacaml should be consistent.)
- Add Mat.is_empty and Vec.is_empty checking that at least one dimension
is 0.
|
I'm currently adding checks for empty matrices, but only in places where the function would otherwise exit the program. That's an easy, incremental improvement that won't prevent other solutions in the future. I hope to push the changes tomorrow. |
On 2017-01-18, Markus Mottl wrote:
* There might be bizarre future cases where empty matrices make sense
so I wouldn't prohibit their creation. We cannot prohibit such a
creation anyway if it happens outside of Lacaml so we'd gain little.
We would gain an additional check consistent with our take on the
matter.
|
It won't prevent us from having to raise exceptions from BLAS/LAPACK functions to avoid exiting the program when a user passes empty matrices. I'll implement this inevitable last step. We can decide on any additional checks later. Note that |
On 2017-01-18, Markus Mottl wrote:
It won't prevent us from having to raise exceptions from BLAS/LAPACK
functions to avoid exiting the program when a user passes empty
matrices.
Sure. It was more in the spirit “if it has to fail, let it fail early”.
I'll implement this inevitable last step. We can decide on any additional checks later. Note that Mat.empty already exists anyway and is useful as a placeholder.
Exactly. Hence my suggestion not to allow empty dimensions for (Mat|Vec).create
|
The "empty" checks are in the distribution now. I'll close this issue for now. Should anybody absolutely need the mathematically saner but not quite BLAS-compatible semantics, they'd likely need to submit significant changes. Probably not worth the trouble. |
I just saw this new feature in ocaml 4.05 Bigarray: zero dimensions in bigarrays. |
I don't think this would affect Lacaml at this point, because zero-dimensional tensors (i.e. really inefficient but potentially useful representations for scalars) are not used anywhere. |
yes, after posting i realized that they mean rank 0 arrays, not dimension zero in a matrix. sorry. good that it's not a problem. |
as a corner case, i happened on
gemm Mat.empty Mat.empty
which i expected to yieldMat.empty
. however, instead this resulted in an exception from blas. just wanted to point this out in case it is not intentional. one could of course test explicitly for empty matrices. i guess it's a tradeoff between convenience and potentially some overhead ifMat.empty
were handled by all functions where it makes sense.The text was updated successfully, but these errors were encountered: