Re: [Cppqed-support] Position correlation

[Andras V. <and...@ui...>]

Hi Raimar,

thanks for your reply. So you are saying blitzplusplus::vfmsi::fullRange
> could
> always only give me the two-particle (left or right) state vector from my
> DensityOperatorLow, this is why I have to use
> blitzplusplus::basi::fullRange.
>

That's right.

On a related note, would it be possible that, given a
> blitzplusplus::basi::Iterator with two or more retained index positions, to
> slice it even further? This would somehow be related to the concept that a
> slice of a multi-array is again a multi-array and can be sliced.
>

Yes, a sliced multi-array (e.g. a dereferenced slice iterator) can be
further sliced (can be used to initialize a slice iterator). This actually
does occur in ModeCorrelations::average, which in general gets a sliced
LazyDensityOperator, and slices it further when calculating the averages
for the individual Modes relying on mode::AveragedQuadratures (cf.
ModeCorrelations.cc:38-39).
You should take ModeCorrelations as an example, because also with the
particle correlations, some functionalities could (perhaps) be delegated to
particle::Averaged.

So in principle the slicing would occur in
> the fft function, not in the average function anymore. How would such a fft
> function with specialized implementation determine the type of the passed
> LazyDensityOperator, by dynamic_cast?
>

Yes, I think this is a paradigmatic example of dynamic_cast. The function
should have roughly this signature:

template<int RANK, int IDX>
const LazyDensityOperator<RANK> ffTransformLazyDensityOperator(const
LazyDensityOperator<RANK>&,
fft::Direction, mpl::int_<IDX>);

IDX is the index position on which the transformation should occur. And in
the density-operator case, the transformation occurs on the index position
RANK+IDX as well, only with opposit
Copying is of course still necessary, because we do not want to touch the
original one (in fact, we cannot). But in case of a state vector, only this
needs to be copied.

Wouldn't boost::mpl::range_c<int,0,1>, boost::mpl::range_c<int,1,2> etc
> work,
> although of course a bit awkward?
>

They should indeed work, but it's an overkill :) .

Best regards,
András