version 2.2.0 gives pgml.predict is not unique about postgresml

[montanalow]

This is due to ambiguity with the single tuple version of predict added for preprocessing when there is a single raw feature argument. This used to work a bit by accident, as the smallint[] and broader feature float4[] were both flattened into a single array. I'll look at what we can do to disambiguate, it maybe as easy as adding explicit predict functions for each type of numeric feature array to provide exact matches and disambiguate, but I'd rather see if we can do something smarter, to disambiguate based on the preprocessing directives, in addition to the types.

[dusanmarjanovic]

any progress on this? :) it makes using preprocessing feature rather unusable

[montanalow]

I'm worried about this ambiguity in the APIs, since you mention it makes preprocessing unusable. To clarify, predict is overloaded, in non equivalent ways for preprocessing.

1. Passing an ARRAY (now of any of the common numeric types, not just FLOAT4), will bypass preprocessing and operate directly on the raw features in the array.
2. Passing a Postgres row type which is differentiated by () instead of ARRAY[].

The syntax distinction is subtle enough that people may overlook it, and call the wrong version. I'm curious if this was biting you, or just the areas in the notebooks that were not explicitly cast to FLOAT4?

[dusanmarjanovic]

Thanks for the update, not just the stuff from the notebooks, thats what I tried in the end to make sure I was not doing something wrong in my own project. I try to run some predictions on my own data but it needs to be preprocessed because of the NULLs and categorical variables. I will try now with the adjusted api.rs hope it works.