Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[burakkucat]

This is the problem picture.

I see no picture. 

But, using my feline powers of "see all", I'll show the URL --

http://i.postimg.cc/8Pn2FX9k/645-C6-D7-A-4389-42-B1-B9-FC-8-EDA5-EF643-D2.png

[Weaver]

The algorithm is now at v.5.2 after a bug fix in respect of the detection of the lhs chord endpoint ie near tone 40. The pseudocode for the paragraph determining x4, y4 code is now replaced by:

    /* Algorithm v 5.2 */

    uint x4 = find the x value for which y[ x ] = max( [ y[40], y[43], y45] );  /* test three points just above tone 40, find the highest y */
    double y4 = y[ x4 ];

There was a stupid bug here before. We want to find the highest y so as to get the best vertical drop value into the middle of any hollow. Any stalactites just above x=40 are irrelevant because they won’t win in the ‘max y’ determination algorithm anyway, as stalactites go down not up.

This change was motivated by the need to handle the latest extremely severe late-stage HCD case. See below. Here’s the relevant picture of horror, line 4, at 288 kbps downstream, 350 kbps upstream. Weird shape, slightly, and it was this that required the small revision of the HCD detection algorithm to also this case, the lhs shape being odd.

The result is now successful:

--
* HCD:❗So-called ‘hollow curve disease’ (HCD) defect detected in the downstream SNR-vs-tones curve of link #4. Serious fault. 🔺
   Link #4: Summary:  tone 52 is 2.36932 dB below chord 2: (tones 40-62);  ❗
   Link #4: Details: chord 2: [ tone 40: 35.0625 dB; curve midpoint test tone 52: 28.875 dB; tone 62: 28.0625 dB ]; chord midpoint test tone 52: 31.24432 dB.

One minor annoyance that I’d like to correct is that while this is being reported as a failure against a chord 2 test, I suspect that it is could also be a failure against chord 1, and although there’s nothing wrong with the result, I’d prefer to report the chord 1 failure somehow where there’s a choice. Re-ordering the tests would fix this, as for some reason the code currently tests for chord 2 first, and first test wins. Moving blocks of code around is a nightmare in the iOS Shortcuts’ code editor and I’d have to think of some clever tricks to make it doable.


Note that unfortunately the picture below is from somewhat earlier today and the numbers don’t match those of the analysis above.

[burakkucat]

Ah, yes, I see. But as you are the expert with iOS Shortcuts, I know you will eventually make the required code adjustments. 

[Weaver]

I found the first serious bug in the field - a false detection report. This was due to a ripple, either noise or a very small stalactite; it was very near the test-midpoint of chord 3 and dipped down just below a chord that was very close to the curve over the whole length of the chord. The ripple just dipped below the chord midpoint and so was bogusly reported to be HCD chord 3. I kludge this by increasing the min midpoint drop parameter for chord 3, a feature that was designed specifically to reject noise like this, but failed because the min midpoint drop parameter was set too low so the chord 3 detector was oversensitive. Now it won’t detect real HCD quite so early, a disadvantage.

That is just a fudge though. The right thing to do is as described in the algorithm 5.2 bug fix for the lhs x= 40 to 45, done again for all three midpoints too, so the find-x-of-max-y[x] test replaces the existing stalactite test everywhere. This has the huge advantage of being possibly parameterless now. The min midpoint drop parameter requires hand-tuning and its value will always be bogus and arbitrary. I’m not completely certain that it should be done away with as getting rid of it is the same as setting the value to zero. I’m wondering if there is any virtue at all in retaining it with a small value. What do you think? It’s only the difference between:
           hcd = ( y_curve_mid < y_chord_mid );                       /* ← new code, possibly */
  and    hcd = ( y_curve_mid < y_chord_mid - min_midpoint_drop );   /* ← existing code, possibly to be retained */

This fix will take us to algorithm - what ? - v5.3 or v6 ? Which do you think it ought to be ?

It’s a slightly onerous change and will have to wait until I have a bit more energy. I wish I could copy code blocks. One of the many limitations of the strange Shortcuts code editor, which is ‘interactive’ - whatever that means - not like a traditional text editor. (It does live checking and offers instant parameter suggestions and various other interactive features integrated with syntax checking on the fly.)

[burakkucat]

This fix will take us to algorithm - what ? - v5.3 or v6 ? Which do you think it ought to be ?

If it is a minor(-ish) tweak, then v5.3; otherwise v6.0 would be my suggestion.

[Weaver]

Have now gone for it, have replaced the stalactite detectors at every point with find-x-for-ymax searching. This has increased reliability a lot. It kills two birds with one stone: it rejects stalactites, and also finds each max-y, something that is desired anyway in some cases, such as when finding the lhs-x.

Have also fixed a nasty bug that I spotted. In a certain case a variable was read before it was first written, so an undefined variable value. In this particular case it was not actually truly undefined, because the code was inside a major, all-enclosing outer loop ‘for-each-modem’, so an ‘undefined’ variable in pass modem( n ) would in this case pick up some bogus value from pass modem( n-1 ).

So very big improvement.

[burakkucat]

So very big improvement.

That reads as if it is v6.0 of the code.

[Weaver]

Agreed, algorithm v6.0 it is then.