Preliminary work on static analogs for Taylor1#241
Preliminary work on static analogs for Taylor1#241mewilhel wants to merge 23 commits intoJuliaDiff:masterfrom
Conversation
dpsanders
left a comment
dpsanders
left a comment
There was a problem hiding this comment.
This is a great start, thanks!
Haven't had a chance to look all the way through but I commented on a few things that I think can be simplified using broadcasting.
benchmark/benchmarks.jl
Outdated
| q = STaylor1(r) | ||
| q2 = STaylor1(r) | ||
| y = rand() | ||
| S["Taylor1{$i,Float64} + Float64"] = @benchmarkable f(+, $x, $y, $n) |
There was a problem hiding this comment.
You should be able to use metaprogramming to script these tests.
src/arithmetic.jl
Outdated
| for T in (:Taylor1, :HomogeneousPolynomial, :TaylorN) | ||
| @eval iszero(a::$T) = iszero(a.coeffs) | ||
| end | ||
| function iszero(a::STaylor1) |
There was a problem hiding this comment.
all(iszero, a.coeffs) perhaps?
src/arithmetic.jl
Outdated
| -(a::Taylor1{T}, b::TaylorN{S}) where {T<:NumberNotSeries,S<:NumberNotSeries} = | ||
| -(promote(a,b)...) | ||
|
|
||
| @inline +(a::STaylor1{N,T}, b::STaylor1{N,T}) where {N, T<:Number} = STaylor1(add_tuples(a.coeffs, b.coeffs)) |
There was a problem hiding this comment.
Can you just use STaylor1(a.coeffs .+ b.coeffs)?
src/arithmetic.jl
Outdated
|
|
||
|
|
||
| function *(a::STaylor1{N,T}, b::T) where {N, T<:Number} | ||
| STaylor1{N,T}(scale_tuple(a.coeffs, b)) |
There was a problem hiding this comment.
Again, should just be a.coeffs .* b
|
|
||
|
|
||
| #= | ||
| Tuple operations taken from ForwardDiff.jl |
There was a problem hiding this comment.
I think all of these can be replaced by simple broadcasts these days.
src/evaluate.jl
Outdated
| end | ||
| evaluate(a::Taylor1{T}) where {T<:Number} = a[0] | ||
|
|
||
| function evaluate(a::STaylor1{N,T}, dx::T) where {N, T<:Number} |
There was a problem hiding this comment.
Maybe some functions like this can be defined only once for both Taylor1 and STaylor1.
Is there an AbstractTaylor1 type?
There was a problem hiding this comment.
I've looked into this a little bit. I haven't added an AbstractTaylor1 type yet.
We could do this for the evaluate(a::Taylor1{T}) function (just have both functions call get_order) but I haven't been able to figure out a way to avoid this for most other functions.
|
Check here for an alternative approach to many of these functions: using the |
|
Sorry, this fell under the radar. I personally think that the separate Are you still working in this direction? |
|
@dpsanders No worries. I had to divert my attention elsewhere for a quite while. The separate package idea works for me. I'm currently throwing a separate package together and I should have the preliminary work done by the end of this week. |
|
@mewilhel I was meaning this package that I wrote quite a while ago that has a lot of overlapping functionality: |
|
@dpsanders Ah! Sorry, I haven't looked at this in a while. That sounds good too. I'll fork a copy of that repository and transfer some of the content there. |
|
@dpsanders I've created a pull request for StaticTaylorSeries.jl: dpsanders/StaticTaylorSeries.jl#2. |
3 participants
#240
STaylor1structure and constructors.STaylor1type:+,-.*,exp,zero,one,evaluate,==, functionality to iterate and get indices.I've added a small benchmarking library for individual operators. This was mostly to provide a means to confirm that none of the operators with
STaylor1objects are allocating.This doesn't include promotion for different types such as
+(STaylor{N,T}, S)or a number of other operators. I figured it was probably better to get some feedback before going too much further.