-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Org #86
Org #86
Conversation
… codebase. INCLUDING CommandDataset! Fixes to #42
…'s output size to the correct length. The trainers don't need this info (or can just read the length of the output in the case of creating the conf_mat). This will throw some errors if a Dataset returns a data point larger than the values read from degreadation_name (which should never happen). Fixes #81
…s and re-ordering existing). Related to #37.
@@ -91,9 +99,11 @@ def pre_process(df, sort=False): | |||
df : pd.DataFrame | |||
The postprocessed dataframe. | |||
""" | |||
df = df.loc[:, NOTE_DF_SORT_ORDER] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(RE: #37)
There is an argument for removing this line:
- Nothing would err with too many columns. Nor would any existing columns be removed. Rather, added notes would just have NaNs in those columns, which is fine.
- Some degradations (remove_note, shift_XXX, join_notes) would still work fine with too many columns.
- This would cause dfs with too few columns to work for remove_note (still fail on the others).
- However, this would cause the resulting dfs to have floats instead of ints if a new note is added (since NaN can't be an int).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why did we put it there in the first place? Is there somewhere that insists on a column order (presume so!).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This line also removes additional columns, which would break some degradations. The reordering is just a happy accident.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah yes, I see. I think in another module I wanted the dataframes to have a specific set of columns and in a specific order when they were first created, pre-degradation. I don't see a reason for this restriction in your pre_process function for degradations here. I think you're good to remove and see if it breaks any tests!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It will break this test I added: #86 (comment)
But no others. Although that's only because we never test with incorrect columns.
The point with having this line is for if people make their own dfs, but I think it's fine to assume they have a reasonable set, and weird things will happen if not (eg. Nan's and floats appear)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can't change this easily now from Switzerland
'onset': [0.5, 100.5, 200.5, 200.5], | ||
'pitch': [10, 20, 30.5, 40], | ||
'dur': [100, 100, 100.5, 100], | ||
'extra': [5, 5, 'apple', None] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also remove this line if you remove the previous line.
os.environ["PYTHONWARNINGS"] = "ignore" # Also affect subprocesses | ||
warnings.showwarning = print_warn_msg_only | ||
# TODO: This should ideally be 'once', but it doesn't work for some reason | ||
warnings.filterwarnings('ignore', message='.* exceeds given seq_len') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See #88
|
||
warnings.showwarning = print_warn_msg_only | ||
# TODO: This should ideally be 'once', but it doesn't work for some reason | ||
warnings.filterwarnings('ignore', message='.* exceeds given seq_len') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See #88
|
||
warnings.showwarning = print_warn_msg_only | ||
# TODO: This should ideally be 'once', but it doesn't work for some reason | ||
warnings.filterwarnings('ignore', message='.* exceeds given seq_len') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See #88
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Bon, I think i'd done this in another branch, but not pushed to main. Silly me! ugh, was trying to comment on specific commits...why this so difficult!
I think I just managed to cancel all my comments on files...great! Not my day! Anyway, I'm going to approve all this and test as I'm making ACME v1.0. I'll reply inline to your initial comment:
LGTM
throughout the code: when creating the pianoroll and command datasets (make sure this seems ok for command), and as defaults for arg parsing.
I like
Only thing I don't like is the breaking of the naming convention that only classes begin with an upper case letter. But bugger it. If I care enough, I'll either rename them, or make them classes with a call in future.
This is great. As I say in the issue - minimal printing is good
Much prefer this default
Have commented on all of these and will move about when I do a full sweep of all issues. |
Fixes a number of issues:
helpfulness = ErrorCorrection
).Additionally, this does some work on #37.
Please also check #37, #27, and #22. For these, I am happy to not fix them. If you agree, remove the milestone marker from them (and optionally also close the issues).