Support for pack of structure/tuple (was Full complex types integration) about boost.simd HOT 6 CLOSED

As a matter of fact, perhaps it will be better to change the function return type policy:

sqrt(x) will for instance return a complex type by default, even if x is scalar floating, but
sqrt(x,real) will return nan if x is not real and greater or equal to zero.

This imply to change the behaviour of all "inverse" functions that are not defined on the full real
range:

log, inverse trigonometry functions inverse hyperbolic functions except asinh.
also the function having no meaning for complex (non real) entries can have a Nan or assert behaviour
on complex for which is_real is false.

I think that will make easier the real/complex mix. Is there any objection or consequences I
have missed ?

from boost.simd.

I am against this for three reasons:

• monumental breaking change in existing code
• unexpected behavior w/r to regular C++ functions
• performances penalty in clear violation of C++ philosophy of 'dont pay for what you dont use'

from boost.simd.

• monumental breaking change in existing code

  Not so clear as boost simd does not exists yet and the change will be only ...,real_)
  inside the library

• unexpected behavior w/r to regular C++ functions

No : regular will be ,real

• performances penalty in clear violation of C++ philosophy of 'dont
  pay for what you dont use'

no penalty with ,real. It is the same philosophy for instance as sqrt
and realsqrt in matlab
More using unduly sqrt or other is immediately seen at compile time if
the result is put in a non complex container

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

from boost.simd.

boost.SIMD exists, people are usign the NT2 internal version already. Not sure they will liek the change. Again, this change is detrimental to the code alreay written, make surprising interface and bring nothing to the table.

complex computations are not the norm and has not to be. people expect sqrt(3.f) to return a real not a complex. Documentign that sqrt(-1.) is NaN is enough. Tags are here for specify behavior of the function not tied to types. return a complex is to be determined by type, so no tags are required.

I suggest we stick to the current model. If you want i as a result of sqrt(-1), use the complex version taking -1 as a complex. No other libraries does it the other way around, nor does the standard nor does C. I woudl prefer having sqrt(-1, complex_) to get rid of dry types than the other way around.

from boost.simd.

Ok I agree

from boost.simd.

The global issue is to support struct and tuple inside pack while maintaining integrity and option to interleave/deinterleave on the fly. Complex is just the diretc use case.

Issue renamed accordingly

from boost.simd.