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

Refactoring reducedim and related functions #7106

Merged
merged 4 commits into from
Jun 5, 2014
Merged

Refactoring reducedim and related functions #7106

merged 4 commits into from
Jun 5, 2014

Conversation

lindahua
Copy link
Contributor

@lindahua lindahua commented Jun 3, 2014

This PR is along the same line as #7061, which improves the generality and coherence of the codes.

The core implementation is done in mapreducedim!, and everything else is just a light-weight wrapper of this function.

end
end # let mapreducedim_fcache
Copy link
Member

Choose a reason for hiding this comment

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

I may be missing something, but why not use @ngenerate here?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The original code also has a cache explicitly instantiated. In this part, I basically followed what was done before. But yes, @ngenerate may be used here. I will look at this later.

Copy link
Member

Choose a reason for hiding this comment

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

The original code generated an F function for every function argument, not just for every number of dimensions, which is why @ngenerate was not sufficient. It looks like you no longer do that, so @ngenerate should suffice. OTOH this could cause performance regressions for code that was relying on the old reducedim behavior.

@lindahua
Copy link
Contributor Author

lindahua commented Jun 4, 2014

ngenerate is now used for mapreducedim!.

end
end
eval(ngenerate(:N, :(typeof(R)),
:(_mapreducedim!{T,N}(f, op, R::AbstractArray, A::AbstractArray{T,N})), mapreducedim_body))
Copy link
Member

Choose a reason for hiding this comment

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

I think this can be simplified to use the standard syntax for @ngenerate instead of eval(ngenerate(.... See the Cartesian docs and multidimensional.jl.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, it is doable. Just that personally, I feel it is more organized (and easier to debug) to have a separated body-generating function (especially when the body generating code is substantial).

Copy link
Member

Choose a reason for hiding this comment

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

macroexpand makes it less important to have a separate body-generating function. The main reason for the pain of eval(ngenerate(... is when your dict lookup sometimes has to be more complicated than just the dimensionality.

@lindahua
Copy link
Contributor Author

lindahua commented Jun 4, 2014

Done, the macro @ngenerate is being used now.

reducedim_init{T}(f, op::MaxFun, A::AbstractArray{T}, region) = reducedim_initarray0(A, region, typemin(evaluate(f, zero(T))))
reducedim_init{T}(f, op::MinFun, A::AbstractArray{T}, region) = reducedim_initarray0(A, region, typemax(evaluate(f, zero(T))))
reducedim_init{T}(f::Union(AbsFun,Abs2Fun), op::MaxFun, A::AbstractArray{T}, region) =
reducedim_initarray(A, region, zero(evaluate(f, zero(T))))
Copy link
Member

Choose a reason for hiding this comment

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

Should this be reducedim_initarray0?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

When a is empty, zero is a reasonable result for maxabs(a).

lindahua added a commit that referenced this pull request Jun 5, 2014
Refactoring reducedim and related functions
@lindahua lindahua merged commit 74a41d2 into master Jun 5, 2014
@JeffBezanson JeffBezanson deleted the dh/reducedim3 branch October 25, 2014 17:26
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.

3 participants