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
In the referenced snippet, MaskedMetric's update function assumes the time dimension is the second.
However, this leads to adding an unnecessary dummy batch dimension when we represent a batch of graphs as a single big graph.
I suggest two possible solutions to avoid this:
Add a t_dim parameter and use x.select(t_dim, self.at) instead of x[:, self.at].
Add a pattern string and use it to identify the time dimension.
In both cases this can either be a class attribute or a method parameter, it depends on preferring to have it set once or allowing it to be changed each time the metric is updated.
The first solution is the easiest to implement, however the second one may make further dimension semantics dependent aggregations easier to implement down the road.
If this is deemed useful I can implement this behavior with an agreed solution.
The text was updated successfully, but these errors were encountered:
Hi Luca, sorry for the late reply! Your suggestion seems useful and nice, I would opt for the first solution you proposed. Also, I think it is better to set the dim attribute just once at instantiation, at the moment I don't see any advantage in having it as a method parameter. Feel free to propose a PR!
tsl/tsl/metrics/torch/metric_base.py
Lines 112 to 122 in 154cccf
In the referenced snippet, MaskedMetric's update function assumes the time dimension is the second.
However, this leads to adding an unnecessary dummy batch dimension when we represent a batch of graphs as a single big graph.
I suggest two possible solutions to avoid this:
t_dim
parameter and usex.select(t_dim, self.at)
instead ofx[:, self.at]
.In both cases this can either be a class attribute or a method parameter, it depends on preferring to have it set once or allowing it to be changed each time the metric is updated.
The first solution is the easiest to implement, however the second one may make further dimension semantics dependent aggregations easier to implement down the road.
If this is deemed useful I can implement this behavior with an agreed solution.
The text was updated successfully, but these errors were encountered: