I agree with Gaël on this. If you want to support complex values just
copy the estimators / functions you want and maintain them in a
separate package. +1 to error when complex are passed.
___
scikit-learn mailing list
scikit-learn@python.org
On Fri, Aug 11, 2017 at 12:37:12PM -0400, Andreas Mueller wrote:
> I opened https://github.com/scikit-learn/scikit-learn/issues/9528
> I suggest to first error everywhere and then fix those for which it seems
> easy and worth it, as Joel said, probably mostly in decomposition.
> Though adding
I opened https://github.com/scikit-learn/scikit-learn/issues/9528
I suggest to first error everywhere and then fix those for which it seems
easy and worth it, as Joel said, probably mostly in decomposition.
Though adding support even in a few places seems like dangerous feature
creep.
On
Although the first priority should be correctness (in implementation
and documentation) and it makes sense to explicitly test for inputs
for which code will give the wrong answer, it would be great if we
could support complex data types, especially where it is very little
extra work.
Raphael
On
Should we be more explicitly forbidding complex data in most estimators,
and perhaps allow it in a few where it is tested (particularly
decomposition)?
On 11 August 2017 at 01:08, André Melo
wrote:
> Actually, it makes more sense to change
>
> B =
I have no idea whether the randomized SVD method is supposed to work for
complex data or not (from a mathematical point of view). I think that all
scikit-learn estimators assume real data (or integer data for class labels)
and our input validation utilities will cast numeric values to float64 by