(Untitled)

[dmih]

Чтобы закрыть тему foat-ов, разовью еще немного 0.9(9) = 1 и фобию по поводу "аааа страшная потеря точности" в виде 0.9999999998765

Comments

[spiculator]

Надо в rational хранить, тогда вообще на всё можно положить. Никаких действий, кроме отнять-сложить-умножить-разделить, в биллинге в принципе быть не может. Хотя при сложении дробей с разными делителями результат может получиться некрасивый, на этот случай применяем вместо int'а бескончный int, как там он называется. :)

[spiculator]

Жалко, что акт нельзя выставить на 14+3/31 р.

[dmih]

1/31 с 1/30 и 1/28 и 1/29 очень уж некрасиво складывается.
Сразу наступит такой ад, что неясно, в чем недостаток хранить просто сразу с эпсилон-точностью, где эпсилон доказанно устраивает :)

[spiculator]

Всего-то четыре разных делителя, наименьшее общее кратное -- четыреста тысяч, в long влезет. :)

[dmih]

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

[spiculator]

Ну, вообще говоря, вариантов (оценочно) 4(месяц)+4(3 месяца)+4(6 месяцев)+4(год)+4(два года), то есть примерно 20, плюс-минус два. Но в long уже не влезет, да. :) Зато bigint не очень даже длинный будет. :)

[dmih]

Не, вариантов гораздо больше. Например даже для 2х месяцев бывает сумма дней в месяцах 57,58,59,60,61 кажется. Дальше там с ростом числа месяцев всё взрывается еще всё на пару степеней минимум, даже для одного интервала.

[spiculator]

У нас нет двух месяцев, есть три. Для двух многовато, да. Для трёх -- строго четыре (от 28+31+30=89 до 31+31+30=92). Для шести -- вообще три, от 28+31+30+31+30+31=181 до 31+30+31+30+31+31=184. Дальше аналогично.

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

Более того, часть периодов являются кратными для других периодов, так что их вообще всё равно что нет (нас же интересует только НОК).

[dmih]

Взрыв в итоговом перемножении в смысле.

Ты не очень правильно считаешь. Во-первых неочевидности см. ниже.
Во-вторых, ты берешь месяцы целиком, а период произвольно начинается в середине месяца. Я что-то не геракл считать всё строго, но наугад кажется, число вариантов дней в периоде там от этого еще растет.

[spiculator]

Для двух кстати тоже четыре, от 28+31 до 31+31 всего лишь.

[dmih]

Ну в принципе да, скорее всего ты прав.

[spiculator]

Для года -- два вариант (високосный или нет), для двух -- два (один из них точно невисокосный), для четырёх -- вообще один вариант. Хотя не, для четырёх тоже два, но второй вариант в последний раз был в 1900-м году, а в следующий раз будет в 2100-м. :)

[dmih]

Вообще наверное можно строго вычислить это прекрасное число и в этих единицах сразу всё и хранить :)

[spiculator]

Я вычислил это прекрасное число. :) Вот те варианты, которые я смог придумать:

28 29 30 31 89 90 91 92 181 182 183 184 365 366 730 731 1460 1461

НОК для них -- 17298125181936645653880, он влезает в 74 бита. Пусть я даже пару-тройку варинтов ещё забыл, всё равно 80 бит хватит заведомо, значит например от int128 остаётся ещё 48 бит, что в принципе для биллинга хватит. :)

[dmih]

Google по этому числу ничего не ищет. Возможно где-то ошибка. :)

[spiculator]

НОК для всех чисел от 1 до 356 -- 2850624383252485846179265922255309899425069992356270089301060675742093164285358590140215269640975472499316259309180587721325320853614906944688757919328000, он влезает примерно в 510 бит (мне нечем логарифм от этого взять, я чисто по числу десятичных цифр). В связи с этим предполагаю, что int512 нам всё же хватит почти наверняка. :)