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

Reorganize files #87

Merged
merged 10 commits into from
Mar 4, 2017
Merged

Reorganize files #87

merged 10 commits into from
Mar 4, 2017

Conversation

lbenet
Copy link
Member

@lbenet lbenet commented Mar 2, 2017

This reorganizes the contents differently. In particular, it allows to exploit metaprogramming tools, though I have only done that to to a limited extent. My idea is to reorganize things and provide a more consistent use of the internal methods.

@coveralls
Copy link

coveralls commented Mar 2, 2017

Coverage Status

Coverage increased (+0.4%) to 97.579% when pulling bdc41ed on reorg_files into 99a4d8e on master.

@PerezHz PerezHz mentioned this pull request Mar 3, 2017
@coveralls
Copy link

coveralls commented Mar 3, 2017

Coverage Status

Coverage increased (+0.4%) to 97.561% when pulling 782317a on reorg_files into 99a4d8e on master.

Luis Benet added 2 commits March 3, 2017 13:26
`Taylor1` and `HomogeneousPolynomial` inner constructors use
now `check_taylor1_order!()` and `check_taylorn_order!()` to modify
the passed coefficients if needed for the construction.
@dpsanders
Copy link
Contributor

I started commenting but think it will be easier for me to do a PR with some code simplification once this is merged.

I certainly agree with splitting up the huge files into pieces. Is this all that is done in the PR? It would be best to make a separate PR for any actual code changes.

Copy link
Contributor

@dpsanders dpsanders left a comment

Choose a reason for hiding this comment

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

I suggest you move these changed to a new PR.

@eval begin
=={T<:Number,S<:Number}(a::$T{T}, b::$T{S}) = ==(promote(a,b)...)
function =={T<:Number}(a::$T{T}, b::$T{T})
a, b = fixorder(a, b)
Copy link
Contributor

Choose a reason for hiding this comment

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

I think the objective should be to get rid of fixorder.

Copy link
Member Author

Choose a reason for hiding this comment

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

fixorder is needed because you may be comparing two Taylor1 (or TaylorN) polynomials with different order.

Copy link
Contributor

Choose a reason for hiding this comment

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

But you are creating a whole new Taylor1 object just to check equality, where you could just be checking that the coeffs that match are equal, and the extra coeffs in the longer vector are all 0.

Copy link
Member Author

Choose a reason for hiding this comment

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

You are right; I'll see if I can do something to deal only with the coefficients.

function =={T<:Number}(a::$T{T}, b::$T{T})
a, b = fixorder(a, b)
@simd for i in eachindex(a.coeffs)
@inbounds (a.coeffs[i] == b.coeffs[i]) || return false
Copy link
Contributor

Choose a reason for hiding this comment

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

Can't this whole loop be replaced by a.coeffs == b.coeffs?

Copy link
Member Author

Choose a reason for hiding this comment

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

Maybe, though I'm not sure if that would be faster or not.

Copy link
Contributor

Choose a reason for hiding this comment

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

I would guess it would be the same speed and much less writing. You are just writing out by hand testing equality of two vectors as far as I can tell.

If you don't use fixorder then testing equality would indeed be more complicated.


function iszero{T}(a::HomogeneousPolynomial{T})
@simd for i in eachindex(a.coeffs)
@inbounds (a.coeffs[i] == zero(T)) || return false
Copy link
Contributor

Choose a reason for hiding this comment

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

Replace loop by all(a.coeffs .== 0)

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 for the advice! I will test it now.

Copy link
Member Author

Choose a reason for hiding this comment

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

I just implemented this; tests are failing ...

Copy link
Member Author

Choose a reason for hiding this comment

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

The idea of using iszero was for optimizing in places like mul!; without such optimizations, we loose a bit of performance in perf/fateman.jl, around ~15%.

Copy link
Member Author

Choose a reason for hiding this comment

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

Sorry, I did something wrong regarding my check with your proposal; indeed tests pass. Regarding performance (perf/fateman.jl) it is slightly degraded (few percent), the number of allocations grows as well as the total memory used grows. So the current implementation, though not so nice, is a bit better.


## zero and one ##
zero{T<:Number}(a::Taylor1{T}) = Taylor1(zero(a.coeffs[1]), a.order)
one{T<:Number}(a::Taylor1{T}) = Taylor1(one(a.coeffs[1]), a.order)
Copy link
Contributor

Choose a reason for hiding this comment

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

Replace by Taylor1(one(T), a.order)?

Copy link
Member Author

Choose a reason for hiding this comment

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

This is necessary for mixed types, e.g. Taylor{TaylorN{T}}`.

Copy link
Contributor

@dpsanders dpsanders Mar 4, 2017

Choose a reason for hiding this comment

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

julia v0.5> x, y = set_variables("x y")
2-element Array{TaylorSeries.TaylorN{Float64},1}:
  1.0 x + 𝒪(‖x‖⁷)
  1.0 y + 𝒪(‖x‖⁷)

julia v0.5> t = Taylor1(x, 10)
  1.0 x + 𝒪(‖x‖⁷) + 𝒪(t¹¹)

julia v0.5> one(eltype(t))
 1.0 + 𝒪(‖x‖¹)

one(a.coeffs[1]) is the same as one(typeof(a.coeffs[1])) so my suggestion should always work.

@lbenet
Copy link
Member Author

lbenet commented Mar 3, 2017

I just responded to some of your comments. I will test a replacement involving all that you point out somewhere.

Sorry about this PR, which includes some other changes beside reorganizing the files. Some things are related to use some metaprogramming to avoid repeating the same lines of code; other changes include SIMD optimizations, or using the new syntax for inner constructors.

Let me check your suggestion, and then it is a good idea to merge (otherwise, I'll continue putting things in top of this)...

@lbenet
Copy link
Member Author

lbenet commented Mar 3, 2017

Regarding this suggestion, tests are failing in several places. So I will stop here making additions... Sorry, once again.

@coveralls
Copy link

coveralls commented Mar 3, 2017

Coverage Status

Coverage increased (+0.4%) to 97.579% when pulling ebeb588 on reorg_files into 99a4d8e on master.

@lbenet
Copy link
Member Author

lbenet commented Mar 3, 2017

@dpsanders One commit more 😄 : separate tests in several files and use Base.Test...

@coveralls
Copy link

coveralls commented Mar 4, 2017

Coverage Status

Coverage decreased (-97.1%) to 0.0% when pulling 36d50f1 on reorg_files into 99a4d8e on master.

@lbenet lbenet changed the title WIP: Reorganize files Reorganize files Mar 4, 2017
@coveralls
Copy link

coveralls commented Mar 4, 2017

Coverage Status

Coverage increased (+0.4%) to 97.579% when pulling 7bcfaef on reorg_files into 99a4d8e on master.

@coveralls
Copy link

coveralls commented Mar 4, 2017

Coverage Status

Coverage increased (+0.4%) to 97.579% when pulling cc0f5b2 on reorg_files into 99a4d8e on master.

@lbenet
Copy link
Member Author

lbenet commented Mar 4, 2017

Indeed, Number includes Real and Complex, but also Taylor1 and the other types defined in TaylorSeries. The reason to restrict it is to consider only those cases.
EDIT: For example, to treat addition of a Taylor1 plus a RealOrComplex.

(Things like Taylor1{Taylor1{T}} should still be possible, but I didn't check this. That actually allows to construct polynomials in many variables in a tree form, but it is something I haven't had time to explore more.)

Copy link
Contributor

@dpsanders dpsanders left a comment

Choose a reason for hiding this comment

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

Since this is mostly reorganization, and tests pass, I think this can be merged.

@lbenet
Copy link
Member Author

lbenet commented Mar 4, 2017

Ok. I'll merge this and address the fixorder and the issue about one in a different PR. Thanks for the review!

@lbenet lbenet merged commit 0a91842 into master Mar 4, 2017
@lbenet lbenet deleted the reorg_files branch March 4, 2017 18:01
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.

None yet

3 participants