компенсация при увольнение

[waw]

Вы же народ напугали, они калькуляторы менять начали.

Похоже, что ничего менять не надо. Считать на "2", но нажимать на "=" только один раз в конце вычислений. Промежуточные результаты калькулятор не округляет.

[waw]

А бывают интеллектуальные калькуляторы-не в компе, а физические такие?

Потеря точности при делении (2,33333333333333) как бы компенсируется при округлении результата до определенного числа знаков (2, 4 или 6), если это количество меньше полной разрядности калькулятора (обычно 12). Не ставьте его в положение "F" без необходимости, нажимайте "=" только в конце вычислений и все будет Ok.

Со словом "интеллектуальные" я погорячился. Просто не знал как понятнее объяснить. На самом деле компьютерный калькулятор отличается от бытового только разрядностью. Он показывает вам 31 десятичную тройку, а в своей памяти хранит большее количество этих троек (но тоже не бесконечное). То есть фактически результат с 31 дес.знаком - это тоже округленный результат (но до 31 знака).

[Wika]

Беру и считаю:

1. 2,(3) = 2 + 1/3

2. (2 + 1/3) * 18 = (2 * 18) + (1/3 * 18) = 36 + 6 = 42

Действительно, математика - наука точная.

А как по вашему нужно считать если человек отработал скажем 1 год и 7 месяцев, 9 месяцев или 3 месяца? как вы обойдетесь без 28/12?

[waw]

как вы обойдетесь без 28/12?

Не обойдусь, буду делить (с трудом).

Хотя многих споров можно было бы избежать простой перестановкой действий:
28 / 12 * 18 = 28 * 18 / 12

[Шмымзик]

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

Легко, этому в 4 классе средней школы учили, как щаз помню:
28/12*18=28/2*3=14*3=42
Даже бумажка не понадобилась.

[Vaclav]

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

Над.К, извините, что не сразу, но у меня нет возможности работать в Форуме каждый день.
Во-первых, я вообще не пользуюсь настольными калькуляторами (для работы мне вполне хватает "виндовского"). Однако все, что написал waw о хранимых и отображаемых результатах - правда не только для WinCalc, но и для моего старого инженерного калькулятора Casio (примерно 1993 года выпуска). И на любых других нормальных калькуляторах встречал правильное отношение к этому, потому и привык уже!

Второе. В вычислениях, например, суммы отпускных/КНО я считаю приемлемой только одну "остановку с округлением" (это когда мы "нажимаем равно") - среднедневной заработок. Все остальные округления - "незаконны" (не предусмотрены методикой), приведут к искажению результата (пусть и на копейки), потому и недопустимы.

[Над.К]

Извините, но я вот считаю нормальным калькулятор тот, который выдает 41,99999...
Поэтому не стоит разбрасываться такими словами "нормально", "не нормально".
Округление в нужную сторону тут совершенно не причем, не стоит забывать, что калькулятор существует не только для расчета среднедневных заработков.
Калькулятор в виндоус с моей точки зрения не удобен и вообще отваритителен. Но я ведь не пропагандирую такую точку зрения с криками - у Вас неправильный калькулятор?

Легко, этому в 4 классе средней школы учили, как щаз помню:
28/12*18=28/2*3=14*3=42
Даже бумажка не понадобилась.

А ты местами не меняй. В данной ситуации сначала делится 28/12, и получается 2 и 3 десятых в периоде. И получится целым оно никак не может.

[Vaclav]

Это мне что ли крики приписывают? Там все было на уровне шуток...

[Шмымзик]

А ты местами не меняй.

Я не меняю местами! Говорю же - как в школе учили. Находим общий множитель у числителя и знаменателя, сокращаем (получается 28/2*3 вместо 28/12*18), и после этого считаем. Хоть на калькуляторе, хоть как. Еще насчет менять местами - дык в школе тоже учили... что от перемены мест... ну и далее ))) А правила арифметики нормативные документы не меняют. Пока что.

[waw]

В данной ситуации сначала делится 28/12, и получается 2 и 3 десятых в периоде. И получится целым оно никак не может.

Про 2 и 3 в периоде я тоже уже отписался в #30.

[waw]

И все же Citizen в режиме F теряет точность при делении, в отличие от WinCalc.
Собственно, он ее теряет во всех режимах, просто в режимах 2, 3, 4 или 6 мы этого не замечаем из-за последующего округления. Я уже писал, что потеря точности "как бы компенсируется".

[Над.К]

там все было на уровне шуток...

угу, только народ помчался менять калькуляторы.
Шмымзик, значит нас учили по разному Но в любом случае калькулятор считает не так как ты. Он сначала делит 28/12 и получает число в периоде. Которое уже никак не сможет стать целым, при умножении его на что-либо.

[waw]

Но в любом случае калькулятор считает не так как ты. Он сначала делит 28/12 и получает...

Не надо пользоваться живыми калькуляторами

Он сначала делит 28/12 и получает число в периоде. Которое уже никак не сможет стать целым, при умножении его на что-либо.

Вы же сами меня просили умножить 2,(3) на 18. Я умножил и получил целое число. А теперь, словно не замечая этого, опять говорите, что оно "никак не сможет стать целым".

На самом деле, все с точностью до наоборот:

Любая бесконечная периодическая дробь может быть обращена в простую дробь.

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

И есть правила, позволяющие находить эти числа для любой бесконечной периодической дроби.
(для 2,(3) - это число 3, то есть 2,(3) * 3 = 7)

[waw]

Проблему бытовых настольных калькуляторов типа Citizen (и им подобных) я вижу в том, что они хранят в памяти ровно столько же цифр, сколько и отображают. И в этом их отличие в худшую сторону от того же WinCalc.

Как в этом убедиться:

1) в режиме F делим 28 на 12 (видим 2,33333333333) и умножаем на 18.
Получили 41,9999999999.

2) теперь просто руками набираем 2,33333333333, умножаем на 18.
Получили те же 41,9999999999.

Этот результат означает, что когда мы в первом случае делили 28 на 12, то отображаемый результат (2,33333333333) и хранимый в памяти калькулятора результат одинаковы, и мы видим потерю точности после умножения на 18.

WinCalc в этих же тестах будет вести себя иначе:

1) После 28 / 12 на экране отобразится 2,3333333333333333333333333333333, но после умножения на 18 появится результат 42.

2) Если же вы руками наберете 2,3333333333333333333333333333333, а затем умножите на 18, то результат будет другой:
41,999999999999999999999999999994

Это означает, что результат деления 28/12 хоть и отображается тем же числом на экране, но в памяти программы хранится с большей точностью (хотя конечно и не с бесконечной), и умножается затем на 18 это более точное число, что и приводит к результату 42, которое на самом деле получается округлением числа 41 и много много "9" (сколько, не знаю) до максимальной точности WinCalc'a.

[waw]

Но для бухгалтеров проблемы, описанной выше, можно считать что и не существует, так как требуемую в бухгалтерии точность они обеспечивают и с запасом.
Просто:
1) не надо пользоваться режимом F без необходимости;
2) не округлять промежуточные результаты, нажимая на "=".

Это не инструкция, а мои собственные "наблюдения за поведением". Так что все дополнения, исправления принимаются (для дальнейшего тестирования ).

[Шмымзик]

Он сначала делит 28/12 и получает число в периоде. Которое уже никак не сможет стать целым, при умножении его на что-либо.

Я не о калькуляторе, а о пользователях.
В нормативке отсутствует методика "сначала 28 делим на 12, а потом...". Сказано о пропорциональной компенсации.
С моей точки зрения, фраза:

у меня получилось, что компенсацию, я должна выплатить за 42 дня. я всегда немного округляю, тем более, что ведь в пользу работника, значит, это допустимо.

звучит так же странно, как и :
"у меня получилось, что компенсацию, я должна выплатить за 28 дней я всегда немного округляю, тем более, что ведь в пользу работника, значит, это допустимо" - если речь идет о КНО для сотрудника, отработавшего ровно год.
Притом после расчетов типа: 28/12=2,(3)*12=27,(9)
Тем более, что в рассматриваемом примере совершенно очевидно, что сотруднику положено 1,5 отпуска.