Back to the main page.

Bug 2357 - split ft_convert_units in a determine and convert function

Reported 2013-11-01 10:39:00 +0100
Modified 2015-02-11 10:43:03 +0100
Product: FieldTrip
Component: core
Version: unspecified
Hardware: PC
Operating System: Mac OS
Importance: P3 normal
Assigned to: Robert Oostenveld
Depends on:
See also:

Robert Oostenveld - 2013-11-01 10:39:10 +0100

This is something we considered in the past, but that somehow never happened. For coordsys we have a determine and a convert function. Right now I think it would better to mirror this for unit as well. A second aspect to be fixed is that the function is called ft_convert_units with an "s" at the end, whereas the field in the geometrical object is called unit without an "s" at the end. So I think it should become ft_determine_unit and ft_convert_unit. @Thijs: agreed or are there aspects I am overlooking right now?

Robert Oostenveld - 2013-11-01 10:41:50 +0100

hmm, I just now notice that there is a ft_estimate_units function involved as well. mac001> find . -name ft_convert_units.m ./fileio/private/ft_convert_units.m ./forward/ft_convert_units.m ./plotting/private/ft_convert_units.m mac001> find . -name ft_estimate_units.m ./fileio/private/ft_estimate_units.m ./forward/ft_estimate_units.m ./plotting/private/ft_estimate_units.m With grep it seems that ft_estimate_units is only being called by ft_convert_units and that therefore the estimate_units can become a subfunction instead.

Jan-Mathijs Schoffelen - 2013-11-01 10:43:51 +0100

(In reply to comment #1) It's probably not as simple as renaming ft_estimate_units into ft_determine_unit? (In reply to comment #0) I agree. Does the function also deal with units that are not length/distance related?