SVC: Do not enforce that input data is of type np.float64

[jamesqo]

I am writing a text classification algorithm that uses an SVM based on tree kernels. I have the following code:

    for tree_kernel in 'ptk', 'sptk', 'csptk':
        kernel = TweetKernel(tree_kernel=tree_kernel)
        svc = SVC(kernel=kernel)
        svc.fit(X_train, y_train)

where X_train contains some text columns. Unfortunately this is erroring out at the following line:

scikit-learn/sklearn/svm/base.py

Line 147 in 49da6c8

X, y = check_X_y(X, y, dtype=np.float64, order='C', accept_sparse='csr')

Please fix so that if a callable is passed for the kernel argument, this restriction is not enforced.

[jamesqo]

This also happens when I try to call pairwise_kernels:

scikit-learn/sklearn/metrics/pairwise.py

Line 1104 in 0a85111

X, Y = check_pairwise_arrays(X, Y)

[jnothman]

I agree that it is absurd if we do not accommodate unstructured data for kernel methods. A fix is welcome. In the meantime, I hope you are able to use precomputed kernels

[jnothman]

We could just fix this specific case, or somehow create a common tests that if an estimator can fit with metric/affinity/kernel=some_function for numeric input that it will also allow text input and some basic text kernel (#common characters) or metric (? edit distance)

[FarahSaeed]

Can I take this if any one else is not working on it?

[qmick]

Since check _X_y will do conversion for some inputs, if we remove check _X_y for text input with callable kernel, I am a little worried about some existing codes may use callable kernels that rely on this conversion.

[jnothman]

Good point. Sigh. Though if we use dtype=None, then they'll still get a numeric array (except if the input is decimal strings, but that's a weird case), but not certainly float64.

[jnothman]

So I think if X has a numeric dtype, we can cast it to float64.

…

On 27 February 2018 at 16:17, Joel Nothman ***@***.***> wrote: Good point. Sigh. Though if we use dtype=None, then they'll still get a numeric array (except if the input is decimal strings, but that's a weird case), but not certainly float64.

[qmick]

Yes, that is it. But for the decimal strings case, It's unlikely used by many users and not in the documents. Not sure we should ignore this case (just leave all text input unchanged) or do something else.

[jnothman]

I'm happy to ignore the decimal numbers case. This is a bigger issue.