Comments (8)
Iβd like to encourage this proposal.
Making N
a type parameter will not make code less efficient: whenever Taylor1
and TaylorN
have differing implementations, simply use dispatch so that the most efficient implementation is always used. As structs, their fields are the same, lending themselves readily to parameterisation.
Unifying Taylor1
and TaylorN
will simplify a lot of the code in functions.jl
especially, large parts of which are inside for T in (:Taylor1, :TaylorN) β¦ end
.
And of course, Taylor{N}
is more elegant from the userβs perspective, alluding to Array{T,N}
.
from taylorseries.jl.
The problem that TaylorN
with numvars=1
does not quite mimic Taylor1
behaviour, is related to the way that multivariable Taylor polynomials are constructed and handled. But the example you describe actually works; the subtlety is in the output of set_variables
, which is fine in general, but special in the one-variable case, since it returns a vector of one element (and then the error follows). But
julia> x = set_variables("x") # Returns a vector
1-element Array{TaylorSeries.TaylorN{Float64},1}:
1.0x + πͺ(βxββ·)
julia> x = set_variables("x")[1] # let x be the first component
1.0xβ + πͺ(βxββΆ)
julia> x*x
1.0xβΒ² + πͺ(βxββΆ)
from taylorseries.jl.
Let me now comment on the subtleties of handling a TaylorN
object of one variable.
I so think it has a performance cost, because instead of using directly the components of a vector, it has to look up in dictionaries what to use in (trivial) homogeneous polynomials in one variable; yet, I haven't tested this.
But a real subtlety/issue is:
julia> (taylor1_variable(6))^2/taylor1_variable(6) # this is OK
1.0β
t + πͺ(tβ·)
julia> x^2/x # x defined as above; should yield x
ERROR: AssertionError: b0 != zero(b0)
in / at /Users/benet/Fisica/6-IntervalArithmetics/TaylorSeries.jl/src/utils_TaylorN.jl:369
The problem is that I couldn't come with a way to recognize easily that the division of two TaylorN
polynomials can be factorized. I can't think (now) of another subtle case like this one.
from taylorseries.jl.
We could probably treat the case Taylor1
as a special case of TaylorN
with one variable, as you suggest. But, without thorough tests about the performance hit, I would proceed rather slowly on this.
from taylorseries.jl.
Yes we must obviously check the performance hit.
You are of course right that you have to take the first element of the list if there's only one variable, sorry.
A possibly simpler / better, but also inelegant, solution is
x, = set_variables("x")
A different solution would be to just have a function set_variable
for the single variable case.
The division problem occurs also in the following example with 2 variables that one would certainly like to work:
julia> x,y = set_variables("x y")
Warning: redefining constant _params_taylorN
2-element Array{TaylorSeries.TaylorN{Float64},1}:
1.0x + πͺ(βxββ·)
1.0y + πͺ(βxββ·)
julia> (x^2_y + x_y^2) / (x*y)
ERROR: AssertionError: b0 != zero(b0)
in / at /Users/dsanders/.julia/v0.4/TaylorSeries/src/utils_TaylorN.jl:369
In this case, the division is by a monomial, so I think it could be checked somehow explicitly if the divisor is a monomial, and then do the division if all of the terms of the Taylor series are divisible by the monomial? This does sound a bit complicated to implement though.
from taylorseries.jl.
I am aware that this kind of things do not work, the reason is the same. I think this is part of the complication that involves representing a polynomial in n variables as vectors of homogeneous polynomials. I was simply unable to solve this. Yet, representing them as a polynomial in one variable, whose coefficients are polynomials in N-1 variables does the trick; this is part of the nice things of #12
EDIT: see this
from taylorseries.jl.
Why not make N
a type parameter and then just have a Taylor{N, T}
type where N
is the number of variables? This way you can specialize on Taylor{1, T}
for single variable functions.
I guess this could introduce type instabilities?
from taylorseries.jl.
The short answer is efficiency; Taylor1
is much faster that TaylorN
s defined over one variable, as we have them now. It also allows to certain improvements because we are dealing with one variable.
More details now: Though Taylor1
and TaylorN
share lots of things, their implementation is a bit different. Taking the product as an example, the Taylor1
case is pretty straight forward; the case for TaylorN
is "more or less" the same, if you think that each coefficient of a Taylor1
polynomial is a HomogeneousPolynomial
for the multivariable case. Yet, in our current implementation, HomogenousPolynomial
s are vectors of coefficients, arranged in a specific way that depends on the number of variables. We need to access some tables, for example, to allow to map those locations to the proper monomials, for bookkeeping, and this takes time. There are other limitations related to TaylorN
; for example, t^2/t
has a well defined Taylor expansion around 0, but x^2/y
has no Taylor expansion defined around 0; in other words, it is trickier to factor in the multidimensional case.
Maybe by including the number of the variables as parameters in the struct, as you suggest, Taylor{1,T}
can be be made to work as the current Taylor1{T}
by dispatch. For me the question is whether we could still have things like Taylor1{TaylorN{T}}
, or Taylor{1, Taylor{N,T}}
.
from taylorseries.jl.
Related Issues (20)
- Should `AbstractSeries` be `<:Real` instead of `<:Number`? HOT 6
- !(iszero(constant_term(b))) HOT 2
- abs2 incorrectly defined for Taylor{Complex{T}} HOT 4
- `lu(A::AbstractMatrix{Taylor1{T}})` method not properly inferred in Julia v1.8 HOT 9
- Stange behaviour when Taylor1 pass to Taylor1 constructor. HOT 2
- Support for Implicitly defined functions HOT 2
- sqrt at zero HOT 2
- Matrix element type for `A*A'` HOT 2
- Taylor1 with empty vector HOT 1
- order of the remainder HOT 1
- Implementation for log1p? HOT 3
- Implement cospi and sinpi HOT 6
- `x^(3/4)` fails when x==0 but not when 0 \in x HOT 5
- Include offset in struct definition HOT 5
- Compatibility with Multi-Threading HOT 3
- Broaden the applicability of `NumberNotSeries`
- Address ordering for nested `Taylor1`s
- Add Aqua tests
- Can't figure out how to create multivariate approximation HOT 7
- Violation of the (informal) `Number` interface HOT 7
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. πππ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google β€οΈ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from taylorseries.jl.