Use an exact +- dt window in spike_time_tiling_coefficient

[adityasingh2400]

run_p builds the synchronicity window with np.isclose(t_j, t_i, atol=dt). np.isclose also applies its default relative tolerance rtol=1e-5, so the test performed is |t_j - t_i| <= dt + 1e-5 * |t_i| rather than the documented |t_j - t_i| <= dt.

Spike times are absolute, so the window grows with the distance of the recording from t = 0, and it is asymmetric between the two trains because rtol multiplies only the second argument. run_t computes the T terms with dt exactly, so P and T were being derived from different windows.

The result is a silently wrong coefficient rather than an error:

scenario	dt	elephant	correct
two spikes 12 ms apart, recording starts at t=0	5 ms	-0.0005	-0.0005
same two spikes, recording starts at t=1000 s	5 ms	+1.0	-0.0005
independent 5 Hz Poisson pair, 600 s, t_start=0	5 ms	+0.027	-0.003
same pair with wall-clock timestamps (t_start=86400 s)	5 ms	+0.9998	-0.003

The effective window is dt + 1e-5*|t|. A requested 5 ms is already 11 ms at the end of an ordinary 10 minute recording, and 869 ms at t = 86400 s.

This compares the times directly instead. It matches the documented [-dt, +dt], it matches what run_t already does, and it makes the result invariant under a time shift of the whole recording. test_sttc_validation_test, which checks against C. Cutts' original C implementation, still passes.

The relative tolerance came in with the vectorization in 8bac14c (#564) and looks like an artifact of moving to np.isclose rather than a deliberate tolerance.

Tested with two new cases in elephant/test/test_spike_train_correlation.py, one pinning the window to exactly dt and one asserting invariance under a time shift. Reverting elephant/spike_train_correlation.py to master makes both fail, the first with np.float64(1.0) != -0.0005. The full file passes after at 37 passed and 12 subtests. pycodestyle is clean.

Note the module doctest shows np.float64(0.4958601655933762) against an expected 0.4958601655933762. The value is identical and the difference is repr only, which is known issue #686, and CI forces legacy numpy printing.

I have not added myself to doc/authors.rst. It is a numbered institutional affiliation list and I did not want to presume, so please let me know if you would like an entry there.

Disclosure: this change was prepared with AI assistance. I have reviewed and tested it.

[coveralls]

coverage: 45.709% (-42.9%) from 88.605% — adityasingh2400:fix/sttc-synchronicity-window into NeuralEnsemble:master

[adityasingh2400]

The three red jobs here are not from this branch.

All three fail on the same two tests, test_datasets.py::TestDownloadDatasets::test_valid_data_with_integrity_check and test_valid_data_with_failed_integrity_check, both with SSLCertVerificationError: certificate verify failed: unable to get local issuer certificate while fetching the sample datasets over HTTPS. The rest of the run is green at 773 passed, 5 skipped, including the spike train correlation tests this PR touches.

This branch only changes elephant/spike_train_correlation.py and its test module, nothing under elephant/datasets and nothing involved in downloading. A rerun once the certificate or network issue clears should be all it needs.

[adityasingh2400]

Small addition to my earlier note: the docs job is red here too now, and it is the same remote-data problem seen from the sphinx side, where a notebook that downloads sample data fails during execution.

Also, the Coveralls number on this PR, about 45.7 percent against a base of 88.6, is consistent with the failed jobs never uploading their coverage rather than with a real regression. The passing run still reports 773 passed and 5 skipped, with only the two TestDownloadDatasets cases failing.

[CozySocksAlways]

Hello there,
And thank you once again for 3 straight PRs :) :). Same story here on the CI/coverage front as the other two. As mentioned I'll review them and post my comments here.

[adityasingh2400]

Correcting my note above, since the rerun has now happened and did not do what I predicted.

I said a rerun should clear this once the network settled. Attempt 2 on 8075b6a cleared pip and conda but not mpi or docs, and those two are now separate problems.

mpi is still the data host, but refusing rather than dropping. Five TestDownloadDatasets cases fail with HTTP Error 403: Forbidden. git ls-remote https://gin.g-node.org/NeuralEnsemble/elephant-data.git succeeds from my machine right now, returning HEAD 666b920d, so the host is up and is refusing the runner specifically. pip and conda passed on that same run, which looks more like rate limiting than a block.

docs is no longer a fetch failure at all:

ImportError: cannot import name 'backend2gui' from 'IPython.core.pylabtools'

That is what #709 pins ipython<9.16 for, and docs plus readthedocs are both green on that branch. #708 hits the same import. My note on #707 saying its docs job would pass once the remote recovered was wrong for the same reason, that run predates the IPython release.