search

G-Node / nix

Neuroscience information exchange format
https://readthedocs.org/projects/nixio/
Other
67 stars 36 forks source link

Handling units #693

Closed jgrewe closed 7 years ago

jgrewe commented 7 years ago

In NIX we do only accept SI units or compound units consisting of only SI where ever a unit can be set. This is very strict and could be relaxed (user request) a bit.

We need to ensure scalability for the data access functions at Tag and MultiTag so setting non-scalable units in these entities as well as the dimension descriptors will make it impossible to return the correct slices. I see two options if we want to relax unit handling:

  1. Allow non-SI in everywhere: In this case we need to check at the critical places (e.g. dimensions, tag positions/extents) and maybe warn if this will lead to problems. Question here, how should the data access methods respond to this? We could skip scaling and just assume 1:1 matching (maybe even check on equality and go on and throw an exception if no match). We could throw an exception when using these functions (quite rude)

  2. Allow non-SI in metadata and DataArray values. Caveat: Things will break in AliasRange where the DataArray unit is used for calculating the index during data access.

If we don't want to go that way we still may decide to switch to a more potent library for unit conversions (boost::units)...

achilleas-k commented 7 years ago

Thanks for making an issue out of this and opening the discussion. We discussed this a few times and I think you summarised everything we mentioned nicely, so we all know the options.

I wonder if it would be reasonable to give users a choice when creating a file of turning off SI unit support. This could be a top level file attribute that when set disables unit scaling but allows anything to be entered into unit properties.

This is just a new idea that I haven't considered much, so feel free to dismiss it if it sounds terrible.

jgrewe commented 7 years ago

closed via pr #704