Подробнее
картинка с текстом,javascript,языки программирования,it-юмор,geek,Прикольные гаджеты. Научный, инженерный и айтишный юмор
Еще на тему
картинка с текстом javascript языки программирования it-юмор geek
Подробнее
картинка с текстом,javascript,языки программирования,it-юмор,geek,Прикольные гаджеты. Научный, инженерный и айтишный юмор
Подробнее
картинка с текстом,javascript,языки программирования,it-юмор,geek,Прикольные гаджеты. Научный, инженерный и айтишный юмор
![e* \
; -s Tomasz is building cloudash.dev 1d
^ npm install esllnt-conflg-airbnb
'••'.K r
Q 31 tn 683 5 023 ¿j](http://img0.reactor.cc/pics/thumbnail/post-5026524.jpg "e* \
; -s Tomasz is building cloudash.dev 1d
^ npm install esllnt-conflg-airbnb
'••'.K r
Q 31 tn 683 5 023 ¿j")
" + " применяется как к числам для сложения, так и к строкам для конкатенации, первый операнд строка"5", значит применяем конкатенацию, приводя 3 к строке и получаем "53".
А последний пример комбинация из двух первых по сути, только к двум применяется унарный оператор " - ", "2" приводится к числу 2, добавляется отрицание -2, приводится опять к строке "-2", а потом конкатенируется с "5"!
А если у тебя там еще не константы, а пара переменных, которые пришли из разных мест через несколько слоев вызовов функций, то это, вообще, поле чудес с попыткой угадать "5" там было или 5.
https://www.destroyallsoftware.com/talks/wat
let pidor = +traps + +memes;
Но в реальном мире процессоры поддерживают работу с дробными числами только в этом формате. Потому если ты хочешь другой, то будь готов реализовывать его руками(ну или брать либу), и будь готов к критической просадке производительности, если тебе нужно много арифметики. Потому что тебе всю блядскую арифметику придется делать самому.
И, на самом деле, абсолютно везде, где идёт работа с деньгами, то есть, дробные числа это суммы денег, всё делается именно таким образом. Потому что точность там намного важнее скорости.
А, скажем, просчёт сцены для игры - на неточных, но быстрых флоатах.
У тебя может быть несколько процессов с разной точностью. По обстоятельствам, не зависящим от тебя. Грубо говоря, где-то используется точность до цента, а где-то до сотой доли цента. Несмотря на то, что физически десятых и сотых долей цента не существует, в расчётах они могут участвовать. И внешние сервисы могут использовать различную точность, и тебе нужно с ними коммуницировать.
Есть также сервисы, которые в протоколе указывают, сколько знаков после запятой используется, и это число изменяемое в зависимости от специфики.
Так что - нет, нихуя оно не фиксед в общем случае.
Точка может плавать. Никто не гарантирует одинаковый порядок, это невозможно для общего случая. Разве что для одной валюты, и одного типа операций.
Надо тебе посчитать 1.257% от суммы, и ты уже теряешь точность со своими 5 знаками.
Но, да. Я работал со всеми валютами, кроме рубля - он сейчас забанен везде.
Только вот для плавающей точки последний знак это могут быть сотни. Не сотые доли, а сотни.
На сотнях миллионов транзакций получается нихуя не маленькая.
Пока ты в рамках одного фин процесса, с одной валютой и требованиями, у тебя обычные лонги(в инты может не влезть), и просто рядом тусуются настройки количества знаков, валюты, и отэтовсе. Сами расчеты быстрые, бо целочисленные - пока мы в одной "системе координат".
Но на стыке (внутри, или для внешнего сервиса), где могут быть разные настройки той же точки, приходится это учитывать и конвертировать. По разным правилам - где-то и округление идёт, но чаще нет, там уже от конкретики зависит.
Смотри.
Если у нас перевод денег со счёта на счёт, то точность - до минимальной расчётной единицы валюты. Обычно это 2 знака от целого значения в валюте(2.55 доллара), и 0 знаков от количества в минимальных единицах(255 центов). Впрочем, подлянка и тут в том, что у валют это разное количество. Например, у венгерского форинта нет "копеек", минимальная единица это сам форинт.
Но если ты считаешь комиссию, или другой процент, то у тебя точность - это (порядок разницы минимальной единицы к основной) + 2 +(максимальное количество знаков после запятой в сумме процентной ставки).
То есть, для доллара, и только целых процентов, это 2+2+0. Для форинта, когда процент возможен типа 1.5 - это 0+2+1.
What the f*ck JavaScript?
Это добавляет геморроя проверки типа каждый раз, если надо писать нормально, а не "хуяк, хуяк, и так сойдёт", добавляет геморроя при чтении кода(блять, какой же тип сука ожидается у этой ахуительной функции???), добавляет геморроя в виде stupid undefined behavior в рантайме, когда пришло что-то не то, обработалось странным образом без ошибок в какую-то дичь, и успешно улетело дальше.
Но этим мало того, что пользуются, некоторые это любят, и даже тащат на сервер. Повбывав бы.
Типа:
var result:Int = 1;
И в рантайме это может быть проигнорировано
Типа:
var num1:Int = 1;
var num2:Int = 1;
var result:Int = num1 + num2; // получится 11
Но пока что в топе по пиздецу кодинг на HAXE который потом конвертится в JS
Я пока над этим проджэктом работал - бухал жестко
Я разные вариации встречал
Там довольно большой проэкт был. Одних только погромистов 50+ шт
Там вообще весело было:
Изначально проэкт на чистом шарпе написан.
Потом шарповый код конвертится в Haxe
Потом хаксовый код конвертится в JS
Нахуя?
Насколько я понял, лид, который этот проект курировал пиздец как не любит юнити(изначально на неё планировали переписать)
И решил вот такое безобразие устроить