|
помогите сделать блок-схему
Вложений: 3
Блок схемы
|
winston07, и в чём проблемы? Пока видно не «помогите сделать», а только «сделайте за меня». См. Правила Форума, особливо шестой пункт.
|
Iska, проблема в том,что не умею,поэтому и обратился
|
Цитата:
См. второй пример на ветвление, если a = b Он совсем не так прост..., ибо никогда в лоб на плавающей точке равенства не будет... |
Цитата:
Цитата:
Цитата:
Забудьте вынесенные Вами из реализации конкретных языков программирования и машинных команд плавающие точки. Кстати, с чего Вы взяли, что там вещественные, а не, скажем, целые? Об этом ровным счётом ничего не сказано. Да и не нужно этого совершенно в алгоритмизации. Так что не надо здесь рассуждать на тему особых случаев, как-то: переполнения порядка и исчезновения порядка. Вы его сейчас ещё озадачьте двумя представлениями нуля, чтоб он свихнулся. |
Цитата:
То, что нужна плавающая точка очевидно из остальных двух картинок... В своё время мне пришлось рисовать кучу блок схем --- так тогда требовал нормо контроль… Более глупого занятия не придумаешь…. За свою жизнь я покодировал на многих языках программтрования от разных ассемблеров до языков высокого уровня… Какие-то картинки с четриками порою для себя рисавал, но блок схемы по ГОСТ не делал, --- пустая трата времени.. Большинство профессионало программистов придерживались аналогичного мнения. Вот примерно как забавно на DxDy народ фрудит… Цитата:
|
Tau_0, Вы понимаете разницу между алгоритмом и программой?
Цитата:
Цитата:
Цитата:
Цитата:
Структурное программирование — Википедия Теорема Бёма — Якопини — Википедия |
winston07, Для прогулявших лекции: http://inf1.info/book/export/html/23
Для тренировки: сделай блок-схему поиска максимума двух чисел: m=max(a,b) |
Цитата:
Я лет 5 программировал на Modula-2, так только картинки для себя изредка рисовал – кроме меня их бы никто не разобрал. Но если Вам так нравится --- рисуйте на каждый оператор блок схему или рельсовую диаграмму. По мне так это пустое и ненужное… Хотя если заставят, то даже под нормоконтроль нарисую… Возьмитите классику Н. Вита Программирование на языке Модула-2 И найдите там хоть одну блок сжему. Там только редьсовые диаграммы есть. Хотя в более раньних книгах у Вирта блок схемы есть… И на разных Fortran’ах лет 20 структурно проекционно сеточные методы долбал со слабо обусловленными матрицами. Там точное решение получалось совсем неточным и надо было далее для уточнения применять итерацинные методы. --- Понятно, что на равенство никогда не проверялось, а только на больше или меньше. По большому счёту равенство только на целых числах имеет смысл. |
Цитата:
Это не бред, т.к действительно так. Цитата:
Цитата:
|
|
Цитата:
Я не знаю для какого языка необходимо нарисовать-блок схему... Но вот Вам очень старая книга Д. Мак-Кракен, У. Дорн, Численные методы и программирование. Она для фортрана. Лучщего введения в численные методы я не видел. Сразу начинается с блок-схем... Очень доходчиво там это дело расписано. Цитата:
|
Цитата:
Если надо нарисовать блок схему, то я бы поступил просто и незамысловато --- просто нарисовал бы укрупнённый прямоугольник типа "вычислить процедуру/функцию F". И ВСЁ --- больше ничего не надо. Мне неважно сколько в ней утверждений/операторов --- может пять, а может и тысяча. Это проектирование сверху вниз... Но может там нужно нарисовать граф типа того, что на картинке. Тогда начинается самое интересное --- численные методы и ошибки округления...???... Но это слишком серьёзно и надолго... Тут не важен язык --- хоть на арифмометре "Феликс" считайте... Бесполезно здесь фантазировать. Моё мнение --- здесь блок-схема никак не нужна и ничего не проясняет. |
нужно,вот по такому примеру
 |
посмотрите вот 2-ой правильно ли?
 а вот первый и второй не знаю как бы правильно оформить( |
Цитата:
Цитата:
Цитата:
Цитата:
Вот Вам два числа с плавающей запятой: «?» ? «?» — между ними, говорите, равенства не будет?! Ну-ну. |
Вложений: 1
Как-то так.
|
Цитата:
Для сравнения вещественных чисел в профессиональных программах пишется отдельная функция, а не используется стандартные условные операторы языка ( > , < , >=, <=, ==, != ) И на сравнении вещественных чисел могут возникнуть проблемы, если подобная отдельная функция не будет реализована. Сравнение на 0 в случае с вещественными числами может не сработать, т.е 0 может не быть равным 0 . Вот например один из примеров проблемы: http://www.rsdn.ru/forum/cpp.applied/1187492.flat (Сравнение вещественных чисел) http://www.rsdn.ru/forum/delphi/1917455.flat (Неверное сравнение чисел типа Double в Delphi) |
Цитата:
Цитата:
Код:
#include <stdio.h>Цитата:
Цитата:
Цитата:
Цитата:
mrcnn, не надо мериться со мной пиписьками. Хотите обосновать своё утверждение — обосновывайте. Доказательно. |
]Это в этой программе может сравнение и работать. Но можно нарваться на ситуацию, когда она не сработает. А если оно не сработает, но на вид все будет правильно (и компилятор все съест, и программа будет работать), то в какой-то момент подобная ошибка сравнения может появиться. Ваше рассуждение индуктивное. Вы пытаетесь ОДНИМ примером доказать правильность перевода вывода на весь класс предметов, и в данном случае это ошибочно. Проблему неполной индукции еще никто не отменял. Это у вас сейчас работает, но в целом оно неправильно даже несмотря на то, что временно работает или работает в каких отдельных ситуациях. Ваш пример работает, потому что это временное исключение. Я сталкивался с ситуациями, когда 0 не был равен 0 в простых программах из-за того, что нет бесконечности. Компьютер всегда работает с приближением, поэтому разрабатываются численные методы дифференцирования, интегрирования, решения уравнений и т.д. То есть с непрерывного класса функций, в компьютере все переводится в дискретный класс функции. На теории вероятностей и мат статистике рассматривается и случай непрерывных функций, и случай дискретных функций. Компьютеры являются дискретными устройствами, поэтому вам даже в информации о процессоре Intel i7 пишут, что видеокадаптер встроенный в процессор является дискретным. В комьютере реализуются дискретные функции, потому что нельзя реализовать непрерывные. Нельзя реальный физический мир повторить в комьютере. Есть специальный курс дискретной математики в профессиональных ВУЗах для программистов и инженеров. Реализуя компьютерный алгоритм в программе, вы всегда переводите с непрерывного класса функций на дискретный.
Бесконечности вещественных чисел в компьютере нет. Поэтому на плавающей точке в лоб равенства может не быть. В электронике на физическом уровне инженерами реализована ТОЧНОСТЬ ДО определенного ЭПСИЛОН, а не бесконечность. Я имею в виду инженеров компаний типа Intel, AMD и т.д., которые занимаются созданием чипов. 1/3 переводится к конечному представлению в компьютерах. |
А ведь предупреждали: не сравнивайте вещественные числа между собой. Нет же, пока САМ не обожжется - должен попробовать. // http://forum.pascalnet.ru/lofiversio...hp/t24610.html ВОТ ПРИМЕР КАК ОБЖИГАЮТСЯ select * from table_name where val=1.7 Значение 1.5 остается как было, значение 1.7 меняется на 1.70000004768372. // http://www.sql.ru/forum/958491/strannyy-kosyak-s-float ГДЕ ТА БЕСКОНЕЧНОСТЬ, КОТОРУЮ ВЫ ТУТ МНЕ ПЫТАЕТЕСЬ ДОКАЗАТЬ? А число 1.7 в двоичной системе имеет бесконечный хвост, который сохранить полностью не представляется возможным. // http://www.sql.ru/forum/958491/strannyy-kosyak-s-float Это, кстати, касается и случая, когда Вы сравниваете вещественные числа, не учитывая точность представления чисел. Посмотрев в отладчике, что числа, вроде как одинаковые, но сравнение срабатывает так, как будто они разные, Вы не задумались бы, что именно в сравнении содержится ошибка. // http://popoff.donetsk.ua/text/work/prg/debug.html У вещественных чисел есть погрешность. Сравнивайте не "равно", а больше/меньше, с учетом этой погрешности. // http://linuxforum.ru/viewtopic.php?id=4076 Не сравнивайте на равенство вещественные числа. // http://www.intuit.ru/studies/courses...?page=2? Уж сколько раз твердили миру: не сравнивайте вещественные числа на равентство. // www.forum.mista.ru/topic.php?id=620586 Не сравнивайте вещественные числа оператором = (равно). Это не проблема Delphi, а свойство их представления. // http://rfpro.ru/?step=search&mode=an...=5&from=110280 |
Цитата:
Цитата:
Цитата:
Цитата:
Цитата:
Цитата:
Зачем Вы мне это доказываете? Я об этом давно уже написал в этой теме, поднимите глаза долу на пост #5. Но всё это никак не отменяет того факта, что утверждение Цитата:
|
ЭВМ оперирует структурами конечного типа. 1/3 не является в компьютере бесконечным. Выше приведен пример с числом 1.7, которое было преобразовано в 1.70000004768372 В 1/3 тоже добавляется в конец "мусор".. Вы проверяете на платформе i386 а на других платформах, например встроенных систем, мобильных устройств и т.п. ваш пример может не сработать. ВАША ПРОГРАММА БЫЛА ПРОВЕРЕНА ЛИШЬ НА ВАШЕМ КОМПЬЮТЕРЕ, но не проверялась на других платформах. Докажите сперва, что ваша программа работает вообще ? Если она на вашем компьютере работает, это не значит, что она правильная. С чего вы решили, что у вас правильный код? Может быть, его и не всякий компилятор скомпилирует? 1/3 вообще в языке C нет, и об этом написано у K&R, что нельзя в программе на языке С писать 1/3, это ошибка. Вы впариваете тут бред и чушь, и еще и спорите, понимая, что не правы.. Ваша программа на языке С ошибочная вообще. Помимо i386 есть еще и платформы ARM, Itanium, а помимо процессоров Intel и AMD есть еще много разных процессоров. Докажите сперва, что ваша программа, которая является как пример, является верной. где ваша выборка и результаты тестирования программы на парке, скажем из тысячи машине? и вообще вы кто такой по жизни, если спорите о простых вещах? Вы не программист вообще, а хз кто.
страница 184 Математический энциклопедический словарь ДИСКРЕТНАЯ МАТЕМАТИКА - область математики, занимающаяся изучением свойств дискретных структур, к-рые возникают как внутри математики, так и в ее приложениях. К числу таких структур могут быть отнесены, напр. конечные группы, конечные графы, а также не-рые математич. модели преобразователей информации, конечные автоматы, машины Тьюринга и т.п. Это примеры структур финитного (конечного) характера. страница 281 Математический энциклопедический словарь КОНЕЧНЫЙ АВТОМАТ - матемтическая модель устройства с конечной памятью, преобразующего дискретную информацию. страница 360 МАШИНА - абстрактное устройство, осуществляющее переработку информации. <...> Возникновение их связано с анализом понятия алгоритма, начавшегося в сер. 30-ч гг. 20 в., с развитием ЭВМ <...> Наибольшее распространение получили М., перерабатывающие дискретную информацию, типичными представителями к-рых являются конечный автомат и Тьюринга машина. страница 597 ТЬЮРИНГА МАШИНА - название, закрепившееся за абстрактными вычислительными машинами некоторого точно охарактеризованного типа. |
mrcnn, обсуждали уже. Я привел шесть разных примеров, где равенство возможно и даже необходимо. Но потом удалил сообщения, чтобы не разводить флейм. Повторю еще раз: полностью согласен с уважаемым Iska. Перестаньте мыслить категориями 20-тилетнй давности. Воспринимайте "a" и "b" из задачи не как числа, а как объекты, между которыми определено отношение эквивалентности.
А уж что именно это за объекты - неважно. Я приводил пример и с вещественными числами для которых оператор == был переопределен и с матрицами и с вещественными для которых требовалось именно побитовое совпадение и даже с виртуальными машиными в которых такие числа как 1/3 или корень из двух представлены без какой-либо потери точности... Сущность этих объектов не имеет никакого значения для контекста задачи. Конечно, если Вы хотите сказать, что никакие объекты не могут быть эквивалентными.... Тогда Вам на философский форум. Я предлагаю оставить вопрос о, якобы, неправильных условиях задачи, поскольку обсуждение его автору не только не поможет, но, напротив, может создать у него ложное впечатление о том, что команды сравнения вещественных чисел на равенство были включены в архитектуру процессоров идиотами. |
winston07,
В примере №2 у тебя из условия идут 3 стрелочки. Должно быть 2 ("да" и "нет"). Не все пути программы приводят к концу (на выводе заканчиваются стрелки). В принципе примеры №1 и №3 могут пройти по прямой, без ветвлений (т..е. рисовать одним блоком). Но можно предусмотреть деление на ноль. Тогда появятся варианты. Код:
(Начало)Добавлю к общему флуду: Блок-схема предназначения для того, чтобы объяснить ход/особенности алгоритма (не вдаваясь в подробности реализации). Например, я лично рисовал блок-схемы узлов, которые программировал, чтобы объяснить их работу заказчику (при этом обучать его программированию не входило в планы). Блок-схемы надо уметь читать и писать. Для этого нужно решать "тупые" задачки в большом количестве. Ровно как обучение письму начинается с рисований "никому не нужных" закорючек. Кстати, я заметил что компиляторы используют представление кода (3-adress-code) очень похожее на блок-схемы. |
Цитата:
Код:
#define FLT_EPSILON 1.192092896e-07F /* smallest such that наименьшее, такое что 1.0+FLT_EPSILON != 1.0 */ |
Цитата:
Цитата:
Цитата:
Цитата:
2. «Докажите сперва, что ваша программа работает вообще ?» — если Вам недостаточно исходного кода, могу выложить бинарный файл, но, боюсь, Вас и это не убедит, что «программа работает». 3. Поищите у «не всякого компилятора» параметр, включающий поддержку стандарта ANSI. Цитата:
Цитата:
Цитата:
Цитата:
Цитата:
Цитата:
Цитата:
|
Цитата:
В итоге пользователи начинают обращаться в тех поддержку из-за того, что у них программа не работает. Потому что программист не предусмотрел некоторые ситуации. Поэтому, для ПО постоянно выпускают обновления, заделывающие ошибки программистов. Цитата:
Цитата:
В лоб числа с плавающей точкой не сравнивают из-за погрешности. И в архитектуре процессоров заложена определенная погрешность и точность. И инженеры, проектирующие процессоры, могут ошибаться. |
Iska
В начале речь шла не о равенстве 1/3 и 1/3 а о сравнении a и b, а вы начали исходить из сравнения a и b при их равенстве сведя в итоге и a и b к 1/3. Конкретно, смотрите изображение IMG_20131130_121057.jpg топик стартера о блок схеме. Вы перевели рассуждение к ситуации, когда a и b аксиоматически являются одинаковы (и равными 1/3), что является неверным для IMG_20131130_121057.jpg Таким образом, вы подменили начальный тезис, сузив его. Причем Tau_0 прокомментировал изображение IMG_20131130_121057.jpg , а не вашу программу. Последовательность событий: 1. 02:10, Вчера IMG_20131130_121057.jpg топик стартера о блок схеме к программе. X = { a / b + 1, если a > b, a + 25, если a = b, (a*b - 2) / a, если a < b; } 2. 05:02, Вчера Tau_0 написал в "См. второй пример на ветвление, если a = b Он совсем не так прост..., ибо никогда в лоб на плавающей точке равенства не будет..." Это замечание является корректным, так как сравнение вещественных чисел будет отличаться от сравнения целочисленных. В лоб сравнивать нельзя, так как в машинном представлении чисел с плавающей точкой есть погрешность. В этой теме: http://www.rsdn.ru/forum/cpp.applied/1187492.flat в сообщении от 24.05.05 14:53 написано, что сравнивать вещественные числа нужно в некой окрестности и приведен код Код:
bool isEq(double a, double b) |
Цитата:
Было сказано: «Для любых X верно Y». Я привёл опровержение, что Y верно отнюдь не для любых X. Но Вы с какого-то перепугу придумали себе и упорно требуете от меня доказательства «Для каждого X не верно Y». Цитата:
Первое ключевое слово — «при вычислениях». Второе — «при различных». Но, повторяю вновь: это никак не подтверждает, либо опровергает сделанного утверждения: Цитата:
Цитата:
Цитата:
|
Понятно, что человек хочет спорить просто ради самого факта спора. Безграмотные статьи из Вики и столь же безграмотные примеры какого-то Васи Пупкина для него пример абсолютной истины. На этом заканчиваю, не буду кормить тролля.
Iska: он просто хотел, чтобы Вы поставили точку после единицы (или после тройки). Иначе производится целочисленное деление и уже его результат преобразуется в вещественное число. При этом сам он опубликовал какой-то глупый код с непонятной функцией "abs", которая при наличии #include <stdlib.h> и отсутствии #include <cmath> будет целочисленной и стало быть все числа различающиеся не более, чем на 1 окажутся равны. А при наличии <cmath> код просто не скомпиллируется, поскольку не указана область видимости. Должно быть либо std::abs, либо явная отсылка к пространству имен в "using std::abs". Но такие "мелочи" его явно не волнуют. Можете задать ему простой вопрос: написать программу вычисяющую машинный эпсилон (котогрый он вслед за Вики безграмотно называет "машинным нулем"). Интересно, как он это сделает без операции сравнения... |
Цитата:
Цитата:
|
Цитата:
На уровне ликбеза и для уточнения посмотрите, что я имел в виду… Просто навскидку нашёл. Более каверзные случаи мне пока придумывать лениво, да и не по теме оно будет… сравнение на равенство вещественных чисел, в последний раз, надеюсь О сравнении действительных чисел. Цитата:
|
Tau_0, Вас тоже «кормить» не буду. Я полагал, мы с Вами разобрались. Оказывается нет. Повторять в пятый раз одно и то же я не стану. Всё, что изложено коллеге mrcnn, считайте теперь адресованным и Вам. На сим закончим.
|
Цитата:
Код:
#include <stdio.h> |
To All:
1. Помогите автору темы решить его вопросы и спорьте до посинения. 2. Если будет замечен переход на личности или троллинг опонента, такой пост будет выпиливаться. |
Цитата:
Помимо этого она является ошибочной, так как вы сравниваете вещественные числа в машинном представлении напрямую. Нельзя сравнивать вещественные a и b оператором ==. |
вот как получилось
  |
Цитата:
Вот мой последний аргумент в виде цитаты… Цитата:
Это я о том, что результат IF может быть как false, так и true --- сиё зависит от реализации… Только и всего. Маленький вопрс на подумать --- чему равно с точностью до восьми знаков 1.0/3.0 + 1.0/3.0 + 1.0/3.0 =…???... Пусть для простоты арифметика десятичная (на самом деле в машине она двоичная и от этого дополнительные фокусы,…) PS Видимо оставанемся при своих и не будем напрягать недотыкомки… |
winston07, как-то не совсем понятно. По первой Вашей блок-схеме:
Какой смысл производить проверку значения X дважды? В первый раз Вы прерываете выполнение по равенству нулю, во -второй - по меньше или равно. Очевидно, что если второе сравнение ложно, то и первое тоже ложно. Тем более, что второе сравнение Вы производите для определения существования вещественного корня, а в таких целях оно должно быть не "меньше или рано нулю", а просто "меньше". С другой стороны, Вы не проверяете X на равенство B. Но если они равны, то разность |B-X| (у Вас ошибочно написано |B+X|) станет равна 0, а логарифм нуля это минус бесконечность. На Вашем месте я сначала бы произвел обе эти проверки, а потом вычислил бы Y одной формулой. В противном случае, у Вас Y оказывается равен не всей дроби, а только её числителю. Tau_0, если бы я был преподавателем и ко мне пришел бы студент с такими соображениями как у Вас. я сразу отправил бы его на пересдачу. Это лет 30 назад можно было рассуждать об ошибках округления. Во времена парадигмы процедурного программирования. Тогда человеку даже поаплодировали бы. Но то время безвозвратно ушло и сегодня человек рассуждающий таким образом сильно напоминает питекантропа пытающегося рассказть об особенностях охоты на мамонтов при помощи камней и дубины. Если человек начинает рассказ с того, что вещественные числа якобы не могут быть равны, ему возвращают зачетку и отправляют переучиваться. Поскольку таким высказыванием он, как минимум, демонстрирует полное непонимание разницы между алгоритмом и его программной реализацией. Я могу пояснить, почему в Ваших рассуждениях имеется дефект. Только что автор темы опубликовал блок-схему, в которой не проверил X на равенство B перед вычислением выражения lg|b-x|. По Вашей логике, он поступил правильно - если считать, что обе величины являются действительными числами, как Вы предположили, то они, по Вашему утверждению, не могут быть равны (Вы это не смогли доказать, но упорно этой точки зрения ипридерживаетесь) и стало быть логарифм будет существовать в области действительных чисел. То есть и проверять незачем. Точка. Послушавшийся Вас человек напишет заведомо неверную блок-схему. Во-первых, потому, что числа могут быть равны и это было наглядно продемонстрировано в программе вычисления "машиннного эпсилон". А во-вторых, если они даже окажутся НЕ равны, они могут быть настолько близки, что логарифм выйдет за пределы представления числа. Тогда надо проверять не только равенство чисел, но еще и переполнение/потерю значимости в процессе вычисления. И не только логарифма, но после любого действия. И т.д. и т.п. В результате получается, что сделав акцент на одном аспекте, Вы полностью упускаете из вида сопутствующие. Вы скажете, что добавите все необходимые проверки в момент написания программы и что это не имеет отношения к собственно алгоритму? И будете правы. Именно об этом и речь - человек долже сначала сформулировать для себя основную идею, а детали реализации, к которым относятся и ошибки округления, оставить на потом. Поймите, что говоря об ошибках округления Вы ни для кого Америку не открыли. Может быть это мы откроем её для Вас, когда расскажем, что с этими ошибками научились бороться несколько десятилетий назад. |
ещё вот вопрос как бы к этому примеру подойти?
 |
Цитата:
Код:
int i, n, k=-1; |
Цитата:
Упрекните и их в невежестве, только учтите что там далеко не студенты… Цитата:
PS Я такой Ваш ответ примерно и предполагал... Хотя в принципе мы говорим примерно об одном и том же, но на разных языках. Вот только контекст не наработан. А блок-схемы я не признаю (уже писал об этом...). --- Уж если припрёт, то буду рисовать графы с вершинами и рёбрами и для себя чёртиков на полях и в скобках рисовать… PPS Надеюсь, что с моим основным тезисом, что "тут очень не просто..." Вы согласитеь... |
вот,что-то такое вышло
 |
winston07, неверно.
Переменная i инициализируется один раз. А не каждый раз в цикле. Иначе у Вас вообще никогда цикл не завершится. В цикле Y суммируется с самим Y и элементом массива дельта х. Печать Y производится после выхода из цикла, а не каждый раз в его теле. Примерно так: Код:
i=0; k=-1; |
AMDBulldozer,
 |
Вложений: 1
winston07, нет, простите. Это не имеет ничего общего с тем, что я нарисовал. Попробуйте просто нарисовать схему из моего предыдущего сообщения.
|
AMDBulldozer,
 |
Вложений: 1
winston07, да, переменную k можно вообще убрать. Я её по привычке запихнул.
Но! Что у вас неправильно: 1. Печать Y производится единственный раз после перехода по ветке "нет". У Вас она стоит в ветке "да". 2. k можете вообще убрать - у Вас там возведение в степень, поэтому промежуточная переменная не нужна 3. У Вас написано "Y=X+(-1)^i+DeltaX". Тут сразу две ошибки: 3.1 Y надо суммировать не с X, а с самим собой - значение этой переменной накапливается в цикле. А у Вас она каждый раз инициализируется заново. То есть "Y=Y+...", а не "Y=X+..." 3.2 Я так понял, что DeltaX - это массив. В Вашей задаче у него есть индекс "i". В то время как у переменной "y" его нет. То есть надо просуммировать дельта x при всех заданных i. Тогда на схеме должно быть тоже "дельта x" с индексом i. А у Вас этого индекса нет. Итого получается: "Y=Y+(-1)^i+DeltaX[i]". Эта схема соответствует такой формуле: |
AMDBulldozer, вот так должно быть?
 |
winston07,
Ай, нет!!! Не обратил внимания - от прямоугольника "I=I+1" срелка должна идти не вниз на выход, а опять вверх, перед сравнением. |
AMDBulldozer, вот так
 |
winston07, ну вот уже ПОЧТИ правильно!!! Только I=0 должно быть не в сравнении, а перед ним. Там, где Y=X0. И на всякий случай советую сохранить прикрепленный файл с формулой http://forum.oszone.net/attachment.p...6&d=1385923271
В матанализе в таком контексте использование индекса "i" означает суммирование по всем его значениям. Если имеется в виду какое-то конкретое значение индекса, он указывается и в левой части равенста тоже: "y i-тое". Но поскольку я не телепат и не могу думать за автора задания, надо на всякий случай иметь с собой формулу по которой Вы составили блок-схему. Если выяснится, что автор имел в виду более простой вариант - не суммирование, а значение при конкретном i, Вы всё равно будете в выигрыше, поскольку получится, что решили более сложную задачу. |
все всем спасибо большое! :)
|
 |
а все понял,спасибо большое :)
|
Блин. Что-то сейчас мне начало казаться, что я всё-таки неправильно понял задачу и что надо было не вычислять Y в цикле, а выполнить самое простое и тупое вычисление y по предложенной формуле. А подвох был в том, что по условиям задачи i должно быть целым числом и именно на это его и надо было проверять: "(int)i == i".
Это подсказали даже два раза: когда в формуле i использовался в качестве показателя степени (если i действительное число, то (-1)^i комплексное) и когда i выступал в виде индекса (индекс должен быть целым). Но эти два флудера в ветке уже успели настолько достать своими повторениями о "невозможножности равенства двух действительных чисел", что у меня совсем вылетело из головы, что числа в условии задачи типа, в общем случае, не имеют и что могут быть специально сформулированы условия при которых надо проверять наличие исключений из этого общего правила. Черт, они даже меня сумели в результате запутать. Я расстроен. |
winston07, Нарисуй, что получилось. У меня есть подозрение, что ты не просёк фишку с блок-схемами и у тебя есть ошибки в схемах.
|
pva, вот, если есть возможность пожалуйста исправте если есть ошибки на самой картинке и скиньте
  |
winston07, Скидывать мне пока некогда...
Но вот смотрите --- мы здесь с коллегами много нафлудили про ошибки и в часности про абсолютные/относительные ошибки вычилений. Но какой либо .оценки их я не вижу... Второе, что бросается в глаза --- алгоритм ветвится и просто идёт на выход... Это как в песок --- ни сообщений ни кодов возврата нет... Такого точно быть не должно... |
winston07,
Картинка №1: 1. согласен с комментарием Tau_0 про выход молчком. Надо как-то пометить (хотя бы подписать ветку), что ошибочная ситуация 2. Y в формуле не равен тому, что написано в схеме. Куда делась дробь? 3. Почему не стал давать имена подвыражениям (я их называл часть1 и часть2) 4. Добавь проверку к логарифму (логарифм от 0 бесконечен), не забудь про деление на ноль, когда добавишь дробь В остальном нормально Картинка №2: 1. почему ТРИ стрелки при сравнении? "да", "нет", "может быть" что ли :-) 2. не понятно что это именно X=A/B+1 3. почему после вывода X нет стрелки в конец? после вывода надо идти на конец. Поводи пальцем по стрелкам. Твой палец в любом случае должен суметь добраться от начала до конца. Картинка №3: 1. откуда взялся X? Картинка №4: 1. откуда взялась картинка №4? |
pva,
Это 4-ое 3. А что нужно взять вместо Х? |
Цитата:
Но придать формуле какой-либо геометрический/математический смысл сложно. О сумме тоже говорить нехорошо --- оператор сигма не написан и пределы изменения i тоже не видны. Такое ощущение, что вы вырезали обломок целого и только его показали… Это мизер. Покажите целый лист, а ненужное я сам отброшу… ЗЫ Какой язык программирования Вам читали...???... |
winston07,
№3: а подумать?... №4: формула действительно выглядит как вырванная из контекста. На соглашение о суммировании Эйнштейна не похожа. Думаю i - это обычная переменная. Формулу можно сделать одним блоком. |
| Время: 20:22. |
Время: 20:22.
© OSzone.net 2001-
