Так, на уровне идеи:
Можно решить проблему выедания пользователем ресурсов тем, что сделать их платными (за операцию/единицу памяти или за операцию/единицу памяти сверх лимита, и т.п.). При этом платой может быть какой-нибудь внутриигровой ресурс, который пользователями же и будет добываться в игровом мире, эдакое топливо для бота. Что-то по примерной аналогии с gas в Ethereum.
При этом для разработчика такой системы возникнет много интересных задач на подумать, как всё это дело отбалансить, а для игроков потом — как оптимизировать свой код и сколько тактов из него выделить на добычу топлива.
Сочувствую, сталкивался с такой же проблемой, почти один в один. Но несмотря на то, что я знал все ответы (и оригинальный пароль, который точно не менялся, и ответ на секретный вопрос, и дату создания аккаунта), меня всё равно не пускали в аккаунт, потому что обнаружили «подозрительную активность», повода для которой я реально не давал. Скорее всего, их роботы посчитали подозрительным, что я заходил в акк через хром в инкогнито или что-нибудь ещё.
Мне в итоге очень повезло, т.к. акк мне восстановили, но геморроя я поимел изрядно. Восстановить получилось через гуглфорум, вот здесь можно почитать мою историю со всеми деталями, возможно, кому-нибудь поможет в аналогичных ситуациях.
Причём, что любопытно, в этот форум особо-то из справки и шаблонных ответов гугла не попадёшь. Т.е. чтобы найти такую возможность, её нужно искать. Ещё интереснее, если копнуть глубже: «поддержка» этого форума — не работники гугла, а энтузиасты. Как я понял, гугл обещал им какие-то призрачные плюшки за статистику (которую там все активно выпрашивают, копипастя устаревшие инструкции гугла и выпрашивая +1), и вот они там сидят, активничают. Но, если повезёт, там можно встретить и человека, у которого есть реальный доступ к сотрудникам гугла (не роботам). И, опять же, если повезёт, то последние порешают твою проблему.
И это вовсе не парадокс, а образец абсолютно корректного следования всеми уважаемому стандарту IEEE 754.
Числа с плавающей запятой в интерпретации IEEE — вообще не числа. Математика требует ассоциативности от операции их сложения.
Математика не требует. Требуется то, что описано в стандарте. Т.к. это «вообще не числа», то и непротиворечивые правила можно вводить свои, которые, собственно, были введены в стандарте. Притом оно — неплохое приближение действительных чисел «с обеих сторон» в ограниченных условиях. Если на пальцах, то по своей сути оно ближе к сути действительных чисел: как в теории действительных чисел (см. матан) есть неопределённости, бесконечности и всякие стремления к нулю слева, так и в реализации стандарта они есть. Если реально нужны не действительные числа, а рациональные, то нужно использовать готовые/писать свои реализации приближения рациональных, а не натягивать сову.
Похожие особенности есть не только у чисел с плавающей запятой. Встроенные целые числа реализованы не лучше.
Ну потому что это тоже не совсем целые числа, а либо просто их конечное подмножество, либо кольцо вычетов по модулю, либо ещё что-нибудь в зависимости от интерпретации.
Чутье подсказывает, что переполнение даст 0x0000. Однако такой исход не задокументирован ни в одном мировом стандарте. В обработке этой операции все ориентируются на подход C и семейства процессоров x86.
Так получается, что подход C — один из мировых стандартов, где исход задокументирован.
В качестве альтернативных вариантов может получиться 0xFFFF или будет вызвано прерывание, или некий специальный, указывающий на переполнение бит будет сохранен в особом месте.
А это — другие стандарты.
Такие моменты вообще нигде не рассматриваются, и правила обработки подобных операций отличается от языка к языку.
И, собственно, главный вопрос: а как новый язык решит эту проблему? [Здесь комикс про универсальный стандарт]
overflowed 9999
underflowed 0
Что это вообще такое? Если состояния, то, собственно, чем оно лучше NaN и +Inf, когда мы получаем оспариваемое состояние? Если поведение, то чем оно лучше переполнения, когда мы получаем оспариваемое поведение? Да и, собственно, подобные обрезки точности можно просто реализовать на базовых типах в готовых языках, для этого не нужно изобретать ещё один язык, или они даже есть из коробки: тип DECIMAL(N,M) в SQL или currency в некоторых языках.
Разве такие вычисления не будут работать медленнее? Да, будут.
Минус пласт пользователей языка.
Насколько я могу судить, типичный программист 21 века нечасто решает дифференциальные уравнения.
Минус ещё один пласт пользователей языка.
Т.е. в итоге мы получаем ещё один язык 21 века, у которого другой синтаксис, который вводит новые костыли, новые стандарты и правила, но при этом не отказывается от костылей, стандартов и правил 20 века, и реализации на котором медленнее? Можно не надо?
Часть заголовков неправильно отображается в мобильной версии из-за ошибок
в проектировании универсальных компонентов.
МЕТА ДАННЫЕ: SECRETMRKT-578, SECRETMRKT-602
Мне кажется, что тут возникла небольшая ошибка. Коммит — не то, что должно быть сделано, а то, что уже сделано. Что нужно сделать должно быть написано в таске где-то или в требованиях. Как я понял, в этом примере такая информация находится в SECRETMRKT-578, SECRETMRKT-602. Т.е. верный вариант будет
fix(products): поправлена длина строки с ценой
Часть заголовков неправильно отображались в мобильной версии из-за ошибок
в проектировании универсальных компонентов.
МЕТАДАННЫЕ: SECRETMRKT-578, SECRETMRKT-602
И тогда автоформирование Change Log уже взлетит само собой.
UPD: Да, не дочитал. В статье об этом есть в конце. Но мне всё равно кажется это несколько странным.
Подход с шаблонами сразу не прокатит, т.к. нужно знать n именно во время компиляции. А если мы знаем n во время компиляции, то мы просто можем написать
print(n--);
n+1 раз.
Просматривая протоколы собеседований на позицию разработчика, обнаружил такую задачу
Это задачка с искусственными ограничениями (в том плане, что вряд ли они встретятся в реальной задаче компании), поэтому давать её на собеседовании, конечно, можно, но ИМХО только в случае собеседования в клуб извращенцев.
Кстати, вы могли бы этот таск переклассифицировать из баги в фичреквест и не спешить закрывать. Ведь на самом деле ситуация показательная и с другой стороны: лог анализатора не дал трём с половиной программистам понять, что же происходит. Т.е. анализатор умён, спору нет, но мысль свою до людей он не донёс. Может быть, стоит на такие проблемы в логических выражениях выдавать другую ошибку? Какую-нибудь одну, красивую, которая подсветит сереньким цветом выражения, не влияющие на истинность условия, или как-то так? Ведь, насколько я понимаю, вы же всё равно строите деревья разборов этих условий, т.е. самая сложная часть уже есть и отлично работает.
Вот да. Правда, второй вариант не всегда может прокатить, не каждый символ можно так просто добавить в исходник — и в таких случаях я бы рекомендовал завести константы с говорящими именами, типа BIG_LETTER_A или FIRST_BIG_LETTER_EN, а в них уже можно любые коды засовывать, всё равно далее исходник будет читаемым.
А вот третий вариант лично я бы рекомендовал почти всем и всегда. А то и в отдельный метод IsLetterOrDigit.
Ошибку, кстати, нашёл, нарисовав интервалы на прямой, но изначально ожидал от задачи подвох в стиле дефайна скобки в начале файла или чего-то такого.
Абсолютно точно.
То ли в 2014, то ли в 2015 у нас налоговая приняла законы, по которым XML-ины электронной отчётности по размеру стали допустимы до 10гб (вроде бы с изначального «копеечного» лимита 10-100мб), так все решения на DOM'ах очень красиво посыпались, когда пошли клиенты с громадными «контролируемыми сделками» и «книгами для ндс». Потому что DOM одной только памяти жрёт х10 от размера файла, и если раньше (100мб-1гб) на это закрывались глаза, то на 100гб глаза уже не закроешь, не говоря уже о платформе х86.
Делал в те времена в системе электронной отчётности проект по уходу с DOM (легаси было крепко на него завязано, XPath и прочие плюшки активно использовались) на SAX в один пробег, с «эмуляцией» плюшек или обоснованным отказом от них — веселья было много. Теперь в резюме указываю тег XML, а на собеседованиях периодически посмеиваются, мол, что там знать-то, древовидная структура, теги/атрибуты и всё. Так-то оно да, но, как и в физическом мире, когда масса объекта пересекает определённые границы, проявляется много интересных эффектов, о которых даже не думаешь, щупая маленькие объекты.
Хотя, кстати, запамятовал: NP-полная задача — задача какой-либо оптимизации стратегии с известной заранее лентой фигур. И разумное приближение как раз, наверное, будет в том, что состояние стакана в итерации будет фиксировано, а известны будут только текущая и следующая фигуры — т.е. естественные ограничения игры. А все такие комбинации расположения двух фигур можно, думаю, и просто перебрать. Но, всё-таки, рано или поздно ИИ всё равно должен проиграть. arxiv.org/pdf/cs/0210020.pdf
Спасибо, интересно! Любопытно будет почитать вторую часть про алгоритмы бота, который играет в тетрис, потому что в строгом смысле эта задача NP-полная. Подозреваю, что там будет просто разумное приближение с допущениями, и ИИ всё-таки будет в конце концов проигрывать.
Кстати, жалко, что статья об этом NES-тетрисе, а не от Tengen. Лично мне тот сильно больше нравится.
должна была проверять разрешённость именно чтения. Хотя комментарий нам и говорит явно про «read-only», он мог писаться постфактум и быть просто навеян названием константы O_RDONLY. Тут без остального контекста сложно понять. Хотя, конечно, Ваше предположение выглядит проще.
Хм, так причём тут STL? Эдак можно и минимум пытаться с помощью std::sort искать. Виновата не STL и не сортировка, просто в данном случае приоритет отдаётся уже реализованным алгоритмам, а не подходящим для задачи, что есть плохой подход (хотя и не всегда, кстати). По названию статьи подумал, что какой-то стандартный алгоритм над std::set работает хуже, чем велосипед, который будет приведён, хех.
По поводу результативности не скажу, но комментарии к статьям про собеседования в IT — это для меня, пожалуй, самый весёлый из «развлекательного контента» на хабре. Всегда узнаю для себя что-то новое в плане поведения собеседующих и собеседующихся, и всегда есть истории дичь-собеседований из опыта хаброжителей, с которых можно посмеяться. В какой-то мере мне оно помогает потом не относиться к собеседованиям и их результатам серьёзнее, чем они того заслуживают.
Гугл он весь такой. Не удивляйтесь, если внезапно не сможете залогиниться в каком-нибудь из их сервисов из-за «подозрительной активности», которая заключается, например, в том, что вы использовали другой браузер, находитесь в другом месте или сменился динамический IP. Будете при этом читать устаревшие инструкции и доказывать, что не верблюд, исключительно роботам, которые будут отмахиваться шаблонами «извините, нам очень жаль, но мы всё-таки оставим своё решение в силе».
do {} while(false)
А разве нельзя заменить эту конструкцию на просто {}
? Она тоже выполнится ровно один раз и ограничит область видимости. Или это делается для того, чтобы потребовать у пользующего кода точку с запятой в конце?
Сталкивался в легаси с верхним вариантом, он там был, в том числе, чтобы использовать break для выхода из границ.
Из самого запоминающегося: будучи школьником-радиолюбителем проводил какие-то свои безумные эксперименты. Точно не помню, как так вышло, но одной рукой взялся за батарею отопления, а другой за фазу 220 через большой советский электролитический кондёр. Отпустил практически сразу, но до сих пор помню это чувство, когда рука на фазе будто затекла по плечо, но при этом в каждую «мурашку» словно воткнули иглу. Считаю, что очень повезло, т.к. анлокнул тогда все ачивки для того, чтобы откинуться.
Можно решить проблему выедания пользователем ресурсов тем, что сделать их платными (за операцию/единицу памяти или за операцию/единицу памяти сверх лимита, и т.п.). При этом платой может быть какой-нибудь внутриигровой ресурс, который пользователями же и будет добываться в игровом мире, эдакое топливо для бота. Что-то по примерной аналогии с gas в Ethereum.
При этом для разработчика такой системы возникнет много интересных задач на подумать, как всё это дело отбалансить, а для игроков потом — как оптимизировать свой код и сколько тактов из него выделить на добычу топлива.
Мне в итоге очень повезло, т.к. акк мне восстановили, но геморроя я поимел изрядно. Восстановить получилось через гуглфорум, вот здесь можно почитать мою историю со всеми деталями, возможно, кому-нибудь поможет в аналогичных ситуациях.
Причём, что любопытно, в этот форум особо-то из справки и шаблонных ответов гугла не попадёшь. Т.е. чтобы найти такую возможность, её нужно искать. Ещё интереснее, если копнуть глубже: «поддержка» этого форума — не работники гугла, а энтузиасты. Как я понял, гугл обещал им какие-то призрачные плюшки за статистику (которую там все активно выпрашивают, копипастя устаревшие инструкции гугла и выпрашивая +1), и вот они там сидят, активничают. Но, если повезёт, там можно встретить и человека, у которого есть реальный доступ к сотрудникам гугла (не роботам). И, опять же, если повезёт, то последние порешают твою проблему.
Математика не требует. Требуется то, что описано в стандарте. Т.к. это «вообще не числа», то и непротиворечивые правила можно вводить свои, которые, собственно, были введены в стандарте. Притом оно — неплохое приближение действительных чисел «с обеих сторон» в ограниченных условиях. Если на пальцах, то по своей сути оно ближе к сути действительных чисел: как в теории действительных чисел (см. матан) есть неопределённости, бесконечности и всякие стремления к нулю слева, так и в реализации стандарта они есть. Если реально нужны не действительные числа, а рациональные, то нужно использовать готовые/писать свои реализации приближения рациональных, а не натягивать сову.
Ну потому что это тоже не совсем целые числа, а либо просто их конечное подмножество, либо кольцо вычетов по модулю, либо ещё что-нибудь в зависимости от интерпретации.
Так получается, что подход C — один из мировых стандартов, где исход задокументирован.
А это — другие стандарты.
И, собственно, главный вопрос: а как новый язык решит эту проблему? [Здесь комикс про универсальный стандарт]
Что это вообще такое? Если состояния, то, собственно, чем оно лучше NaN и +Inf, когда мы получаем оспариваемое состояние? Если поведение, то чем оно лучше переполнения, когда мы получаем оспариваемое поведение? Да и, собственно, подобные обрезки точности можно просто реализовать на базовых типах в готовых языках, для этого не нужно изобретать ещё один язык, или они даже есть из коробки: тип DECIMAL(N,M) в SQL или currency в некоторых языках.
Минус пласт пользователей языка.
Минус ещё один пласт пользователей языка.
Т.е. в итоге мы получаем ещё один язык 21 века, у которого другой синтаксис, который вводит новые костыли, новые стандарты и правила, но при этом не отказывается от костылей, стандартов и правил 20 века, и реализации на котором медленнее? Можно не надо?
Мне кажется, что тут возникла небольшая ошибка. Коммит — не то, что должно быть сделано, а то, что уже сделано. Что нужно сделать должно быть написано в таске где-то или в требованиях. Как я понял, в этом примере такая информация находится в SECRETMRKT-578, SECRETMRKT-602. Т.е. верный вариант будет
И тогда автоформирование Change Log уже взлетит само собой.
UPD: Да, не дочитал. В статье об этом есть в конце. Но мне всё равно кажется это несколько странным.
Это задачка с искусственными ограничениями (в том плане, что вряд ли они встретятся в реальной задаче компании), поэтому давать её на собеседовании, конечно, можно, но ИМХО только в случае собеседования в клуб извращенцев.
А вот третий вариант лично я бы рекомендовал почти всем и всегда. А то и в отдельный метод IsLetterOrDigit.
Ошибку, кстати, нашёл, нарисовав интервалы на прямой, но изначально ожидал от задачи подвох в стиле дефайна скобки в начале файла или чего-то такого.
То ли в 2014, то ли в 2015 у нас налоговая приняла законы, по которым XML-ины электронной отчётности по размеру стали допустимы до 10гб (вроде бы с изначального «копеечного» лимита 10-100мб), так все решения на DOM'ах очень красиво посыпались, когда пошли клиенты с громадными «контролируемыми сделками» и «книгами для ндс». Потому что DOM одной только памяти жрёт х10 от размера файла, и если раньше (100мб-1гб) на это закрывались глаза, то на 100гб глаза уже не закроешь, не говоря уже о платформе х86.
Делал в те времена в системе электронной отчётности проект по уходу с DOM (легаси было крепко на него завязано, XPath и прочие плюшки активно использовались) на SAX в один пробег, с «эмуляцией» плюшек или обоснованным отказом от них — веселья было много. Теперь в резюме указываю тег XML, а на собеседованиях периодически посмеиваются, мол, что там знать-то, древовидная структура, теги/атрибуты и всё. Так-то оно да, но, как и в физическом мире, когда масса объекта пересекает определённые границы, проявляется много интересных эффектов, о которых даже не думаешь, щупая маленькие объекты.
arxiv.org/pdf/cs/0210020.pdf
Кстати, жалко, что статья об этом NES-тетрисе, а не от Tengen. Лично мне тот сильно больше нравится.
скорее на
и проверка
должна была проверять разрешённость именно чтения. Хотя комментарий нам и говорит явно про «read-only», он мог писаться постфактум и быть просто навеян названием константы O_RDONLY. Тут без остального контекста сложно понять. Хотя, конечно, Ваше предположение выглядит проще.
do {} while(false)А разве нельзя заменить эту конструкцию на просто
{}? Она тоже выполнится ровно один раз и ограничит область видимости. Или это делается для того, чтобы потребовать у пользующего кода точку с запятой в конце?
Сталкивался в легаси с верхним вариантом, он там был, в том числе, чтобы использовать break для выхода из границ.