Здравствуйте, deniok, Вы писали:
D>Здравствуйте, ffar, Вы писали:
F>>Что лучше: хорошие алгоритмы с плохими структурами данных или плохие алгоритмы с хорошими структурами данных?
D>Кто такие "хорошие алгоритмы" и "хорошие структуры данных"? Это те, при разработке которых ни одно животное не пострадало?
Изначальный вопрос — философский, потому что данный раздел — философский, поэтому точных формулировок тут не требуется
Здравствуйте, fplab, Вы писали:
F>Здравствуйте, ffar, Вы писали:
F>>Что лучше: хорошие алгоритмы с плохими структурами данных или плохие алгоритмы с хорошими структурами данных?
F>IMHO один вариант другого не лучше другого. Но если уж "пропадать", то лучше хорошие структуры данных
Здравствуйте, ffar, Вы писали:
F>Здравствуйте, fplab, Вы писали:
F>>Здравствуйте, ffar, Вы писали:
F>>>Что лучше: хорошие алгоритмы с плохими структурами данных или плохие алгоритмы с хорошими структурами данных?
F>>IMHO один вариант другого не лучше другого. Но если уж "пропадать", то лучше хорошие структуры данных
F>Спасибо за мнение, а какая аргументация? )))
Глядя на хорошие структуры данных можно хотя бы попытаться понять какая задача решается. Мне во всяком случае так проще. Может, кому-то удобнее танцевать от алгоритма.
Приходиться заниматься гадостью — зарабатывать на жизнь честным трудом (Б.Шоу)
Здравствуйте, ffar, Вы писали:
F>Что лучше: хорошие алгоритмы с плохими структурами данных или плохие алгоритмы с хорошими структурами данных?
Наверно, это зависит от области, в которой человек работает. Где-то читал, что раньше на первом месте были алгоритмы, а теперь данные. Ну и предпочтения будут смещаться.
Я бы выбрал нормальные структуры данных. Ну вот как пример — сортировка строк. У нас есть массив со строками, мы можем его отсортировать как "плохой" пузырьковой, так и "хорошей" быстрой. А вот если у нас строки не в массиве, а в виде:
std::string s1, s2, s3, s4;
То хоть какой алгоритм возьми — реализовывать его замучаешься.
Другой пример. Представь, что все данные в программе лежат в одной структуре, которая пишется в файл (по аналогии с БД — у нас одна таблица с двумя сотнями строк). Тут хоть тресни, а конфетку из такого слепить будет сложно.
Здравствуйте, ffar, Вы писали:
F>>>Что лучше: хорошие алгоритмы с плохими структурами данных или плохие алгоритмы с хорошими структурами данных? D>>Кто такие "хорошие алгоритмы" и "хорошие структуры данных"? Это те, при разработке которых ни одно животное не пострадало? F>Изначальный вопрос — философский, потому что данный раздел — философский, поэтому точных формулировок тут не требуется
И точных ответов тоже получить, видимо, не получится....
Алгоритмы и структуры данных не бывают хорошими или плохими, они бывают подходящими к данной конкретной задаче или неподходящими.
Здравствуйте, monax, Вы писали:
M>Я бы выбрал нормальные структуры данных. Ну вот как пример — сортировка строк. У нас есть массив со строками, мы можем его отсортировать как "плохой" пузырьковой, так и "хорошей" быстрой. А вот если у нас строки не в массиве, а в виде: M>
M>std::string s1, s2, s3, s4;
M>
M>То хоть какой алгоритм возьми — реализовывать его замучаешься.
А чего тут мучаться — создать массив из указателей на строки и свести задачу к предыдущей.
M>Другой пример. Представь, что все данные в программе лежат в одной структуре, которая пишется в файл (по аналогии с БД — у нас одна таблица с двумя сотнями строк). Тут хоть тресни, а конфетку из такого слепить будет сложно.
Откроем memory-mapped file, расставим указатели на данные и слепим конфетку.
Здравствуйте, ffar, Вы писали:
F>Что лучше: хорошие алгоритмы с плохими структурами данных или плохие алгоритмы с хорошими структурами данных?
Хороший риторический вопрос.
Есть смутное ощущение, что хорошие структуры данных все же важней. Как мне кажется алгоритмы не так сложно будет переделать с
продуманными структурами нежели наоборот.
Здравствуйте, ffar, Вы писали:
F>>>Что лучше: хорошие алгоритмы с плохими структурами данных или плохие алгоритмы с хорошими структурами данных? D>>Кто такие "хорошие алгоритмы" и "хорошие структуры данных"? Это те, при разработке которых ни одно животное не пострадало? F>Изначальный вопрос — философский, потому что данный раздел — философский, поэтому точных формулировок тут не требуется
Ты путаешь философию с со словоблудием алкашей на лавочке.
Здравствуйте, Кодёнок, Вы писали:
Кё>Здравствуйте, ffar, Вы писали:
F>>>>Что лучше: хорошие алгоритмы с плохими структурами данных или плохие алгоритмы с хорошими структурами данных? D>>>Кто такие "хорошие алгоритмы" и "хорошие структуры данных"? Это те, при разработке которых ни одно животное не пострадало? F>>Изначальный вопрос — философский, потому что данный раздел — философский, поэтому точных формулировок тут не требуется
Кё>Ты путаешь философию с со словоблудием алкашей на лавочке.
. Взять плохие структуры данных, сделать для них обёртку и получаем хороший алгоритм и хорошие структуры. Это хороший подход, ещё лучше сразу не брать ничего плохого. Но ведь сейчас мы обсуждаем или/или.
А во-вторых: M>>Я бы выбрал нормальные структуры данных. Ну вот как пример — сортировка строк. У нас есть массив со строками, мы можем его отсортировать как "плохой" пузырьковой, так и "хорошей" быстрой. А вот если у нас строки не в массиве, а в виде: M>>
M>>std::string s1, s2, s3, s4;
M>>
M>>То хоть какой алгоритм возьми — реализовывать его замучаешься.
PD>А чего тут мучаться — создать массив из указателей на строки и свести задачу к предыдущей.
А если так?
std::string s1, s2, s3, s4,....,s2000; // я сильно утрирую
Это не просто моя фантазия. Мне как-то довелось видеть исходник для системы тестирования, сделанной очень интересным человеком. Окно приложения, вопрос, несколько радио-батонов (варианты ответа), кнопка "далее". Человек это писал на делфи. На каждый вопрос были свои радиобатоны (которые уже были на форме), своя кнопка и свой label с вопросом. На каждую кнопку свой обработчик. Поскольку вопросов было около 70, то человек сваял 70 методов обработки кликов по 70 кнопкам.
Здравствуйте, ffar, Вы писали:
F>Что лучше: хорошие алгоритмы с плохими структурами данных или плохие алгоритмы с хорошими структурами данных?
Что лучше: производительность или универсальность?
. Взять плохие структуры данных, сделать для них обёртку и получаем хороший алгоритм и хорошие структуры. Это хороший подход, ещё лучше сразу не брать ничего плохого. Но ведь сейчас мы обсуждаем или/или.
А не надо или/или. Надо взять лучший алгоритм с лучшей структурой данных, причем не абстрактно лучшие, а в применении к конкретной задаче. А зачем брать хорошую структуру данных и портить все дело плохим алгоритмом или наоборот — не понимаю. Единственный аргумент — структура данных legacy, но тогда нет смысла обсуждать, хорошая она или плохая — какая уж есть.
M>А если так? M>
M>std::string s1, s2, s3, s4,....,s2000; // я сильно утрирую
M>
Ну и что ? Сколько si — столько и строк типа ps[i] = &si; . Если тебе 2000 описаний переменных не сложно сделать, что за проблема для тебя еще 2000 присваиваний сделать ?
ps[0] = &s0;
ps[1] = &s1;
...
ps[2000] = &s2000;
Многоточия в обоих случаях заполни сам как автор идеи
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>А не надо или/или. Надо взять лучший алгоритм с лучшей структурой данных, причем не абстрактно лучшие, а в применении к конкретной задаче. А зачем брать хорошую структуру данных и портить все дело плохим алгоритмом или наоборот — не понимаю. Единственный аргумент — структура данных legacy, но тогда нет смысла обсуждать, хорошая она или плохая — какая уж есть.
Сложно спорить, если согласен с оппонентом. Собственно, на этом можно и остановиться.
PD>Ну и что ? Сколько si — столько и строк типа ps[i] = &si; . Если тебе 2000 описаний переменных не сложно сделать, что за проблема для тебя еще 2000 присваиваний сделать ?
ffar wrote:
> Что лучше: хорошие алгоритмы с плохими структурами данных или плохие > алгоритмы с хорошими структурами данных?
Лучше хорошие алгоритмы с хорошими структурами данных.
Ты что-то другое хотел услышать ?
На самом деле структуры данных — то могут быть любыми,
но достаточными для работы алгоритмов. Например, если надо
делать вставку/удаление в центр текстовой строки, нужны связные
списки. Без них быстрой вставки не будет. Какие угодно плохие,
но связные списки. Если нужен просмотр строки в прямом и обратном
порядке, нужен двусвязный список. Какой угодно, но двусвязный.
Так что, если серьёзно, лучше хорошие алгоритмы с достаточными для них
структурами данных.
