-
Notifications
You must be signed in to change notification settings - Fork 51
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
Reorganize files #87
Conversation
…s ... ... delete HomogeneousPolynomial(x), and adapt everything to this change.
`Taylor1` and `HomogeneousPolynomial` inner constructors use now `check_taylor1_order!()` and `check_taylorn_order!()` to modify the passed coefficients if needed for the construction.
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. |
There was a problem hiding this 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) |
There was a problem hiding this comment.
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
.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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
?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 ...
There was a problem hiding this comment.
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%.
There was a problem hiding this comment.
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) |
There was a problem hiding this comment.
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)
?
There was a problem hiding this comment.
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}}`.
There was a problem hiding this comment.
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.
I just responded to some of your comments. I will test a replacement involving 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)... |
Regarding this suggestion, tests are failing in several places. So I will stop here making additions... Sorry, once again. |
@dpsanders One commit more 😄 : separate tests in several files and use Base.Test... |
Indeed, (Things like |
There was a problem hiding this 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.
Ok. I'll merge this and address the |
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.