Циклы

[Вадим Мошев]

Сообщение от TinMan

Вадим.. скажи - ты правда думаешь, что если бы компьютеры были троичными, или там десятичными (на 3 или 10 уровнях сигнала, или еще как-то..), то этой проблемы бы не было?..

Вовсе нет.
Двоичная система счисления - одна из причин, но она не единственная причина того, что дробные числа представляются с некоторой ошибкой в иных системах счисления. То же самое и может быть, если бы система была троичной, пятиричной, n-чной.

[TinMan]

Каким-то образом я пропустил эти два поста в этой теме.. Очень извиняюсь за опоздание с ответом.

Сообщение от JUDAS

TinMan скажи что обломался и не знаешь как себя выправдвть.

ох.. JUDAS, кончай уже про эмоции.. обрати, наконец, внимание на суть.

в своём коде ошибку увидел, но форум устроен так, что я не могу поменять местами две строки внутри цикла.

Ты пока нашел не ту, главную ошибку, а вторичную. Ты прочти внимательно все, что я писал. В твоем коде _существенная_ ошибка. Рекомендую тщательно разобраться в этом вопросе. Ошибки, возникающие при усечении чисел принципиально неустранимы в общем случае - ни повышенная точность, ни специальный набор инструкций тут не спасает. Подтверждение тому - вот та самая ошибка в твоем коде.
(Кстати, зачем исправлять старые мессаджи? Это нарушает ход дискуссии. Ты пиши новые.)

Я использовал в данном случае последнюю версию FPC, 2.4.4. Но дело, повторяю - не в этом. Вникни. Задавай вопросы, я всегда отвечу (сейчас подпишусь на эту тему и больше не пропущу ничего). Успехов.

Сообщение от Вадим Мошев

Вовсе нет.
Двоичная система счисления - одна из причин, но она не единственная причина того, что дробные числа представляются с некоторой ошибкой в иных системах счисления. То же самое и может быть, если бы система была троичной, пятиричной, n-чной.

Вадим, извини, это была полушутка.. )) Я понимаю, что ты это понимаешь. Просто твои слова так прозвучали. Извини еще раз.
Но дело все же не в дробности и не в системе, а в конечности представления чисел в машине. И это, как я уже писал, принципиально неустранимо. В большинстве случаев это почти не влияет на результат, но в некоторых (как, например, завдача в этой теме) результат очень сильно зависит, и даже не от точности самой по себе, а от самого ФАКТА, что вычисления не совсем точны (данном случае результат отличается в два раза, но может быть и гораздо больше). В таких случаях теребуется делать специальные коррекции в алгоритме (см. выше мое решение), причем общего рецепта таких коррекций тоже нет (и быть не может). Этому аспекту обычно уделяется очень мало внимания, но от этого его важность в подобных ситуациях не становится меньше.

[JUDAS]

Ошибки, возникающие при усечении чисел принципиально неустранимы в общем случае - ни повышенная точность, ни специальный набор инструкций тут не спасает.

TinMan советую выбросить железо на котором пишешь код и примочки которым по 30 лет, и купить чтото серёзное и более менее современное.
Проблеме с ошибками сравнивания вещественных чисел столько же лет, как мне. Вычитал в какой то статье бред 40-летней давности на эту тему и лечишь тут форумчан.
-----
Мой тебе совет парень, прежде чем лечить опытных программистов, я не имею ввиду только себя, сам наберись опыта, и учись принимать поражения и обломы более спокойно и уравновешено, "папа" блин

[SVing]

TinMan напиши в личку пожалуйсто , нужна твоя помощь

[TinMan]

JUDAS, я не знаю, как еще тебе объяснить. Хорошо, давай попробуем так..
Сначала я приведу условие этой задачи (на всякий случай)

2. Найти Z = (h +3) (h +2.8) (h +2.6) (h +2.4 ).....( h +1).

Теперь подстваляем h=1. Получаем:

4.0 * 3.8 * 3.6 * 3.4 * 3.2 * 3.0 * 2.8 * 2.6 * 2.4 * 2.2 * 2.0

Правильно? Вроде, да.
Теперь копируем эту строчку в буфер, вызываем калькулятор (я использовал стандартный calc из Windows 7), и нажимаем в нем ctrl-v. Затем нажимаем Enter. Получаем (копирую сюда ответ)

137306.63890944

Ты видишь отличие от твоего ответа? Твой ответ:
Z= 68653.32
Отличие РОВНО в 2 раза. Дело в том, что твой код не домножает на последнюю двойку (которую я выделил красным). До нее не доходит дело, потому что при многократном вычитаний (v:=v-0.2 получается, что параметр v чуть-чуть меньше единицы. Понятно теперь?

Постарайся вникнуть. И не надо так много эмоций, это чисто технический вопрос.

[JUDAS]

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

[TinMan]

Сообщение от JUDAS

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

Странно.. Это где же разобрались? видимо, я что-то пропустил.. Хорошо, виноват.
У меня просьба тогда: запость тут, пожалуйста, исправленный вариант кода, чтоб я разобрался. Спасибо.

[JUDAS]

Запостил

program Project2;
var Z,h,v : double;
begin
 writeln('введите h '); read (h);
 v:=3.2;  
 Z:=1;
 while v>=1 do
 begin
   v:=v-0.2;
   z:=z*(h+v);
 end;
 writeln('Z= ',z:6:2);
end.

[TinMan]

Сообщение от JUDAS

Запостил

program Project2;
var Z,h,v : double;
begin
 writeln('введите h '); read (h);
 v:=3.2;  
 Z:=1;
 while v>=1 do
 begin
   v:=v-0.2;
   z:=z*(h+v);
 end;
 writeln('Z= ',z:6:2);
end.

Н-да.. JUDAS, скажи - ты правда думаешь, что меня можно поймать на такую простую уловку? Я прямо теряюсь в догадках - то ли ты всеми силами пытаешься выкрутиться, то ли правда не понимаешь.. Ладно, я предприму последнюю попытку открыть тебе ускользающую истину..

Смотри. Я в твой код вставил одну строку - печать v после всего цикла. ПОлучилось вот, что:

var Z,h,v : double;
begin
 writeln('введите h '); read (h);
 v:=3.2;
 Z:=1;
 while v>=1 do
 begin
   v:=v-0.2;
   z:=z*(h+v);
 end;
 writeln('v= ',v:6:2);
 writeln('Z= ',z:6:2);
end.

Результат работы этой программы вот такой:

введите h
1
v=   1.00
Z= 137306.64

Ты видишь, напечатано v=1, да? Что это значит? Это значит, что это значение не прошло условие цикла. Потому что, елси бы оно прошло, то из него вычлось бы 0.2 и оно стало бы равно 0.8. Верно?
Так вот, JUDAS, это и есть ТО, о чем я говорил выше. НЕЛЬЗЯ проверять на точное равенство (в данном случае на точное граничное значение).

Твое исправление - это чистой воды подгонка. Если изменить параметры (допустим, увеличить шаг) равенство может снова выполниться, и тебе придется откатывать изменения назад..

Ну, понял, наконец?? Если нет - я умываю руки.. ))

Серж, ведь ты наверняка следишь за развитием этой темы и не вылезаешь изпацтала )). Хватит уже потешаться, бери у меня эстафету и попробуй сам объяснить.. Ну, сделай доброе дело, помоги открыть глаза человеку )).

[Serge_Bliznykov]

Сообщение от TinMan

Никогда нельзя сравнивать действительные переменные ТОЧНО.

JUDAS, Вы заблуждаетесь!
Раз у Вас обнаружилась такая брешь в познаниях, то
ОЧЕНЬ рекомендую Вам ознакомиться со статьями (я на их на данном форуме неоднократно приводил ссылки, но не поленюсь повторить ещё раз).

если непонятно, что выдаст вот такой кусочек кода:

var R:double;
begin
  R:=0.1;
  if R=0.1 then
   Label1.Caption:='Равно'
  else
   Label1.Caption:='Не равно'
end;

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

статья Антона Григорьева "Неочевидные особенности вещественных чисел"

и статья Загадки округления


p.s.
JUDAS, и теперь подумайте, кто сказал бред, а кто нет..