И мы опять приходим к простому среднему, которое не учитывает количества голосов.
Вы путаете простое среднее и средневзвешенное (1 частный случай второго)
Средневзвешенное может учитывать число голосов. Например, (sqrt(N)*p/N + 0.5)/(sqrt(N)+1).
Чем больше N тем больше значимость оценок. sqrt(N) — функция взвешивания (сглаживания), 0.5 — с чем мы взвешиваем (средняя оценка).
Суть была именно в том, чтобы использовать не какую-то среднюю температуру по больнице, а нечто, что учитывало бы также и степень нашей уверенности в ответе
Единственное что в бинарном рейтинге нам говорит об этом это число голосов. Если взять любую функцию возрастающую с N и использовать как коэффициент при среднем взвешивании, то мы получим учет достоверности.
А какая разница, сразу задавать alpha и beta или выводить их из количества голосов и средней оценки?
Константа осталась одна. Она приобрела смысл (чем больше тем сильнее сглаживание). И стала безопасной — при любом ее значении большем нуля значение будет между 0.5 и p/N.
Современные поисковые движки используют больше 100 подстраиваемых коэффициентов, чтобы улучшить результаты ранжирования результатов, а вы наоборот хотите уменьшить их количество и сделать систему жёсткой и не поддающейся регуляции.
У поисковиков есть автобалансировка коэффициентов в формулах (матрикс.нет у Яши) и сотни тысяч оценок ассесоров, чтобы это сбалансировать.
Не большая абстракция, чем вероятность сама по себе. Но ведь использование вероятности вас не смущает?
Вероятность физична как и прогноз. Они несут явный смысл. Есть смысл сортировать фильмы по вероятности того, что они понравятся пользователю. Смысла ранжировать по «нижнему пределу доверительного интервала бета-распределения с коэффициентом значимости 0.95» нет никакого.
Вы сейчас скажите, что он выражает пессимистичный прогноз вероятности того, что фильм понравиться пользователю.
А почему сортировать по пессимистичному прогнозу? Почему не по обычному прогнозу, который можно получить взвесив среднюю оценку по статье со средней по сайту?
В этом случае, следуя центральной предельной теореме, мы получим то же самое нормальное распределение, а оно всё-таки менее гибкое, чем бета.
ЦПТ действует только на бесконечности. На практике можно ее применять к большим числам. Однако, мы рассматриваем маленькие числа (если бы число голосов было бы большим, то каким-то образом балансировать рейтинг не нужно). Для биномиального распределения есть отдельные функции.
Бета и нормальное разные распределения, то что стандартное нормальное распределения частный случай бета не говорит о том, что нормальное частные случай бета, как и то что бета частный нормального. И бета и нормальное двупараметрические кривые, они не могут быть частными случаями друг-друга (разве что эквивалентами, но область значений у них разная).
P.S. Биномиальное распределение характеризуется одним параметром P, откуда у вас второй параметр взялся для бета непонятно.
вы путаете случайные числа и абсолютно случайные. Случайные подвержены какому-то закону, например, людей с ростом 175см в разы больше чем двухметровых. Или игральная кость с равной вероятностью падает на 1 из 6 граней. Случайные числа подвержены какому-то закону распределения. Абсолютно случайных чисел нет (это философская максима, кажется) любые числа подвержены какому-то распределению (в некоторых случаях нам не известен этот закон).
Случайных чисел тоже нет это мат. абстракция (ну кроме квантовой механики). Мы считаем число случайным, поскольку нам что-то не известно. Например, угловая скорость и скорость центра тяжести монеты и расстояние до пола в противном случае для нас Орел/Решка не было бы случайным событием.
Если мы могли считать мысли каждого пользователя, который проголосует за фильм, то для нас голосование не было бы случайным. Но поскольку мы не знаем кто проголосует и как до голосования для нас это случайные величины.
С другой стороны все реальные события и числа случайны: на событие может повлиять бесконечное множество факторов, которые учесть все мы не в состоянии. Квантовая механика говорит, что все априори случайно и дело ни в недостатке информации или вычислительных способностей.
Интересность понятие субъективное. А в человеческой психике все идет волнами сегодня вам покажется интересным то, что месяц назад не показалось бы или наоборот.
Интересная статья. Однако использование бета-распределения не объяснено.
У вас число положительных(positive) и отрицательных голосов(negative). И сразу вы строите на ним бета функцию с параметрами 1+p и 1+n.
В теории, бета функция в вашем случае должна выражать прогноз оценок которые бы поставили пользователи если бы могли поставить любую оценку от 0 до 1. Это единственный ее физический смысл, который может у нее быть в этом контексте. Однако непонятно зачем сводить задачу бинарного рейтинга к рейтингу с бесконечной дискретностью.
Мат. ожидание у вас получилось (1+p)/(1+p + 1+n) т.е. вы просто по 1це прибавили к обоим оценкам, тем самым сгладив оценки с 0.5.
По большому счету эта формула ничто иное как частный случай среднего арифметического взвешивания средней оценки конкретного фильма с 0.5. Коэффициенты при этом 2 и N(=n+p) общее число голосов:
(1+p)/(2+p +n)=(2* 0.5 + N*p / N)/(2 + N)
Из второй формулы можно зная среднюю оценку фильмов (она не обязательно равна 0.5) можно посчитать первые слагаемые параметров бета функции. Выбрав вместо двойки другую константу сглаживания. Вот в итоге мы сводим задачу к одной константе.
Один из вариантов сравнения — это посчитать минимальное доверительное качество фильма, число, показывающее минимальную оценку, которую может получить фильм после бесконечного количества отзывов.
Опять таки, вы предлагаете упорядочивать фильмы по минимально возможной оценке. Это во-первых не физично (минимум доверительного интервала это мат. абстракция). Во-вторых он сильно зависит от точности. 95% и 90% даст огромную разницу. Мы получим еще один коэффициент. В третьих почему-бы не использовать бинарное распределение вместо бета-функций и считать их доверительные интервалы.
Интересно было бы если бы вы рассмотрели не бинарные шкалы, а «5 звезд» или от 1 до 10. Построили общую бета-функцию и с помощью нее, сравнивая с частной шкалой, снизили бы влияние накруток.
обычно PM имеет больше представления о проекте в целом, чем программист, в плане его предназначения и потребностей, которые он удовлетворяет у пользователей.
Если, конечно, программистов больше 1го (если 1 программист то непонятно зачем PM нужен).
Если последнее слово было бы больше чем за одним человеком, то проект не был бы целостным в плане дизайна (в английском смысле этого слова).
Тоже самое было бы если бы актеры и операторы при съемке фильма бы сами выбирали сцены и диалоги, а не слушались бы режиссера. Некоторая свобода у актеров есть, но последнее слово должно оставаться за одним человеком.
Ну не всегда, когда работаешь сам на себя бывает желание ничего не делать пару недель. Отмазываешься перед собой, что ты не в настроении или прочее. Когда на кого-то или на тебя другие ты чувствуешь ответственность.
А при работе «на дядю» практически всегда проще, полезнее для нервной системы и «профессиональнее» ответить «Yes sir!» и дать estimate на месяц, чтобы реализовать идиотские фичереквесты с не менее идиотскими requirements (а идиотов переубедить вообще невозможно!)
Ну заказчики или руководители бывают неадекватные. Но, обычно, руководители адекватные и способны разобраться какому прогеру нравиться детальное ТЗ, чтобы меньше думать, а кому-то нужны белые пятна и возможности для полета фантазии.
Я не сильно знаком с терминологией разработки под Эпл. Три viewController'a это три формы(экрана)? Мне сложно оценить сложность этого, поскольку экраны разного размера. Сколько всего элементов интерфейса (кнопок, чек боксов) без стандартных диалогов?
Полный цикл? Конечно, если все делать правильно, то получится долго, и нудно дорого. А если просто сделать приложение, то это заняло две недели. WinRT версия заняла столько же времени (я .NET знаю так, для галочки).
Так или иначе вы проектируете интерфейс (не рандомно же вы кнопки по форме раскидываете). При полном цикле сначала проект интерфейса делается, а потом сам интерфейс програмится. При подходе без изначального проектирования вы проектируете интерфейс по ходу разработки. Шило на мыло. Это не ускоряет процесс. Даже замедляет, поскольку
1. Вы отвлекаетесь от програминга на обдумывание интерфейса.
2. Часто делаете ненужную работу: запрограмили кнопку, а потом она оказалась не нужна.
3. Не видя общую картину сложно спланировать архитектуру кода.
Хотя, возможно, некоторым так интереснее работать. Когда сам работаешь, то документация излишня, но это не отменяет необходимость какого-то первоначального проектирования интерфейса на листочке. Даже если есть документация, то это не отменяет того, что некоторые вещи нужно решать походу.
100 в день, 3 в месяц стоит прогер-джуниор в Москве. Нужен дизайнер и тот, кто занимается продвижением.
Считаем по минимуму.
Допустим вы сами программингом занимаетесь и продвижением, дизайнера и художника вы наняли фрилансеров. Минимум по графике у вас бы вышло 3 тыс затрат на приложение. Каждое приложение вы разрабатывали по 3 месяца. Допустим вы средний программист и в офисе могли бы получать 5тыс.
В итоге у вас 18тыс затрат на приложение (включая альтернативные).
Допустим 3 приложения вы выпустили у вас 54 затрат.
Оборот по одному приложению 3тыс (если выбрать довольно оптимистический период в графике). Минус комиссия Apple (30% если не ошибаюсь) и коммисии за перевод. (про налоги забудем). В итоге получается 2тыс.
А прибыть 2*3=6 — 5(альтернативные затраты)=1 (почти убыточное предприятие в экономическом смысле).
В итоге получаем 54 месяца на возврат инвестиций и куча рисков.
Вы путаете простое среднее и средневзвешенное (1 частный случай второго)
Средневзвешенное может учитывать число голосов. Например, (sqrt(N)*p/N + 0.5)/(sqrt(N)+1).
Чем больше N тем больше значимость оценок. sqrt(N) — функция взвешивания (сглаживания), 0.5 — с чем мы взвешиваем (средняя оценка).
Единственное что в бинарном рейтинге нам говорит об этом это число голосов. Если взять любую функцию возрастающую с N и использовать как коэффициент при среднем взвешивании, то мы получим учет достоверности.
Константа осталась одна. Она приобрела смысл (чем больше тем сильнее сглаживание). И стала безопасной — при любом ее значении большем нуля значение будет между 0.5 и p/N.
У поисковиков есть автобалансировка коэффициентов в формулах (матрикс.нет у Яши) и сотни тысяч оценок ассесоров, чтобы это сбалансировать.
Вероятность физична как и прогноз. Они несут явный смысл. Есть смысл сортировать фильмы по вероятности того, что они понравятся пользователю. Смысла ранжировать по «нижнему пределу доверительного интервала бета-распределения с коэффициентом значимости 0.95» нет никакого.
Вы сейчас скажите, что он выражает пессимистичный прогноз вероятности того, что фильм понравиться пользователю.
А почему сортировать по пессимистичному прогнозу? Почему не по обычному прогнозу, который можно получить взвесив среднюю оценку по статье со средней по сайту?
ЦПТ действует только на бесконечности. На практике можно ее применять к большим числам. Однако, мы рассматриваем маленькие числа (если бы число голосов было бы большим, то каким-то образом балансировать рейтинг не нужно). Для биномиального распределения есть отдельные функции.
Бета и нормальное разные распределения, то что стандартное нормальное распределения частный случай бета не говорит о том, что нормальное частные случай бета, как и то что бета частный нормального. И бета и нормальное двупараметрические кривые, они не могут быть частными случаями друг-друга (разве что эквивалентами, но область значений у них разная).
P.S. Биномиальное распределение характеризуется одним параметром P, откуда у вас второй параметр взялся для бета непонятно.
Случайных чисел тоже нет это мат. абстракция (ну кроме квантовой механики). Мы считаем число случайным, поскольку нам что-то не известно. Например, угловая скорость и скорость центра тяжести монеты и расстояние до пола в противном случае для нас Орел/Решка не было бы случайным событием.
Если мы могли считать мысли каждого пользователя, который проголосует за фильм, то для нас голосование не было бы случайным. Но поскольку мы не знаем кто проголосует и как до голосования для нас это случайные величины.
С другой стороны все реальные события и числа случайны: на событие может повлиять бесконечное множество факторов, которые учесть все мы не в состоянии. Квантовая механика говорит, что все априори случайно и дело ни в недостатке информации или вычислительных способностей.
2. Если трупней меньше, то они и срежутся в основном.
У вас число положительных(positive) и отрицательных голосов(negative). И сразу вы строите на ним бета функцию с параметрами 1+p и 1+n.
В теории, бета функция в вашем случае должна выражать прогноз оценок которые бы поставили пользователи если бы могли поставить любую оценку от 0 до 1. Это единственный ее физический смысл, который может у нее быть в этом контексте. Однако непонятно зачем сводить задачу бинарного рейтинга к рейтингу с бесконечной дискретностью.
Мат. ожидание у вас получилось (1+p)/(1+p + 1+n) т.е. вы просто по 1це прибавили к обоим оценкам, тем самым сгладив оценки с 0.5.
По большому счету эта формула ничто иное как частный случай среднего арифметического взвешивания средней оценки конкретного фильма с 0.5. Коэффициенты при этом 2 и N(=n+p) общее число голосов:
(1+p)/(2+p +n)=(2* 0.5 + N*p / N)/(2 + N)
Из второй формулы можно зная среднюю оценку фильмов (она не обязательно равна 0.5) можно посчитать первые слагаемые параметров бета функции. Выбрав вместо двойки другую константу сглаживания. Вот в итоге мы сводим задачу к одной константе.
Опять таки, вы предлагаете упорядочивать фильмы по минимально возможной оценке. Это во-первых не физично (минимум доверительного интервала это мат. абстракция). Во-вторых он сильно зависит от точности. 95% и 90% даст огромную разницу. Мы получим еще один коэффициент. В третьих почему-бы не использовать бинарное распределение вместо бета-функций и считать их доверительные интервалы.
Интересно было бы если бы вы рассмотрели не бинарные шкалы, а «5 звезд» или от 1 до 10. Построили общую бета-функцию и с помощью нее, сравнивая с частной шкалой, снизили бы влияние накруток.
Если, конечно, программистов больше 1го (если 1 программист то непонятно зачем PM нужен).
Если последнее слово было бы больше чем за одним человеком, то проект не был бы целостным в плане дизайна (в английском смысле этого слова).
Тоже самое было бы если бы актеры и операторы при съемке фильма бы сами выбирали сцены и диалоги, а не слушались бы режиссера. Некоторая свобода у актеров есть, но последнее слово должно оставаться за одним человеком.
Ну не всегда, когда работаешь сам на себя бывает желание ничего не делать пару недель. Отмазываешься перед собой, что ты не в настроении или прочее. Когда на кого-то или на тебя другие ты чувствуешь ответственность.
Ну заказчики или руководители бывают неадекватные. Но, обычно, руководители адекватные и способны разобраться какому прогеру нравиться детальное ТЗ, чтобы меньше думать, а кому-то нужны белые пятна и возможности для полета фантазии.
про резюме и про фан согласен.
Так или иначе вы проектируете интерфейс (не рандомно же вы кнопки по форме раскидываете). При полном цикле сначала проект интерфейса делается, а потом сам интерфейс програмится. При подходе без изначального проектирования вы проектируете интерфейс по ходу разработки. Шило на мыло. Это не ускоряет процесс. Даже замедляет, поскольку
1. Вы отвлекаетесь от програминга на обдумывание интерфейса.
2. Часто делаете ненужную работу: запрограмили кнопку, а потом она оказалась не нужна.
3. Не видя общую картину сложно спланировать архитектуру кода.
Хотя, возможно, некоторым так интереснее работать. Когда сам работаешь, то документация излишня, но это не отменяет необходимость какого-то первоначального проектирования интерфейса на листочке. Даже если есть документация, то это не отменяет того, что некоторые вещи нужно решать походу.
2 недели полный цикл до первой публичной версии? Концепт, проектирование интерфейса, программинг и дизайн, отладка сильно мало.
По числу приложений сколько вы сможете одновременно поддерживать (апдейты, продвижение, суппорт)?
Считаем по минимуму.
Допустим вы сами программингом занимаетесь и продвижением, дизайнера и художника вы наняли фрилансеров. Минимум по графике у вас бы вышло 3 тыс затрат на приложение. Каждое приложение вы разрабатывали по 3 месяца. Допустим вы средний программист и в офисе могли бы получать 5тыс.
В итоге у вас 18тыс затрат на приложение (включая альтернативные).
Допустим 3 приложения вы выпустили у вас 54 затрат.
Оборот по одному приложению 3тыс (если выбрать довольно оптимистический период в графике). Минус комиссия Apple (30% если не ошибаюсь) и коммисии за перевод. (про налоги забудем). В итоге получается 2тыс.
А прибыть 2*3=6 — 5(альтернативные затраты)=1 (почти убыточное предприятие в экономическом смысле).
В итоге получаем 54 месяца на возврат инвестиций и куча рисков.
Не слишком ли много мороки, чтобы сотку в день делать?
Если я правильно понял.
2% * 2000 * 3$= 120$ в день оборота.
Не слишком ли много гембеля, чтобы сотку в день делать?