И тогда тоже его смена стоила примерно от полугодовой его зарплаты. Эти деньги же не на смузи уходят. Скорее наоборот, сейчас проще, программисты стали типовыми, практически клонированными.
Как я и сказал, в результате меня не уволили. И по сей день мне непонятно, почему.
Ха. Да потому что нанять нового инженера стоит примерно от полугодовой его зарплаты. На поиск, на собеседования, на обучение, на притирку, на исправление проблем при притирке. Если сотрудник сделал что-то не очень хорошее, но последствия предотвратили и объяснили, что это было плохо и есть надежда, что он понял, то оставить будет дешевле, чем через год ловить такую же ошибку у следующего.
Понимаю, что тут автор, конечно, комментарий не увидит, но по fraction использование как раз понятно в финансовых, торговых и экономических программах: "Decimal type, based on Fraction type with explicit precision" (цитата из описания). Писать вычисления денег (цен, количества, стоимости, котировок и т.п.) на флоатах и интах больно.
Обратил внимание. У вас в asm используются команды в нотации, которую я обычно видел для Z80: мнемоника LD для загрузки регистра, а в классической интелской используется MOV. Мне нотация Z80 чуть больше нравится (потому что даные не move, а load).
Хм. Если посмотреть на скорость в символах в секунду, то самый быстрый вариант оригинала статьи в его замерах ищет со скоростью порядка 100к симв/сек. Про улучшенный вариант Kranar/a_e_k пишут, что они "быстрее в 10 раз". Миллион символов строк в секунду (если я нигде множитель не пропустил). Это ж, блин, соревнование улиток какое-то. Скорее всего почти всё время уходит на интерпретатор и движок Python, потому что на C/C++/Rust/C#/Java я бы ожидал скорости порядка 100М-1G симв/сек на реализациях без SIMD и 1-10G для SIMD.
Если это в запросе СУБД на миллиард строк, то, наверное, может стать важным. Другой вопрос, что возникает много оговорок. Во-первых, даже для манипуляций с датами в чистом виде эта функция не очень нужна. Во-вторых, в классической OLTP СУБД будет гораздо больше накладных расходов на доступ к полю (в колоночных аналитических может и есть какой-то смысл).
"Добавить дней/секунд к дате" можно выполнять в удобном для хранения формате, храня смещение относительно какой-то точки (собственно, отсюда же системный формат unix и растёт). А преобразование в человеческую дату и обратно требует другой задачи - сколько високосных лет (29.02) прошло до этого момента. И "добавить N месяцев/лет" проще делать конвертацией сначала в структуру годы-месяцы-дни, потому что всё равно 29.02 отдельно обрабатывать.
Совет, который мало где попадается. Если надо наскоро посмотреть, насколько ровные лады у только что взятой гитары (в магазине или при покупке с рук, например), то обычно специального инструмента под рукой нет. Но можно воспользоваться пластиковой картой (банковской или аналогичной по формату). Ставим её между струнами вдоль грифа перпендикулярно плоскости накладки грифа так, чтобы она накрывала 3 лада (1 в середине и 2 по краям) - если она ощутимо качается (с характерным тактильным тык-тык), то этот лад будет звенеть. Конечно, что надо проверять и по краям ладов и в середине. Наверху грифа прикладываем длинной стороной, внизу, где интервал между ладами меньше - короткой. Примерно за 10-20-30 секунд легко проверить весь гриф.
а изменение одного пикселя требует модификации 4х байт
Если рисовать в одной "странице", то 8 пикселов за команду. Для игр можно статические спрайты делать полноцветными, а движущиеся фигурки брать элементарных цветов. Кажется там большая часть игр примерно так и выживала. И еще кажется это не они сами придумали, а откуда-то еще подсмотрели (потому что часть игр явно была где-то ранее написана). Ну и зато в отличие от Спектрума можно каждый пиксель в свой цвет красить.
У меня Криста-2 была лета с 1989 или с 1990 года. Года полтора до Спектрума. Что меня удивляет до сих пор, и в чём хотелось бы разобраться, это в том, что в ней по документации ПЗУ 512 байт. В это как-то умещена надпись "Криста-2" при запуске, прогресс-бар при загрузке и сам загрузчик. Еще помню, что клавиатура там была приятной - герконовые контакты и клавиши с мягким ходом. На голову выше по удобству самих клавиш не только "Микрош" и "БК", но и учебных Корветов и следующего моего "Magic/Кворум".
есть ещё БК-0010/11, Вектор-06ц, и многие другие редкоземельные, уникальные машины местного производства.
А откуда начать, если интересует Вектор-06ц и соседние с ним "редкоземельные, уникальные машины"? Больше всего интересует Криста-2 родом из города Мурома :)
С какими-то тезисами я согласен, с какими-то не согласен, но всё перечёркивают какие-то "напёрсточнические" приёмы убеждения.
В истории США делаются прыжки между примерно 1760-м, 1860-м и 1960-м годами. Ага. Аналогично сравните 1825, 1925 и 2025 год в России, а особенно что между этими годами крупного произошло. Так же я почти уверен и в США разница во всём была колоссальная.
Состояние и практики тех же США не сравниваются с распространёнными практиками в других странах. Ну или различия упоминаются совсем вскользь. Условия работы на фабриках и заводах со сменами по 12-14 часов не были эксклюзивной прерогативой США, они даже и не были особо пионерами в этой части - а в одной стране в том числе с лозунгами борьбы против этого, даже большевики победили.
Много обобщающих штампов, но с такими штампами надо быть очень осторожным, особенно обобщая на страну с сотнями млн жителей. В реальной жизни даже в компании с 1000 сотрудников мнения сотрудников их взгляд на компанию будет сильно различаться (в контексте статьи от "чиллим, неспешно и планово задачи делаем" до "кранчим непрерывно по 80 часов в неделю").
Но наряду с обобщающими штампами много какого-то уж совсем популистского черри-пикинга, в частности про Microsoft. Перечисленные "факторы" успеха Билла Гейтса с одной стороны достаточно спорные, с другой - не факт, что именно они повлияли. И есть много ИТ-компаний примерно того же периода с совершенно другими судьбами (у которых были не менее везучие в молодости основатели).
Ну и есть какие-то небольшие передёргивания, которые похожи на манипулятивные. Ну вот например фраза "Даже больше, как в классической ошибке выжившего забывали про сбитые самолёты". Никто в этой истории про сбитые самолёты не забывал. Сложно, блин, забыть про сбитые самолёты, когда решаешь задачу защиты самолётов от сбития. Абрахам Вальд был математиком, который специализировался в статистике, поэтому сделал несколько контринтуитивный вывод, что "надо защищать те места, где у вернувшихся самолётов меньше пробитий", но ни о каком "забытии" тут речь не идёт.
И тогда тоже его смена стоила примерно от полугодовой его зарплаты. Эти деньги же не на смузи уходят. Скорее наоборот, сейчас проще, программисты стали типовыми, практически клонированными.
Ха. Да потому что нанять нового инженера стоит примерно от полугодовой его зарплаты. На поиск, на собеседования, на обучение, на притирку, на исправление проблем при притирке. Если сотрудник сделал что-то не очень хорошее, но последствия предотвратили и объяснили, что это было плохо и есть надежда, что он понял, то оставить будет дешевле, чем через год ловить такую же ошибку у следующего.
Люди гибнут за металл.
Сатана там правит бал, там правит бал,
Понимаю, что тут автор, конечно, комментарий не увидит, но по
fractionиспользование как раз понятно в финансовых, торговых и экономических программах: "Decimal type, based on Fraction type with explicit precision" (цитата из описания). Писать вычисления денег (цен, количества, стоимости, котировок и т.п.) на флоатах и интах больно.Счётчик написан криво, некорректно отрабатывает количество более
.
Обратил внимание. У вас в asm используются команды в нотации, которую я обычно видел для Z80: мнемоника LD для загрузки регистра, а в классической интелской используется MOV. Мне нотация Z80 чуть больше нравится (потому что даные не move, а load).
Хм. Если посмотреть на скорость в символах в секунду, то самый быстрый вариант оригинала статьи в его замерах ищет со скоростью порядка 100к симв/сек. Про улучшенный вариант Kranar/a_e_k пишут, что они "быстрее в 10 раз". Миллион символов строк в секунду (если я нигде множитель не пропустил).
Это ж, блин, соревнование улиток какое-то. Скорее всего почти всё время уходит на интерпретатор и движок Python, потому что на C/C++/Rust/C#/Java я бы ожидал скорости порядка 100М-1G симв/сек на реализациях без SIMD и 1-10G для SIMD.
Чего-то я не понял, как строки считались.
Как ни считаю, 5 и 14 не получается.
Отличная шутка.
Похожие вроде бы процессы в осыпании сыпучего склона.
Если это в запросе СУБД на миллиард строк, то, наверное, может стать важным.
Другой вопрос, что возникает много оговорок. Во-первых, даже для манипуляций с датами в чистом виде эта функция не очень нужна. Во-вторых, в классической OLTP СУБД будет гораздо больше накладных расходов на доступ к полю (в колоночных аналитических может и есть какой-то смысл).
"Добавить дней/секунд к дате" можно выполнять в удобном для хранения формате, храня смещение относительно какой-то точки (собственно, отсюда же системный формат unix и растёт). А преобразование в человеческую дату и обратно требует другой задачи - сколько високосных лет (29.02) прошло до этого момента. И "добавить N месяцев/лет" проще делать конвертацией сначала в структуру годы-месяцы-дни, потому что всё равно 29.02 отдельно обрабатывать.
Баян
Ну я как раз про случаи, когда инструментов нет под рукой.
Совет, который мало где попадается. Если надо наскоро посмотреть, насколько ровные лады у только что взятой гитары (в магазине или при покупке с рук, например), то обычно специального инструмента под рукой нет. Но можно воспользоваться пластиковой картой (банковской или аналогичной по формату). Ставим её между струнами вдоль грифа перпендикулярно плоскости накладки грифа так, чтобы она накрывала 3 лада (1 в середине и 2 по краям) - если она ощутимо качается (с характерным тактильным тык-тык), то этот лад будет звенеть. Конечно, что надо проверять и по краям ладов и в середине. Наверху грифа прикладываем длинной стороной, внизу, где интервал между ладами меньше - короткой. Примерно за 10-20-30 секунд легко проверить весь гриф.
Если рисовать в одной "странице", то 8 пикселов за команду. Для игр можно статические спрайты делать полноцветными, а движущиеся фигурки брать элементарных цветов. Кажется там большая часть игр примерно так и выживала. И еще кажется это не они сами придумали, а откуда-то еще подсмотрели (потому что часть игр явно была где-то ранее написана). Ну и зато в отличие от Спектрума можно каждый пиксель в свой цвет красить.
У меня Криста-2 была лета с 1989 или с 1990 года. Года полтора до Спектрума. Что меня удивляет до сих пор, и в чём хотелось бы разобраться, это в том, что в ней по документации ПЗУ 512 байт. В это как-то умещена надпись "Криста-2" при запуске, прогресс-бар при загрузке и сам загрузчик.
Еще помню, что клавиатура там была приятной - герконовые контакты и клавиши с мягким ходом. На голову выше по удобству самих клавиш не только "Микрош" и "БК", но и учебных Корветов и следующего моего "Magic/Кворум".
А откуда начать, если интересует Вектор-06ц и соседние с ним "редкоземельные, уникальные машины"? Больше всего интересует Криста-2 родом из города Мурома :)
Почему-то подумалось: ...вам всегда поможет графический редактор :)
С какими-то тезисами я согласен, с какими-то не согласен, но всё перечёркивают какие-то "напёрсточнические" приёмы убеждения.
В истории США делаются прыжки между примерно 1760-м, 1860-м и 1960-м годами. Ага. Аналогично сравните 1825, 1925 и 2025 год в России, а особенно что между этими годами крупного произошло. Так же я почти уверен и в США разница во всём была колоссальная.
Состояние и практики тех же США не сравниваются с распространёнными практиками в других странах. Ну или различия упоминаются совсем вскользь. Условия работы на фабриках и заводах со сменами по 12-14 часов не были эксклюзивной прерогативой США, они даже и не были особо пионерами в этой части - а в одной стране в том числе с лозунгами борьбы против этого, даже большевики победили.
Много обобщающих штампов, но с такими штампами надо быть очень осторожным, особенно обобщая на страну с сотнями млн жителей. В реальной жизни даже в компании с 1000 сотрудников мнения сотрудников их взгляд на компанию будет сильно различаться (в контексте статьи от "чиллим, неспешно и планово задачи делаем" до "кранчим непрерывно по 80 часов в неделю").
Но наряду с обобщающими штампами много какого-то уж совсем популистского черри-пикинга, в частности про Microsoft. Перечисленные "факторы" успеха Билла Гейтса с одной стороны достаточно спорные, с другой - не факт, что именно они повлияли. И есть много ИТ-компаний примерно того же периода с совершенно другими судьбами (у которых были не менее везучие в молодости основатели).
Ну и есть какие-то небольшие передёргивания, которые похожи на манипулятивные. Ну вот например фраза "Даже больше, как в классической ошибке выжившего забывали про сбитые самолёты". Никто в этой истории про сбитые самолёты не забывал. Сложно, блин, забыть про сбитые самолёты, когда решаешь задачу защиты самолётов от сбития. Абрахам Вальд был математиком, который специализировался в статистике, поэтому сделал несколько контринтуитивный вывод, что "надо защищать те места, где у вернувшихся самолётов меньше пробитий", но ни о каком "забытии" тут речь не идёт.