Pascal

[Maslov]

(Оффтоп)

ewert в сообщении #264201 писал(а):

не знаю, просто это откровенно неадекватно (с чисто программистской, да и прикладной точки зрения) -- представлять вещественный результат в целом виде

Вы когда-нибудь НДС считали?

[ewert]

(Оффтоп)

Никогда. И уверен -- теперь уже никогда не буду (или на пенсию уйду, или просто подохну).

Однако же любопытно. А в методиках того налога -- прописаны как-то формальные правила округления?...

[Maslov]

(Оффтоп)

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

[ewert]

(Оффтоп)

Да это понятно. Интересно другое. Там ведь, наверное, есть несколько уровней, на которых возможно округление. И возможно: или на каждом уровне и округлять -- или все расчёты производить "точно", а округлять лишь на самом выходе. Любопытно, регламентировано ли это как-то, ведь результаты-то получатся, вообще говоря, разные. И за те три с половиной недо- или переокруглённых копейки запросто ведь можно и под суд попасть (или во всяком случае привлечь -- было б желание).

[Maslov]

(Оффтоп)

ewert в сообщении #264221 писал(а):

И возможно: или на каждом уровне и округлять -- или все расчёты производить "точно", а округлять лишь на самом выходе.

Ну это в теории. А на практике всё довольно просто . А точно расчёты иногда ни на каком уровне производить не получается. Например, если цена - "100 руб. включая НДС", то для определения цены без НДС надо 100 на 1.18 делить.

ewert в сообщении #264221 писал(а):

И за те три с половиной недо- или переокруглённых копейки запросто ведь можно и под суд попасть (или во всяком случае привлечь -- было б желание).

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

[Circiter]

2ewert

Цитата:

Int64 -- это не замена Comp, с точки зрения языка (хотя хранятся они и совершенно одинаково).

Именно замена. Так сказано во всех мануалах паскаль-компиляторов, в диалектах которых введен тип Int64. Старый тип Comp вообще не рекомендуется использовать.

2Maslov

Цитата:

А ещё у него фиксированная точность.

А у Int64 разве не "фиксированная точность"?

[Maslov]

Circiter в сообщении #264963 писал(а):

2Maslov
Цитата:
А ещё у него фиксированная точность.

А у Int64 разве не "фиксированная точность"?

А при чём тут Int64? Обсуждалось отличие Comp от (других) вещественных типов.

[Dongara]

Для меня лично Pascal симпатичен громадной скоростью трансляции кода - и это не дебильный Бейсик. Будь моя воля, я бы все громадные проекты на нем реализовывал.

[ewert]

Circiter в сообщении #264963 писал(а):

2ewert

Цитата:

Int64 -- это не замена Comp, с точки зрения языка (хотя хранятся они и совершенно одинаково).

Именно замена. Так сказано во всех мануалах паскаль-компиляторов, в диалектах которых введен тип Int64. Старый тип Comp вообще не рекомендуется использовать.

Не знаю, что в мануалах. Но что 100% (с точки зрения собственно языка, а не формата хранения): Int64 -- стандартный целый тип, только 8-байтовый. Comp -- сугубо вещественный, но уродливый.