Description
Current implementation extends HasFeaturesCol. Personally I find it rather unfortunate. Up to this moment we used consistent conventions - if we mix-in HasFeaturesCol the featuresCol should be VectorUDT.
Using the same Param for an array<T> (and possibly for array<arrray<T>> once PrefixSpan is ported to ml) will be confusing for the users.
I would like to suggest adding new trait (let's say HasTransactionsCol) to clearly indicate that the input type differs for the other Estiamtors.
Attachments
Issue Links
- blocks
-
SPARK-19281 spark.ml Python API for FPGrowth
- Resolved
-
SPARK-19825 spark.ml R API for FPGrowth
- Resolved
- is related to
-
SPARK-14503 spark.ml Scala API for FPGrowth
- Resolved
-
SPARK-19825 spark.ml R API for FPGrowth
- Resolved
-
SPARK-14501 spark.ml parity for fpm - frequent items
- Resolved
- links to