This is something which i found unintuitive when looking at the factors for OOBs. Metrics which had very narrow high/low ranges could generate OOBs with very large factors from values just above or below their high/low, while metrics with larger ranges generated OOBs with smaller factors, even though the values were much further away from their high/low. See conversation below for more details...

(10:45:06 AM) ccrouch: pilhuhn: so I'm looking at some oobs
(10:45:28 AM) ccrouch: trying to work out what the factor is now?
(10:45:48 AM) ccrouch: "Out of range factor (%)"
(10:46:34 AM) pilhuhn: factor is the same -- the issue you are probably seeing is that the one 5.2m is not the same as the other 5.2m So the band is perhaps really 5.1999m - 5.20001m  but our code displays it as 5.2
(10:46:47 AM) ccrouch: right, i think i get it
(10:46:50 AM) pilhuhn: go to the big chart (click on the metric name) and see what it says for the band
(10:47:10 AM) ccrouch: it produces some arguably unintuitive results
(10:47:14 AM) ccrouch: for example
(10:47:27 AM) ccrouch: 4.9m - 4.9m   4.2m    8110
(10:47:45 AM) pilhuhn: for line 2 it is   (84-3) / (3-2)  = 81 / 1 = 81 = 8100 %
(10:47:55 AM) ccrouch: 4.2minutes is 8110% out of the range
(10:48:43 AM) ccrouch: around 4.9minutes
(10:48:43 AM) ccrouch: and then
(10:48:43 AM) ccrouch: 2.0ms - 3.0ms 84.0ms  8100
(10:49:10 AM) ccrouch: 84ms is 8100% out of the range between 2 and 3
(10:49:23 AM) ccrouch: i agree the math is correct :-)
(10:50:00 AM) ccrouch: i'm just arguing is something that goes from 4.9 to 4.2 more out of bounds than something that goes from 2 to 84
(10:50:36 AM) mazz: no ccrouch. 2->84 is more OOB
(10:50:38 AM) pilhuhn: ccrouch: that is because the band of the 4.2 one is so narrow
(10:50:49 AM) mazz: assuming the band is small too
(10:50:59 AM) ccrouch: (10:50:36 AM) mazz: no ccrouch. 2->84 is more OOB
(10:50:59 AM) ccrouch: not using the factors as they are today
(10:51:06 AM) pilhuhn: 4.2 is not 4.2 but in reality it is something like 4.19999 or 4.20005
(10:51:07 AM) ccrouch: pilhuhn: yep
(10:51:23 AM) ccrouch: right,  i understand why its like this
(10:51:38 AM) ccrouch: i'm just saying its somewhat counter intuitive
(10:51:59 AM) pilhuhn: ccrouch: Try to get the raw band data from the big charts page. If this shows the same, try to get it from the db -- we can still argue if we shall ignore those bands that are too narrow
(10:52:24 AM) ccrouch: hmm thats an interesting option
(10:52:48 AM) ccrouch: ignoring the very narrow bands
(10:53:03 AM) pilhuhn: But dividing through the band size is the only way to be able to compare very big metrics (100s of MBs ) with small ones (single digits)
(10:56:17 AM) ccrouch: pilhuhn: agreed about the need for some sort of banding
(10:56:49 AM) ccrouch: but very narrow bands have disproportionately big impact on the fact
(10:56:52 AM) ccrouch: factor
(10:57:18 AM) ccrouch: well they have the same impact as the metric which is actually out of bounds i guess
(10:57:44 AM) pilhuhn: yes
(10:58:10 AM) pilhuhn: I mean if the band is 4.21 - 4.22 and the metric is 4.3 the factor will be small too
(10:58:41 AM) ccrouch: yep, but the issue is 4.21001 - 4.21002 and the metric is 4.3
(10:59:01 AM) ccrouch: the factor will be 1000x what it was previously
(10:59:38 AM) ccrouch: but to me its not very much more out of bounds
(11:00:34 AM) pilhuhn: then draw it on a sheet of paper, in a unit where high and low bounds are 10cm away and then try to put 4.3 on that sheet too :)
(11:00:39 AM) ccrouch: infact with a band of 4.2199999-4.220000 and the metric of 4.3, its arguable no more out of bounds than before
(11:01:10 AM) pilhuhn: And then after that put a band 100,150  with an outlier of 200 next to that -- also the bounds on the same place on the sheet as before
(11:01:11 AM) ccrouch: can we do something that takes into account the bound values when calculating the band?
(11:02:07 AM) pilhuhn: I don't want to change this now. We can add a FR for 2.3
(11:02:48 AM) ccrouch: we're going to get support case on this :-)
(11:03:32 AM) pilhuhn: I am sure we will - but we will no matter what algorithm we use