How to implement time-Spline basis functions as available in MATLAB unfold?

[jordandeakin]

Hi all :)

I used to use the MATLAB version and would use time-spline basis functions as opposed to stick functions.
cfg.method = "splines".
cfg.timeexpandparam = x

From what I understand, firbasis() is a stick function basis set. I liked the spline method in MATLAB because of the smoothing properties. Is this spline basis set available in the Julia version?

Alternatively
My (julia) eFRPs can often look a little spiky compared to the ones generated by MATLAB. In the original paper:
"Low-pass filtering and downsampling of the data followed by using the stick function deconvolution might result in better control of the spectral properties."

Not sure if I understand correctly but, if the spline approach is not available in Unfold.jl, does this mean I could just keep the stick functions but just downsample to address this? Do you see any issues with doing this?

Thanks very much, I really appreciate how helpful this discussion board is!

EDIT: I just realised there is splinebasis() in basisfunctions.jl. I will try this out. But I am still curious about using the stick function + downsampling possibility

[ReneSkukies]

Hey!

Just to quickly give a few thoughts because Benedikt is on holiday:

Yes you can use splines as basisfunctions, however it is part of the BSplineKit extension, so you have to using BSplineKit beforehand. I also just had a look and this should proabably work:

using Unfold
using UnfoldSim
using BSplineKit

data, events = UnfoldSim.predef_eeg();

Unfold.splinebasis((-0.1, 0.8), 100, 5, "basisA")
f = @formula 0~ 1 + condition

#etc.

For some reason splinebasis did not get exported for me so I had to use Unfold.splinebasis(), maybe it was because I used Pluto...

Additionally, using Pluto currently seems to result in a bug:

Failed to show value: 

FieldError: type Unfold.SplineBasis has no field `scale_duration`, available fields: `kernel`, `colnames`, `times`, `name`, `shift_onset`

I tracked it down to be purely an issue with some compat for spline plotting in Pluto, so if you are using normal scripts you should be fine. I'll make an issue for it as well.

(I also wanted to try out the stickfunction + downsampling, but I don't have time to not do it in Pluto; maybe Bene has more thoughts when he's back)

[jordandeakin]

Hi Rene,

Thank you for the quick reply. I also get this scale_duration error in normal scripts if I try to print 'design'. But I did get another error which I managed to fix:

ArgumentError: syntax df[column] is not supported use df[!, column] instead
which traces back to this line in designmatrix.jl (ln 424)

for r in eachindex(rows)
       **rows[r] .+= floor(onsets[r] - 1) .+ shift**
   end

It seems onsets comes in as a dataframe with size (x,1). I can force it to be a vector inside timeexpand_rows and the model fit runs.

However, maybe I am misunderstanding the spline time basis but, in the matlab version, I would still get a beta value for every time point. Here, this is not the case.
For example, with a time window of (-.2, 1.2), at a sampling frequency of 500Hz, and n_splines = 5, I am getting 5 (nsplines) betas for each predictor using coeftable(m).

Is it possible to use these to still get a predictor for every time point?

Thanks so much for your help!

[ReneSkukies]

Hey Jordan,

ah I see, the renderable obj is always tested to have the scale_duration attribute, hence the error when displaying. I will edit the issue, thanks for the catch!

For the dataframe error: I just had a bit of a dive into the code and there is definitely something wrong.

First, the error in line 424 is viable, and I can make a PR as a quickfix:

for r in eachindex(rows)
       rows[r] .+= floor(onsets[r, 1] - 1) .+ shift**
end

But that doesn't fix the results. I can confirm that I also only get one estimate per spline if I only use an intercept model. Ideally you are correct and you should get the same output as in the Matlab version (i.e. one beta per time point per channel). Although I am not sure if you would actually get one beta per time point, per channel, per spline; and then you could get the expected erp using the effects function. Whatever bug occurs here also breaks the effects function however.

Can you write us a bug report on this? I feel like this will take some more time and I still have to finish my dissertation 👀

[jordandeakin]

Thanks for checking! I will write a bug report. All the best with your dissertation :)

[behinger]

Unfortunately, this feature was on back-burner for such a long time... #12 - uff 2020, then basic implementation in '22.

Indeed what is missing is to "undo" the time-basis (e.g. multiply out the betas). I did that in matlab in the uf_condense, but there is no such step in Julia. At the time in Julia I didnt really know how to include it in the interface properly

The scale_duration relates to the Base.show function, where right now it tries to use the one of firbasis, because no more specific one is used. I should remedy that as well.

Note that in the issue linked above, there is some code to apply the basis, but I don't have time to test it right now.

Thanks for the bug report.

---

That being said, if it is just about "less spiky", and not about computation time, you could really simply lowpass filter your data to get smoother results. No need to down/upsample at all - that would just be for computational convenience.

[jordandeakin]

Hi Benedikt, thanks for replying (despite also being on holiday!).
I will check out the code you linked, but in the meantime I think I will just go with the low pass filtering.

Thanks again to both of you.