Back to the main page.
Bug 1025 - inconsistent number of tapers
| Status | CLOSED FIXED |
| Reported | 2011-10-09 14:23:00 +0200 |
| Modified | 2011-11-11 11:19:42 +0100 |
| Product: | FieldTrip |
| Component: | specest |
| Version: | unspecified |
| Hardware: | Other |
| Operating System: | Linux |
| Importance: | P1 major |
| Assigned to: | Roemer van der Meij |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | |
| See also: |
Eric Maris - 2011-10-09 14:23:51 +0200
Run ft_freqanalysis with cfg and data in attached file and observe that the number of tapers in fourierspctrm is not equal to sum(tapsumcnt). Eric
Eric Maris - 2011-10-09 14:35:44 +0200
Dag Roemer, het bestand forbugreport.mat staat in mijn storage directory op Bilbo: \ericm\Rat_Receptive_Field_Mapping\output\2011-09-29_12-21-15_B3R4_KetMed_UL_4Pins_50HzPulseTrain groet, Eric
Roemer van der Meij - 2011-10-11 10:35:39 +0200
The size of the first dimension of freq.fourierspectrum is determined by taking the maximum number of tapers of all trials, and then filling it up with NaNs if the actual number of tapers is less. As far as I know, isn't this the way it always has been?
Roemer van der Meij - 2011-10-11 11:25:04 +0200
My previous comment was false, I was confused with variable number of tapers per frequency, more to come.
Roemer van der Meij - 2011-10-11 11:40:36 +0200
The bug occurs because memory allocation of the output array is determined on by the output of the first trial. If this one has more tapers than other trials, a larger output array of zeros is created, which should be avoided. It is a matter of either letting the output array grow till its end size, or try to allocate it using prior knowledge. This prior knowledge can only be attained if we implement some way of determining the number of tapers before actually doing the analysis on all trials. There are some ways to do to this, which are not terribly complex or time-consuming calculations, but until that is implemented I am letting the output array grow to its end size. (the downside of this is of course that a lack of memory available, and thus a resulting crash of matlab, will only be detected later in the analysis). JM, I cc'ed you on this cause this is quite a major bug (no idea why I didn't notice it before). I'm gonna try and think of a way of pre-computing the amount of tapers that will be required, to avoid unnecessary matlab crashes.
Roemer van der Meij - 2011-10-11 12:03:15 +0200
I added an exception to compute the number of tapers for mtmfft if taper = dpss, in all other cases it is as before. JM, could you check the line of code and my comment? (line 526, just before memory allocation)