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

scan! and scan functions #14730

Closed
StefanKarpinski opened this issue Jan 19, 2016 · 12 comments
Closed

scan! and scan functions #14730

StefanKarpinski opened this issue Jan 19, 2016 · 12 comments
Assignees
Labels
help wanted Indicates that a maintainer wants help on an issue or pull request
Milestone

Comments

@StefanKarpinski
Copy link
Member

I'm a little incredulous that we don't have a scan function generalizing cumsum and cumprod for an arbitrary reducer. But it seems that we don't, nor as far as I can tell do we have an issue for it.

@StefanKarpinski StefanKarpinski added the help wanted Indicates that a maintainer wants help on an issue or pull request label Jan 19, 2016
@StefanKarpinski
Copy link
Member Author

Ah, yes. We should possibly steal all of those. Arguably it would be better to do these after Jeff's branch is merged since we can avoid the whole functor dance after that.

@lobingera
Copy link

btw: Is there a clear definition of 'We'?

For this here, and for other topics it's not clear, what should be in julia Base and what is expected to be in a package (e.g. Very early there was a list of matlab functions which have/haven't julia counterparts. and it looked, like this should be available in julia Base)
Package has the advantage that it's an independent development, while at the same time it has the disadvantage of an independent development.

@StefanKarpinski
Copy link
Member Author

"We" refers to the Julia project / community as a whole. So no? It's a judgement call what should be in Base versus in a package, but scan is a pretty basic piece of functionality for a numerical language.

@ViralBShah
Copy link
Member

Yeah scan is a no-brainer.

@timholy
Copy link
Member

timholy commented Jun 18, 2016

Hmm, in the giant cleanup that was #16260, I may have unknowingly fixed this. Anyone should feel free to rename/repackage these functions to their heart's content.

@StefanKarpinski
Copy link
Member Author

Hmm. Since these are already implemented, perhaps we should do the rename before 0.5.

@StefanKarpinski StefanKarpinski added this to the 0.5.0 milestone Jun 18, 2016
@rfourquet
Copy link
Member

+1 to rename them. I just needed scanl recently (and wasn't aware of this issue), but thought it was not trivial enough to implement, if the type of the output array has to be inferred somehow (like map does). IIUC, @timholy, cumop! is like scan! but there is no cumop/scan yet? Also a version accepting an intitial value would be needed, in the case where the binary operator has args of different types.

@tkelman
Copy link
Contributor

tkelman commented Jun 19, 2016

-1 to adding new things to the milestone. If someone wants to rename, document, and independently test these go ahead, but it's not at all worth delaying the release for.

@StefanKarpinski
Copy link
Member Author

If it doesn't get done, we can just remove the milestone. The tag is useful for remembering things to do.

@jw3126
Copy link
Contributor

jw3126 commented Oct 14, 2016

Let me grab this issue!

@kmsquire
Copy link
Member

Closed by #18931

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Indicates that a maintainer wants help on an issue or pull request
Projects
None yet
Development

No branches or pull requests

9 participants