В статистике гистограмма — это функция плотности распределения. Но иногда под этим словом понимают просто столбчатую диаграмму. Именно так слово «гистограмма» переводится с греческого.
1) «Код 1217 — тоже валидный, а вот 1218 — нет.» — чуть поторопился. Правильно «Код 1216 — тоже валидный, а вот 1218 — нет.»
2) Описанный способ стал стандартом вычисления контрольной суммы EAN13 за небольшими правками: число цифр стало фиксированным и равно 13, где 13-ая — это та самая контрольная цифры. Цифры на нечетных местах считаются трижды, на четных — один раз.
Интересна история контрольной цифры. Она возникла эволюционно.
Контрольная цифра нужна для того, чтобы избежать неправильного декодирования. Если штрихкод был 1234, а его распознали как 7234, то нужна валидация, которая предупредит замену 1 на 7. Валидация может быть неточная, чтобы хотя бы в 90% невалидные номера определялись заранее.
1-й подход: Давайте просто возьмем сумму. Чтобы в остатке от деления на 10 был 0. Ну то есть первые 12 символов несут информационную нагрузку, а последняя цифры подбирается так, чтобы сумма цифр делилась на 10. Декодируем последовательность, если сумма не делится на десять — значит декодировали с багом и нужно сделать это еще раз. Например, код 1234 — валидный. 1+2+3+4 = 10. Код 1217 — тоже валидный, а вот 1218 — нет.
Это позволяет избежать проблем с автоматикой. Однако в момент создания штрихкодов был фоллбек в виде набивания номер на клавишах. И там есть плохой кейс: если поменять порядок следования двух цифр, то контрольная сумма не меняется, и это плохо. То есть если штрихкод 1234 был вбит как 2134, контрольная сумма сойдется, а вот номер мы вбили неправильный. Оказывается, неправильный порядок цифр — это распространенный кейс, если стучать по клавишам быстро.
2-й подход. Хорошо, давайте сумму сделаем чуть сложнее. Чтобы цифры на четных местах учитывались дважды. Тогда при изменении порядка, сумма точно не сойдется к нужной. Например код 2364 валидный (2 + 3+3 + 6 + 4+4 = 20), а код 3264 — невалидный (3+ 2+2 + 6 + 4+4 = 19). Но тут оказался еще один плохой пример вбития. Некоторые клавиатуры такие, что десять цифр располагаются в два ряда. первый ряд 12345 и под ним второй второй ряд 67890. Если вместо клавишы «1» нажать правее клавишу «2», то контрольная сумма предупредит неправильный ввод. А вот если вместо клавишу «1» нажать ниже клавишу «6» — то может не предупредить. Ведь 6=1+5, и в случае когда эта цифра стоит на четном месте при вычислении контрольной суммы, мы имеем 2*6 = 2*1 + 2*5. То есть контрольная сумму увеличилась ровно на 10, поэтому ее последняя цифра не изменилась. Например контрольные суммы кодв 2134 и 2634 одинаковые. Та же ошибка будет, если мы вместо 2 нажмем 7, вместо 3 нажмем 8 и тд.
3-й подход. Ок, давайте что ли возьмем опять сумму, только цифры, стоящие на четных местах будем учитывать… трижды. То есть код 1234565 — валидный, потому как 1 + 2*3 + 3 + 4*3 + 5 + 6*3 +5 = 50.
В задаче нет никаких размеров торта.
Из данных есть только ответы на вопрос «доволен ли участник текущим разбиением, или нет?», которые можно задавать в любой момент времени любому из участников.
Придти нужно к такому состоянию, когда все участники отвечают положительно на этот вопрос.
Проблема статистики, как и любого другого формального подхода в интерпретации.
Это проблема не только статистики. В том числе тезиса «Есть три вида лжи: ложь, наглая ложь и статистика», открывшего эту дискуссию. Недобросовестный человек с помощью него может обмануть значительно больше людей чем просто лжец.
Не стоит так переоценивать angular2. Это не более чем еще один js фреймворк, коих сейчас очень много. То, что в его названии есть слово angular я воспринимаю просто как маркетинговый ход. Каким бы плохим не был angular1, ему удалось создать вокруг себя сообщество, а это куда важнее «академической правильности», новизны, или даже отсутствия багов.
Про переезд python 2->3 в 2008-м тоже говорили «Да пару лет, и все забудут про вторую версию».
Но сообщество языка/фреймворко обычно гораздо более инертно, нежели работа авторов. И вот сейчас уже 2015, а нового продакшн-кода под python2 создается раза в 2 больше, чем под python3.
Generator expressions and list comprehensions.
List comprehension удобнее тем, что фильтрацию удобно вставлять
Также
generator-comprehensiongenerator-expression можно делать подобным образом.1) «Код 1217 — тоже валидный, а вот 1218 — нет.» — чуть поторопился. Правильно «Код 1216 — тоже валидный, а вот 1218 — нет.»
2) Описанный способ стал стандартом вычисления контрольной суммы EAN13 за небольшими правками: число цифр стало фиксированным и равно 13, где 13-ая — это та самая контрольная цифры. Цифры на нечетных местах считаются трижды, на четных — один раз.
Контрольная цифра нужна для того, чтобы избежать неправильного декодирования. Если штрихкод был 1234, а его распознали как 7234, то нужна валидация, которая предупредит замену 1 на 7. Валидация может быть неточная, чтобы хотя бы в 90% невалидные номера определялись заранее.
1-й подход: Давайте просто возьмем сумму. Чтобы в остатке от деления на 10 был 0. Ну то есть первые 12 символов несут информационную нагрузку, а последняя цифры подбирается так, чтобы сумма цифр делилась на 10. Декодируем последовательность, если сумма не делится на десять — значит декодировали с багом и нужно сделать это еще раз. Например, код 1234 — валидный. 1+2+3+4 = 10. Код 1217 — тоже валидный, а вот 1218 — нет.
Это позволяет избежать проблем с автоматикой. Однако в момент создания штрихкодов был фоллбек в виде набивания номер на клавишах. И там есть плохой кейс: если поменять порядок следования двух цифр, то контрольная сумма не меняется, и это плохо. То есть если штрихкод 1234 был вбит как 2134, контрольная сумма сойдется, а вот номер мы вбили неправильный. Оказывается, неправильный порядок цифр — это распространенный кейс, если стучать по клавишам быстро.
2-й подход. Хорошо, давайте сумму сделаем чуть сложнее. Чтобы цифры на четных местах учитывались дважды. Тогда при изменении порядка, сумма точно не сойдется к нужной. Например код 2364 валидный (2 + 3+3 + 6 + 4+4 = 20), а код 3264 — невалидный (3+ 2+2 + 6 + 4+4 = 19). Но тут оказался еще один плохой пример вбития. Некоторые клавиатуры такие, что десять цифр располагаются в два ряда. первый ряд 12345 и под ним второй второй ряд 67890. Если вместо клавишы «1» нажать правее клавишу «2», то контрольная сумма предупредит неправильный ввод. А вот если вместо клавишу «1» нажать ниже клавишу «6» — то может не предупредить. Ведь 6=1+5, и в случае когда эта цифра стоит на четном месте при вычислении контрольной суммы, мы имеем 2*6 = 2*1 + 2*5. То есть контрольная сумму увеличилась ровно на 10, поэтому ее последняя цифра не изменилась. Например контрольные суммы кодв 2134 и 2634 одинаковые. Та же ошибка будет, если мы вместо 2 нажмем 7, вместо 3 нажмем 8 и тд.
3-й подход. Ок, давайте что ли возьмем опять сумму, только цифры, стоящие на четных местах будем учитывать… трижды. То есть код 1234565 — валидный, потому как 1 + 2*3 + 3 + 4*3 + 5 + 6*3 +5 = 50.
Из данных есть только ответы на вопрос «доволен ли участник текущим разбиением, или нет?», которые можно задавать в любой момент времени любому из участников.
Придти нужно к такому состоянию, когда все участники отвечают положительно на этот вопрос.
Имхо фраза эта вредней, нежели аргументы в виде ложной статистики, потому как проще в использовании.
Это проблема не только статистики. В том числе тезиса «Есть три вида лжи: ложь, наглая ложь и статистика», открывшего эту дискуссию. Недобросовестный человек с помощью него может обмануть значительно больше людей чем просто лжец.
Вы уже начали пользоваться секретными чатами?
Про переезд python 2->3 в 2008-м тоже говорили «Да пару лет, и все забудут про вторую версию».
Но сообщество языка/фреймворко обычно гораздо более инертно, нежели работа авторов. И вот сейчас уже 2015, а нового продакшн-кода под python2 создается раза в 2 больше, чем под python3.
Посмотрите в сторону almond.js