Сообщение Re[16]: Круглое число от 01.03.2017 7:35
Изменено 01.03.2017 7:44 netch80
Re[16]: Круглое число
Здравствуйте, кт, Вы писали:
Разверну секции в ответе.
кт>А вообще, мне эта тема надоела. Надоело спорить с людьми, никогда не видевшими реального использования BCD-команд в программах.
Я видел. Причём не только на твоём любимом x86, а и на S/360. Так что это ещё вопрос, кому должно надоесть спорить с тем, кто видел слишком мало, зато упёрто игнорирует слова более опытных коллег.
кт>Описание, как определяется точность при всех действиях входит в официальное описание языка, например, здесь:
кт>page 349b, http://bitsavers.trailing-edge.com/pdf/ibm/360/pli/GC33-0009-4_PLI_Checkout_And_Opt_Compiler_Lang_Ref_Oct76.pdf
Интересный документ, спасибо. Не скажу, что полезный, всё-таки интерес чисто исторический, но перечитаю на досуге.
Только вот на вопрос коллеги pagid он не отвечает, и это странно, что ты этого не видишь.
Например, если надо деньги в копейках умножить на 17%, должна быть точность 4 цифры после запятой, или нет? Чисто по правилам главы F — должна, а по целевой задаче — неизвестно, скорее всего нужно вернуться к копейкам (если это налог), но может быть полезно и усилить точность, если это вычисления для разбивки кредита на части. Там же тебе дадут ровно 4 цифры, что может оказаться для конкретной задачи самым бесполезным.
(Мнэээ... где картинки из этого документа, со страницы 338, по его нумерации, и далее?)
кт>Что касается всяких умножений и делений, то это все давно отработано и транслятор не вешается. Вешатся должны те, у которых из ничего вдруг лимит в копейку получился
кт>А еще через миллион транзакций это может быть уже не копейка. Вот тогда и объясняйте, что это допустимо.
Количество транзакций не имеет значения. Имеет значение то, что любые деньги должны быть распилены на части ровно, без потерь, а это значит, например, что 1.00 на 3 делится не иначе, как 0.33+0.33+0.34, при том, что 1.00/3 само по себе будет округлено до 0.33 даже в самой лучшей десятичной арифметике, а, значит, надо помнить, что после деления может результат не сойтись.
Как именно это будет обеспечено программистом — уже его дело и его заказчика. Должно быть чётко прописано ТЗ, что делать с лишними или недостающими копейками. Обычно такое делается итерациями вычитания; в случае двоичной арифметики есть методы оценки погрешности и корректировки по ходу, не буду тут подробно расписывать, но они неплохо проработаны.
В примере на экране телефона это было не проработано именно на уровне ТЗ, компьютер не виноват.
кт> а введен специальный механизм расчетов, имеющий в Х86 даже аппаратную поддержку.
А вот этот логический переход уже некорректен. Из расчётов с десятичной точкой никак не следует необходимость BCD, особенно стиля x86 и S/360.
BCD было хоть как-то выгодным ровно до того момента, когда стало доступным машинное умножение быстрее, чем O(N^2). Я не про Карацубу, Тоома-Кука и т.п., а про умножение одного слова на одно слово. На современном техническом уровне нарисовать умножение N*N сеткой из И+сумматоры — меньше чем копейки. Но даже на более древних методах уже в i286 умножение стало стоить чуть больше, чем собственно выборка команд и операндов.
кт>https://groups.google.com/forum/#!forum/comp.lang.pl1
кт>Там среди завсегдатаев есть несколько пожилых преподавателей из калифорнийских ВУЗов
кт>Они доброжелательно относятся к задающим вопросы.
кт>Задайте им вопрос и, вероятно, они понятнее меня и с примерами объяснят, почему полвека назад очевидная идея при финансовых расчетах хранить центы, копейки и прочие фартинги в виде целых чисел была отвергнута,
Это и так известно — не отвергнута. Но для того, чтобы не путать прикладных программистов финансовой области, которым слишком сложно и вообще не нужно объяснять, как оно работает внутри, маскировка под десятичную плавучку была введена на уровне языка.
Разверну секции в ответе.
кт>А вообще, мне эта тема надоела. Надоело спорить с людьми, никогда не видевшими реального использования BCD-команд в программах.
Я видел. Причём не только на твоём любимом x86, а и на S/360. Так что это ещё вопрос, кому должно надоесть спорить с тем, кто видел слишком мало, зато упёрто игнорирует слова более опытных коллег.
кт>Описание, как определяется точность при всех действиях входит в официальное описание языка, например, здесь:
кт>page 349b, http://bitsavers.trailing-edge.com/pdf/ibm/360/pli/GC33-0009-4_PLI_Checkout_And_Opt_Compiler_Lang_Ref_Oct76.pdf
Интересный документ, спасибо. Не скажу, что полезный, всё-таки интерес чисто исторический, но перечитаю на досуге.
Только вот на вопрос коллеги pagid он не отвечает, и это странно, что ты этого не видишь.
Например, если надо деньги в копейках умножить на 17%, должна быть точность 4 цифры после запятой, или нет? Чисто по правилам главы F — должна, а по целевой задаче — неизвестно, скорее всего нужно вернуться к копейкам (если это налог), но может быть полезно и усилить точность, если это вычисления для разбивки кредита на части. Там же тебе дадут ровно 4 цифры, что может оказаться для конкретной задачи самым бесполезным.
(Мнэээ... где картинки из этого документа, со страницы 338, по его нумерации, и далее?)
кт>Что касается всяких умножений и делений, то это все давно отработано и транслятор не вешается. Вешатся должны те, у которых из ничего вдруг лимит в копейку получился
кт>А еще через миллион транзакций это может быть уже не копейка. Вот тогда и объясняйте, что это допустимо.
Количество транзакций не имеет значения. Имеет значение то, что любые деньги должны быть распилены на части ровно, без потерь, а это значит, например, что 1.00 на 3 делится не иначе, как 0.33+0.33+0.34, при том, что 1.00/3 само по себе будет округлено до 0.33 даже в самой лучшей десятичной арифметике, а, значит, надо помнить, что после деления может результат не сойтись.
Как именно это будет обеспечено программистом — уже его дело и его заказчика. Должно быть чётко прописано ТЗ, что делать с лишними или недостающими копейками. Обычно такое делается итерациями вычитания; в случае двоичной арифметики есть методы оценки погрешности и корректировки по ходу, не буду тут подробно расписывать, но они неплохо проработаны.
В примере на экране телефона это было не проработано именно на уровне ТЗ, компьютер не виноват.
кт> а введен специальный механизм расчетов, имеющий в Х86 даже аппаратную поддержку.
А вот этот логический переход уже некорректен. Из расчётов с десятичной точкой никак не следует необходимость BCD, особенно стиля x86 и S/360.
BCD было хоть как-то выгодным ровно до того момента, когда стало доступным машинное умножение быстрее, чем O(N^2). Я не про Карацубу, Тоома-Кука и т.п., а про умножение одного слова на одно слово. На современном техническом уровне нарисовать умножение N*N сеткой из И+сумматоры — меньше чем копейки. Но даже на более древних методах уже в i286 умножение стало стоить чуть больше, чем собственно выборка команд и операндов.
кт>https://groups.google.com/forum/#!forum/comp.lang.pl1
кт>Там среди завсегдатаев есть несколько пожилых преподавателей из калифорнийских ВУЗов
кт>Они доброжелательно относятся к задающим вопросы.
кт>Задайте им вопрос и, вероятно, они понятнее меня и с примерами объяснят, почему полвека назад очевидная идея при финансовых расчетах хранить центы, копейки и прочие фартинги в виде целых чисел была отвергнута,
Это и так известно — не отвергнута. Но для того, чтобы не путать прикладных программистов финансовой области, которым слишком сложно и вообще не нужно объяснять, как оно работает внутри, маскировка под десятичную плавучку была введена на уровне языка.
Re[16]: Круглое число
Здравствуйте, кт, Вы писали:
Разверну секции в ответе.
кт>А вообще, мне эта тема надоела. Надоело спорить с людьми, никогда не видевшими реального использования BCD-команд в программах.
Я видел. Причём не только на твоём любимом x86, а и на S/360. Так что это ещё вопрос, кому должно надоесть спорить с тем, кто видел слишком мало, зато упёрто игнорирует слова более опытных коллег.
кт>Описание, как определяется точность при всех действиях входит в официальное описание языка, например, здесь:
кт>page 349b, http://bitsavers.trailing-edge.com/pdf/ibm/360/pli/GC33-0009-4_PLI_Checkout_And_Opt_Compiler_Lang_Ref_Oct76.pdf
Интересный документ, спасибо. Не скажу, что полезный, всё-таки интерес чисто исторический, но перечитаю на досуге.
Только вот на вопрос коллеги pagid он не отвечает, и это странно, что ты этого не видишь.
Например, если надо деньги в копейках умножить на 17%, должна быть точность 2, 4 цифры после запятой, или сколько? Чисто по правилам главы F — должна 4 (я правильно прочёл?), а по целевой задаче — неизвестно, скорее всего нужно вернуться к копейкам (если это налог), но может быть полезно и усилить точность, если это вычисления для разбивки кредита на части.
Кстати, там ещё и ни слова про правила округления результатов, не представимых в целевом размере. А это ещё более важно. Если я не нашёл, хотя написано — укажи, пожалуйста, конкретную страницу.
кт>Что касается всяких умножений и делений, то это все давно отработано и транслятор не вешается. Вешатся должны те, у которых из ничего вдруг лимит в копейку получился
кт>А еще через миллион транзакций это может быть уже не копейка. Вот тогда и объясняйте, что это допустимо.
Количество транзакций не имеет значения. Имеет значение то, что любые деньги должны быть распилены на части ровно, без потерь, а это значит, например, что 1.00 на 3 делится не иначе, как 0.33+0.33+0.34, при том, что 1.00/3 само по себе будет округлено до 0.33 даже в самой лучшей десятичной арифметике, а, значит, надо помнить, что после деления может результат не сойтись.
Как именно это будет обеспечено программистом — уже его дело и его заказчика. Должно быть чётко прописано ТЗ, что делать с лишними или недостающими копейками. Обычно такое делается итерациями вычитания; в случае двоичной арифметики есть методы оценки погрешности и корректировки по ходу, не буду тут подробно расписывать, но они неплохо проработаны.
В примере на экране телефона это было не проработано именно на уровне ТЗ, компьютер не виноват.
кт> а введен специальный механизм расчетов, имеющий в Х86 даже аппаратную поддержку.
А вот этот логический переход уже некорректен. Из расчётов с десятичной точкой никак не следует необходимость BCD, особенно стиля x86 и S/360.
BCD было хоть как-то выгодным ровно до того момента, когда стало доступным машинное умножение быстрее, чем O(N^2). Я не про Карацубу, Тоома-Кука и т.п., а про умножение одного слова на одно слово. На современном техническом уровне нарисовать умножение N*N сеткой из И+сумматоры — меньше чем копейки. Но даже на более древних методах уже в i286 умножение стало стоить чуть больше, чем собственно выборка команд и операндов.
кт>https://groups.google.com/forum/#!forum/comp.lang.pl1
кт>Там среди завсегдатаев есть несколько пожилых преподавателей из калифорнийских ВУЗов
кт>Они доброжелательно относятся к задающим вопросы.
кт>Задайте им вопрос и, вероятно, они понятнее меня и с примерами объяснят, почему полвека назад очевидная идея при финансовых расчетах хранить центы, копейки и прочие фартинги в виде целых чисел была отвергнута,
Это и так известно — не отвергнута. Но для того, чтобы не путать прикладных программистов финансовой области, которым слишком сложно и вообще не нужно объяснять, как оно работает внутри, маскировка под десятичную плавучку была введена на уровне языка.
Разверну секции в ответе.
кт>А вообще, мне эта тема надоела. Надоело спорить с людьми, никогда не видевшими реального использования BCD-команд в программах.
Я видел. Причём не только на твоём любимом x86, а и на S/360. Так что это ещё вопрос, кому должно надоесть спорить с тем, кто видел слишком мало, зато упёрто игнорирует слова более опытных коллег.
кт>Описание, как определяется точность при всех действиях входит в официальное описание языка, например, здесь:
кт>page 349b, http://bitsavers.trailing-edge.com/pdf/ibm/360/pli/GC33-0009-4_PLI_Checkout_And_Opt_Compiler_Lang_Ref_Oct76.pdf
Интересный документ, спасибо. Не скажу, что полезный, всё-таки интерес чисто исторический, но перечитаю на досуге.
Только вот на вопрос коллеги pagid он не отвечает, и это странно, что ты этого не видишь.
Например, если надо деньги в копейках умножить на 17%, должна быть точность 2, 4 цифры после запятой, или сколько? Чисто по правилам главы F — должна 4 (я правильно прочёл?), а по целевой задаче — неизвестно, скорее всего нужно вернуться к копейкам (если это налог), но может быть полезно и усилить точность, если это вычисления для разбивки кредита на части.
Кстати, там ещё и ни слова про правила округления результатов, не представимых в целевом размере. А это ещё более важно. Если я не нашёл, хотя написано — укажи, пожалуйста, конкретную страницу.
кт>Что касается всяких умножений и делений, то это все давно отработано и транслятор не вешается. Вешатся должны те, у которых из ничего вдруг лимит в копейку получился
кт>А еще через миллион транзакций это может быть уже не копейка. Вот тогда и объясняйте, что это допустимо.
Количество транзакций не имеет значения. Имеет значение то, что любые деньги должны быть распилены на части ровно, без потерь, а это значит, например, что 1.00 на 3 делится не иначе, как 0.33+0.33+0.34, при том, что 1.00/3 само по себе будет округлено до 0.33 даже в самой лучшей десятичной арифметике, а, значит, надо помнить, что после деления может результат не сойтись.
Как именно это будет обеспечено программистом — уже его дело и его заказчика. Должно быть чётко прописано ТЗ, что делать с лишними или недостающими копейками. Обычно такое делается итерациями вычитания; в случае двоичной арифметики есть методы оценки погрешности и корректировки по ходу, не буду тут подробно расписывать, но они неплохо проработаны.
В примере на экране телефона это было не проработано именно на уровне ТЗ, компьютер не виноват.
кт> а введен специальный механизм расчетов, имеющий в Х86 даже аппаратную поддержку.
А вот этот логический переход уже некорректен. Из расчётов с десятичной точкой никак не следует необходимость BCD, особенно стиля x86 и S/360.
BCD было хоть как-то выгодным ровно до того момента, когда стало доступным машинное умножение быстрее, чем O(N^2). Я не про Карацубу, Тоома-Кука и т.п., а про умножение одного слова на одно слово. На современном техническом уровне нарисовать умножение N*N сеткой из И+сумматоры — меньше чем копейки. Но даже на более древних методах уже в i286 умножение стало стоить чуть больше, чем собственно выборка команд и операндов.
кт>https://groups.google.com/forum/#!forum/comp.lang.pl1
кт>Там среди завсегдатаев есть несколько пожилых преподавателей из калифорнийских ВУЗов
кт>Они доброжелательно относятся к задающим вопросы.
кт>Задайте им вопрос и, вероятно, они понятнее меня и с примерами объяснят, почему полвека назад очевидная идея при финансовых расчетах хранить центы, копейки и прочие фартинги в виде целых чисел была отвергнута,
Это и так известно — не отвергнута. Но для того, чтобы не путать прикладных программистов финансовой области, которым слишком сложно и вообще не нужно объяснять, как оно работает внутри, маскировка под десятичную плавучку была введена на уровне языка.