Я працюю над статистикою для побудови програмного забезпечення. У мене є дані про кожну збірку про пропуск / відмову та минулий час, і ми генеруємо ~ 200 таких / тиждень.
Коефіцієнт успішності легко агрегувати, я можу сказати, що 45% пройшли будь-який тиждень. Але я також хотів би узагальнити минулий час, і хочу переконатися, що я не надто погано подаю дані. Подумав, що краще запитати плюси :-)
Скажіть, у мене 10 тривалостей. Вони представляють як випадки пропуску, так і збої. Деякі побудови виходять з ладу негайно, що робить тривалість незвично короткою. Деякі зависають під час тестування і, в кінцевому рахунку, вичерпуються, що призводить до дуже тривалої тривалості. Ми створюємо різні продукти, тому навіть успішні збірки варіюються від 90 секунд до 4 годин.
Я можу отримати такий набір:
[50, 7812, 3014, 13400, 21011, 155, 60, 8993, 8378, 9100]
Мій перший підхід полягав у тому, щоб отримати середній час шляхом сортування множини та вибору середнього значення, в цьому випадку 7812 (я не переймався середнім арифметичним для множин з парними числами.)
На жаль, це, здається, породжує багато варіацій, оскільки я вибираю лише одне задане значення. Тож якби я трендував це значення, воно відхилиться між 5000-10000 секундами залежно від того, яка збірка була на медіані.
Отже, щоб вирівняти це, я спробував інший підхід - вилучити атрибути, а потім обчислити середнє значення, що залишилося. Я вирішив розділити його на третіл і працювати лише на середньому:
[50, 60, 155, 3014, 7812, 8378, 8993, 9100, 13400, 21011] ->
[50, 60, 155], [3014, 7812, 8378, 8993], [9100, 13400, 21011] ->
[3014, 7812, 8378, 8993]
Причина, яка мені здається кращою, двояка:
- Ми не хочемо, щоб якісь дії з швидшими побудовами, вони вже добре
- Найдовші побудови, ймовірно, викликані тайм-аутом, і вони завжди будуть. У нас є інші механізми їх виявлення
Тож мені здається, що це дані, які я шукаю, але я переживаю, що я досяг гладкості, видаливши, ну, правду.
Це суперечливо? Чи здоровий метод?
Дякую!