This WIKI page may also help, though the line numbers refer to SPM5
code, and may differ for SPM8 code:
http://imaging.mrc-cbu.cam.ac.uk/imaging/ParametricModulations
> Dear Ryan,
>
> as far as I remember, we came across that issue a while ago. Which
> version of spm_orth.m are you using? Both updated SPM5 and SPM8 should
> compare the norm of each vector to exp(-32) to assess if they are 0 or not.
>
> Best regards,
> Guillaume.
>
>
> Ryan Haynes wrote:
>
>> Thanks for your response, Jan. I am aware that a parametric modulator that does not change will not explain additional variance in the data. For some of my subjects this parametric value changes and for some it does not. I could modify my scripts to omit the non-changing modulator, but technically SPM should be capable of tossing out this modulator automatically without crashing which is what the original code in spm_orth is intended to do by using the any() function. spm_orth should not work successfully for some vectors and fail on others. But, in the meantime I'll use your solution to work around the problem.
>>
>> Thanks,
>> Ryan
>>
>>
>> --- On Wed, 5/13/09, Jan Gläscher <[log in to unmask]> wrote:
>>
>>
>>> From: Jan Gläscher <[log in to unmask]>
>>> Subject: Re: [SPM] Possible bug in spm_orth
>>> To: "Ryan Haynes" <[log in to unmask]>
>>> Cc: [log in to unmask]
>>> Date: Wednesday, May 13, 2009, 2:08 PM
>>> Hi Ryan,
>>>
>>> I came across a similar problem before and admittedly
>>> didn't spend as much
>>> time as you on figuring out a solution for spm_orth,
>>> because in the end it
>>> doesn't make sense to include a parametric modulator
>>> that only has the same
>>> value for all events, not even a single one. It doesn't
>>> explain any
>>> additional variance in the data that is not captured by the
>>> primary onset
>>> regressors. Therefore, when coding up some batch scripts I
>>> always check if
>>> my modulator has at least 2 differing values in it and if
>>> not, I don't
>>> include it in the design matrix.
>>>
>>> Cheers,
>>> Jan
>>>
>>>
>>> Ryan Haynes wrote:
>>>
>>>> Hi,
>>>>
>>>> I am trying to determine if an error I'm getting
>>>>
>>> in spm_fMRI_design is coming from a possible round-off error
>>> in spm_orth. This bug is extremely rare as it only occurs in
>>> certain cases of parametric modulators and only in the
>>> situation in which the modulator for every event is
>>> identical such that the two vectors for an event are
>>> linearly dependent. For example, consider the following
>>> matrix "u" inside spm_get_ons:
>>>
>>>> 1 40
>>>> 1 40
>>>> 1 40
>>>> 1 40
>>>> 1 40
>>>> 1 40
>>>> 1 40
>>>>
>>>> spm_orth on this matrix returns a vector of 1's
>>>>
>>> and a vector of 7.10e-15. Mathematically this should be a
>>> vector of 1's and a vector of 0's of course and for
>>> most practical purposes 7.10e-15 is essentially 0. But, the
>>> problem that occurs is that if you run spm_orth on this
>>> matrix again you get a vector of 1's and a vector of
>>> 0's. This throws and error in matlab in spm_fMRI_design
>>> because of the following:
>>>
>>>> for i = 1:length(Fc)
>>>> X(:,Fc(i).i) = spm_orth(X(:,Fc(i).i));
>>>> end
>>>>
>>>> Matlab expects the return of spm_orth(X(:,Fc(i).i)) to
>>>>
>>> have the same number of dimensions as X(:,Fc(i).i) which is
>>> doesn't since spm_orth drops vectors that contain only
>>> 0's. What should have happened is that spm_orth should
>>> have dropped the vector containing 7.10e-15 originally.
>>> Instead of the following code in spm_orth
>>>
>>>> if any(D)
>>>> x = [x D];
>>>> end
>>>>
>>>> maybe this code should be used:
>>>>
>>>> epsilon = 1e-10;
>>>> if ~isempty( find(D) > epsilon )
>>>> x = [x D];
>>>> end
>>>>
>>>> The reason this bug is rare is that it only occurs for
>>>>
>>> certain numbers and for certain lengths of vectors. For
>>> example, the following vector of length 6
>>>
>>>> 1 40
>>>> 1 40
>>>> 1 40
>>>> 1 40
>>>> 1 40
>>>> 1 40
>>>>
>>>> does not cause this error while the one of length 7
>>>>
>>> does. Likewise, if you replace 40 with 50 in the
>>> 7-dimensional vector it also does not cause the error.
>>> Please let me know if this actually is a bug, or if not,
>>> please let me know what I'm doing wrong. Thanks.
>>>
>>>> Ryan Haynes
>>>>
>>>>
>>> --
>>> Jan Gläscher, Ph.D. Div. Humanities & Social
>>> Sciences
>>> +1 (626) 395-3898 (office) Caltech, Broad Center, M/C
>>> 114-96
>>> +1 (626) 395-2000 (fax) 1200 E. California Blvd
>>> [log in to unmask] Pasadena, CA 91125
>>>
>>
>
>
>
--
-------------------------------------------------------
DR RICHARD HENSON
MRC Cognition & Brain Sciences Unit
15 Chaucer Road
Cambridge, CB2 7EF
England
EMAIL: [log in to unmask]
URL: http://www.mrc-cbu.cam.ac.uk/people/rik.henson/personal
TEL +44 (0)1223 355 294 x522
FAX +44 (0)1223 359 062
MOB +44 (0)794 1377 345
-------------------------------------------------------
|