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

Should AbstractSeries be <:Real instead of <:Number? #288

Closed
jonniedie opened this issue Nov 9, 2021 · 6 comments
Closed

Should AbstractSeries be <:Real instead of <:Number? #288

jonniedie opened this issue Nov 9, 2021 · 6 comments

Comments

@jonniedie
Copy link

I would like to do some calculations involving complex numbers with TaylorModel1 (from TaylorModels.jl) real and imaginary components. As far as I can tell, the only thing preventing this is that Complex requires the component types to be <:Real, but TaylorModel1 <: AbstractSeries <: Number. Is there any reason AbstractSeries is <:Number instead of <:Real? Or rather, is there any time an AbstractSeries wouldn't be <:Real?

@lbenet
Copy link
Member

lbenet commented Nov 9, 2021

Thanks for opening this issue.

The reason we have <:Number is because Taylor series are naturally defined over the complexes, where the radius of convergence or analytic functions are properly defined; if you like, this is mathematical convenience. Once said this, there are cases where to have it <:Real seems convenient.

Regarding Taylor models, your point is well taken a probably they should be <:Real. Taylor models are defined for one (real) variable as a (real) Taylor expansion around x0 in a domain D, plus a remainder, which is an interval that rigorously bounds the true (mathematical) function in D. I haven't thought about the extension to complexes, but I guess it would need to have a "complex remainder", i.e. some sort of (two dimensional) interval box. Have you tried to use TaylorModelN with two variables for your application?

@jonniedie
Copy link
Author

Ah, that makes sense. I probably should have opened this over at TaylorModels.

As for my use case, I have a function that takes one real input (frequency) and returns two real outputs (phase and gain of the frequency response of a given linear system). The need for a Complex{<:TaylorModel1} is just to perform intermediate calculations. I could probably make my own version of Complex with only the arithmetic I need defined (should just be +, -, *, /, ^, abs, real, and imag), I was just hoping to avoid that.

@lbenet
Copy link
Member

lbenet commented Nov 12, 2021

Thanks for the explanation!

Do the independent variable in your (complex) expansion depends on the same real parameter? Perhaps combining two TaylorModel1s avoids redefining a bunch of functions...

@jonniedie
Copy link
Author

To be honest, I'm still trying to learn how Taylor models fit in with interval methods, so I'm not 100% sure what I need yet. To give you a little more detail on what I'm trying to do:

I have a rational polynomial function G(s) = n(s) / d(s) where n(s) and d(s) are polynomial functions of s. The coefficients of these polynomials have uncertain parameters, which are represented by Intervals. For a given (real) value ω, I would like to evaluate the response G(ω*im) and get the argument and magnitude of the resulting complex number.

When I tried evaluating this directly using Intervals, the resulting bounds were too wide. @mforets recommended I give Taylor models a try, which is when I noticed Complex{<:TaylorModel}s wouldn't work because Complex requires <:Real parameters.

@jonniedie
Copy link
Author

So I suppose we would have multiple parameters; one for each uncertain coefficient of n(s) and d(s).

@lbenet
Copy link
Member

lbenet commented Nov 15, 2021

Thanks for the detailed explanation @jonniedie. Let me propose to close this issue (feel free to do it), and since this discussion belongs to TaylorModels, continue it there.

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

No branches or pull requests

2 participants