Add basic vector transforms equivalent to existing scalar ones, along with vector transform composition

[dom-linkevicius]

Addresses #141, but not only for TVShift but others too, with the ultimate goal of adding vector transform composition.

Initial PR is to kick off discussions about API, as working off of something should be easier. Also, initial PR does not contain vector transform compositions yet.

[dom-linkevicius]

I think we should spend a bit of time discussing the API first.
Do you want to shift vectors by vectors (in which case we can just make it accept vector arguments), or vectors by scalars?
What would you combine it with?

@tpapp thoughts on the current code in vector.jl?

[devmotion]

I wonder if it would be better to define an alternative to ArrayTransformation that transforms each element with a possibly different transformation.

[devmotion]

This transform already exists in a more general form: as(Real, dims...)

If there are performance improvements possible I think it would be better to implement them this existing array transformation.

[devmotion]

Same here, a more general version of this transform already exists.

[devmotion]

Same here, also this already exists.

[devmotion]

One could exploit muladd when not decomposing shifting and scaling (which in my experience are usually both needed) in separate steps.

[devmotion]

This must also take into account the element type of the shift. Moreover, currently the compiler won't specialize on T.

Suggested change

	inverse_eltype(t::VecTVShift, T::Type) = eltype(T)
	inverse_eltype(t::VecTVShift, ::Type{<:AbstractVector{T}}) where {T<:Real} = promote_type(eltype(t.shift), T)

[devmotion]

The type should be a type parameter T<:AbstractVector{<:Real}.

[devmotion]

This should just be

Suggested change

	function VecTVShift(val::Real, dim::Integer)
	return VecTVShift(repeat([val;], dim))
	end
	function VecTVShift(val::Real, dim::Integer)
	return VecTVShift(fill(val, dim))
	end

Ideally, though, I think users might want to use FillArrays here. To avoid additional dependencies and keep it more flexible, I'd remove this definition:

Suggested change

	function VecTVShift(val::Real, dim::Integer)
	return VecTVShift(repeat([val;], dim))
	end

[dom-linkevicius]

This transform already exists in a more general form: as(Real, dims...)
If there are performance improvements possible I think it would be better to implement them this existing array transformation.

@devmotion yes, I'm aware some of those already existed, just that in terms of API, I thought that if I want to have a concise/easier way to write compositions of vector transformations then something like

t =  VecTVExp(n) ∘ VecTVShift(x) ∘ VecTVScale(y)

would be preferable to

t =  as(Real, dims...) ∘ VecTVShift(x) ∘ VecTVScale(y)

Haven't tested for performance differences, will check.

I wonder if it would be better to define an alternative to ArrayTransformation that transforms each element with a possibly different transformation.

That would be a more general approach, yes, but unsure how error prone composition of such transformation would be. If I have AlternativeArrayTransformation ∘ AlternativeArrayTransformation, I may have very little guarantees of what each of them are and whether they should compose. I don't think this is the case for VectorTransformations. But I'm up to giving it a shot, if you think that's a non-concern and at the end I'd still be able to get compositions of vector transformations.