Сочувствую, сталкивался с такой же проблемой, почти один в один. Но несмотря на то, что я знал все ответы (и оригинальный пароль, который точно не менялся, и ответ на секретный вопрос, и дату создания аккаунта), меня всё равно не пускали в аккаунт, потому что обнаружили «подозрительную активность», повода для которой я реально не давал. Скорее всего, их роботы посчитали подозрительным, что я заходил в акк через хром в инкогнито или что-нибудь ещё.
Мне в итоге очень повезло, т.к. акк мне восстановили, но геморроя я поимел изрядно. Восстановить получилось через гуглфорум, вот здесь можно почитать мою историю со всеми деталями, возможно, кому-нибудь поможет в аналогичных ситуациях.
Причём, что любопытно, в этот форум особо-то из справки и шаблонных ответов гугла не попадёшь. Т.е. чтобы найти такую возможность, её нужно искать. Ещё интереснее, если копнуть глубже: «поддержка» этого форума — не работники гугла, а энтузиасты. Как я понял, гугл обещал им какие-то призрачные плюшки за статистику (которую там все активно выпрашивают, копипастя устаревшие инструкции гугла и выпрашивая +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 через большой советский электролитический кондёр. Отпустил практически сразу, но до сих пор помню это чувство, когда рука на фазе будто затекла по плечо, но при этом в каждую «мурашку» словно воткнули иглу. Считаю, что очень повезло, т.к. анлокнул тогда все ачивки для того, чтобы откинуться.
Введение с явным обозначением проблематики, которую должен решать данный материал, с обозначением состояния на начальном этапе и обозначением ожидаемого состояния на момент исполнения читателем действий описанных в материале. В случае с тикетом это — обязательное описание ожидаемого поведения программного обеспечения и фактического. По возможности должна быть отсылка на источник с описанием корректного поведения.
Ох. Мой мозг на автомате начинает скипать такие тексты. Может, конечно, это я такой тупой, но это же всё-таки инструкция.
Напишите в вашем тикете/багрепорте:
0. Заголовок — краткое описание проблемы.
1. Окружение, на котором она происходит (продукт, локально/транк/тест/прод, учётка).
2. Начальное состояние продукта (залогинился/запустил программу, программа работала 3 часа простаивая).
3. Что было сделано, конкретно, по шагам (нажал эту кнопку, вбил в это поле «12345»).
4. Что получили в итоге (неправильный ответ «123», ошибка «неверный дескриптор 1234», зависание).
5. Что хотели получить (правильный ответ «333», отсутствие ошибки, отсутствие зависания).
6. Ссылки на ТЗ/согласования, почему хотели бы получить именно это (если не очевидно).
7. Скриншоты, логи, дампы, исходные файлы, полученные файлы и т.п., если есть.
Нет. Так просто сказать нельзя. И про иррациональные числа тоже так просто сказать нельзя. Всё нужно доказывать. И доказательство существования иррациональных чисел есть. А доказательство существования этого номера — нет. Есть только попытки итерационного приближения.
Число существует не потому что мы дали ему имя/обозначение. Я тоже могу ввести число Гладина, которое в поле действительных чисел при делении на единицу не равно себе. От этого оно существовать не станет.
Мне в итоге очень повезло, т.к. акк мне восстановили, но геморроя я поимел изрядно. Восстановить получилось через гуглфорум, вот здесь можно почитать мою историю со всеми деталями, возможно, кому-нибудь поможет в аналогичных ситуациях.
Причём, что любопытно, в этот форум особо-то из справки и шаблонных ответов гугла не попадёшь. Т.е. чтобы найти такую возможность, её нужно искать. Ещё интереснее, если копнуть глубже: «поддержка» этого форума — не работники гугла, а энтузиасты. Как я понял, гугл обещал им какие-то призрачные плюшки за статистику (которую там все активно выпрашивают, копипастя устаревшие инструкции гугла и выпрашивая +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 для выхода из границ.
Ох. Мой мозг на автомате начинает скипать такие тексты. Может, конечно, это я такой тупой, но это же всё-таки инструкция.
Напишите в вашем тикете/багрепорте:
0. Заголовок — краткое описание проблемы.
1. Окружение, на котором она происходит (продукт, локально/транк/тест/прод, учётка).
2. Начальное состояние продукта (залогинился/запустил программу, программа работала 3 часа простаивая).
3. Что было сделано, конкретно, по шагам (нажал эту кнопку, вбил в это поле «12345»).
4. Что получили в итоге (неправильный ответ «123», ошибка «неверный дескриптор 1234», зависание).
5. Что хотели получить (правильный ответ «333», отсутствие ошибки, отсутствие зависания).
6. Ссылки на ТЗ/согласования, почему хотели бы получить именно это (если не очевидно).
7. Скриншоты, логи, дампы, исходные файлы, полученные файлы и т.п., если есть.
Число существует не потому что мы дали ему имя/обозначение. Я тоже могу ввести число Гладина, которое в поле действительных чисел при делении на единицу не равно себе. От этого оно существовать не станет.