Skip to content
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

Open
daniel-vainsencher opened this issue Aug 6, 2015 · 4 comments
Open

We shouldn't implicitly insert default values? #22

daniel-vainsencher opened this issue Aug 6, 2015 · 4 comments

Comments

@daniel-vainsencher
Copy link
Contributor

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:

  • It masks bugs; I would prefer a panic whenever we run out of values early.
  • It requires the Zero trait even when really should be just copying stuff around.
  • Relatively speaking, lots of code is spent on it.

I don't mind opening a PR if we agree on the change.

@shailesh1729
Copy link
Contributor

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 from_iter which forces that at least M x N values must be there. Another from_iter_with_zero_padding which allows zeros to be filled in the remaining cells. The first one won't require Zero trait while the second one will require. The function name would clarify the intent. In both cases we should continue to allow a source iterator which may have more values than the matrix can consume.

@daniel-vainsencher
Copy link
Contributor Author

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.

@shailesh1729
Copy link
Contributor

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.

@daniel-vainsencher
Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants