Comments 29
Да-да… я же говорил, что программисты погубят мир: https://habrahabr.ru/post/310026/
> позволяющий выявлять ещё на этапе кодирования многие ошибки в программах на языке С, С++ и С#
Можно узнать, как инструмент статанализа, не имея привязок к конкретной предметной области, сможет выловить вот эту ошибку с округлением в системе Patriot?
Можно узнать, как инструмент статанализа, не имея привязок к конкретной предметной области, сможет выловить вот эту ошибку с округлением в системе Patriot?
Конкретно эту, наверное никак. Зато он выявляет тысячи других ошибок, которые могут быть не менее опасны.
Статический анализ — это полезная практика, особенно для старого кода на таких небезопасных языках, как C и С++.
Но у вас здесь получилось как в анекдоте «у рыбы нет шерсти, поэтому нет блох, а вот кстати о блохах».
Но у вас здесь получилось как в анекдоте «у рыбы нет шерсти, поэтому нет блох, а вот кстати о блохах».
Почитал вашу статью про разный результат в 32битном и 64битном коде. Есть ещё одно объяснение. Не знаю, что там конкретно в MSVC, но общая ситуация выглядит так:
1) Регистры плавающей арифметики на IBM PC — 80 бит (long double)
2) При вычислении общих подвыражений используется long double
3) Таким образом, результат зависит от оптимизации. Если делать строго по коду — значение одно. А если оптимизировать — то все считается в 80 битах и лишь потом превращается в 32 бита float.
Можете проверить на MSVC, принудительно отключив все оптимизации. Скорее всего, дефолтный набор оптимизаций просто разный.
1) Регистры плавающей арифметики на IBM PC — 80 бит (long double)
2) При вычислении общих подвыражений используется long double
3) Таким образом, результат зависит от оптимизации. Если делать строго по коду — значение одно. А если оптимизировать — то все считается в 80 битах и лишь потом превращается в 32 бита float.
Можете проверить на MSVC, принудительно отключив все оптимизации. Скорее всего, дефолтный набор оптимизаций просто разный.
Не так давно было обсуждение, человек тоже долго возмущался, что точные десятичные дроби в двоичном виде бесконечны и поэтому всегда записываются с погрешностью.
https://habrahabr.ru/post/309812
https://habrahabr.ru/post/309812
точные десятичные дроби в двоичном виде бесконечны и поэтому всегда записываются с погрешностью.
Не все, а только непредставимые.
А теперь по теме.В статье говорится:
За сто часов работы набегает 0.000000095×100×60×60×10=0.34 секунды
Однако, причина сбоя в комплексе Patriot связана не столько с накоплением с течением времени ошибок при работе с числами с плавающей точкой, сколько с природой самих real numbers. Если исходить из тех условий работы программы, которые представлены в отчете, то можно увидеть, что при достижении таймером числа 1048576, которое в 24-разрядном двоичном слове записывается как 000 100 000 000 000 000 000 000, следующая добавка в 0.1≈0.000 110 011 001 100 110 011 001 101 дает число, равное 100 000 000 000 000 000 000.000 1100110≈100 000 000 000 000 000 000.000=1048576. Т.е. дальнейшего накопления в счетчике не происходит. И достигается это значение за 1048576*0.1/60/60=29,127 часа работы комплекса.
Полученный эффект, как мы видим, не связан с переполнением таймера в классическом понимании.
(del)
Что-то они недоговаривают. Значение системного времени само по себе можно использовать разве что чтобы показать часики пользователю. В алгоритмах имеет значение только разница системного времени в разные моменты. Поэтому накапливаться ошибка может только начиная с момента обнаружения ракеты — но не с момента включения.
Если ошибка накапливалась с момента включения — значит, в системе было два независимых таймера, один из которых был точный, а второй — "приближенный".
(а лучше в сатоси)можно подробней что это?
satoshi = 10−8 Bitcoin
я так понимаю речь о битках, по имени их мифического разраба — Сатоши Накамото. Возможно новая крипто-валюта.
В системе Биткоина это минимальная возможная сумма, этакий квант валюты. Тут имеется ввиду, что нужно желательно измерять все валюты в аналогах таких квантов.
Всё-таки конкретно с теми «скад-ами» — вопрос нужно ли было их вообще сбивать — до сих пор дискуссионный. Т.е. если бы они несли ОМП (хим или атомное) — это одно дело, а так — точность его на его дальности совершенно никакая, а «сбитый» он наносил ущерб сопоставимый с «несбитым» — как по силе взрыва так и по месту попадания…
>«Керосинка» летит со скоростью 1676 метров в секунду
Да ну, 5 махов? Когда SR-71 может максимум 3.2М, раскаляясь при этом до свечения.
Да ну, 5 махов? Когда SR-71 может максимум 3.2М, раскаляясь при этом до свечения.
Все так, вот только SR-71 летает в более плотной атмосфере. Верхняя точка траектории Р-17 — около 86 км, у Blackbird потолок всего 25 км.
Скорость звука не константа, она зависит от температуры и, следовательно, высоты (http://tehtab.ru/Guide/GuidePhysics/Sound/SoundSpeedAirHeight/). Поэтому реальный Мах еще выше 5. Кстати число Маха больше 10 на некоторых участках траекторий современных ракет совсем не редкость.
И кстати Мах — удобная единица для аэродинамических расчетов(подобие течения для одинаковых числел Маха), но о нагреве она напрямую судить не позволяет.
И кстати Мах — удобная единица для аэродинамических расчетов(подобие течения для одинаковых числел Маха), но о нагреве она напрямую судить не позволяет.
Это баллистическая ракета — она проникает в атмосферу сверху и проводит в ней достаточно немного времени.
Баллистическая ракета же! Она необитаема и спроектирована для одного полета. Можно испарить часть обшивки боеголовки в процессе полета, если начинка долетит.
Интересно, а можно совместить статический анализатор кода с git? чтобы ошибки и подозрительные места вылавливались и подсвечивались при помещении кода в репозиторий? можно ли обучить нейронную сеть на выявление наиболее частых ошибок например в Си коде? им ведь всё равно что распознавать? статистика у Вас большая
А что мешает взять статический анализатор и прикрутить к post/pre хукам репозитория? Ничего! Как и прикрутить к этому добру проверку тестов (что уже делает много продуктов).
Одно время был озадачен подобной проблемой. Как раз пытался прикрутить PVS-studio для этой цели. Но возникла одна сложность — у PVS-studio нет возможности проанализировать отдельный файл (а хотелось анализировать именно те файлы, которые в данный момент пушатся в репозиторий).
Будь добр анализировать либо весь проект, либо на худой конец весь solution.
Будь добр анализировать либо весь проект, либо на худой конец весь solution.
Coverity Scan предлагает всем желающим бесплатно сканировать их open-source репозитории на github.
А у нас теперь ещё лучше. Можно бесплатно использовать и в закрытых проектах: Как использовать PVS-Studio бесплатно.
И ещё один вариант: Бесплатный PVS-Studio для тех, кто развивает открытые проекты.
UFO just landed and posted this here
Sign up to leave a comment.
«Керосинка» против «Патриотов»: как американские военные программисты научились правильно округлять