|Re: [eigen] matrix::linspace|
[ Thread Index |
| More lists.tuxfamily.org/eigen Archives
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] matrix::linspace
- From: Benoit Jacob <jacob.benoit.1@xxxxxxxxx>
- Date: Tue, 26 Jan 2010 08:02:27 -0500
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=nsaZKXQ/10meSE1/VCIZUNu46YyLERYBGI1pUN02m7o=; b=helZxHtRVZe/XDBk/mnoXHaA5P9RLifHR0KZ6XUtcOZjqhLHaPp1o/ddpcugdpb6/y Y2nqFyNrAJqRpRSi9mhval2dftSbejjmkwPOW/C28kT+pSFmYSfuzsb+1I8PoRPSGdiN 8rFYOpiOk3Q9RiY5YdF3ILm9HNp1sIckL87L8=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=kH2aDE1Bday4GexQSrL2tINbAIwqc8cuLsysBjKFc6oAiHtbdbQ9BIs388YNlzFIco /8JIMZ7s47Uo9DkRo+b8UWMjrgE2bTICM1xCpzMNhVAUvZs93jDbAljKsusK5pZRPNdv Pyw/0dG56TzZCAZV8S+mA+wg9SF0qf05pcjoA=
2010/1/25 Hauke Heibel <hauke.heibel@xxxxxxxxxxxxxx>:
> 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
> The main new functionality offered is
> DenseBase::setLinSpace(Scalar l,Scalar h,int s)
as discussed on IRC, LinSpace ---> LinSpaced.
> 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
> 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).
I understand that the API for the sequential case is setLinSpaced.
What is the API for the random case? Are you going to provide a static
LinSpaced() ? Meanwhile, it's untested?
> 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.
Good stuff, it even decrements the number of for loops in Eigen.
> If I am not wrong, this is all. Any comments, or am I good to synch?
You can push, I'm just curious about the random access version,
especially API wise and testing wise.