Параметры по умолчанию инициализируются один раз в момент инициализации функции. Поэтому с мутабельными объектами (вроде списков) в качестве дефолтных параметров и получается вот такая беда. И как уже выше написали, у многих начинающих с этим проблемы, т.к. поведение действительно очень неочевидное, если знаком с питоном поверхностно.
Собственно, решение простое — использовать immutable значения в качестве параметров по умолчанию. Как правило используют None с последующей инициализацией в теле функции:
def my_func(my_arg=None):
if my_arg is None:
my_arg = []
...
В некоторых случаях также можно использовать пустой кортеж, он во многом аналогичен пустому списку. Но тут уже зависит от самой функции.
>>> a = [-10, -10]
>>> a[0] is a[1]
True
>>> b = [-10]
>>> b.append(-10)
>>> b[0] is b[1]
False
>>> b[0] is a[0]
False
Причина — в оптимизациях. В интерактивном режиме единицей трансляции является строка. Соответственно, интерпретатор выполняет (и оптимизирует) каждую строку независимо от других. Если в этой одной строчке несколько раз используется одна и та же константа, то оптимизатор способен это заметить и создать единственный объект этой константы под нужды всей строки. Если же одна и та же константа используется в нескольких строках, то интерпретатор уже не в силах оптимизировать такой вариант.
К слову, если код выше поместить в файл и выполнить его, то вывод станет
True
True
True
Потому что в этом случае единицей трансляции будет уже весь файл и оптимизатор сможет использовать один объект для константы "-10" в рамках всего файла, а не только строки.
\1 — это первая группа, а не строка "\1" буквально. Т.е. регулярка "P+(..)\1.*" означает:
1) один или больше симоволов "P", затем
2) два произвольных символа, затем
3) снова те-же 2 символа из пункта 2, затем
4) любое количество произвольных символов.
Надо в интерпретаторе запускать. Там код построчно выполняется и оптимизируется, соответственно, только одна строчка за раз. Если в виде .py файла запускать, то оптимизирован будет весь файл и тогда уже все 4 переменные будут указывать в одно место.
В разделе «Графический контент» большая часть советов в лучшем случае бессмысленны, а некоторые даже вредны.
Во-первых, для устройств с iOS 9 и выше работает App slicing. iTunes Connect пересобирает загруженный архив в несколько вариантов для разных устройств. Таким образом, например, iPhone 6 при установке из апп стора будет тянуть только @2x ресурсы, а iPad mini 1 — только @1x. Поэтому если продукт поддерживает iOS 9+, то прислушивание к совету об оставлении только 3x ресурсов будет иметь строго обратный эффект — для айфонов+ ничего не изменится, а вот устройства с меньшим разрешением будут вынуждены тянуть себе 3x ресурсы, тогда как могли обойтись 2x или 1x.
Во-вторых — совет о переводе растровых изображений в вектор также не имеет смысла. Единственное, что вы таким образом можете сэкономить — это место на компьютере разработчиков. Xcode растеризирует векторные изображения при сборке билда, в чем несложно убедиться, к примеру, отмасштабировав «векторную» картинку на устройстве и увидев дико пикселизированное растровое изображение. Я не спорю, векторные ресурсы — это удобно: проще экспортировать дизайнерам, не нужно следить чтобы при изменении ресурса остались «синхронизированными» все его версии разных разрешений и т.п. Но перевод существующих растровых картинок в вектор именно с целью уменьшения размера билда не имеет никакого смысла.
Да, если приложение выпускается для старых версий iOS, а вектор — это не pdf-ки, кинутые в asset catalog, а формат, который парсится и отрисовуется своими силами и своим кодом, то да, эти советы могут быть полезными. Но в статье об этих «границах применимости» ни слова.
Я немного не о том. Внутри своего фрейма — да, текст отзеркаливался всегда.Но если этот фрейм расположен, скажем, в левой половине экрана, то надпись остается слева и на арабском и на английском. И в результате визуально разметка «плывет» — появляются дырки пустого пространства в неожиданных местах, текст выравнивается криво и т.п.
Если же верстать с автолейаутом по феншую, то помимо авто-разворота самого текста в надписях, также автоматически будут меняться фреймы вьюшек. И вьюха, расположенная в английской локали слева, на иврите будет расположена справа (при чем, это не только для надписей работает). Намного меньше усилий в таком случае затрачивается на то, чтобы все выглядело хорошо независимо от направления письма. Единственная оставшаяся проблема, требующая особого внимания — это выравнивание текста, но и ее в большинстве случаев можно решить просто поставив выравнивание NSTextAlignmentNatural.
С недавних пор никаких проблем с RTL языками нет. Если интерфейс верстался с autolayout-ом и использованием Leading/Trailing constraints, то все будет работать из коробки — достаточно просто добавить файлы с переводами в точности как для европейских языков. Интерфейс будет отзеркаливаться автоматически.
Какие-то добрые люди подняли за комментарии, очевидно.
Выше уже ответили, что карму таким как я можно поднимать только до определенного предела (только не до 3, а до 4)
Read&Comment — тип аккаунта, обозначающий, что у вас уже есть как минимум один опубликованный комментарий. Профиль пользователя выглядит как и у полноценного аккаунта — есть рейтинг и карма, за которую другие пользователи могут голосовать с некоторым ограничением: карма пользователя не имеющего публикации на сайте не может подняться выше +4. Появляется возможность писать личные сообщения другим участникам сообщества.
Комментарии начинают появляться на сайте сразу, без модерации, как только пользователь получает 10 одобрений от 10 разных авторов или модераторов.
Голосование на данном этапе еще не доступно, а публикации по-прежнему можно публиковать только в Песочницу.
Да, read-only разрешили писать комментарии, но публикуются эти комментарии после модерации автором поста (при чем, после одобрения хотя-бы одного коммента пометка read-only у аккаунта убирается). И голосовать read-only аккаунты не могут (даже после исчезновения пометки).
Для архитектуры Pascal (на которой построена 10 серия) дров нет. И не факт, что когда-нибудь появятся, т.к. Эппл переключился на AMD карты. То есть, кроме как на хакинтошах карты десятой серии нигде использоваться не могут и, соответственно, ни Эпплу ни НВидии нет смысла пилить дрова. Такие дела.
Отвечая на вопрос: карточки 10 серии просто не заведутся. А в остальном — проблем никаких :)
Точнее, не то чтоб совсем не завелись — картинка будет и даже разрешение родное можно будет поставить. Но граф. ускорение работать не будет, т.е. рендеринг будет силами CPU, а значит будут дичайшие тормоза даже при банальном перетягивании статического окна. Не говоря уже о том, чтобы какие-то анимации показывать. Интернет будет абсолютно неюзабельным, т.к. перерисовка экрана может занимать вплоть до нескольких секунд, а многие сайты любят себя перерисовывать довольно часто.
а конкретные цифры (1/3 или 2/3) всё равно ничего особо не решат для данного конкретного игрока.
Представьте ситуацию: есть 2 стула стола, на которых стоят непрозрачные коробки. На одном столе 2, на втором — 100. При этом, в одной коробке на каждом столе лежит по 1000 долларов, а остальные — пустые. У вас есть возможность показать пальцем одну любую коробку и забрать ее со всем содержимым. С какого стола будете брать?
Следуя вашей логике, конкретные цифры (1/2 или 1/100) тут тоже ничего особо не решат для данного конкретного игрока. Так как
это стопроцентная угадайка, и подсказок, в какой коробке деньги, так и нет. Так что во всех случаях выбор будет случайным.
Тесты — это где группа одних и тех же людей участвует в этой ситуации многократно (они вроде как не обучаются и процент их побед ниже, чем у голубей).
Игра — это каждый раз новый человек участвует и у него нет возможности обучаться.
А как, простите, обучение человека на выбор одной из нескольких стратегий (в данном случае — одной из двух — менять либо не менять) влияет на эффективность этих стратегий?
основная проблема не понимания (у тех кто не понимает почему шанс выиграть при смене двери 2 к 3) в том, что рассматривается одна конкретная ситуация, а не последовательность ситуаций.
Опять таки, какая разница, сколько ситуаций рассматривается? По вашему, для одного эксперимента вероятность одна, а для нескольких (независимых друг от друга) — другая?
Ниже (почти в конце) Caullerd привел статистику смены выбора двери и без смены, она очень наглядно показывает где шансы больше.
Да, и там наглядно видно, что при смене двери вероятность победы в 2 раза выше. И там никакого обучения не происходит. Первая программа всегда меняет дверь, вторая — никогда не меняет. И ни одна из них ничему не учится в процессе. То есть, если я правильно вас понял, программы Caullerd'а подходят под ваше определение «игры, а не тестов». Как, кстати, и почти все прочие симуляции этой задачи.
какого козла ведущий откроет — первого или второго?
Конкретный козел действительно не важен. Значение имеет количество дверей, доступных ведущему для открытия. «Запрещая» ему открывать одну из них (выбрав ее) игрок получает преимущество по сравнению с ситуацией, где такого запрета нет.
т.е. первоначальный выбор не изменяет ничего, дверь с козлом будет открыта все равно, второй выбор (ткнуить снова в ту же дверь или в другую) ничего не меняет…
Меняет. И я описал в предыдущем комментарии, как именно меняет.
убрав одного из козлов, это ведущий изменил условия задачи, сравняв вероятности машины для обеих оставшихся дверей
В вашей задаче, где ведущий может открыть любую дверь — да, сравнял. В исходной задаче, где он не может открыть выбранную дверь — нет, там вероятности 33/66.
в случае команды игроков и многократных повторов, без обмана — все так, что не отменяет всего выше описанного для каждого конкретного игрока...
То есть вы хотите сказать, что для одного отдельного игрока вероятность 50/50, но если таких отдельных игроков взять много, то для них она будет 33/66?
П.С. еще из соседней ветки
И это кстати также видно на той же картинке из википедии — из 6-и человек 3-м досталась машина и 3-м — коза.
Если вы внимательно посмотрите на картинку, то заметите, что из этих 6 человек 3 меняли свой выбор, а 3 — не меняли. Так что совсем не удивительно, что в результате у троих есть машина, а у троих нет: 1/3 (вероятность выиграть, не меняя дверь) * 3 (не меняли свой выбор 3 человека) + 2/3 (вероятность выиграть, меняя дверь) * 3 (меняли свой выбор тоже 3 человека) = 1/3 * 3 + 2/3 * 3 = 3.
Если бы все 6 человек не меняли дверь, то победителей было бы 4, а не 3.
Изменилась постановка задачи. Теперь ведущий может открыть любую из дверей с козлами и вероятность выбрать после этого дверь с призом действительно становится 50%.
В исходной же задаче ведущий не может открыть ту дверь, которую выбрал игрок. Таким образом, если игрок изначально выбрал дверь с козлом (а вероятность этого — 2/3, кстати, с этим вы согласны или тут, по вашему, тоже 50 на 50?), то у ведущего нет выбора — он может открыть только одну единственную дверь с козлом. А за второй дверью будет приз, который и получит игрок, если поменяет свой выбор. Если же изначально была выбрана дверь с призом (а вероятность этого события — 1/3), то ведущий может выбрать, какую из оставшихся дверей открыть. И в обоих случаях игрок проиграет при смене своего выбора.
Путем совсем несложных подсчетов, можем теперь получить и общую вероятность выигрыша при смене двери:
2/3 (вероятность выбора козла изначально) * 1 (вероятность того, что после открытия двери ведущим за второй дверью будет приз) + 1/3 (вероятность выбора приза) * 0 (все та-же вероятность того, что после открытия двери ведущим за второй дверью будет приз) = 2/3 * 1 + 1/3 * 0 = 2/3
Для вашей же задачи, где мы дверь изначально не выбираем, а только после открытия ведущим одного из козлов, мы имеем вероятность 1/2, потому как просто выбираем уже из двух дверей и выбор игрока никак не ограничивает свободу действий ведущего.
Параметры по умолчанию инициализируются один раз в момент инициализации функции. Поэтому с мутабельными объектами (вроде списков) в качестве дефолтных параметров и получается вот такая беда. И как уже выше написали, у многих начинающих с этим проблемы, т.к. поведение действительно очень неочевидное, если знаком с питоном поверхностно.
Собственно, решение простое — использовать immutable значения в качестве параметров по умолчанию. Как правило используют None с последующей инициализацией в теле функции:
В некоторых случаях также можно использовать пустой кортеж, он во многом аналогичен пустому списку. Но тут уже зависит от самой функции.
Конечно, с этим сложно поспорить. Просто немного прояснил природу явления для тех, кому интересно.
Касательно Python.
Причина — в оптимизациях. В интерактивном режиме единицей трансляции является строка. Соответственно, интерпретатор выполняет (и оптимизирует) каждую строку независимо от других. Если в этой одной строчке несколько раз используется одна и та же константа, то оптимизатор способен это заметить и создать единственный объект этой константы под нужды всей строки. Если же одна и та же константа используется в нескольких строках, то интерпретатор уже не в силах оптимизировать такой вариант.
К слову, если код выше поместить в файл и выполнить его, то вывод станет
Потому что в этом случае единицей трансляции будет уже весь файл и оптимизатор сможет использовать один объект для константы "-10" в рамках всего файла, а не только строки.
\1 — это первая группа, а не строка "\1" буквально. Т.е. регулярка "P+(..)\1.*" означает:
1) один или больше симоволов "P", затем
2) два произвольных символа, затем
3) снова те-же 2 символа из пункта 2, затем
4) любое количество произвольных символов.
Надо в интерпретаторе запускать. Там код построчно выполняется и оптимизируется, соответственно, только одна строчка за раз. Если в виде .py файла запускать, то оптимизирован будет весь файл и тогда уже все 4 переменные будут указывать в одно место.
Во-первых, для устройств с iOS 9 и выше работает App slicing. iTunes Connect пересобирает загруженный архив в несколько вариантов для разных устройств. Таким образом, например, iPhone 6 при установке из апп стора будет тянуть только @2x ресурсы, а iPad mini 1 — только @1x. Поэтому если продукт поддерживает iOS 9+, то прислушивание к совету об оставлении только 3x ресурсов будет иметь строго обратный эффект — для айфонов+ ничего не изменится, а вот устройства с меньшим разрешением будут вынуждены тянуть себе 3x ресурсы, тогда как могли обойтись 2x или 1x.
Во-вторых — совет о переводе растровых изображений в вектор также не имеет смысла. Единственное, что вы таким образом можете сэкономить — это место на компьютере разработчиков. Xcode растеризирует векторные изображения при сборке билда, в чем несложно убедиться, к примеру, отмасштабировав «векторную» картинку на устройстве и увидев дико пикселизированное растровое изображение. Я не спорю, векторные ресурсы — это удобно: проще экспортировать дизайнерам, не нужно следить чтобы при изменении ресурса остались «синхронизированными» все его версии разных разрешений и т.п. Но перевод существующих растровых картинок в вектор именно с целью уменьшения размера билда не имеет никакого смысла.
Да, если приложение выпускается для старых версий iOS, а вектор — это не pdf-ки, кинутые в asset catalog, а формат, который парсится и отрисовуется своими силами и своим кодом, то да, эти советы могут быть полезными. Но в статье об этих «границах применимости» ни слова.
То есть на вопрос
«Продолжите последовательность 2, 4, 8, 16, ?, ?»
надо отвечать 30, 52?
Именно эти числа дает полином наименьшей возможной степени:
x^3/3-x^2+8x/3
Если же верстать с автолейаутом по феншую, то помимо авто-разворота самого текста в надписях, также автоматически будут меняться фреймы вьюшек. И вьюха, расположенная в английской локали слева, на иврите будет расположена справа (при чем, это не только для надписей работает). Намного меньше усилий в таком случае затрачивается на то, чтобы все выглядело хорошо независимо от направления письма. Единственная оставшаяся проблема, требующая особого внимания — это выравнивание текста, но и ее в большинстве случаев можно решить просто поставив выравнивание NSTextAlignmentNatural.
Выше уже ответили, что карму таким как я можно поднимать только до определенного предела (только не до 3, а до 4)
Собственно, в правилах это все подробно описано:
Отвечая на вопрос: карточки 10 серии просто не заведутся. А в остальном — проблем никаких :)
Точнее, не то чтоб совсем не завелись — картинка будет и даже разрешение родное можно будет поставить. Но граф. ускорение работать не будет, т.е. рендеринг будет силами CPU, а значит будут дичайшие тормоза даже при банальном перетягивании статического окна. Не говоря уже о том, чтобы какие-то анимации показывать. Интернет будет абсолютно неюзабельным, т.к. перерисовка экрана может занимать вплоть до нескольких секунд, а многие сайты любят себя перерисовывать довольно часто.
Тот комментарий писался в такое время, когда комментарии писать уже не стоило)
Представьте ситуацию: есть 2
стуластола, на которых стоят непрозрачные коробки. На одном столе 2, на втором — 100. При этом, в одной коробке на каждом столе лежит по 1000 долларов, а остальные — пустые. У вас есть возможность показать пальцем одну любую коробку и забрать ее со всем содержимым. С какого стола будете брать?Следуя вашей логике, конкретные цифры (1/2 или 1/100) тут тоже ничего особо не решат для данного конкретного игрока. Так как
А как, простите, обучение человека на выбор одной из нескольких стратегий (в данном случае — одной из двух — менять либо не менять) влияет на эффективность этих стратегий?
Опять таки, какая разница, сколько ситуаций рассматривается? По вашему, для одного эксперимента вероятность одна, а для нескольких (независимых друг от друга) — другая?
Да, и там наглядно видно, что при смене двери вероятность победы в 2 раза выше. И там никакого обучения не происходит. Первая программа всегда меняет дверь, вторая — никогда не меняет. И ни одна из них ничему не учится в процессе. То есть, если я правильно вас понял, программы Caullerd'а подходят под ваше определение «игры, а не тестов». Как, кстати, и почти все прочие симуляции этой задачи.
Конкретный козел действительно не важен. Значение имеет количество дверей, доступных ведущему для открытия. «Запрещая» ему открывать одну из них (выбрав ее) игрок получает преимущество по сравнению с ситуацией, где такого запрета нет.
Меняет. И я описал в предыдущем комментарии, как именно меняет.
В вашей задаче, где ведущий может открыть любую дверь — да, сравнял. В исходной задаче, где он не может открыть выбранную дверь — нет, там вероятности 33/66.
То есть вы хотите сказать, что для одного отдельного игрока вероятность 50/50, но если таких отдельных игроков взять много, то для них она будет 33/66?
П.С. еще из соседней ветки
Если вы внимательно посмотрите на картинку, то заметите, что из этих 6 человек 3 меняли свой выбор, а 3 — не меняли. Так что совсем не удивительно, что в результате у троих есть машина, а у троих нет: 1/3 (вероятность выиграть, не меняя дверь) * 3 (не меняли свой выбор 3 человека) + 2/3 (вероятность выиграть, меняя дверь) * 3 (меняли свой выбор тоже 3 человека) = 1/3 * 3 + 2/3 * 3 = 3.
Если бы все 6 человек не меняли дверь, то победителей было бы 4, а не 3.
Изменилась постановка задачи. Теперь ведущий может открыть любую из дверей с козлами и вероятность выбрать после этого дверь с призом действительно становится 50%.
В исходной же задаче ведущий не может открыть ту дверь, которую выбрал игрок. Таким образом, если игрок изначально выбрал дверь с козлом (а вероятность этого — 2/3, кстати, с этим вы согласны или тут, по вашему, тоже 50 на 50?), то у ведущего нет выбора — он может открыть только одну единственную дверь с козлом. А за второй дверью будет приз, который и получит игрок, если поменяет свой выбор. Если же изначально была выбрана дверь с призом (а вероятность этого события — 1/3), то ведущий может выбрать, какую из оставшихся дверей открыть. И в обоих случаях игрок проиграет при смене своего выбора.
Путем совсем несложных подсчетов, можем теперь получить и общую вероятность выигрыша при смене двери:
2/3 (вероятность выбора козла изначально) * 1 (вероятность того, что после открытия двери ведущим за второй дверью будет приз) + 1/3 (вероятность выбора приза) * 0 (все та-же вероятность того, что после открытия двери ведущим за второй дверью будет приз) = 2/3 * 1 + 1/3 * 0 = 2/3
Для вашей же задачи, где мы дверь изначально не выбираем, а только после открытия ведущим одного из козлов, мы имеем вероятность 1/2, потому как просто выбираем уже из двух дверей и выбор игрока никак не ограничивает свободу действий ведущего.
Т.е. ход игры такой:
1) Игрок выбирает дверь
2) Ведущий открывает одну из оставшихся дверей, за которой нет приза
3) Участник либо меняет дверь, либо не меняет
Все. Если за выбранной дверью приз — игрок выиграл. Если козел — проиграл.