Unique identifier for each available feature in a Sample

[xroynard]

Base standardization

• We should standardize the way we call a these objects in Samples, among:

  • feature
  • variable
  • quantity
    Let’s call it feature for now

• We should simultaneously standardize the way we call these object’s type, among:

  • type
  • kind
  • sort
  • species
  • genre.
    Let’s call it type for now

Further standardization

• Then, we will be able to standardize the way we uniquely identify such an object in a Sample, to ease implementations of any function/method in PLAID, for example:
  • for scalars: scalar::<scalar_name>
  • for time_series: time_series::<time_series_name>
  • for fields, depending if default base and/or default zone are non-ambiguous:
    • field::<field_name>, field::/<field_name> or field:://<field_name>
    • field::<zone_name>/<field_name> or field::/<zone_name>/<field_name>
    • field::<base_name>/<zone_name>/<field_name>
    • field::<base_name>//<field_name>
  • same for mesh nodes coordinates ?
  • same for mesh elements ?
• Would it be better in the reverse order: field::<field_name>/<zone_name>/<base_name>.

The first part (scalar, time_series or field) is then called feature_type (according to Base Standardization)

And second part after ::, something like feature_name (according to Base Standardization). feature_names are not unique among features of a Sample as a scalar, an time_series and a field could have the same.

• We should then simultaneously standardize the way we call the full name (comprising first part, :: and second part), for example something like feature_A with A among (non-exhaustive):
  • identifier
  • key
  • reference

Will be usefull for

• Pipelines
• Dataset.get_tabular_from_keys
• Statistics
• Base/Zone/Name and defaults
• any method that needs to work seamlessly on different kind of features

Needs

• Saving a Sample with names containing / fails #82 to be solved by forbidding / in feature_names

May interfere with

• time_series reorganization
• scalars generalization
• API retrocompatibility
• Disk format retrocompatibility

What should be done after standardization is complete

• add this standardization to the documentation
• replace any incoherent reference to such ideas in class/method/function names

[xroynard]

standardization effort @casenave

[casenave]

Very nice proposition, thank you. I like feature and type. Then scalar::<scalar_name>, time_series::<time_series_name> and field::<base_name>/<zone_name>/<field_name>. Hence feature_type::feature_name. And I like feature_identifier.

Sample.get_feature(feature_identifier) would be a nice generic function to access the features. Then, a make_column_selector (https://github.com/scikit-learn/scikit-learn/blob/da08f3d99/sklearn/compose/_column_transformer.py#L1505) dedicated to plaid samples would make possible the use of sklearn ColumnTransformer and powerful pipelines.

[casenave]

I proposed a first implementation in #110
I implemented sample.get_feature_from_string_identifier with a string feature_identifier, but upon reflection, this requires to specify all the previous details when specifying a given detail: for instance in field::test_node_field_1/Base_2_2/Zone/Vertex/0: one must specify Base_2_2/Zone/Vertex/ if he wants to specify the time value 0.
For this reason, I also implemented sample.get_feature_from_identifier, which takes a dict as argument, and relies on the default parameter section mechanism of sample, meaning that any combination of optional parameters can be provided.
I added extensive unit tests in test_sample.py

[xroynard]

Maybe the order should be : <field_name>/<location>/<zone_name>/<base_name>/<timestamp> to respect the CGNS hierarchy

[casenave]

It's already merged :-D But it easy to change this convention, if we decide to :-)

[casenave]

I'm also thinking of implementing such function in the dataset class, but not limited to the particular case of tabular retrievals.
I would prevent dataset.get_feature_from_identifier to return a list[FeatureType], to let the features having potentially different sizes. For fields and nodes, this would return features at a given time value (the default value if not specified), and let the user handle the time variations. This means that the fields and nodes features are only defined at a particular time value.

[casenave]

done in #110