Деление по модулю для рациональных чисел

Как сделать операцию деления по модулю

но только не для целых, а для рациональных чисел?

0

Сообщение от DenNik Все упирается в семантику и принятые в обществе соглашения

Как проблему не назови, от этого она никуда не исчезнет.

Символическая роль или нет, но сие всё равно существует, и с этим нужно что-то делать.

Если у вас не было эмпирического опыта использования fmod(), то опять же, вперёд исследовать бескрайний мир Shadertoy'я.

Если вы не воспринимаете проблему точности float'а всерьёз, то моя вам рекомендация заняться реверс-инженерингом существующих рендер движков на трассировке лучей.
Я заглядывал в один из них, и уж поверьте мне, если забить на точность чисел и сделать вид, что этой проблемы нет, то не видать вам никаких голливудских фильмов со спецэффектами. Такой трассировщик бы трещал по швам и крашился при первом чихе.

Для любознательных, вот пример демонстрации одной из проблем, и её качественное решение.

Растеризаторы тоже имеют проблемы с точностью, окда. Какой ваш любимый фильм со спецэффектами?

0

Ну, положим, нехватка точности типа float он же Single в Паскале может проявляться не только в рендеринге, но и в некоторых игровых механиках, т. к. игры для производительности оперируют именно float'ом. Но если задачи рендеринга в реальном времени не стоит, или точность критична, то, как минимум, переходят на Double. Все профессиональное ПО работает с Double, игровые же видеокарты как раз и отличаются от профессиональных тем, что в 64-хбитную точность они могут сильно хуже.

Когда в инсте учился, у нас был TP 7. Некоторые задания в курсе численных методов с использованием стандартного 6-ти байтного паскалевского Real просто не считались из-за потери точности. Только включать FPU и Double, как эти задачи решались до повсеместного появления FPU я вообще не понимаю.

0

Сообщение от Beltar Только включать FPU и Double, как эти задачи решались до повсеместного появления FPU я вообще не понимаю.

Ну, насколько я понимаю, подобные задачи явно не решались в TP7. А методы работы с числами с плавающей точкой имелись и до появления комьютеров в принципе.

0

Исторический экскурс в эту тему, скорее всего, приведет к особенностям архитектуры ALU компьютеров конца 50-ых, 60-ых годов в т. ч. стоимостным разницам, приведшим к идее, что есть компьютеры и ЯП для матана, а есть для бизнес-расчетов с большим количеством вычислений в денежных типах, резко ограниченной точности и строках, очевидно, более простых и доступных не только военным, но и тем, кто деньги умеет считать и зарабатывать. Ну и соответствующих особенностей компиляторов, так что, возможно, нельзя было просто взять и что-то переписать с Фортрана на более вменяемый язык.

Методы работы до компьютеров, предполагают замену крайне трудоемких точных вычислений, менее трудоемкими приближенными. Главная проблема тут, видимо, вообще понять, насколько результаты будут отличаться от истинных. У меня в школьном учебнике алгебры был пример приближенного вычисления выражения 1.03^200. Я уже не помню, какой там было ответ, по описанной в учебнике методике приближенных вычислений, но инженерный калькулятор у меня уже был, и он давал ответ 369,355815215590539499, что на порядок, если не на 2, отличается от получаемого по описанной в учебнике методике.

0

Сообщение от Beltar Я уже не помню, какой там было ответ, по описанной в учебнике методике приближенных вычислений, но инженерный калькулятор у меня уже был, и он давал ответ 369,355815215590539499, что на порядок, если не на 2, отличается от получаемого по описанной в учебнике методике.

Я сейчас навскиду не вспомню, но мы изучали в древние мохнаты годы алгоритмы по обработке чисел с плавающей точкой. Операции несложные, но дико рутинные. И количество значащих цифр после запятой определелось количеством итераций, которые было смысл в этих расчетах задейтствовать. Т.е., нужно до 20 знака - считаем час. Нужно до 50 - три часа (условно).

0