Требуется совет, проблемы с логикой в задачах.
Приветствую, хотелось бы услышать советов от знающих людей, начал изучать сначала Паскаль, затем Делфи, затем С++. Сами языки даются не сложно, проблема в том, что когда дается задание, примера "Найти периметр треугольника" сразу возникает ступор с логикой, не то чтобы саму формулу не знаю, а именно как это записать, тоесть как написать код программы, бывает что даже условие написать не могу. Как только вижу код решенной задачи, сходу могу объяснить что к чему ... Друг посоветовал мне заняться плотной практикой, тоесть решать-решать и решать типовые задачи. Вопрос заключается в том, поможет ли практика, что поможет вообще и поможет ли оно?
з.ы. с++ только шел среда, визуал еще не трогал, да и знания шел среды тоже очень скудны.
Спасибо.
з.ы. с++ только шел среда, визуал еще не трогал, да и знания шел среды тоже очень скудны.
Спасибо.
[QUOTE=anarx]Приветствую, хотелось бы услышать советов от знающих людей, начал изучать сначала Паскаль, затем Делфи, затем С++. Сами языки даются не сложно, проблема в том, что когда дается задание, примера "Найти периметр треугольника" сразу возникает ступор с логикой, не то чтобы саму формулу не знаю, а именно как это записать, тоесть как написать код программы, бывает что даже условие написать не могу. Как только вижу код решенной задачи, сходу могу объяснить что к чему ... Друг посоветовал мне заняться плотной практикой, тоесть решать-решать и решать типовые задачи. Вопрос заключается в том, поможет ли практика, что поможет вообще и поможет ли оно?
з.ы. с++ только шел среда, визуал еще не трогал, да и знания шел среды тоже очень скудны.
Спасибо.[/QUOTE]
Ну что тут можно предложить? Попробуй перед решением задачии написать словесно алгоритм, потом напиши его на псевдокоде (т.е. типа паскаля русскими словами, ШАЯ) а потом уже писать программу на си или паскале, думаю штук после 5-10 таких операций у тебя будет получаться лучше (так же можно попробовать по своему алгоритму на псевдокоде попробовать помоделировать работу программы - тоже полезное упражнение, поможет понять логику работы программы).
з.ы. с++ только шел среда, визуал еще не трогал, да и знания шел среды тоже очень скудны.
Спасибо.[/QUOTE]
Ну что тут можно предложить? Попробуй перед решением задачии написать словесно алгоритм, потом напиши его на псевдокоде (т.е. типа паскаля русскими словами, ШАЯ) а потом уже писать программу на си или паскале, думаю штук после 5-10 таких операций у тебя будет получаться лучше (так же можно попробовать по своему алгоритму на псевдокоде попробовать помоделировать работу программы - тоже полезное упражнение, поможет понять логику работы программы).
Программирование и кнопконажимательство - не совсем одно и то же.
Почитай книги по алгоритмизации - класику типа Кнутта, Пратта, Вирта
Почитай книги по алгоритмизации - класику типа Кнутта, Пратта, Вирта
[quote=Hydra]Почитай книги по алгоритмизации - класику типа Кнутта, Пратта, Вирта[/quote]
ему пока ранова-то.
[quote=anarx]начал изучать сначала Паскаль, затем Делфи, затем С++. Сами языки даются не сложно, проблема в том, что когда дается задание, примера "Найти периметр треугольника" сразу возникает ступор с логикой, не то чтобы саму формулу не знаю, а именно как это записать, тоесть как написать код программы, бывает что даже условие написать не могу.[/quote]
странно изучать начал, а не можешь самое простое написать -> изучай лучше. есть такое понятие блок-схема. сначал прогу с помощью неё опиши. типовые задачи решать не советую, потом могут возникнуть определенные трудности. тебе надо над логикой поработать: решай больше алгебраических, а лучше геометрических задачек, и найди где-нибудь книжку по логике, такую чтоб больше повествовательного характера была, если сможешь найди где-нить сборничек отрывков из рассуждений Аристотеля и прочитай, для развития логики просто необходимо.
ему пока ранова-то.
[quote=anarx]начал изучать сначала Паскаль, затем Делфи, затем С++. Сами языки даются не сложно, проблема в том, что когда дается задание, примера "Найти периметр треугольника" сразу возникает ступор с логикой, не то чтобы саму формулу не знаю, а именно как это записать, тоесть как написать код программы, бывает что даже условие написать не могу.[/quote]
странно изучать начал, а не можешь самое простое написать -> изучай лучше. есть такое понятие блок-схема. сначал прогу с помощью неё опиши. типовые задачи решать не советую, потом могут возникнуть определенные трудности. тебе надо над логикой поработать: решай больше алгебраических, а лучше геометрических задачек, и найди где-нибудь книжку по логике, такую чтоб больше повествовательного характера была, если сможешь найди где-нить сборничек отрывков из рассуждений Аристотеля и прочитай, для развития логики просто необходимо.
Цитата:
ему пока ранова-то.
Не солидарен. Такое никогда не рано - это основы основ.
Берем простой пример - сложение. Реализуем его. Потом оформим как процедуру. Потом как рекурсивную функцию принимающую N параметров, потом как рекурсивную функцию принимающую указатель на первый элемент массива, потом на два массива, в первом числа, во втором - каким-то образом закодированные признаки операций сложения, вычитания, умножения и деления, соответствующие первому списку. Потом все делаете с односвязным списком. И так далее...
Возьмите простой пример, а потом добавляйте новое - в процессе программизма получите опыт и понимание алгоритмов. :)
Возьмите простой пример, а потом добавляйте новое - в процессе программизма получите опыт и понимание алгоритмов. :)
[QUOTE=kosfiz]типовые задачи решать не советую, потом могут возникнуть определенные трудности.[/QUOTE]
Какие?
Какие?
Green
на мой взгляд типовые задачи предполагают какую-то шаблонность их решения и эти шаблоны запоминаются, т.к. решаешь таких задач много. а потом сталкиваешься с какой-то более сложной или просто сложной задачей и кажется тебе, что вот она хоть и сложная, но её можно разбить на вот такую и такую и т.д. по шаблонам. и в итоге пишешь правильный код, выполняющий всю необходимую работу, но оказывается, что если подумать, то можно прийти к решению, используя код в 2-3 раза меньше того, что есть у тебя и работающий быстрее. начинающим для того, чтобы писать правильный код не обязательно решать сотню задач по программированию, не надо хвататься сразу за клавиатуру и печатать код, а с листком бумаги и карандашом(ручкой и т.д.) в руках постараться понять смысл поставленной задачи, предложить варианты её решения, проанализировать каждый и выбрать оптимальный.
на мой взгляд типовые задачи предполагают какую-то шаблонность их решения и эти шаблоны запоминаются, т.к. решаешь таких задач много. а потом сталкиваешься с какой-то более сложной или просто сложной задачей и кажется тебе, что вот она хоть и сложная, но её можно разбить на вот такую и такую и т.д. по шаблонам. и в итоге пишешь правильный код, выполняющий всю необходимую работу, но оказывается, что если подумать, то можно прийти к решению, используя код в 2-3 раза меньше того, что есть у тебя и работающий быстрее. начинающим для того, чтобы писать правильный код не обязательно решать сотню задач по программированию, не надо хвататься сразу за клавиатуру и печатать код, а с листком бумаги и карандашом(ручкой и т.д.) в руках постараться понять смысл поставленной задачи, предложить варианты её решения, проанализировать каждый и выбрать оптимальный.
[QUOTE=kosfiz]
на мой взгляд типовые задачи предполагают какую-то шаблонность их решения и эти шаблоны запоминаются, т.к. решаешь таких задач много. а потом сталкиваешься с какой-то более сложной или просто сложной задачей и кажется тебе, что вот она хоть и сложная, но её можно разбить на вот такую и такую и т.д. по шаблонам. и в итоге пишешь правильный код, выполняющий всю необходимую работу,
[/QUOTE]
Да, это так и это правильно.
Первая итерация - решить задачу простейшим способом, разделив её на простейшие подзадачи.
[QUOTE=kosfiz]
но оказывается, что если подумать, то можно прийти к решению, используя код в 2-3 раза меньше того, что есть у тебя и работающий быстрее.
[/QUOTE]
Это уже вторая итерация.
Решив задачу простейшим способом, разделив её на простейшие подзадачи, далее есть варианты оптимизации как самих решений подзадач, так и манипулированием решениями подзадач объядиняя их и упорядочивая различными способами.
Ты почему-то считаешь, что решив задачу одним способом, а точнее набором типовых способов, программист не сможет придумать и другого решения. В действительности же наоборот: программист, который решает задачу своим "уникальным" "монолитным" способом не в состоянии оценить правильность своего решения, толком заоптимизировать алгоритм или изменить. Кроме того на решение уходит значительно больше времени, за которое при использовании типовых решений можно нагенерить множество вариантов, выбрать лучший, заоптимизировать его и т.п.
Как метафора: задача "радиоприемник" распределяется на подзадачи "колебательный контур", "детектор", "усилитель". Далее эти подзадачи разделяются на более мелкие вплодь до конкретных радиоэлементов.
Задача решена. Далее оптимизируем: мы можем слить воедино колебательный контур и детектор, а можем влить в колебательный контур лишь часть элементов детектора; можем разделить усилитель на УНЧ и УВЧ, сделать УВЧ частью детектора и т.п. В любом случае мы оперируем элементами уже решенной задачи, а сл-но видим проблему целиком и как-бы подгоняем (оптимизируем) решение под уже известный результат.
Другой вариант придумать такой единый прибор, и вытачить его из единого куска кристалла.
[QUOTE=kosfiz]
начинающим для того, чтобы писать правильный код не обязательно решать сотню задач по программированию, не надо хвататься сразу за клавиатуру и печатать код, а с листком бумаги и карандашом(ручкой и т.д.) в руках постараться понять смысл поставленной задачи, предложить варианты её решения, проанализировать каждый и выбрать оптимальный.[/QUOTE]
Для решения задачи в любом случае нужен некоторый план действий, но не обязательно, что бы этот план был детальным. Для того чтобы уметь набросать такой универсальный план нужно иметь багаж знаний и опыта применения некоторых типовых решений (паттернов).
Решение же любой задачи влоб без использования априорного опыта (получаемого в практике решения типовых задач) очень трудоемкий и неоптимальный процесс.
Заходи в ветку "Общие вопросы программирования", там мы иногда решаем различные задачки и посмотри на сколько решение с использованием некоторых типовых решений получается стройнее, проще, а значит более пригодным для оптимизации, повторного использования, реализации и т.п.
на мой взгляд типовые задачи предполагают какую-то шаблонность их решения и эти шаблоны запоминаются, т.к. решаешь таких задач много. а потом сталкиваешься с какой-то более сложной или просто сложной задачей и кажется тебе, что вот она хоть и сложная, но её можно разбить на вот такую и такую и т.д. по шаблонам. и в итоге пишешь правильный код, выполняющий всю необходимую работу,
[/QUOTE]
Да, это так и это правильно.
Первая итерация - решить задачу простейшим способом, разделив её на простейшие подзадачи.
[QUOTE=kosfiz]
но оказывается, что если подумать, то можно прийти к решению, используя код в 2-3 раза меньше того, что есть у тебя и работающий быстрее.
[/QUOTE]
Это уже вторая итерация.
Решив задачу простейшим способом, разделив её на простейшие подзадачи, далее есть варианты оптимизации как самих решений подзадач, так и манипулированием решениями подзадач объядиняя их и упорядочивая различными способами.
Ты почему-то считаешь, что решив задачу одним способом, а точнее набором типовых способов, программист не сможет придумать и другого решения. В действительности же наоборот: программист, который решает задачу своим "уникальным" "монолитным" способом не в состоянии оценить правильность своего решения, толком заоптимизировать алгоритм или изменить. Кроме того на решение уходит значительно больше времени, за которое при использовании типовых решений можно нагенерить множество вариантов, выбрать лучший, заоптимизировать его и т.п.
Как метафора: задача "радиоприемник" распределяется на подзадачи "колебательный контур", "детектор", "усилитель". Далее эти подзадачи разделяются на более мелкие вплодь до конкретных радиоэлементов.
Задача решена. Далее оптимизируем: мы можем слить воедино колебательный контур и детектор, а можем влить в колебательный контур лишь часть элементов детектора; можем разделить усилитель на УНЧ и УВЧ, сделать УВЧ частью детектора и т.п. В любом случае мы оперируем элементами уже решенной задачи, а сл-но видим проблему целиком и как-бы подгоняем (оптимизируем) решение под уже известный результат.
Другой вариант придумать такой единый прибор, и вытачить его из единого куска кристалла.
[QUOTE=kosfiz]
начинающим для того, чтобы писать правильный код не обязательно решать сотню задач по программированию, не надо хвататься сразу за клавиатуру и печатать код, а с листком бумаги и карандашом(ручкой и т.д.) в руках постараться понять смысл поставленной задачи, предложить варианты её решения, проанализировать каждый и выбрать оптимальный.[/QUOTE]
Для решения задачи в любом случае нужен некоторый план действий, но не обязательно, что бы этот план был детальным. Для того чтобы уметь набросать такой универсальный план нужно иметь багаж знаний и опыта применения некоторых типовых решений (паттернов).
Решение же любой задачи влоб без использования априорного опыта (получаемого в практике решения типовых задач) очень трудоемкий и неоптимальный процесс.
Заходи в ветку "Общие вопросы программирования", там мы иногда решаем различные задачки и посмотри на сколько решение с использованием некоторых типовых решений получается стройнее, проще, а значит более пригодным для оптимизации, повторного использования, реализации и т.п.
Всем спасибо, ответы очень помогли, думаю проблема разрешиться. Еще раз всем спасибо.
напоследок т.к. тему видимо сейчас закроют:
[quote=Green]Ты почему-то считаешь, что решив задачу одним способом, а точнее набором типовых способов, программист не сможет придумать и другого решения.[/quote]
почему же сможет, но не всякий к этому стремится и не всякий способен придумать другое решение, другие же считают что шаблоны это и есть оптимальный вариант(особенно начинающие).
[quote=Green]Ты почему-то считаешь, что решив задачу одним способом, а точнее набором типовых способов, программист не сможет придумать и другого решения.[/quote]
почему же сможет, но не всякий к этому стремится и не всякий способен придумать другое решение, другие же считают что шаблоны это и есть оптимальный вариант(особенно начинающие).
[QUOTE=kosfiz]но не всякий к этому стремится и не всякий способен придумать другое решение,
[/QUOTE]
Неспособный придумать другое решение без умения решать типовые задачи не придумает вообще никакого.
[QUOTE=kosfiz]
другие же считают что шаблоны это и есть оптимальный вариант(особенно начинающие).[/QUOTE]
Да так оно и есть. Типовые решения в большинстве случаев самые оптимальные. Другое дело, что многие не знают, что "придуманное" ими решение является типовым, и зная его они бы давно уже решили задачу, а не долбили бы гранит рядом с уже готовым тунелем.
Я так понял, что ты не любитель типовых решений. Отлично! Давай к нам:
http://forum.codenet.ru/showthread.php?t=30412
реши задачу любым нетривиальным способом так, чтоб она была быстрее O(n^3). Быстрее можно, как уже замеченно в теме. Тогда и разговор будет более предметным.
Ну или приведи пример своей задачи, которая подтверждала бы твои слова. Это тоже будет интересно.
[/QUOTE]
Неспособный придумать другое решение без умения решать типовые задачи не придумает вообще никакого.
[QUOTE=kosfiz]
другие же считают что шаблоны это и есть оптимальный вариант(особенно начинающие).[/QUOTE]
Да так оно и есть. Типовые решения в большинстве случаев самые оптимальные. Другое дело, что многие не знают, что "придуманное" ими решение является типовым, и зная его они бы давно уже решили задачу, а не долбили бы гранит рядом с уже готовым тунелем.
Я так понял, что ты не любитель типовых решений. Отлично! Давай к нам:
http://forum.codenet.ru/showthread.php?t=30412
реши задачу любым нетривиальным способом так, чтоб она была быстрее O(n^3). Быстрее можно, как уже замеченно в теме. Тогда и разговор будет более предметным.
Ну или приведи пример своей задачи, которая подтверждала бы твои слова. Это тоже будет интересно.
[quote=Green]Я так понял, что ты не любитель типовых решений. Отлично! Давай к нам:
http://forum.codenet.ru/showthread.php?t=30412
реши задачу любым нетривиальным способом так, чтоб она была быстрее O(n^3).[/quote]
обязательно посмотрю, может если и сам не смогу, то хотя бы гляну, что умные люди предлагают.
http://forum.codenet.ru/showthread.php?t=30412
реши задачу любым нетривиальным способом так, чтоб она была быстрее O(n^3).[/quote]
обязательно посмотрю, может если и сам не смогу, то хотя бы гляну, что умные люди предлагают.