Как стать автором
Обновить
0
0

Пользователь

Отправить сообщение
Дорогой автор! Выражу свою скромное мнение:
Этапы анализа: лучше начинать с формирования нулевой гипотезы, а не с процессинга и предварительной обработки данных. Тогда в рамках нулевой гипотизы вы сможете задать ожидаемую величину эффекта, статистическу мощность, размеры выборок (смотрите анализ мощности/power analysis) и избежать неудобных вопросов, а почему эти датасеты, а что с инфляцией и т.п.
Идея с выбросами (outliers) вообще не ясна, почему выбрано такое значение порога и какое оно ( 1.5 * ICR, 2*ICR). Вообще выброс в зарлатах — это либо бухгалтерия в цифре ошиблась или коррупция, ну так на вскидку и каждое значение перед отсевкой нужно обосновать. Сколько у вас выбросов было не ясно.
И поэтому я плавно перейду к графике: к сожалению она не информативна, тот же ящик boxplot надо снабдить количеством наблюдений, а лучше сверху cлой beeswarm. Но вообще для этих целей есть куда более удачные аналоги. Ну и дальше по списку. Наилучший вариант графика в рамках EDA ( exploratory data analysis) это ECDF. Вообще графика это та еще трясина и по моему опыту лучший вариант это не статика- seaborn, а интерактивка bokeh, если в R то не ggplot/lattice, а trelliscope.
Сама 0 гипотиза хороша, но не ясно что заложено в этой фразе «НЕ верность гипотезы, несмотря на всю ее очевидность, мы сможем точно проверить рассчитав P-value для нулевой гипотезы». P-value в рамках классической статистики вероятность получить такое или еще большие отклонение от значения целевой статистики, при условии верности 0 гипотеза, бесконечно большого числа повторения эксперемтов на «схожих» выборках, не более того. Та к что лучше избегать фразы точно проверить верность/не верность 0 гипотизы.
NB
mean_salary_14 = np.mean(data_14_1['Salary'])
conf_salary_14 = np.percentile(data_14_1['Salary'], [2.5, 97.5]) никакого отношения к ДИ для среднего этот чанк не имеет. Нужно генерировать бутстрапированные выборки, сохранять для каждой значение среднего и уже для этого массива искать ДИ. И хотелось бы прежде увидеть результаты перестановочных тестов(permutation test), чтобы понять, а вообще у вас выборки то сопостовимы по структуре участников( может в 14 у вас много Junior QA Engineers, а в 19 много System Architects, что опять таки возвращает нас к вопросу о выбросах).
Ну и выводы очень странные: нулевая гипотиза одна, а выводов целых три
P.S. и всегде, любую метрику снабжайте либо ДИ либо пишите что это выборочное значение исследуемого показателя.
А что, R уже совсем не в почете что ли? Стистистика там явно сильнее реализована, с big data он и локально и через Spark работать может
Ну какой смысл давать проценты, но не давать для них доверительные интервалы, а потом говорить больше меньше стало. Что тот год, что прошлый могут быть из одной генеральной совокупности, а отличия между выборками чисто случайными.
Ну тут на самом деле спорно про максимально быстро и data.table, только если у вас достаточно маленькие объемы данных. Вообще сравнить spark и data.table на локалке слегка не верно. А вот сравнивать iotools/bigmemory и sparklyr и с подкруткой под эти пакеты master-worker и map and reduce парадигм параллизации процессов соответственно, куда логичнее
Имел небольшой опыт работы с spark через пакет sparklyr. В общем и целом пакет новый, можно нарваться на ошибку и зависнуть над ней надолго, потому что невсегда она очевидна. Хотя синтексис очень близок к обычному dplyr, что конечно удобно, хоть и странно, тот же data.table тут был бы роднее. Мне кажется, многим роднее будет работать через iotools, чем вникать в spark

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность