Thanks for letting us know. We are running SPM5 but we checked the website and it appears that we are using an outdated version. The updated spm_orth works properly as you have said.
Ryan
--- On Wed, 5/13/09, Guillaume Flandin <[log in to unmask]> wrote:
> From: Guillaume Flandin <[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, 3:12 PM
> 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
> >
> >
>
>
> --
> Guillaume Flandin, PhD
> Wellcome Trust Centre for Neuroimaging
> University College London
> 12 Queen Square
> London WC1N 3BG
>
|