-
Notifications
You must be signed in to change notification settings - Fork 17
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
update normalization #32
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -59,13 +59,21 @@ Must be a list of *tensor specification keys*. | |
|
||
*tensor specification keys*: | ||
- `name` tensor name | ||
- `axes` string of axes identifiers, e.g. btczyx | ||
- `data_type` data type (e.g. float32) | ||
- `data_range` tuple of (minimum, maximum) | ||
- `axes` string of axes identifying characters from: btczyx | ||
- `shape` specification of tensor shape\ | ||
Either as *exact shape with same length as `axes`*\ | ||
or as {`min` *minimum shape with same length as `axes`*, `step` *minimum shape change with same length as `axes`*} | ||
|
||
- `preprocessing` optional description of how this input should be preprocessed | ||
- `name` name of preprocessing (currently only 'zero_mean_unit_variance' is supported) | ||
- `kwargs` key word arguments for `preprocessing`\ | ||
for 'zero_mean_unit_variance' these are: | ||
- `mode`: either 'fixed', 'per_dataset', or 'per_sample' | ||
- `axes`: subset of axes to normalize jointly, e.g. 'xy', batch ('b') is not a valid axis key here! | ||
- `mean`: mean if mode == fixed, e.g. (with channel dimension of length c=3, and all axes 'cxy') [1.1, 2.2, 3.3] | ||
- `std`: standard deviation if mode == fixed analogously to mean | ||
|
||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We like explicit normalization descriptions in this way, but would like to talk about supported normalization schemes rather sooner than later. Maybe one of the next meetings? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Let's put it on the agenda 👍 |
||
- `outputs` | ||
Describes the output tensors from this model. | ||
Must be a list of *tensor specification*. | ||
|
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.
Do we have a place to give detailed definition for the axes and the meaning? Are we allowed to give a custom letter to it?
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 think we should be as restrictive with these letters as possible to keep them meaningful/useful from a consumer software perspective, e.g restrict them to btczyx. We can have a (separate) discussion on the axes keys (use HW, instead of xy, etc...). I'd prefer to delay that for 0.3.1+, for now in a given input the
description
field could add specific meaning in the model context for humans? I feel anaxes_description
field would go a bit too far anyway, but again, let's leave that for future discussion if necessary.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 do agree that for now, it is too ambitious to get this kind of specifications. I think it was already discussed at some point but outputs might also be better described with rows and columns. While in NumPy arrays those could be understood as HW, displaying them as tables could need a different kind of description.