OSDev

Там почти ничего практически полезного нет. И объяснение не вполне подходящее. Но это я так думаю, с позиции преподавателя.


Это значит меня кто-то обманул, мне сказали, что там фиксированная точка была. Я-то не проверял, поверил.


Вот поэтому в любых специальных задачах пишется своя специальная арифметика.


Пока не могу прочитать, но, имея опыт работы с псевдоучёными, могу сходу засвидетельствовать по ссылке несколько типичных для них штампов: большой копирайт в начале с указанием, что только автор владеет всей правом на всю нижеперечисленную информацию и повторения о том, что новая технология очень быстро и скоро произведёт революцию в вычислительной технике. Эти две вещи наличествовали в 100% всех псевдонаучных работ, которые я видел, тогда как в работах нормальных учёных формулировки всегда значительно более сдержанные. Разумеется, автор может быть глубоко прав во всём и действительно его идеи хороши, но эти два момента всегда настораживают.

Скорей всего, Вы пали жертвой терминологической путаницы В тех же IBMовских мэйнфреймах и в некоторых языках программирования, появившихся на них (в частности, в PL/1), говорится о числах с плавающей и фиксированной запятой. Но в последнем случае всегда разумеют "технически целые" числа -- эта самая запятая при вводе-выводе программно позиционируется там, где надо программисту (ведь целое число -- это частный случай чисел с фиксированной запятой, по большому счёту), а в машинном представлении её вообще нет, её позиция просто подразумевается. Если использовались двоично-кодированные десятичные числа (BCD), что на мэйнфреймах очень широко использовалось в экономических приложениях, то запятая была "десятичной" -- скажем, отводили 2 разряда под дробную часть (рубли с копейками или там доллары с центами), эти два разряда и оставались при любых сложениях-вычитаниях (а при умножениях-делениях про это "помнили программно"). Если же использовались двоичные числа, то и запятая была "двоичной", но сути дела это не меняло.

Мне сразу вспоминается СУБД Oracle с ее number(m,n), имеющим размер вплоть до 22 байтов. Поскольку причуд со значимостью и округлением в Oracle не встречал, запятая там наверняка фиксированная. В доке должно быть написано, наверное. Надо будет перечитать при случае. Как-то не обращал раньше внимания.

_________________
Путь успеха Циолковского — правильно умереть

вы чего профессора с докторскими диссертациями по математики, что ли
у вас мозгов хоть хватит, что бы такое сделать (Беседа о создании математической библиотеки для ЯП).
там единственное что может быть это пару недальновидных формулок и ничего больше.

Да, не, что вы. Мы наворуем чужого кода просто и скажем, что это мы написали.

Это как же тогда считать-то? Если компьютер не знает, где запятая?

А зачем компьютеру знать? Он как множил и складывал целые числа так и продолжает. Ему позийию запятой надо знать только при выводе числа на экран.
Хотя ещё при деление надо знать где запятая.
Так как базовые операции что для целых что для фиксированной точке одинаковы, то и со всеми остальными операциями нет проблем.


Окромя двух: рост длины чисел, и точность представления малых чисел т.е в диапазоне 0 .. 1.
Для решения второй проблемы применяют числа с плавающей точкой в нормированном виде. Либо делать длинными.

Вот вам загадка при растяжении картинки надо посчитать коэффициент масштаба как правильно сделать?
Варианты ответа:
1) NewSize/OldSize
2) (Newsize-1)/(OldSize-1)

Подсказка пиксел в отличии от геометрической точки имеет размеры.

если бы было что воровать я бы призадумался.

Да, действительно. Однако, здесь есть две тонкости, которые надо учитывать.
1. Никакие объекты в машине Тьюринга не могут являться аналогами действительных чисел, т.к. для адекватного представления трансцедентных чисел потребуется бесконечная память, а точное представление алгебраических чисел уже обременено такими проблемами, что лучше от него отказаться.
2. Можно (и в ряде случаев даже нужно) конечно изобретать свои структуры, но нужно помнить, что это как правило сопряжено с потерей скорости или простоты. Поэтому когда объём планируемых расчётов значителен или создание своих структур нецелесообразно по трудозатратам, следует провести анализ применимости плавающей арифметики, математический анализ устойчивости и погрешности алгоритмов, а затем... смело пользоваться предложенным механизмом.


Я вот наблюдаю занятную картину. Некоторые люди, наступившие на серьёзные грабли, начинают проклинать инструмент и говорить о его неприменимости и даже вредоносности. Так, периодически слышна яростная критика объектно ориентированного программирования, включая отсылки на то, что сам Александр Степанов, создатель STL, разочаровался в ООП. Ровно в ту же область я отношу и критику плавающей арифметики, причём в данном случае вообще сталкиваемся с какой-то странной подменой понятий. Весь гнев в интернете обрушен именно на стандарт IEEE 754, при этом неявно подразумевается, что существуют некие альтернативные представления, которые лишены недостатков, а злая компания Intel прогнула весь мир. Да-да, некоторые почти не стесняясь сравнивают IEEE 754 с проникновением дьявола в наш мир. Но на самом деле именно этот стандарт является наиболее надёжным и вменяемым, и огромное спасибо Интелу, что смогли убедить комитет в том, что можно обеспечить приемлемую скорость для реализации всех защитных механизмов, заложенных в драфт. Если бы не Интел, самолёты падали бы чаще.
Теперь по поводу граблей. Если кто-то попадает в серьёзную аварию, это не означает, что автомобили – это зло. Это означает, что нужно тщательно учить и соблюдать правила дорожного движения и следить за исправностью транспортного средства. И применять их там, где это нужно. От взломов люди страдают гораздо больше, чем от ошибок плавающей арифметики. Поэтому сейчас никому не придёт в голову доверить вопрос разработки системы безопасности банка человеку, который знаком с криптографией лишь понаслышке и не имеет высшего профильного образования. Вместе с тем, мир не откажется от использования банковских услуг или интернет-платежей. Точно так же, отказ от плавающей арифметики означает или возврат в каменный век или неявно подразумевает существование альтернативы. Однако, разумной альтернативы пока никто не предложил (и вряд ли предложит). Поэтому если вы проектируете самолёт или дыхательный аппарат, то надо готовить специалистов и использовать только их, а не ругать IEEE.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

Ну, например, у нас есть два числа: 123,45 и 678,90. Чтоб их правильно сложить, нам не требуется хранить саму запятую -- достаточно помнить, что у нас в обоих числах два разряда после запятой. Складываем как обычные целые: 12345 + 67890, получаем 80235. При выводе для человека просто вставляем запятую в нужное место: 802,35. Таким образом, о позиции запятой должен помнить программист (если на ассемблере пишем) или компилятор, а сама машина считает всё в целых числах.

На мэйнфреймах экономические расчёты сильно упрощались наличием двоично-десятичной арифметики с числами переменной длины (до 16 байтов, т.е. до 31 десятичной цифры + знак). Поэтому в принципе не возникало проблем с точным представлением очень больших чисел вроде госдолга США Но, понятно, что для научных расчётов это годится плохо (хотя б потому, что эта арифметика существенно медленней обычной двоичной -- для "экономических" приложений это не преграда, поскольку львиную долю времени там занимает ввод-вывод, а не расчёты).