Skip to content

fix: correct swapped val_acc / val_f1 labels in the training log - #14

Open
JOhnsonKC201 wants to merge 1 commit into
mims-harvard:mainfrom
JOhnsonKC201:fix/swapped-val-acc-f1-log-labels
Open

JOhnsonKC201 wants to merge 1 commit into
mims-harvard:mainfrom
JOhnsonKC201:fix/swapped-val-acc-f1-log-labels

Conversation

@JOhnsonKC201

Copy link
Copy Markdown

calc_metrics returns (roc, ap, acc, f1), so in train, val_acc is accuracy and val_f1 is F1. The print just above and the wandb.log just below both pair them correctly, but the tab-separated log line has them transposed:

"val_f1 = {:.5f}".format(val_acc),
"val_acc = {:.5f}".format(val_f1)])

So every epoch written to <save_prefix>_gnn_train.log reports accuracy under val_f1 and F1 under val_acc. Anyone reading that log to compare epochs gets the two metrics mislabeled.

This swaps them back so the log agrees with the print and W&B output. Nothing else changes — training and best-model selection already read the values directly, not the log string.

calc_metrics returns (roc, ap, acc, f1), so val_acc holds accuracy and
val_f1 holds F1 (see the print on the line above and the W&B log below,
both of which pair them correctly). The tab-separated log line formatted
'val_f1' with val_acc and 'val_acc' with val_f1, so every epoch written
to <save_prefix>_gnn_train.log reports the two metrics under each
other's names.

Swap them back so the log matches the print/W&B ordering. No effect on
training or model selection, which already use the values directly.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant