Should the log_loss metric really be named the mean_log_loss?

[Carl-McBride-Ellis]

Should the log_loss metric really be named the mean_log_loss?

[tanushpatel-git]

I think keeping the name log_loss is reasonable, even though the function returns the mean loss by default.
The current API already makes this distinction through the normalize parameter: when normalize=True, the function returns the mean loss per sample, whereas normalize=False returns the sum of the individual losses.
Renaming the function to mean_log_loss could make its default behavior more explicit, but it would also make the API less convenient when the sum is desired and could introduce backward-compatibility concerns.
Perhaps the most useful improvement would be to make the distinction between per-sample log loss, mean log loss, and summed log loss especially clear in the documentation, rather than changing the function's name.
I'm curious whether the main concern here is naming consistency with other metrics or making the default aggregation behavior more explicit.

[Carl-McBride-Ellis]

Dear @tanushpatel-git ,

main concern here: Indeed the reason for the thread was to highlight a naming (in)consistency since the (mean) log_loss is often used as a cost functional, thus to bring it in line with the mean_absolute_error and the mean_squared_error nomenclature. Suffice to say, at this stage of the game I do not expect my suggestion to be actionable, hence a post in the discussions rather than raising an issue.

Many thanks for your reply and all the best,
carl

[tanushpatel-git]

Hi Carl,
Thinking further about your point, I believe the distinction between the metric's name and its aggregation behavior is particularly interesting here.
For example, scikit-learn's mean_squared_error explicitly communicates that the result is averaged across samples, while log_loss uses a shorter name even though its default behavior also returns an average. This does create a naming inconsistency from an API-design perspective.
At the same time, since log_loss already supports both mean and summed loss through the normalize parameter, changing the function name alone wouldn't fully address the distinction between these two behaviors.
Perhaps one useful question is whether the current documentation makes the default reduction sufficiently clear, or whether a more explicit naming convention would improve consistency across the metrics API.
Thanks again for raising this point. It's a useful example of how small naming decisions can affect the clarity of a machine-learning library's API.