Feature: Add Symmetric Mean Absolute Percentage Error (sMAPE) to Regression Metrics

[oglego]

Currently, metrics_regression.rs provides Mean Absolute Percentage Error (MAPE), but lacks its symmetric counterpart, sMAPE.

sMAPE is a useful regression metric, particularly in time-series forecasting, because it addresses the asymmetry of standard MAPE (which penalizes over-forecasting more heavily than under-forecasting) and handles values near zero more gracefully by summing the absolute values of both the actual and predicted targets in the denominator.

It would be beneficial to add sMAPE to the Regression Metrics.

[Whatsonyourmind]

Good feature request. A few implementation notes on sMAPE specifically:

Formula choice matters: There are two common definitions, and they give different results:

1. Original (Armstrong 1985): `sMAPE = (2/n) * sum(|y - yhat| / (|y| + |yhat|))`, range [0, 2]
2. Adjusted (Makridakis 1993): `sMAPE = (1/n) * sum(|y - yhat| / (|y| + |yhat|) * 2) * 100`, range [0, 200%]

Most modern forecasting competitions (M3, M4, M5) use the adjusted version. I would suggest matching what `sklearn.metrics` and `statsforecast` use for interoperability.

Edge cases to handle in Rust:

• `y_i = yhat_i = 0`: Both numerator and denominator are zero. Convention is to return 0 for this term (perfect prediction). Use `if num == 0.0 && den == 0.0 { 0.0 } else { num / den }`.
• `y_i = -yhat_i`: Denominator `|y| + |yhat|` is nonzero but the error is maximum. This is correct behavior.
• All zeros: Return 0.0 (trivially perfect).

```rust
pub fn symmetric_mape(y: &[f64], yhat: &[f64]) -> f64 {
let n = y.len() as f64;
let sum: f64 = y.iter().zip(yhat.iter())
.map(|(&yi, &yhi)| {
let num = (yi - yhi).abs();
let den = yi.abs() + yhi.abs();
if den == 0.0 { 0.0 } else { num / den }
})
.sum();
(2.0 / n) * sum
}
```

One consideration: sMAPE is still criticized for being asymmetric when predictions are biased (Chen & Yang, 2004). You might also consider adding MASE (Mean Absolute Scaled Error) which is the M4/M5 competition standard. Would that be in scope?

[oglego]

Thank you for the feedback and for clarifying the different definitions of sMAPE!

I think that matching the Adjusted (Makridakis 1993) version is a good call. It doesn't look like sklearn.metrics actually has an implementation of sMAPE, but it does look like the statsforecast version uses the Adjusted (Makridakis 1993) one.

I can update on the PR so that the implementation returns the percentage-scaled value (0 to 200) to match the standard forecasting convention.

I can also adopt the suggested if den == 0.0 { 0.0 } else { num / den } logic - I think that will make this more robust than what I currently have.

For the suggestion on implementing MASE, I can explore that further and if I can get it implemented I'll submit a separate Feature Request and PR on it!

Thanks again for the feedback!

[Whatsonyourmind]

@oglego Glad it helped! The Makridakis 1993 version is the right call — it's what statsforecast, Darts, and most forecasting competitions (M4, M5) use.

One edge case to handle in the implementation: when both y and yhat are zero, the denominator |y| + |yhat| is zero. The standard convention is to treat that term as 0 contribution to the sum (perfect prediction), not NaN. statsforecast handles this with a conditional check before the division.

Also worth noting: sMAPE is symmetric in name but not fully symmetric in behavior — sMAPE(y, yhat) == sMAPE(yhat, y) holds, but the metric still penalizes under-prediction and over-prediction differently when the magnitudes differ. This is a known quirk that the Hyndman & Koehler (2006) paper discusses as motivation for MASE as an alternative.