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

More non-1 indexing fixes #19015

Merged
merged 3 commits into from
Oct 24, 2016
Merged

More non-1 indexing fixes #19015

merged 3 commits into from
Oct 24, 2016

Conversation

timholy
Copy link
Member

@timholy timholy commented Oct 18, 2016

Contains fixes in setindex!, reducedims functions, and some statistics functions.

Backporting guide: on 0.5, the added deprecations should be moved to reducedims.jl, and the depwarn lines deleted. (Can't introduce new deprecations in the middle of a release cycle.)

reduced_dims(::Tuple{}, region) = ()
function reduced_dims(dims::Dims, region)
Base.depwarn("`reduced_dims` is deprecated for Dims-tuples; pass `indices` instead", :reduced_dims)
map(r->last(r), reduced_dims(map(n->OneTo(n), dims), region))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

map(last, reduce_dims(map(OneTo, dims), region))? Shouldn't be necessary to construct anonymous functions in those places, I would think.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, @ararslan.

function reduced_dims0{N}(siz::NTuple{N,Int}, region)
rsiz = [siz...]
function reduced_dims0{N}(inds::Indices{N}, region)
rinds = [inds...]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would collect be any more efficient than splatting in this case?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since the length of inds is a type parameter, I would say splatting is fine: the compiler is going to specialize on that anyway.

Copy link
Member Author

@timholy timholy Oct 23, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It turns out that splatting is (barely) more efficient, at least for the couple of Ns I tried.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh interesting. Good to know!

@timholy timholy merged commit 5a66f24 into master Oct 24, 2016
@timholy timholy deleted the teh/stats_indices branch October 24, 2016 00:50
@tkelman
Copy link
Contributor

tkelman commented Oct 24, 2016

probably should have run nanosoldier here before merging

@timholy
Copy link
Member Author

timholy commented Oct 24, 2016

Hmm, you're right. I'll run it locally and see if I see anything.

@timholy
Copy link
Member Author

timholy commented Oct 25, 2016

No real regressions turned up (whew), but I noticed that we currently have disastrous performance on benchmarks of this function, as appearing in e.g. run(BaseBenchmarks.SUITE[["simd",("local_arrays","Int32",4096)]]). @code_warntype reveals that it's absolutely riddled with type-instability. EDIT: see #19096.

@KristofferC
Copy link
Member

Looks like the problem is with samerand but it is type unstable on 0.5 as well.

@timholy
Copy link
Member Author

timholy commented Oct 25, 2016

I can fix the type instability of samerand easily, but perhaps we want to leave it as-is as a test for #19096.

@KristofferC
Copy link
Member

Could fix it and add a test_broken to base perhaps.

@nalimilan
Copy link
Member

Doesn't seem to be backportable as-is. It touches a lot of code, deprecates several functions and restricts signatures...

@timholy
Copy link
Member Author

timholy commented Oct 25, 2016

See the "backporting guide" in the top post.

@nalimilan
Copy link
Member

Ah, sorry. Then better make a separate PR and remove the label from this one.

@timholy
Copy link
Member Author

timholy commented Oct 25, 2016

See #19100.

@tkelman
Copy link
Contributor

tkelman commented Oct 26, 2016

Are packages expected to need to implement trailingsize ? See the MethodError here http://pkg.julialang.org/logs/LinearLeastSquares_0.6.log, introduced by 360fd40

@timholy
Copy link
Member Author

timholy commented Oct 27, 2016

Not for AbstractArrays, but it looks like it must have been called with a non-AbstractArray that nevertheless implemented size. There's no real need for that method signature restriction (I put it in to resolve an ambiguity at one point in the evolution). Fix appended to #19103.

timholy added a commit that referenced this pull request Nov 1, 2016
tkelman added a commit that referenced this pull request Nov 4, 2016
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

Successfully merging this pull request may close these issues.

5 participants