Sharp constraints in OptimalTermTreatment cause large non-linearities #345

Open
danluu opened this Issue Dec 17, 2016 · 0 comments

Projects

None yet

1 participant

@danluu
Member
danluu commented Dec 17, 2016

I believe these are a sign that our constraints to the problem are causing us to get a non-optimal solution.

If we look at the current output of Optimal:

idf 1.1: 0.0794328 ==> 000002: snr: 187.781, qw: 1.99882, bits: 1.58866, dq: 0.314917
idf 1.2: 0.0630957 ==> 000002: snr: 46.3284, qw: 1.99882, bits: 1.26191, dq: 0.396457
idf 1.3: 0.0501187 ==> 000002: snr: 20.143, qw: 1.99882, bits: 1.00237, dq: 0.49911
idf 1.4: 0.0398107 ==> 000002: snr: 10.9891, qw: 1.99882, bits: 0.796214, dq: 0.628342
idf 1.5: 0.0316228 ==> 001002: snr: 34.674, qw: 2.07235, bits: 0.757456, dq: 0.637058
idf 1.6: 0.0251189 ==> 001002: snr: 28.1701, qw: 2.0356, bits: 0.627377, dq: 0.783029
idf 1.7: 0.0199526 ==> 001002: snr: 24.1472, qw: 1.98517, bits: 0.524052, dq: 0.961232
idf 1.8: 0.0158489 ==> 001002: snr: 21.4938, qw: 1.92178, bits: 0.441979, dq: 1.17732
idf 1.9: 0.0125893 ==> 001002: snr: 18.9153, qw: 1.85296, bits: 1.21565, dq: 0.443941
idf 2: 0.01 ==> 001002: snr: 13.9546, qw: 1.81021, bits: 0.972553, dq: 0.568012
idf 2.1: 0.00794328 ==> 001002: snr: 10.4148, qw: 1.77269, bits: 0.776939, dq: 0.726071
idf 2.2: 0.00630957 ==> 002002: snr: 15.7914, qw: 1.71022, bits: 1.11371, dq: 0.525021
idf 2.3: 0.00501187 ==> 002002: snr: 14.6435, qw: 1.61479, bits: 0.888211, dq: 0.697217
idf 2.4: 0.00398107 ==> 002002: snr: 13.4926, qw: 1.51834, bits: 0.707788, dq: 0.930523
idf 2.5: 0.00316228 ==> 002002: snr: 12.3267, qw: 1.42362, bits: 0.563645, dq: 1.24624
idf 2.6: 0.00251189 ==> 002002: snr: 11.1478, qw: 1.33338, bits: 0.448624, dq: 1.67172
idf 2.7: 0.00199526 ==> 002002: snr: 9.96861, qw: 1.24994, bits: 0.356927, dq: 2.24146
idf 2.8: 0.00158489 ==> 002002: snr: 8.80842, qw: 1.17481, bits: 0.283879, dq: 2.99848
idf 2.9: 0.00125893 ==> 002002: snr: 7.68941, qw: 1.10871, bits: 0.225721, dq: 3.99586

We go from having 2 rank 0 rows to 2 rank 0 and a rank 5. This is because the rank 5 row is cheaper in space than another rank 0, and it gives the smallest bump that gets us above our snr threshold. However, this is a sign that our hard threshold is causing us to make artificial decisions. This could be fixed by doing one or more of the following:

  1. Explicitly trade off SNR in the cost function.
  2. Allow densities to vary in the TermTreatment.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment