You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The number of components of a GazeDataFrame is currently only inferred using the columns pixel, position, velocity, acceleration.
If a user would want to use a non-standard column only, like pixel_velocity, the inference wouldn't work.
But if the user would have specified just one of the mentioned columns, everything would work out.
Description of a solution
We could try to solve this in the current frame of using polars.list, but to me it seems most reasonable to implement #453
The n_components argument is really just needed for internal usage as a workaround as during the time of RD struct didn't seem that well developed.
After implementing #453 we would need n_components anymore for internal usage. We could then decide how to deal with it.
As a workaround, users can still write something like
gaze.n_components=2
Also, n_components is mostly used for transformation functions.
Additionally for non-standard columns a user could still explicitly pass n_components:
Description of the problem
The number of components of a GazeDataFrame is currently only inferred using the columns
pixel
,position
,velocity
,acceleration
.If a user would want to use a non-standard column only, like
pixel_velocity
, the inference wouldn't work.But if the user would have specified just one of the mentioned columns, everything would work out.
Description of a solution
We could try to solve this in the current frame of using
polars.list
, but to me it seems most reasonable to implement #453The
n_components
argument is really just needed for internal usage as a workaround as during the time of RD struct didn't seem that well developed.After implementing #453 we would need n_components anymore for internal usage. We could then decide how to deal with it.
As a workaround, users can still write something like
Also,
n_components
is mostly used for transformation functions.Additionally for non-standard columns a user could still explicitly pass n_components:
So the workflow is not completely broken and a comfortable workaround exists.
Context
Originally requested by @prassepaul in #521 (comment)
The text was updated successfully, but these errors were encountered: