New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[ENH] implement efficient _evaluate_by_index for forecast performance metrics #4304 Implementation for GeometricMeanAbsoluteError #6244
base: main
Are you sure you want to change the base?
Conversation
…etricMeanAbsoluteError
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
I think there has been a mistake, you copied the mean absolute error (MAE)?
This metric is supposed to be GMAE, geometric mean absolute error.
Btw, it would also be nice if you provide the formula in the docstring, like in MeanAbsoluteError
, that helps avoiding math errors and make the review easier.
Thank You @fkiraly , I will check it once. |
…MeanAbsoluteError with documentation as well
@fkiraly I have added the changes that I missed earlier. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, this looks correct now!
Before we merge, can we discuss numerical stability?
If we implement the formula directly, we use np.prod
which can lead to a numerical explosion.
Would it be better to use the exp/log representation instead?
That is, using that geometric averages are arithmetic averages of logarithms, then exp?
For discussion - we could test with a vector of length 100, with value 1000. My conjecture is that the current formula produces nans, while exp/log will be fine.
@fkiraly Thank you, I will give it a check and will let you know. |
@fkiraly I checked your conjecture and yepp you are right in that. and implementing the given functions to check it, I found this as my result. # Function to compute GMAE using direct product approach And :- def gmae_log_exp(y_true, y_pred, epsilon=1e-10): And so this was the result I got :-
|
hm, something is not right here - the result should be 1000 |
Okay I will check it once. |
I see - I meant when the errors are a vector of 1000. To create that situation, you could make |
@fkiraly I gave the input as :- test_length = 100 and I got this as the result :-
|
hm, is direct more accurate? Surprising. How about you make the errors larger, e.g., 1e-10 and see what happens? |
@fkiraly So I used the input values given and here is the output for the same :-
|
yes, seems more stable for extreme values. Shall we go with the log/exp approach then? |
Yes I have written the code for that as well. I will just add it. |
…MAE. This modification ensures that the errors are strictly positive before taking their logarithm, improving the numerical stability of the calculation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! This is great!
We're not quite done yet, I think we should clarify what evaluate
and evaluate_by_index
are doing. evaluate
computes the overall metric (the geometric mean), while evaluate_by_index
produces the contribution per time index, to the error metric at the end. If the overall metric is not a mean, it's supposed to be producing jackknife pseudo-values.
So, your implementation of _evaluate_by_index
seems like it should be in _evaluate
, and you still need to work out a fast algorithm for the pseudo-values.
To help you, I've done the same for MSE/RMSE, have a look at the RMSE part (if squared=True
), you can take this PR as a template: #6248
Thank you @fkiraly, I will work on the same. |
You have to work it out, but it's almost the same as in #6248:
|
@fkiraly yes I used the similar method in my code, I will share it as soon as possible. |
… efficient _evaluate_by_index for GMAE. Additional methods added :- _compute_pseudo_values: Computes the jackknife pseudo-values for the Geometric Mean Absolute Error (GMAE) metric, estimating the influence of each observation on the overall metric. _evaluate: Evaluates the GMAE metric on given inputs, providing the overall metric value. This method is the core logic called from the evaluate method and computes the arithmetic mean over time points by default.
@fkiraly , Does the code need any modification now?? |
Can you kindly make sure it passes the code formatting test? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your contribution!
This does not look correct though:
- the pseudo-values should be returned in
_evaluate_by_index
, not_evaluate
_evaluate_by_index
should return apandas
object with the same index asy_true
@fkiraly thanks for this. I will give it a check and then give the correct code. |
Reference Issues/PRs
Towards #4304
What does this implement/fix? Explain your changes.
Implementation of efficient
_evaluate_by_index
performance metrics by taking reference from #4302Does your contribution introduce a new dependency? If yes, which one?
No
What should a reviewer concentrate their feedback on?
Did you add any tests for the change?
No
Any other comments?
PR checklist
For all contributions
How to: add yourself to the all-contributors file in the
sktime
root directory (not theCONTRIBUTORS.md
). Common badges:code
- fixing a bug, or adding code logic.doc
- writing or improving documentation or docstrings.bug
- reporting or diagnosing a bug (get this pluscode
if you also fixed the bug in the PR).maintenance
- CI, test framework, release.See here for full badge reference
maintainers
tag - do this if you want to become the owner or maintainer of an estimator you added.See here for further details on the algorithm maintainer role.
For new estimators
docs/source/api_reference/taskname.rst
, follow the pattern.Examples
section.python_dependencies
tag and ensureddependency isolation, see the estimator dependencies guide.