Preliminary work on static analogs for Taylor1 #241
Conversation
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
| @@ -31,11 +33,23 @@ end | |||
| 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
| @@ -205,6 +219,48 @@ end | |||
| -(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
| @@ -30,18 +31,41 @@ function evaluate(a::Taylor1{T}, dx::S) where {T<:Number, S<:Number} | |||
| 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. |
#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.