Чи відповідає математика з плаваючою комою в C #? Чи може бути?

Ні, це не інше питання "Чому це (1 / 3.0) * 3! = 1" .

Останнім часом я багато читав про плаваючі точки; конкретно, як один і той же розрахунок може давати різні результати в різних архітектурах або налаштуваннях оптимізації.

Це проблема для відеоігор, які зберігають повторення або є одноранговими мережевими (на відміну від сервера-клієнта), які покладаються на всіх клієнтів, що створюють однакові результати щоразу, коли вони запускають програму - невелика розбіжність в одному Обчислення з плаваючою комою може призвести до різко різного стану гри на різних машинах (або навіть на одній машині! )

Це трапляється навіть серед процесорів, які «слідують» за IEEE-754 , насамперед тому, що деякі процесори (а саме x86) використовують подвійну розширену точність . Тобто вони використовують 80-бітні регістри для проведення всіх обчислень, а потім скорочують до 64- або 32-бітних, що призводить до різних результатів округлення, ніж машини, які використовують для обчислень 64- або 32-бітні.

Я бачив декілька рішень цієї проблеми в Інтернеті, але все для C ++, а не для C #:

• Вимкніть подвійний режим розширеної точності (щоб усі doubleобчислення використовували 64-бітні IEEE-754) за допомогою _controlfp_s(Windows), _FPU_SETCW(Linux?) Або fpsetprec(BSD).
• Завжди запускайте один і той же компілятор з однаковими налаштуваннями оптимізації та вимагайте від усіх користувачів однакової архітектури процесора (відсутня міжплатформатна гра). Оскільки мій "компілятор" - це насправді JIT, який може оптимізуватися по-різному щоразу, коли програма запускається , я не думаю, що це можливо.
• Використовуйте арифметику з фіксованою точкою, уникайте floatі doubleвзагалі. decimalпрацював би для цієї мети, але був би набагато повільніше, і жодна з System.Mathфункцій бібліотеки не підтримує це.

Отже, це навіть проблема в C #? Що робити, якщо я маю намір лише підтримувати Windows (не Mono)?

Якщо це так, чи є який-небудь спосіб змусити мою програму працювати у звичайній подвійній точності?

Якщо ні, то чи існують бібліотеки, які допомогли б підтримувати обчислення з плаваючою комою?

Я не знаю жодного способу зробити нормальні плаваючі точки детермінованими в .net. JITter дозволено створювати код, який веде себе по-різному на різних платформах (або між різними версіями .net). Тож використання нормального floats у детермінованому .net-коді неможливо.

Я вирішив обхідні шляхи:

1. Реалізуйте FixedPoint32 в C #. Незважаючи на те, що це не надто важко (у мене наполовину закінчена реалізація), дуже малий діапазон значень робить його дратівливим у використанні. Ви повинні бути обережними в будь-який час, щоб ні перелити, ні втратити занадто багато точності. Зрештою, я знайшов це не простіше, ніж безпосередньо використовувати цілі числа.
2. Впровадити FixedPoint64 в C #. Мені це було досить важко зробити. Для деяких операцій корисними будуть проміжні цілі числа 128 біт. Але .net не пропонує такого типу.
3. Реалізуйте власну 32-бітну плаваючу точку. Відсутність властивості BitScanReverse викликає кілька неприємностей при здійсненні цього. Але зараз я думаю, що це найбільш перспективний шлях.
4. Використовуйте нативний код для математичних операцій. Вводить накладні витрати виклику делегата на кожну математичну операцію.

Я тільки почав реалізацію програмного забезпечення 32-бітної математики з плаваючою комою. На моєму 2,66 ГГц i3 він може робити близько 70 мільйонів доповнень / множень за секунду. https://github.com/CodesInChaos/SoftFloat . Очевидно, це все ще дуже неповно і баггі.

Специфікація C # (§4.1.6 типів з плаваючою точкою) спеціально дозволяє проводити обчислення з плаваючою комою, використовуючи точність, вищу, ніж результат. Отже, ні, я не думаю, що ви можете зробити ці розрахунки детермінованими безпосередньо у .Net. Інші пропонували різні способи вирішення, тож ви можете спробувати їх.

Наступна сторінка може бути корисною у випадку, коли вам потрібна абсолютна портативність таких операцій. У ньому обговорюється програмне забезпечення для тестування реалізацій стандарту IEEE 754, включаючи програмне забезпечення для емуляції операцій з плаваючою комою. Більшість інформації, мабуть, характерні лише для C або C ++.

http://www.math.utah.edu/~beebe/software/ieee/

Примітка про фіксовану крапку

Двійкові цифри з фіксованою точкою також можуть добре працювати як заміна плаваючої точки, як видно з чотирьох основних арифметичних операцій:

• Додавання і віднімання тривіально. Вони працюють так само, як цілі числа. Просто додайте або віднімайте!
• Щоб помножити два числа з фіксованою точкою, помножте два числа, потім змістіть праворуч на визначене число дробових бітів.
• Щоб розділити два числа з фіксованою точкою, змістіть дивіденд на ліву визначену кількість дробів, а потім поділіть на дільник.
• Розділ четвертий цього документу містить додаткові вказівки щодо застосування двійкових фіксованих точок.

Бінарні номери з фіксованою точкою можуть бути реалізовані на будь-якому цілому типі даних, такому як int, long та BigInteger, а типи, що не відповідають стандартам CLS, uint та ulong.

Як запропоновано в іншій відповіді, ви можете використовувати таблиці пошуку, де кожен елемент таблиці є двійковим номером фіксованої точки, щоб допомогти реалізувати складні функції, такі як синус, косинус, квадратний корінь тощо. Якщо таблиця пошуку менш деталізована, ніж номер фіксованої точки, пропонується округлити введення, додавши до входу одну половину деталізації таблиці пошуку:

// Assume each number has a 12 bit fractional part. (1/4096)
// Each entry in the lookup table corresponds to a fixed point number
//  with an 8-bit fractional part (1/256)
input+=(1<<3); // Add 2^3 for rounding purposes
input>>=4; // Shift right by 4 (to get 8-bit fractional part)
// --- clamp or restrict input here --
// Look up value.
return lookupTable[input];

Це проблема для C #?

Так. Різні архітектури - це найменше занепокоєння, різні рамки тощо можуть призвести до відхилень через неточності в представленнях поплавця - навіть якщо вони однакові неточності (наприклад, однакова архітектура, за винятком більш повільної GPU на одній машині).

Чи можу я використовувати System.Decimal?

Немає причини, чому не можна, однак собака повільна.

Чи є спосіб змусити мою програму працювати в подвійній точності?

Так. Приймайте час виконання CLR самостійно ; і компілювати всі несезарні виклики / прапори (які змінюють поведінку арифметики з плаваючою комою) у додаток C ++ перед тим, як викликати CorBindToRuntimeEx.

Чи є бібліотеки, які допомогли б підтримувати розрахунки з плаваючою комою послідовними?

Не те, що я знаю.

Чи є інший спосіб вирішити це?

Я вирішував цю проблему раніше, ідея - використовувати QNumbers . Вони є формою реал, які мають фіксовану точку; але не фіксована точка в базі-10 (десятковий) - скоріше база-2 (двійкова); через це математичні примітиви на них (add, sub, mul, div) набагато швидше, ніж наївна основа-10 фіксованих точок; особливо якщо nце однаково для обох значень (що у вашому випадку було б). Крім того, оскільки вони є цілісними, вони мають чітко визначені результати на кожній платформі.

Майте на увазі, що частота кадрів все ще може впливати на них, але це не так вже й погано і легко виправляється за допомогою точок синхронізації.

Чи можу я використовувати більше математичних функцій за допомогою QNumbers?

Так, зворотній шлях десяткової для цього. Крім того, ви дійсно повинні використовувати таблиці пошуку для функцій trig (sin, cos); оскільки вони дійсно можуть давати різні результати на різних платформах - і якщо ви правильно їх кодуєте, вони можуть використовувати QNumbers безпосередньо.

Відповідно до цього трохи старого запису в блозі MSDN, JIT не використовуватиме SSE / SSE2 для плаваючої точки, це все x87. Через це, як ви вже згадували, ви повинні турбуватися про режими та прапори, а в C # це неможливо контролювати. Таким чином, використання звичайних операцій з плаваючою комою не гарантуватиме точно такий же результат на кожній машині для вашої програми.

Щоб отримати точну відтворюваність подвійної точності, вам потрібно буде виконати програмну емуляцію з плаваючою точкою (або фіксованою точкою). Я не знаю бібліотек C # для цього.

Залежно від операцій, які вам потрібні, ви зможете піти з однією точністю. Ось ідея:

• зберігати всі цінності, які вам цікаві, в одній точності
• виконати операцію:
  • розширити вхідні дані до подвійної точності
  • робіть операцію в подвійній точності
  • конвертувати результат назад в єдину точність

Велика проблема з x87 полягає в тому, що обчислення можна проводити з 53-бітною або 64-бітовою точністю, залежно від прапора точності та того, чи зареєструвався регистр в пам'ять. Але для багатьох операцій виконання операції з високою точністю і округлення назад до меншої точності гарантуватиме правильну відповідь, що означає, що відповідь буде гарантовано однаковою для всіх систем. Чи отримаєте ви додаткову точність, не має значення, оскільки у вас є достатня точність, щоб гарантувати правильну відповідь в будь-якому випадку.

Операції, які повинні працювати за цією схемою: додавання, віднімання, множення, ділення, sqrt. Такі речі, як sin, exp тощо, не працюватимуть (результати зазвичай збігаються, але гарантії немає). "Коли подвійне округлення нешкідливо?" Довідка ACM (платний реєстр. Запит)

Сподіваюся, це допомагає!

Як уже було сказано в інших відповідях: Так, це проблема в C # - навіть якщо ви залишаєтеся чистими Windows.

Що стосується рішення: Ви можете зменшити (і доклавши певних зусиль / продуктивності) повністю уникнути проблеми, якщо використовувати вбудований BigIntegerклас і масштабувати всі обчислення до визначеної точності, використовуючи загальний знаменник для будь-якого обчислення / зберігання таких чисел.

Як вимагає ОП - щодо ефективності:

System.Decimalпредставляє число з 1 бітом для знака та 96-бітним цілим числом та "шкалою" (представляє де десяткова крапка). Для всіх обчислень, які ви робите, він повинен працювати на цій структурі даних і не може використовувати жодних інструкцій з плаваючою комою, вбудованих у процесор.

BigInteger«Рішення» робить щось подібне - тільки те , що ви можете визначити , скільки цифр вам потрібно / хочу ... можливо , ви хочете тільки 80 біт або 240 біт точності.

Повільність завжди пов'язана з необхідністю моделювання всіх операцій над цим номером за допомогою цілих інструкцій без використання вбудованих інструкцій CPU / FPU, що, в свою чергу, призводить до набагато більше інструкцій на математичну операцію.

Щоб зменшити хіт продуктивності, існує декілька стратегій - наприклад, QNumbers (див. Відповідь Джонатана Дікінсона. Чи відповідає математика з плаваючою комою в C #? Чи може це бути? ) Та / або кешування (наприклад, обчислення тригерів ...) і т.д.

Ну, ось моя перша спроба, як це зробити :

1. Створіть проект ATL.dll, в якому є простий об’єкт, який буде використовуватися для ваших операцій з критичною плаваючою точкою. не забудьте скомпілювати його з прапорами, які відключають використання будь-якого обладнання, яке не xx87, робити плаваючу точку.
2. Створюйте функції, які викликають операції з плаваючою комою та повертають результати; почніть просто, і тоді, якщо це працює для вас, ви завжди можете збільшити складність, щоб згодом задовольнити свої продуктивні потреби, якщо це необхідно.
3. Поставте заклики control_fp навколо фактичної математики, щоб переконатися, що це робиться однаково на всіх машинах.
4. Перегляньте свою нову бібліотеку та тестуйте, щоб переконатися, що вона працює, як очікувалося.

(Я вважаю, що ви можете просто скомпілювати 32-розрядний .dll, а потім використовувати його з x86 або AnyCpu [або, ймовірно, лише націлювання на x86 у 64-бітній системі; див. Коментар нижче].)

Тоді, якщо припустити, що це працює, ви хочете використовувати Mono, я думаю, ви повинні мати можливість тиражувати бібліотеку на інших платформах x86 аналогічним чином (не COM, звичайно; хоча, можливо, з вином? Трохи поза моїм районом один раз ми ходимо туди хоч ...).

Якщо припустити, що ви можете змусити його працювати, ви повинні мати можливість налаштувати спеціальні функції, які можуть робити кілька операцій одночасно, щоб виправити будь-які проблеми з продуктивністю, і ви матимете математику з плаваючою комою, яка дозволяє мати постійні результати на платформах з мінімальною кількістю коду, написаного на C ++, а решту вашого коду залишити в C #.

Я не розробник ігор, хоча в мене є великий досвід роботи з обчислювально складними проблемами ... тому я зроблю все можливе.

Стратегія, яку я прийняв би, по суті така:

• Використовуйте повільніший (якщо необхідно; якщо швидший шлях, чудовий!), Але передбачуваний метод для отримання відтворюваних результатів
• Використовуйте подвійний для всього іншого (наприклад, надання)

Короткий термін цього: потрібно знайти баланс. Якщо ви витрачаєте 30мм на візуалізацію (~ 33 кадрів в секунду) і лише 1 мс робите виявлення зіткнень (або вставляєте якусь іншу високочутливу операцію) - навіть якщо ви потроїть час, необхідний для виконання критичної арифметики, вплив, який він робить на ваш кадр, є ви падаєте з 33,3 кадрів в секунду до 30,3 кадрів в секунду.

Я пропоную вам проаналізувати все, врахувати, скільки часу витрачається на виконання кожного з помітно дорогих обчислень, а потім повторити вимірювання за допомогою одного чи більше методів вирішення цієї проблеми і побачити, який вплив має.

Перевіривши посилання в інших відповідях, ви зрозумієте, що ви ніколи не будете гарантуватися, чи «плаваюча точка» реалізована «правильно», чи ви завжди отримаєте певну точність для даного розрахунку, але, можливо, ви могли б докласти максимум зусиль, (1) обрізання всіх обчислень до загального мінімуму (наприклад, якщо різні реалізації дадуть вам 32 - 80 біт точності, завжди обрізання кожної операції до 30 або 31 біт), (2) мати таблицю з декількома тестовими випадками при запуску. (прикордонні випадки додавання, віднімання, множення, ділення, sqrt, косинуса тощо), і якщо реалізація обчислює значення, що відповідають таблиці, то не турбуйте внесення будь-яких коригувань.

Ваше запитання у досить складних та технічних матеріалах O_o. Однак у мене може бути ідея.

Ви впевнені, знаєте, що процесор вносить певні корективи після будь-яких плаваючих операцій. А процесор пропонує декілька різних інструкцій, які роблять різні операції округлення.

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

Помилки, допущені коригуванням округлення, зростатимуть з кожною подальшою інструкцією.

Як приклад можна сказати, що на рівні складання: a * b * c не еквівалентно a * c * b.

Я не зовсім впевнений у цьому, вам потрібно буде попросити когось, хто знає архітектуру процесора набагато більше, ніж я: p

Однак, щоб відповісти на ваше запитання: на C або C ++ ви можете вирішити свою проблему, оскільки у вас є деякий контроль над машинним кодом, сформованим вашим компілятором, однак у .NET у вас немає. Тож поки ваш машинний код може бути різним, ви ніколи не будете впевнені в точному результаті.

Мені цікаво, яким чином це може бути проблемою, тому що варіація здається дуже мінімальною, але якщо вам потрібна дійсно точна операція, єдиним рішенням, про який я можу подумати, буде збільшення розміру ваших плаваючих регістрів. Використовуйте подвійну точність або навіть довгу подвійну, якщо можете (не впевнений, що це можливо за допомогою CLI).

Я сподіваюся, що я був досить зрозумілий, я не досконалий англійською (... зовсім: s)