Various PSX fixes #2362
Open
Various PSX fixes #2362
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
t-b
force-pushed
the
bugfix/2362-psx-support-multiple-selections
branch
from
f508957 to
f23db8a
Compare
t-b
force-pushed
the
bugfix/2362-psx-support-multiple-selections
branch
from
1332271 to
08deb18
Compare
t-b
force-pushed
the
bugfix/2362-psx-support-multiple-selections
branch
4 times, most recently
from
a12c1dd to
193bf80
Compare
This comment was marked as outdated.
This comment was marked as outdated.
Collaborator
|
@t-b I also tested pasting the average fit results into Excel. The row formatting is correct. However, Excel plots all the columns in one column. Excel is dumb. To correct this, paste into Excel, select the cells, select Data from the menu, select Text to Columns, and select the appropriate delimiter in the Excel pop-up GUI. |
Collaborator
|
@t-b there may also be issues with the indivdual decay tau values. For example in this case I'm getting a negative weighted tau.
|
New MiES algorithmic utility for band pass filtering with Nan, Inf, and ringing rejection and automatic order reduction
Rename it to psxDeconvBPFilter to make it clear that this is a bandpass filter, see also PSX_DeconvoluteSweepData. And also reorder the filter frequencies for the user to avoid an assertion.
Due to implementation details of how FilterIIR implements band pass filters the used order is always even. If required, odd values are increased by one so that they are even. Document that and also make them even already when we get them. We can as well adap the default value to be even already.
Define all variables at the top, reword the documentation.
When PSX_OperationSweepGathering returns 1 as error code, we wrote the code so that idx is not incremented in this case. The idea in d359a7a (PSX_Operation: Handle partial results better, 2024-02-27) was that we don't want holes in the output wave. But the code was buggy as it, after an error, would reuse the same data again, and thus error out again, and therefore ignoring all data behind the first combination with an error. Fix that by introducing separate indizes for reading and writing.
The FFT algorithm used by Igor Pro requires the prime factors of the data
points to be small, the documentation even says < 5. A real world dataset
with size 2308332 was way too slow and all time was spent in FFT. This
number factors into {2,2,3,13,14797} so this is really not small.
We now fix that by padding the data to the next power of two, this should
also not influence the result.
This reverts commit 2180a89.
We now have average fits for all states (accept, reject, undet, all) and not only accept. The GUI was also redesigned to accomodate the new checkboxes and buttons.
These routines allow to calculate all values between 2^1 and 2^30 which have 2 and 3 as prime factors. This helps in deciding a good cut off value for FFT as it only performs when the primes are smaller than 5.
The FFT implementation in Igor Pro requires the prime factors of the length to be < 5 for speedy execution. For some cases these prime factors can be very large (~1e5) and thus FFT would be dead slow, i.e. in the order of minutes on common machines. We now employ a data shortening to a size which has only 2 and 3 as prime factors, which makes FFT very fast. This is only done if we have prime factors larger than a 1000 in the original size.
We now reserve space for the defaults in the psxDeconvBPFilter/psxSweepBPFilter operations so that we can later on add the calculated defaults, which need parameters from psxKernel, can be added via PSX_AddDefaultFilterFrequencies.
And allow querying them from psxstats.
This is convenient for documentation purposes although this is not an input parameter.
Ever since 7aa2be6 (PSX: Add average fit for all states, 2025-06-04) we are using the per-combo index for gathering the eventKernelAmp/eventOnsetTime/eventPeakTime values. This is wrong as we must use the index of the displayed events.
camel case fix Co-authored-by: Copilot <[email protected]>
camel case fix Co-authored-by: Copilot <[email protected]>
t-b
force-pushed
the
bugfix/2362-psx-support-multiple-selections
branch
from
a497d56 to
ba0dc32
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
2^l + 3^klogic, closes: PSX: Make it faster #1663()behind numberOfSDs in the JWN to document itV_modeand all other missing entries from StatsQuantiles to postProc output forstatsinpsxStatsTim provides Poc for figuring outpsxKernelparameters from scratchOld Todos
So this should be ready for a first test. I've adapted `psxKernel` and `psxStats` to allow passing in multiple selections.
that still makes sense. The baseline search shouldn't search past the previous
peak_t. With the baseline_t of the event available, PSX_CalculateEventPeak, instead
of using prevDeconvPeak_t to constrain the search, can use the event
baseline_tinstead. The above makes adding a peakfinding operation, which I suggested
yesterday, unnecessary.
// 3 checkboxes to turn all of these on/off below suppress update
// peak_t
// baseline_t
with, see SweepFormula: Groups multiple x-axis labels #2423psxStats, see psxstats: Should accept an array of properties #2422