solving system of Funs about approxfun.jl HOT 16 CLOSED

I am not really sure what spacecompatible means but should AnySpace be space-compatible with any other space? (related to #66)

julia>  ApproxFun.spacescompatible(UltrasphericalSpace{2}(Interval{Float64}(0.0,50.0)), ApproxFun.AnySpace())
false

I am tempted to try defining

spacescompatible(f,g::AnySpace)=true
spacescompatible(f::AnySpace,g)=true

but that, at the very least, breaks how spacecompatible works on lists of spaces, which is to make sure that each consecutive pair is compatible.

from approxfun.jl.

I think it should look like this:

d = Interval(0.,50.)
D = diff(d)
t = Fun(identity,d)

F = D^2 +.5D + 1
BC = [ldirichlet(d), lneumann(d)]
A = [BC,F]
BC1 = [1.0, 0.0]
BC2 = [2.0, 0.0]
b = [BC1 BC2]
xu = vec(A\b)

You could add forcing terms underneath the boundary conditions in b.

from approxfun.jl.

Thanks. I'm not sure I understand. That looks like it solves the undriven system for two initial conditions.

from approxfun.jl.

I don't exactly know what I am doing, but these changes goretkin@894ea09 make the the code in my initial post run, with seemingly correct results.

Not quite... It's not possible to do A*xu to check, but you can check

x = vec(xu)[1]
u = vec(xu)[2]
F*x-u

and the last fun should have been zero.

In this case there are multiple solutions to the problem I asked. I am not sure which one ApproxFun chooses

from approxfun.jl.

I'm sorry, I made some assumptions on the mathematical problem you are solving. The ApproxFun code for A was unclear to me. Is it a coupled system of two second order equations with forcing?

from approxfun.jl.

It is one second-order system with forcing. The forcing is an unknown function u
So we're looking for funs x and u such that
x'' + .5x' + x = u with boundary conditions x(0) = 1, x'(0) = 0 x(50) = 2

There should be many solutions.

from approxfun.jl.

Sorry, I think I was mistaken about ApproxFun returning the right thing. I edited the post above.

from approxfun.jl.

Just to give an example that does work

using ApproxFun

d = Interval(0.,50.)
D = diff(d)
t = Fun(identity,d)

F = D^2 +.5D + 1

#solves (D^2 + .5D + 1)x=0 and x+u=0
A= [    ldirichlet(d)   0;
        lneumann(d)     0;
        F               0;
        1               1; ] 

b = [1.0; 0.0; 0.0; 0.0; ]

xu = A\b 

x = vec(xu)[1]
u = vec(xu)[2]

x+u #is zero

from approxfun.jl.

When a linear equation has multiple solutions, approx fun should pick the "smoothest" one, in the sense of fastest decaying coefficients

from approxfun.jl.

I don't think your original equation is well-posed: given any solution pair (x,u) and function p that satisfies the boundary conditions (e.g., p(x)=x^2*(x-50), then (x+p,u+p''+.5p'+p) is also a solution to the original equation.

from approxfun.jl.

yes, you are correct, it's not well-posed. It's still a linear problem and you mentioned that approxfun would regularize by finding the smoothest (probably the smallest L2 norm on the coefficients?) function.

I hope to still return to this one day!

from approxfun.jl.

That's only when the operator is banded. If we interlace this operator, it would be "skew-banded" in the sense that it's banded around the entries that grow 2x for columns and 1x for rows

Sent from my iPad

On 22 Apr 2015, at 6:58 am, Gustavo Goretkin [email protected] wrote:

yes, you are correct, it's not well-posed. It's still a linear problem and you mentioned that approxfun would regularize by finding the smoothest (probably the smallest L2 norm on the coefficients?) function.

I hope to still return to this one day!

—
Reply to this email directly or view it on GitHub.

from approxfun.jl.

Ah, I can see why the interlaced operator is skew-banded. But I don't understand what that means for the type of the solution it returns. Shouldn't it be possible to produce a minimum-norm solution either way?

(In reality, for this kind of control problem, you'd have some additive cost on u to make the problem well-posed, but there's probably an additive cost that corresponds to the minimum-norm Chebyshev coefficients.)

from approxfun.jl.

It's because there is only currently adaptiveqr for "BandedOperator". Adding a SkewBandedOperator may be worthwhile.

Sent from my iPad

On 22 Apr 2015, at 7:14 am, Gustavo Goretkin [email protected] wrote:

Ah, I can see why the interlaced operator is skew-banded. But I don't understand what that means for the type of the solution it returns. Shouldn't it be possible to produce a minimum-norm solution either way?

(In reality, for this kind of control problem, you'd have some additive cost on u to make the problem well-posed, but there's probably an additive cost that corresponds to the minimum-norm Chebyshev coefficients.)

—
Reply to this email directly or view it on GitHub.

from approxfun.jl.

This is now implemented in development branch! (Ignore what I said about SkewBandedOperator, it recognizes that ConstantSpace should just append columns).

Though you need to put the constant terms in the first column:

d = Interval(0.,50.)
D = Derivative(d)
t = Fun(identity,d)

F = D^2 +.5D + 1
BC = [ldirichlet(d), lneumann(d)]
BC0 = [1.0, 0.0]
x = [BC, F][BC0, 0.0] #evolution of undriven equation x'' + .5x' + x = 0, works beautifully

A= [0 ldirichlet(d);
0 lneumann(d);
0 rdirichlet(d);
-1 F; ]

u,x=A[1.,0.,2.,0.]

norm(F*x-u) # is ~zero

from approxfun.jl.

Also ignore the comment about it not being well-posedness: it is when u is assumed to be constant.

from approxfun.jl.