override diff for vector of funs about approxfun.jl HOT 8 CLOSED

I'm debating whether diff should be deprecated in favour of differentiate. The vector fun is an example where there is ambiguity. I've also moved away from functions as vectors, using * instead of .*

cumsum might also be renamed in this case, but I'm currently using integrate to mean indefinite integral without normalising at a point

Sent from my iPhone

On 18 Dec 2014, at 1:13 am, Gustavo Goretkin [email protected] wrote:

for consideration,

diff of a vector-domain function should probably raise a warning or be redefined to be
as approximately
diff{T<:VectorDomainSpace} (x::Array{Fun{T,...}}) = diff(devec(x)

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

from approxfun.jl.

I strongly agree with * instead of .* for the point-wise product of two functions. .* could be used to mean the point-wise point-wise product of two compatible vector funs.

I think it would be okay to keep diff, sum, cumsum for scalar-valued funs as aliases for better names like differentiate, integrate and prefix_integrate... or something, but it makes sense to avoid defining them for vector-valued funs and perhaps raise a warning when they are used on an Array of Funs.

from approxfun.jl.

We could use the behaviour of diff/sum/cumsum on matrices as argument that they should also be differentiate, integrate and prefix_integrate when applied to vector funs. (Though the analogy is a bit weak since its unclear whether vector fun is thought of as ∞ x n matrix (so row vector of functions) or n x ∞ matrix (so column vector of functions). I think I use both viewpoints.

I suppose we should answer the following: if f is an n-degree vector fun, D=Derivative() and A=rand(n,n), which conventions do we want to use:

D*f     and     f*A.’
f*D.’     and         A*f
D*f     and     A*f

At the moment I use #3, which lets you do say matrix exp as D-A

On 18 Dec 2014, at 5:57 pm, Gustavo Goretkin [email protected] wrote:

I strongly agree with * instead of .* for the point-wise product of two functions. .* could be used to mean the point-wise point-wise product of two compatible vector funs.

I think it would be okay to keep diff, sum, cumsum for scalar-valued funs as aliases for better names like differentiate, integrate and prefix_integrate... or something, but it makes sense to avoid defining them for vector-valued funs and perhaps raise a warning when they are used on an Array of Funs.

—
Reply to this email directly or view it on GitHub #83 (comment).

from approxfun.jl.

to confirm, an "n-degree vector fun" means a vector fun with n elements (not represented by a degree-n polynomial)

I think ideally a "vector" fun could be any array shape. that means, evaluate(f,0) could return any Array type, just as you could have a a::Array{Fun,3} where a[i,j,k] is a fun. Maybe that's over-kill, though.

Also note that sum(rand(10,20)) produces a 1x20 array in matlab and a scalar in julia (to do the same in julia, you do sum(rand(10,20),1)

from approxfun.jl.

I'm going to replace VectorDomainSpace with Array..Space{1} where the .. is up for suggestions

I was thinking VectorizedSpace had a nice ring to it, but ArrayizedSpace..not so much

Sent from my iPhone

On 18 Dec 2014, at 5:26 pm, Gustavo Goretkin [email protected] wrote:

to confirm, an "n-degree vector fun" means a vector fun with n elements (not represented by a degree-n polynomial)

I think ideally a "vector" fun could be any array shape. that means, evaluate(f,0) could return any Array type, just as you could have a a::Array{Fun,3} where a[i,j,k] is a fun. Maybe that's over-kill, though.

Also note that sum(rand(10,20)) produces a 1x20 array in matlab and a scalar in julia (to do the same in julia, you do sum(rand(10,20),1)

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

from approxfun.jl.

What does the {1} mean?

I have a hard time wrapping my head around what "Space" means. in the \Spaces directory, there are different spaces corresponding to different evaluation points and different basis functions. And \Spaces\Modifiers has ways of composing or modifying spaces into new types of spaces. These all seem to be of type DomainSpace. In all these cases, the Domain is some interval on R or maybe some region in C, right? What is FunctionSpace and RangeSpace? (lots of questions, sorry!)

For Array..Space, some options that come to mind are ArraySpace, ArrayConcatSpace ArrayValuedSpace, ArrayStructureSpace, ArrayComposeSpace

from approxfun.jl.

I was thinking that we have something like ArraySpace{S<:FunctionSpace,n} that mimics Array{S<:Number,n}.

A DomainSpace is a FunctionSpace that lives on a domain. Example FunctionSpaces that aren’t DomainSpace’s are AnySpace, NoSpace, and VectorSpace (which represents constant vectors). Though maybe this is overkill and leads to awkward typing (for example, ArraySpace{AnySpace,n} should work.). So I could be in favour of getting rid of DomainSpace. Especially since I think domain(::FunctionSpace) might already default to returning AnySpace().

The reason I used VectorDomainSpace instead of VectorSpace was since I wanted to a space to represent finite-dimensional vectors. But maybe ArraySpace{ConstantSpace,1} is a fine since this is a rare situation.

On 19 Dec 2014, at 12:01 am, Gustavo Goretkin [email protected] wrote:

What does the {1} mean?

I have a hard time wrapping my head around what "Space" means. in the \Spaces directory, there are different spaces corresponding to different evaluation points and different basis functions. And \Spaces\Modifiers has ways of composing or modifying spaces into new types of spaces. These all seem to be of type DomainSpace. In all these cases, the Domain is some interval on R or maybe some region in C, right? What is FunctionSpace and RangeSpace? (lots of questions, sorry!)

For Array..Space, some options that come to mind are ArraySpace, ArrayConcatSpace ArrayValuedSpace, ArrayStructureSpace, ArrayComposeSpace

—
Reply to this email directly or view it on GitHub #83 (comment).

from approxfun.jl.

I've made the following changes which I think take care of this issue:

1. Added ArraySpace
2. Removed all mention of the diff() shorthand in the Readme in favour of differentiate/Derivative
3. Base.diff(f::Fun{ArraySpace}) now does demat(diff(mat(f)) while differentiate does entrywise derivative

I think since Base.diff changes the dimension, if a user is expecting it to differentiate it will be clear that its not doing the right thing. Also, Base.diff is now only "unofficially" supported as a short hand for differentiate, so a new user can't have expectations on its behaviour.

from approxfun.jl.