feat: added normal plot for time series

[Gerhardsa0]

Closes #549

Summary of Changes

Add more plot for time series:

• TimeSeries.plot_lineplot
• TimeSeries.plot_scatterplot

[github-actions]

🦙 MegaLinter status: ✅ SUCCESS

Descriptor	Linter	Files	Fixed	Errors	Elapsed time
✅ PYTHON	black	3	0	0	0.83s
✅ PYTHON	mypy	3		0	1.84s
✅ PYTHON	ruff	3	0	0	0.16s
✅ REPOSITORY	git_diff	yes		no	0.25s

See detailed report in MegaLinter reports
Set VALIDATE_ALL_CODEBASE: true in mega-linter.yml to validate all sources, not only the diff

MegaLinter is graciously provided by

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 100.00%. Comparing base (3415045) to head (ba11d24).

Additional details and impacted files

@@            Coverage Diff            @@
##              main      #550   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           50        50           
  Lines         2866      2915   +49     
=========================================
+ Hits          2866      2915   +49     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[lars-reimann]

Wouldn't it also make sense to plot numeric feature columns against the time column? In that case, this function should get a parameter column_name to select the column to plot.

[Gerhardsa0]

Wouldn't it also make sense to plot numeric feature columns against the time column? In that case, this function should get a parameter column_name to select the column to plot.

Yes, it would give a user a more detailed view on, how the other data points are correlated to the target column. On the other hand, the plots can get messy, but only if a lot of columns are plotted. Also, it should be an optional argument, so the user can always easy plot the time series.

[lars-reimann]

On the other hand, the plots can get messy, but only if a lot of columns are plotted.

I was only thinking of plotting one feature column against the time column.

Yes, it would give a user a more detailed view on, how the other data points are correlated to the target column. Also, it should be an optional argument, so the user can always easy plot the time series.

Then let's add an optional column_name parameter. If it's not set, we plot the target column. If it is set, we plot the selected column. Validation that the column is numeric should happen in any case.

[Gerhardsa0]

Should a user choose between scatter and normal plot?

[lars-reimann]

Should a user choose between scatter and normal plot?

In the Table class we have plot_lineplot and plot_scatterplot. Both take x_column_name and a y_column_name as required parameters.

We could also have those two methods in TimeSeries, but make x_column_name and y_column_name optional parameters. The default x_column_name would be the name of the time column and the default y_column_name would be the name of the feature column.

[Gerhardsa0]

Should a user choose between scatter and normal plot?

In the Table class we have plot_lineplot and plot_scatterplot. Both take x_column_name and a y_column_name as required parameters.

We could also have those two methods in TimeSeries, but make x_column_name and y_column_name optional parameters. The default x_column_name would be the name of the time column and the default y_column_name would be the name of the feature column.

The X-Axis is usally the date in time series or the usual index column. Should I still add the x_column_name ? and should the time series take an optional parameter for a date column?

[lars-reimann]

The X-Axis is usally the date in time series or the usual index column. Should I still add the x_column_name ?

I'd say yes due to two reasons:

1. Symmetry with the Table class.
2. It's useful in order to see correlation between two feature columns.

and should the time series take an optional parameter for a date column?

Hmm, probably not. The time column should include dates (timestamps). Otherwise, we would also need to support separate columns for year/month/day, hour/minute/second/nanos or variations thereof.

[Gerhardsa0]

Should a user choose between scatter and normal plot?

In the Table class we have plot_lineplot and plot_scatterplot. Both take x_column_name and a y_column_name as required parameters.

We could also have those two methods in TimeSeries, but make x_column_name and y_column_name optional parameters. The default x_column_name would be the name of the time column and the default y_column_name would be the name of the feature column.

The default value of, y_column_name should be the index, so the user can simple plot the timeseries with a call like: TimeSeries.plot_time_series(). Or is this not wanted behavior?

[lars-reimann]

The default value of, y_column_name should be the index, so the user can simple plot the timeseries with a call like: TimeSeries.plot_time_series(). Or is this not wanted behavior?

Would the time column not make more sense as the default x _column_name? The default y _column_name should be the target.

[Gerhardsa0]

The default value of, y_column_name should be the index, so the user can simple plot the timeseries with a call like: TimeSeries.plot_time_series(). Or is this not wanted behavior?

Would the time column not make more sense as the default x _column_name? The default y _column_name should be the target.

Yes, I didn't notice.

[Gerhardsa0]

The default value of, y_column_name should be the index, so the user can simple plot the timeseries with a call like: TimeSeries.plot_time_series(). Or is this not wanted behavior?

Would the time column not make more sense as the default x _column_name? The default y _column_name should be the target.

I added this behavior, to the function, which throws up new questions.

The time column can be pretty useful for plotting, so the user could see dates in the plot. But we don't handle them as dates, only as a time dummy right now.

Should the time column only allow numerical values? As we don't want it to handle, “real” date-types.

[lars-reimann]

Should the time column only allow numerical values? As we don't want it to handle, “real” date-types.

Data types would be a useful addition eventually. Maybe create an issue for this if we don't have one already.

[lars-reimann]

From my point of view, this is ready to merge. Thank you!

[lars-reimann]

🎉 This PR is included in version 0.20.0 🎉

The release is available on:

• v0.20.0
• GitHub release

Your semantic-release bot 📦🚀