Re: [eigen] matrix::linspace

[Ricard Marxer Piñón <email@xxxxxxxxxxxxxxxx>]

Thanks for this work, this will be really useful, at least for me for sure.
I haven't checked if this is done or not yet, but it would be really
nice to have a class that allows us to do:

VectorXf::LinSpace(0, 10, 100)

in the spirit of the other ones: Random, Zero, Constant and Ones.

Doest this make sense?

ricard

On Mon, Jan 25, 2010 at 6:31 PM, Hauke Heibel
<hauke.heibel@xxxxxxxxxxxxxx> wrote:
> Ok, I am done. I have the whole patch ready for review. Since I have
> no idea what else to do for reviewing larger commits, I am posting
> here.
>
> The main new functionality offered is
>
>  DenseBase::setLinSpace(Scalar l,Scalar h,int s)
>
> which computes for each vector index
>
>  a(i) = l + i*(h-l)/(s-1)
>
> Now to the changes this involves.
>
> a) I added a new packet op ei_plset(Scalar a). It creates packages [a,
> a+1, ..., a+packet_size]. The nice part as opposed to ei_pset(...) is
> that for all types (float, double, int) there is only a single
> argument and not a varying number of arguments. This also allows to
> offer a GenericPacketMath implementation where this operator acts as
> identity.
>
> b) I added new constraints for functors that are meant to be used with
> CwiseNullaryOp. They are now required to offer a vector indexing
> operator()(int). For minimal invasive modifications, I simply changed
> existing ones by defining operator()(int,int) as operator()(int,int =
> 0) - where it was appropriate. That was already partially done.
>
> c) As discussed, ei_linspace_op_impl has two specializations one for
> random access and one for sequential or linear access. The vectorized
> sequential versions are much faster than non-vectorized ones and the
> random access versions seem to perform equally fast and faster (at
> least not worse).
>
> d) I introduced a new proxy ojbect ei_unaligned_assign_impl. It
> performs a simple loop assignment when required and it does not
> inline. Preventing the inlining was crucial in order to allow MSVC to
> perform proper optimization of packet ops. Maybe this should be
> guarded by a pre-processor define and activated only for MSVC.
>
> If I am not wrong, this is all. Any comments, or am I good to synch?
>
> - Hauke
>



-- 
ricard
http://www.ricardmarxer.com
http://www.caligraft.com