Back to the main page.
Bug 1750 - use consistent option names for segmentationstyle, inside and cmbrepresentation
| Status | NEW |
| Reported | 2012-09-28 11:21:00 +0200 |
| Modified | 2012-10-01 12:03:59 +0200 |
| Product: | FieldTrip |
| Component: | core |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | Mac OS |
| Importance: | P5 minor |
| Assigned to: | |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | |
| See also: |
Robert Oostenveld - 2012-09-28 11:21:12 +0200
They all refer to a "style" of representation of one of the data fields. It would be better to have them named consistently.
Robert Oostenveld - 2012-09-29 07:42:27 +0200
On 28 Sep 2012, at 18:05, Johanna Zumer wrote: Is there a way to test , for a structure which is true for ft_datatype(data,'segmentation') , as to what it's segmentationstyle is? ft_datatype_segmentation(data,'segmetnationstyle', 'XXX') converts the data to that style but doesn't give out a binary answer if the orignal data was indeed that style or not. ---------- Hi Johanna, (Let me post it here for future reference, rather than in an email.) There is not. The general idea is that you tell ft_checkdata what you want w.r.t. the data representation and that you don't have to make your code dependent on the representation. The output from a function should also be in the preferred (internal) format of that function. However, an exception is e.g. ft_megplanar, which does convert input timelock data to raw, and at the end back to timelock. Search for "istlck" in that function and have a look. The data "type" is quite well designed, but the "style" (which we should perhaps treat as subtype) is not so well developed in the code and my thinking about it. We could perhaps consider another naming scheme such as bool = ft_datatype(data, 'segmentation.probabilistic') or bool = ft_datatype(data, 'probabilistic_segmentation') and similarly bool = ft_datatype(freq, 'freq.full'); for doing the check and data = ft_checkdata(data, 'datatype', 'segmentation.probabilistic') for doing a check+conversion if needed. But what if there are (or will be) mutiple style attributes? And what if those depend on each other, or if they are orthogonal? ...