Chat > Chit Chat
Maths - hollow curve phenomenon detector - algorithm design
burakkucat:
Just differentiate the arithmetic mean and find the turning point(s) of the curve. If you have a local maximum, followed by a local minimum, followed by a local maximum then the hollow curve phenomenon has struck again.
Hmm . . . I think you will need to look at the second differential. (My memory of A-level pure mathematics, from 50+ years ago, has faded somewhat.)
Weaver:
I understand the calculus rationale. However the pilot tone thing has a huge spike in both first and second derivatives.
l would rather not do differentiation; recte finite differences here, since the bits-per-bin data are discrete integer-valued (y). The reason is because having a loop with lots of subtractions in it will be slow, as Shortcuts is incredibly slow.
What were you saying before about four quarters? My most urgent need is to get rid of all spikes, pilot tone being the main one. Wobble of y +/- 1 is also a nuisance, some being mere quantisation noise.
burakkucat:
I'm not too sure what I was thinking about, late yesterday. :-[
At the moment, I can't see a clear forward path to a boolean answer to a query asking if a "hollow curve" is present.
Random thought. Suppose that the bit loading per sub-carrier index is "harvested", once, at the same time each 24 hour period. Now subtract that of dayn from that of dayn+1 to give the delta on dayn+1. What would that delta show when the "hollow curve phenomenon" first appears?
Weaver:
Yes, it would, but that won’t fit in the spec for this as I was going to add this in as an additional immediate health check amongst those already checked in the application program that I write about some weeks ago, an iOS Shortcuts app that checks all the modems and delivers a very succinct report - good or bad and if bad it gives the details. That program does not run continuously so that rules out your idea, because iOS doesn’t allow Shortcuts programs to run continuously - they’re UI-modal, locking up the UI, with no multitasking and no thought given to what should happen if you run two Shortcuts programs - in other words a complete design dog’s breakfast. Perhaps tolerable on an iPhone for very short excution-time programs, but not suitable for an iPad with a big screen and several very slow Shortcuts programs wanting to run side by side. But apart from being painfully slow in iOS 15 the result works really well and does what it’s supposed to.
I was thinking about a crude spike detector that looks at x==60 for a dip down to y=2 (or maybe 3,4 for a bit of insurance) and then if it sees one at x==60 it walks sideways in increasing x+=2 to get away from the spike. Then y[x==60 or 62] now is compared against y[40] and y[85] as mentioned in my first post. Something like
hollow = y[x==60 or 62] < y[40] && y[x==60 or 62] < y[85];
The benefit of this is that it has no loops in it, given the painful slowness of Shortcuts iOS15
burakkucat:
--- Quote from: Weaver on January 20, 2022, 08:55:57 PM ---I was thinking about a crude spike detector that looks at x==60 for a dip down to y=2 (or maybe 3,4 for a bit of insurance) and then if it sees one at x==60 it walks sideways in increasing x+=2 to get away from the spike. Then y[x==60 or 62] now is compared against y[40] and y[85] as mentioned in my first post. Something like
hollow = y[x==60 or 62] < y[40] && y[x==60 or 62] < y[85];
--- End quote ---
I am not that certain . . . but it certainly is worth testing.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version