Как правильно решать вопрос с математикой в JS?

Question

[Алексей]

Про 0.1 + 0.2 я знал давно, но вот сегодня неожиданно столкнулся с тем, что и 1.005 * 1000 = 1004.9999999999999, чуть не запоров мне весь сайт.
Вопрос в том, как правильно и без ошибок инкрементить тогда проценты ? тоесть мне надо было за каждую итерацию прибавлять по половине процента 100% + 0.5%, во избежания каких либо проблем, думал что перевод в целочисленную сторону сработает, но оказалось наоборот.
Вобщем, как вы решаете подобные проблемы ?

Answer 1

[Павло Пономаренко]

Сначала умножаете, а потом делите. Вам нужно умножить на 0.5%, а это 1005/1000 ;)

const myValue = 1000;

return myValue * 1005 / 1000;
// ну или 
return myValue + myValue * 5 / 1000;

Comments

[Алексей]

Чего то я вообще не понял. Если бы у меня нормально получилось брать 1005, то и вопроса бы небыло.

(1 * 1000 + 5) / 1000 = 1.005 = 100,5%
(1.005 * 1000 + 5) / 1000 = 1.0099999999999998 = 100,99999999999998 %

[Алексей]

Суть не в том, чтобы получить процент от числа, а увеличить сам процент.
если брать грубо то

var x = 1;
while(true) {
  x += 0.05;
}

Хотел избежать дробных частей, а получилось наоборот ) видмо Math.round придется использовать

[Павло Пономаренко]

Не, вы не поняли. У вас есть необходимый процент. Откуда у вас берется вот этот вот 1.005? Где-то в конфиге, или в базе? Юзер указывает? Или админ? Заставьте его указывать в других значениях. Пусть одно деление будет равнятся не 100 % (1 = 100%, 1.5 = 150%, 2 = 200%). Пусть оно будет в 1/100 процента (то есть 1 = 0.01%, 10 = 0.1%, 100 = 1%, 1000 = 10%, 10000 = 100%).

Теперь, у вас в базе хранится значение. Скажем, надо добавить 50 у.е. (а это 50/100 = 0.5%). В вашем коде вы пишете:

const changeValue = 50; // вот тут ваши полпроцента
const factor = 10000; // а это ваш порог чувствительности, допустимая погрешность. Чем выше - тем меньше погрешность.
return currentValue + currentValue * changeValue / factor;

Или с другими значениями:

const changeValue = 5000; // вот тут ваши полпроцента
const factor = 1000000; // а это ваш порог чувствительности, допустимая погрешность. Чем выше - тем меньше погрешность.
return currentValue + currentValue * changeValue / factor;

[Павло Пономаренко]

Хорошо, у вас есть вот этот пример:

var x = 1;
while(true) {
  x += 0.005;
}

Измените и записывайте его так:

var x = 1000;
while(true) {
  x += 5;
}

А там, где используете х - потом делите на 1000.

currentValue * x / 1000;
// вместо простого
currentValue * x;

Math.round можно использовать, но это решение похуже

[Алексей]

Павло Пономаренко, Суть в чем: у каждого пользователя есть свой модификатор например 1, тоесть 100%, при определенных действиях он может перманентно увеличиваться на некоторое число, в данном примере 0.5% (0.005), также может быть и 0.008% (0.00008) и так далее. Тоесть оно варьируется от условий, но у юзера всегда должен храниться уже готовый такой модификатор для умножения 1.32 например.

[Павло Пономаренко]

Алексей, ну вот и храните его в значительно большем значении. Пусть в вашей базе будет не 1.00008, а 100008. И вы добавляйте не 0.00003, а 3. И тогда получится не 1.00011, а 100011. В базе будет храниться целое число. Умножать вы будете на целое число, а потом поделите на factor. И юзеру перед выводом будете делить на factor. Если какая-то "Перчатка Бесконечности" дает "+0.0003" к силе, то пусть геймдизайнеры запишут, что она дает "+30", а вы поделите на порог в самый последний момент, когда все рассчеты будут завершены.

[Алексей]

Павло Пономаренко, вот в этом то и заключался камень преткновения, расчет на деления этого числа будет просто в разы больше, чем количество инкрементов. Тоесть повышение этого модификатора будет происходить 1-2 раза в сутки, а расчеты с его использованием где-то 300-400 раз в такое же время, поэтому я и посчитал что будет логичней и эффективней хранить для расчета уже готовое число

// вместо такого
1280 * (100008 / 100000)
// использовать это
1280 * 1.00008

[Павло Пономаренко]

Алексей, вы боитесь о производительности? Бросьте. В этом никакого смысла, возможно подход с целыми числами даже быстрее.

На повышение, на самом деле, плевать. Важно, чтобы при рассчетах не было ошибки из-за флоата. Именно потому нужно хранить целые числа, а приводить их к окончательному виду только в самый последний момент

[Алексей]

Павло Пономаренко, это не столько страх, сколько мысль, что использование такого подхода более рациональным. И я щас даже не задеваю преждевременную оптимизацию, но сама идея о том, что пользователей станет хотябы на порядок больше и соответственно количество этих операций возрастет просто в прогрессии, то такая экономия мне показалась логичной. Ладно попробуемс большие целочисленные значения, надеюсь проц ими не поперхнется.

[Павло Пономаренко]

Алексей, это очень преждевременная оптимизация. Процу абсолютно всё-равно как стоят биты в числе. Стоит единичка на 13-й позиции или на 20-й. Эта ваша "оптимизация" никогда не даст снижения нагрузки даже на 0.1% (а это очень мало и, обычно, не стоит свеч).

Делайте так, как будет лучше для вычислений.

Answer 2

[AngReload]

Не очень понятно, откуда у вас появляется число 1.005.
Если оно записано в коде, то вместо 1.005 * 1000 просто пишите 1005
Если оно приходит из инпута, то вместо приведения к числу Number("1.005"), разделите целую и дробную часть

let [integerPart, fractionalPart] = '100.05'.match(/[0-9]+/g); // [ '100', '05']
result = Number(integerPart) * 1000 + Number(fractionalPart);

Если что-то сложнее, то пользуйтесь библиотеками типа https://github.com/MikeMcl/big.js/

Comments

[Алексей]

Цифры берутся отсюда, проще прочитать комментарии предыдущего ответа, чтоб было понятней о чем речь идет. Убивать производительность регуляркой я точно не хочу.

(1 * 1000 + 5) / 1000 = 1.005 = 100,5%
(1.005 * 1000 + 5) / 1000 = 1.0099999999999998 = 100,99999999999998 %

[Павло Пономаренко]

Убивать производительность регуляркой я точно не хочу.

Алексей, я так и думал. Поверьте, один запрос или одна отрисовка одного кадра занимает в миллион раз больше времени чем все советы, которые вам тут дают. Вы убъете производительность регуляркой если запустите её 100000 раз в секунду. 400 раз в сутки - это раз в 3.6 секунды. Вы даже не заметите никакого влияния. Поверьте человеку, который оптимизировал сложные игрушки под JS годами.

[Алексей]

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

[Павло Пономаренко]

Алексей, влияет. Если она сложная, с рекурсивными выражениями и применяется к тексту длиной в десятки тысяч символов тысячи раз в секунду. Тут, конечно, нужно искать другие пути. Вот смотрите

var re = /[0-9]+/g;

console.time('regexp');
for (var x = 0; x < 10000; x++) {
  '100.04'.match(re)
  '100.05'.match(re)
  '100.06'.match(re)
  '100.07'.match(re)
  '100.08'.match(re)
  '200.04'.match(re)
  '200.05'.match(re)
  '200.06'.match(re)
  '200.07'.match(re)
  '200.08'.match(re)
}
console.timeEnd('regexp');

Результат на моем компе - 21.5ms. 100 тысяч матчей отрабатывает приблизительно за время, за которое отрисовывается один кадр. То есть если вы его запустите 100 раз, то пользователь даже не заметит просадки фпс. Просто не отрисует один кадр.

Если вы будете запускать её на сервере (как мой домашний комп) 100 тысяч раз в секунду, то выполнение этой регулярки займет приблизительно 2% процессора. Как считаете, стоит волноваться из-за таких значений?

Как думаете, вы будете выполнять эту регулярку 100 т. раз в секунду, чтобы процессор просел аж на 2% из-за неё?

[AngReload]

Алексей, без регэкспов так. Время выполнения не отличается, в js очень быстрые регулярки.

function getParts(str) {
  const i = str.indexOf('.');
  return [str.substring(0, i), str.substring(i + 1)];
}

[Алексей]

Павло Пономаренко, за 2% я думаю стоит волноваться. Темболее что на вдс процессоры явно послабже чем на домашнем.

AngReload я если честно не понял зачем такие махинации, если можно просто сделать сплит по точке
'50.0123'.split('.')
но суть не в этом, проблему то оно не решает

[Павло Пономаренко]

Алексей, 2% на 100 т. раз в секунду. Такую нагрузку вы собираетесь запускать на vds? Серьёзно? Обычно такую нагрузку держит кластер из многих топовых компов.

[Алексей]

Павло Пономаренко, ну я еще раз повторюсь, 2% это на хорошем процессоре, какая цифра может быть на более слабом это еще надо посмотреть. Весь вдс не решает ведь только одну задачу с этими модификаторами, там и других нагрузок полно, вот поэтому я и боюсь, что суммарно они дадут жесткую просадку.

[Павло Пономаренко]

Алексей, еще раз повторюсь, это на 100 т. раз в секунду. Вы игнорируете мои слова, потому что они противоречят тому, к чему вы привыкли? Ну так отвыкайте от ошибочных мыслей. Если у вас 10 раз в секунду, то вы вообще не заметите никакой разницы. А на 100 т. раз в секунду у вас на vds будет влиять ЛЮБАЯ операция. Добавление элемента в массив, создание класса, вызов функции. Вот только никто в здравом уме не будет запускать 100 000 операций в секунду на vds.