Луа со цели броеви w; повторно апсолутен хит форум - Хајсе на Интернет
Јас всушност многу ми се допаѓа Луа како јазик, но тој постоел досега
Особено 2 работи што ме спречија да го правам тоа интензивно
да се користи:
* Оние I/O функции каде грешките се незгодни за барање со тврдење ()
наместо само да се фрли исклучок без оглед на јазикот
да, поддржан во секој случај.
* Индексите на низи засновани на "1".
Последниот проблем е чисто лична аверзија, но не би бил
сериозна причина да не се користи јазикот (затоа и напишав
само над * 2 * причини.)
Поранешниот проблем може да се реши релативно лесно со користење на
I/O функциите се спакувани во класи на обвивки од кои упатството
Отстрани проверка на грешка.
Но, има малку што може да се направи против аритметиката со подвижна точка, што не ми се допаѓа
да направиш.
Може да го смените стандардниот тип од двојно во uint64_t
преименувајте што се однесува до самиот јазик - сè што треба да направите е да внесете a
# дефинирај ја промената.
Како и да е, како резултат веќе немате Lua: Во спецификацијата за јазик
и во сите можни системски библиотеки како и C-API се наоѓаат
се користат сите можни цифри со броеви на подвижна точка.
Ако го смените типот на бројот на глобално ниво во цел број, ќе морате
Исто така препишете ги повеќето функции на стандардната библиотека
или понекогаш дури и да го сменат нивниот API.
Повеќето од постојните екстензии за Луа тогаш може да бидат
исто така, не користете го, но треба да го преработите или барем
лепенка значително.
Пред сè, таков модифициран толкувач повеќе не би бил во
Способни да извршуваат нормални скрипти на Луа: Де факто би имале поинаква
Создадете јазик.
Сите овие размислувања досега ме спречуваа во тоа
Користење на Луа, иако ми се допадна многу подобро од Перл,
Python, Tcl или Ruby.
Би сакал Луа да работи исто како Пајтон
Загриженост за броевите: Какви било точни цели броеви или броеви на подвижна точка ако
има голем број на децимални места. Дополнителен тип на децимални податоци
би бил шлаг на тортата, но исто така можете да ја погледнете директно во
Спроведете ја Луа како час.
Единственото нешто што навистина е важно е дека вградениот базен тип на податоци не е
присилно останува тип на подвижна точка.
Лебдечката точка е исто така совршена во ред - подвижната точка е задолжителна
но идиотизам:
* Броевите на подвижна точка може ефикасно да се пресметаат само со FPU.
Но, особено кај малите, особено компјутерите што штедат енергија, често има
нема FPU. Овие тогаш треба да имитираат подвижна точка во софтверот што
е многу повеќе работа, трае подолго и троши повеќе електрична енергија. Но
дури и да има FPU, тоа ќе троши повеќе енергија од истото
Чип што има само цели единици и функциите FPU
би изоставил: аритметиката на ФП едноставно неизбежно бара повеќе
Гејтс треба да се имплементираат колку што е јасна аритметика
е посложена. Затоа, дури и ако не е побавно, тоа чини
во секој случај повеќе електрична енергија. Но, моите сценарија треба да се одвиваат насекаде
може; Не ги сакам за системи без FPU на други јазици
треба да се дуплираат само затоа што Луа таму поради
Аритметиката со подвижна точка е премногу бавна.
* Само инженерите и научниците имаат потреба од броеви на подвижна точка.
Повеќето програмери кои не спаѓаат во овие категории,
во вистината, тешко дека некогаш сакаат броеви со подвижна точка, тие всушност ги сакаат
Десетина аритметика затоа што тие пресметуваат со износи на пари. За тоа е
Аритметичка подвижна точка, но тотална поради проблемите со заокружувањето
несоодветно.
* Луѓе кои сакаат точни пресметки, * мразат * броеви со подвижна точка. Значи
при пресметки на подвижна точка се случува, на пример, A + B -
Б не е еднакво на А! Многу луѓе веруваат дека аритметиката на ФП е само на
особено сложени операции неточно - но всушност може
дури и со едноставно собирање и одземање на проблеми со заокружување
дојди.
Но, броевите со подвижна точка сè уште имаат употреба: Ако со измерени вредности
се извршува работа, што веќе е инхерентно предмет на грешки во мерењето
документирана и со тоа непрецизна, нивната точност е обично целосна
доволен Оттука и релевантноста за инженерите и
Природен научник.
Сепак, тие обично треба да обработуваат или обработуваат големи количини на податоци.
перформансите се важни и во вакви случаи земате само
нема Луа при рака, туку јазици како Ц или FORTRAN
рака што се * навистина * брзи со подвижна точка.
Па, како да се сврти: Броеви на подвижна точка како
Земањето стандарден тип на податоци не го прави на кој било јазик на толкувач
навистина смисла.
Во BASIC може да се објасни историски, а на BASIC компјутерите имало
едноставно, без C или FORTRAN како алтернатива - затоа мораше
ОСНОВНО може да стори сé, а со тоа и да совлада подвижна точка, и често
не можевте да си дозволите повеќе од тоа што немаше простор во ROM-от
имплементира нумерички тип на податоци. Но и тоа беше
сè уште времињата кога комплетен ОСНОВЕН толкувач во 8 KiB (не
МБ!) РОМ-от мораше да се вклопи. Дури и најпатетичната понуда
Вградените системи обично се многу повеќе денес.
Но, Луа би бил одличен јазик за скрипти, особено за
Идеални се типичните „случаи на употреба на скрипта“ кои не се релевантни за подвижната точка
би понудил - и има лебдечка точка како основен тип
Блокирање на ногата и без благослов.
Како дополнителен тип, тоа не е проблем - туку основниот тип
современ скриптен јазик треба да биде цел број. (* Со *
Проверка на прелевање!) Или можете да го направите како во Пајтон
Типови „варијанти“ што можат да ги прават и двете.
Quicklyе ја добијам новата Луа брзо, но од
Формулација на статијата Се плашам дека основниот тип останува таков
пред Floating Point и Integer само есеј со половина срце
што е дури и побавно од подвижната точка бидејќи постојано внатрешно
сè е претворено во подвижна точка.
Се надевам, сепак, дека моите стравови се обистиниле
не ти самиот.