Back to the main page.
Bug 1592 - allow for a dimord that is different from the standard ones
| Status |
NEW |
| Reported |
2012-07-05 10:32:00 +0200 |
| Modified |
2012-07-05 10:32:35 +0200 |
| Product: |
FieldTrip |
| Component: |
core |
| Version: |
unspecified |
| Hardware: |
PC |
| Operating System: |
Mac OS |
| Importance: |
P3 normal |
| Assigned to: |
|
| URL: |
|
| Tags: |
|
| Depends on: |
|
| Blocks: |
|
| See also: |
|
Robert Oostenveld - 2012-07-05 10:32:35 +0200
On 29 Jun 2012, at 4:56, Arnaud Delorme wrote:
- restore the any order for datatype (and put a big warning if you prefer users to use a specific order). This is inconvenient to users to have to guess at the correct order (and the error you get when you put in another order is not informative). I was trying by the way rpt_chan (which are scalp topographies at a given frequency) and it does not work. I have to fake like I have a frequency dimension (which I set to 1).
comment from Robert
This indeed used to be (more) allowed in the past than it is now. The change is due to changes in the FT data handling (the old statistics_wrapper function dealt with this more lenient than the present code). We can consider to extend ft_datatype_xxx (with xxx for example timelock) with a "desired" dimord order.
E.g.
timelock = ...
timelock.dimord = 'time_chan'
where
ft_datatype_timelock(timelock)
would return the dimensions flipped.
The ft_datatype_xxx functions are always called at the beginning of each FT function, since ft_checkdata calls them.