Lua з цілими числами w; ти абсолютно абсолютний хіт-форум - heise online
Насправді мені дуже подобається Lua як мова, але вона існувала дотепер
Зокрема, дві речі, які заважали мені робити це інтенсивно
використовувати:
* Ті функції вводу-виводу, де помилки є громіздкими для запиту за допомогою assert ()
замість того, щоб просто кидати виняток незалежно від мови
так підтримано в будь-якому випадку.
* Індекси масивів на основі "1".
Остання проблема - це суто особиста відраза, але це не було б
серйозна причина не використовувати мову (тому я написав
вище лише * 2 * причини.)
Першу проблему можна порівняно легко виправити за допомогою
Функції вводу-виводу упаковані в класи обгортки, які є керівництвом
Видалити перевірку помилок.
Але проти арифметики з плаваючою комою мало що можна зробити, що мені не подобається
зробити.
Ви можете змінити тип за замовчуванням з подвійного на uint64_t
перейменувати, що стосується самої мови - все, що вам потрібно зробити, це ввести
#define change.
Однак, як результат, у вас більше немає Lua: у специфікації мови
і у всіх можливих системних бібліотеках, а також C-API
використовуються всі можливі цифри з плаваючою комою.
Якщо ви зміните тип числа в цілому на ціле, вам доведеться
Також перепишіть більшість функцій стандартної бібліотеки
або іноді навіть змінюють їх API.
Тоді могла б бути більшість існуючих розширень для Lua
також не використовувати його, але довелося б його переписати або принаймні
патч значно.
Перш за все, такого модифікованого інтерпретатора більше не буде в
Можливість виконувати звичайні сценарії Lua: Де-факто у вас був би інший
Створіть мову.
Всі ці міркування дотепер заважали мені це робити
Використовуючи Lua, хоча мені це сподобалось набагато більше, ніж Perl,
Python, Tcl або Ruby.
Я хотів би, щоб Lua працювала так само, як Python
Проблеми з числами: Будь-які точні цілі числа або числа з плаваючою комою, якщо
має кількість десяткових знаків. Додатковий десятковий тип даних
буде глазур’ю на торті, але ви також можете подивитися на це безпосередньо в
Реалізуйте Lua як клас.
Єдине, що насправді має значення, це те, що вбудований базовий тип даних не є таким
примусово залишається типом з плаваючою комою.
З плаваючою точкою також цілком нормально - плаваюча точка є обов’язковою
але ідіотизм:
* Числа з плаваючою комою можна ефективно розрахувати лише за допомогою FPU.
Але особливо на невеликих, особливо енергозберігаючих комп’ютерах, це часто буває
немає ФПУ. Потім вони повинні імітувати плаваючу крапку в програмному забезпеченні
значно більше роботи, займає більше часу і споживає більше електроенергії. Але
навіть якщо є FPU, він буде споживати більше енергії, ніж той самий
Мікросхема, що має лише цілі одиниці та функції FPU
пропустив би: арифметика FP просто неминуче вимагає більше
Ворота застосовувати як цілу арифметику, наскільки вони зрозумілі
є більш складним. Тому, навіть якщо це не повільніше, це коштує
у будь-якому випадку більше електроенергії. Але мої сценарії повинні працювати скрізь
може; Я не хочу їх для систем без FPU іншими мовами
потрібно дублювати лише тому, що Lua там через
Арифметика з плаваючою точкою надто повільна.
* Тільки інженерам та науковцям потрібні числа з плаваючою комою.
Більшість програмістів, які не потрапляють у ці категорії,
насправді навряд чи колись хочуть числа з плаваючою комою, вони насправді хочуть їх
Десяткова арифметика, оскільки вони обчислюються за сумою грошей. Для цього є
Арифметика з плаваючою комою, але сумарна через проблеми округлення
невідповідний.
* Люди, які люблять точні розрахунки, * ненавидять * числа з плаваючою комою. Так
під час обчислення з плаваючою комою трапляється, наприклад, A + B -
B не дорівнює A! Багато людей вважають, що арифметика FP є лише на
особливо складні операції неточно - але насправді це може
навіть із простим додаванням і відніманням до задач округлення
приходь.
Але числа з плаваючою комою все ще мають застосування: якщо з виміряними значеннями
проводиться робота, яка вже за своєю суттю зазнає помилок вимірювання
задокументовані і, отже, неточні, їх точність, як правило, повна
достатньо. Звідси актуальність для інженерів та
Природознавець.
Однак їм зазвичай доводиться обробляти або обробляти великі обсяги даних.
продуктивність важлива, і в таких випадках ви берете лише
немає Lua під рукою, а скоріше такі мови, як C або FORTRAN
руки, які * дуже * швидкі з плаваючою комою.
Отже, як це повернути: числа з плаваючою комою як
Прийняття стандартного типу даних не виконується жодною мовою перекладача
справді сенс.
На BASIC це можна було пояснити історично, а на BASIC комп'ютерах це було
часто просто немає C або FORTRAN як альтернативи - тому довелося
BASIC може робити все, і, отже, також часто опановувати плаваючою комою
Ви не могли дозволити собі цього більше, ніж через брак місця в ПЗУ
реалізувати числовий тип даних. Але це теж було
все ще часи, коли повний перекладач BASIC розміром 8 КіБ (не
MB!) ПЗУ повинен був поміститися. Навіть самі жалюгідні пропозиції
Вбудованих систем сьогодні набагато більше.
Але Lua була б чудовою мовою сценаріїв, особливо для
Типові "випадки використання сценарію", які не мають відношення до плаваючої крапки, є ідеальними
запропонував би - і є плаваюча крапка як основний тип
Блок на нозі і ніякого благословення.
Як додатковий тип це не проблема - а основний тип
сучасна мова сценаріїв має бути цілим числом. (* З *
Перевірка переповнення!) Або ви можете зробити це, як у Python
"Варіантні" типи, які можуть робити і те, і інше.
Я швидко отримаю нову Lua, але від
Формулювання статті Боюсь, що основний тип залишається подібним
до «Плаваючої крапки» та «Ціле число» лише половинчате есе
що навіть повільніше, ніж плаваюча крапка, тому що постійно внутрішній
все перетворюється на плаваючу крапку.
Однак я сподіваюся, що мої страхи справдяться
не себе.