Чому C не має підписаних плавців?

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

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

Мені подобаються ці попередження. Вони допомагають мені правильний код.

Чому б ми не мали однакової розкоші для поплавців? Квадратний корінь точно ніколи не поверне від’ємне число. Є й інші місця, де від'ємне значення поплавця не має значення. Ідеальний кандидат для непідписаного поплавця.

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

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

Будь-яка ідея, чому їх не існує?

Редагувати:

Я знаю, що x87 FPU не має інструкцій поводжуватися з непідписаними плавцями. Давайте просто використовувати підписані вказівки поплавця. Неправильне використання (наприклад, нижчий за нуль) може вважатися невизначеною поведінкою так само, як невизначене переповнення підписаних цілих чисел.

Чому C ++ не підтримує неподписані плавці, тому що для процесора не існує еквівалентних операцій машинного коду. Тож було б дуже неефективно його підтримувати.

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

Отже, питання полягає в тому, чому не підтримують це програмні засоби. І я думаю, що відповідь на це полягає в тому, що не було визначеного неподписаного стандарту float спочатку. Оскільки мови люблять бути зворотними сумісними, навіть якщо вони були додані, мови не могли ним користуватися. Щоб побачити специфікацію з плаваючою точкою, слід переглянути стандарт IEEE 754 з плаваючою точкою .

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

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

Існує значна різниця між підписаними та неподписаними цілими числами в C / C ++:

value >> shift

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

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

float a = 2.0f, b = 10.0f, c;
c = a - b;

Яке значення має c? -8. Але що це означатиме в системі без від’ємних чисел. FLOAT_MAX - 8 можливо? Насправді, це не працює, оскільки FLOAT_MAX-8 є FLOAT_MAX завдяки точним ефектам, тому речі стають ще більш складними. Що робити, якщо це було частиною більш складного виразу:

float a = 2.0f, b = 10.0f, c = 20.0f, d = 3.14159f, e;
e = (a - b) / d + c;

Це не є проблемою для цілих чисел через характер системи комплектування 2.

Також врахуйте стандартні математичні функції: sin, cos і tan працюватимуть лише для половини вхідних значень, ви не змогли знайти журнал значень <1, ви не могли вирішити квадратичні рівняння: x = (-b +/- root ( bb - 4.ac)) / 2.a тощо. Насправді це, ймовірно, не буде працювати для будь-якої складної функції, оскільки вони, як правило, реалізуються як поліноміальні наближення, які б десь використовували негативні значення.

Отже, непідписані поплавці досить марні.

Але це не означає сказати, що клас, що діапазон перевіряє плаваючі значення, не є корисним, ви можете зафіксувати значення до заданого діапазону, наприклад, обчислення RGB.

(Убік, Perl 6 дозволяє писати

subset Nonnegative::Float of Float where { $_ >= 0 };

і тоді ви можете використовувати так Nonnegative::Floatсамо, як і будь-який інший тип.)

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

[редагувати]

C - це як збірка: те, що ти бачиш, саме те, що ти отримуєш. Неявне "Я перевірте, чи цей поплавок не є негативним для вас" суперечить його філософії дизайну. Якщо ви дійсно хочете цього, можете додати assert(x >= 0)або подібне, але це потрібно зробити явно.

Я вважаю, що непідписаний int був створений через необхідність більшої вартості, ніж підписаний Int.

Поплавок має набагато більший запас, тому ніколи не було фізичної потреби в неподписаному поплавці. І як ви самі себе вказуєте у своєму питанні, додаткова 1-бітова точність не є для чого вбивати.

Редагувати: Прочитавши відповідь Брайана Р. Бонді , я повинен змінити свою відповідь: Він, безумовно, правий, що в центральних процесорах не було операцій з безпідписною плаваючою операцією. Однак я переконаний, що це було дизайнерське рішення, виходячи з причин, про які я говорив вище ;-)

Я думаю, що Треб на правильному шляху. Для цілих чисел важливіше наявність у вас відповідного типу без підпису. Це ті, які використовуються в переміщенні бітів і використовуються в бітових картах . Знаковий шматочок просто заважає. Наприклад, праворуч змістивши негативне значення, отримане значення є реалізацією, визначеною в C ++. При цьому з непідписаним цілим числом або переповненням такого є ідеально визначена семантика, тому що такого біта немає на шляху.

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

Квадратний корінь напевно ніколи не поверне від’ємне число. Є й інші місця, де від'ємне значення поплавця не має значення. Ідеальний кандидат для непідписаного поплавця.

C99 підтримує складні числа та тип загальної форми sqrt, тому sqrt( 1.0 * I)буде негативним.

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

#include <complex.h>
#include <tgmath.h>

int main () 
{
    complex double a = 1.0 + 1.0 * I;

    double f = sqrt(a);

    return 0;
}

Він також містить мозок-fart, оскільки реальна частина sqrt будь-якого складного числа є додатною або нульовою, а sqrt (1.0 * I) - sqrt (0.5) + sqrt (0.5) * I не -1.0.

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

Стаття у Вікіпедії про номери IEEE-754 з плаваючою комою

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

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

Непідписані цілі типи в C визначаються таким чином, щоб вони підкорялися правилам абстрактного алгебраїчного кільця. Наприклад, для будь-яких значень X і Y додавання XY до Y дасть X. Непідписані цілочисельні типи гарантовано дотримуються цих правил у всіх випадках, які не передбачають перетворення на чи з будь-якого іншого числового типу [або неподписані типи різних розмірів] , і ця гарантія є однією з найважливіших особливостей таких типів. У деяких випадках варто відмовитися від можливості представляти негативні числа в обмін на додаткові гарантії, які можуть надати лише неподписані типи. Типи з плаваючою комою, підписані чи ні, не можуть дотримуватися всіх правил алгебраїчного кільця [наприклад, вони не можуть гарантувати, що X + YY буде рівним X], і дійсно IEEE не відповідає " t навіть дозволяти їм дотримуватися правил класу еквівалентності [вимагаючи, щоб певні значення порівнювали нерівні з собою]. Я не думаю, що "безпідписаний" тип з плаваючою комою може дотримуватися будь-яких аксіом, яких звичайний тип з плаваючою комою не міг, тому я не впевнений, які переваги він би запропонував.

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

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

• Арифметичний та логічний зсув потребують лише незначної зміни наповнювача для верхніх бітів
• Розширення множення може використовувати одне і те ж апаратне забезпечення для основної частини, а потім деяку окрему логіку для коригування результату для зміни ознаки . Мало того, що він використовується у справжніх множниках, але це можливо зробити
• Підписане порівняння можна легко перетворити на неподписане порівняння і навпаки легко, перемикаючи верхній біт або додаючи йогоINT_MIN . Також теоретично можливо, він, ймовірно, не використовується на апаратному забезпеченні, але він корисний у системах, які підтримують лише один тип порівняння (наприклад, 8080 або 8051)

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

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

• Збільшити діапазон, додавши його до показника
• Підвищити точність, додавши її до мантіси. Це часто корисніше, оскільки ми, як правило, потребуємо більшої точності, ніж дальності

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

У системах, що використовують програмне забезпечення з плаваючою комою, вам потрібні 2 версії для кожної функції, що не очікувалося за той час, коли пам’ять була настільки дорогою, або вам доведеться знайти якийсь «хитрий» спосіб ділитися частинами підписаних і непідписаних функцій

Однак апаратне забезпечення з плаваючою комою існувало задовго до того, як був винайдений C , тому я вважаю, що вибір у C був пов'язаний з відсутністю апаратної підтримки через причину, яку я згадав вище

Однак, існує кілька спеціалізованих безпідписаних форматів з плаваючою комою, переважно для цілей обробки зображень, таких як 10-ти та 11-розрядний тип з плаваючою точкою групи Khronos

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

Гарне питання.

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

Раніше я те саме обмотував, але річ така: це мало би допомогло. У кращому випадку компілятор може знайти статичні завдання.

unsigned float uf { 0 };
uf = -1f;

Або мінімалістично довше

unsigned float uf { 0 };
float f { 2 };
uf -= f;

Але саме про це. З типовими цілими числами без підпису ви також отримуєте визначене обгортання, а саме воно поводиться як модульна арифметика.

unsigned char uc { 0 };
uc -= 1;

після цього 'uc' має значення 255.

Тепер, що буде робити компілятор із тим самим сценарієм, надаючи неподписаний float-тип? Якщо значення невідомі під час компіляції, потрібно створити код, який спочатку виконує обчислення, а потім робить перевірку знаків. Але що, коли результатом такого обчислення буде сказати «-5,5» - яке значення слід зберігати у поплавці, оголошеному неподписаним? Можна спробувати модульну арифметику, як для інтегральних типів, але це пов'язано зі своїми проблемами: Найбільше значення - це безперечно нескінченність .... що не працює, не можна мати "нескінченність - 1". Переміщення за найбільшу цінність, яку він може мати, також не спрацює, оскільки там ви натрапите на її точність. "NaN" був би кандидатом.

Нарешті, це не буде проблемою з фіксованими номерами точок, оскільки там модуль чітко визначений.