david graff
david graff
FWIW I prefer `atom_encodings`. I prefer to avoid the term "fingerprint" as much as possible as it's not defined in the CS community, but the chemists occasionally like to use...
the last option isn't too bad IMO. As-is, we "define" (air-quotes) the following scalers: - for each input: `V`, `E`, `V_f`, `X_f` essentially a list of shape $(m, 4, \ast,...
what's this CLI flag intended to do?
what docstring?
FWIW the original goal was to make it such that _a `LossFunction` is a valid `Metric` but not all `Metric`s are valid `LossFunction`s_. I don't think I really achieved that,...
> I'd prefer to decouple Metric from LossFunction as they serve different purposes. I can see that we would like minimal duplication of code between these two functions. Flipping the...
> I originally wanted to say that not all loss functions are suitable as metrics (e.g., `MVELoss`, `EvidentialLoss`). Therefore, I oppose allowing users to "supply an arbitrary LossFunction as input...
I've been thinking about my original comment some more, mainly this point: > * It would be nice if users could simply supply an arbitrary `LossFunction` as input to the...
I've thought about this as well. The original design decision was that, for any tracking callback on the validation (e.g., checkpointing, early stopping, etc.), they _only_ ever use the `"val_loss"`...
You can already do this in v2 without any new features: ```python import chemprop import lightning as L from torch_scatter import scatter_sum trainer: L.Trainer = ... model: chemprop.MPNN = ......