-
Notifications
You must be signed in to change notification settings - Fork 29
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
We shouldn't implicitly insert default values? #22
Comments
zero padding is a typical use case in signal processing. e.g. in order to do N point FFT, you first extend the vector to nearest power of 2 (padding with zero) and then process. May be we can have two versions. a |
Well, allowing larger iterators still masks some errors. I would prefer to make the default method (or version with the shortest name...) as safe as possible, but reasonable people may disagree. |
Here is an alternative. Rather than spending too much gray cells on what is the right API for matrix, work more on developing the libraries on top of it (linear algebra, statistics, signal processing etc.) Come back later to the matrix API and do a cleanup based on actual use cases. |
I am happily contributing code, but mostly as I need it myself. I spent all of today writing numerical code against scirust, and raised issues mostly based on that. This one specifically because I was missing a Zero trait in some context, hence the latest PR. |
Matrix::from_iter* etc all fill out the rest of the matrix with zeros if they run out of values early. I have several problems with this:
I don't mind opening a PR if we agree on the change.
The text was updated successfully, but these errors were encountered: