Forth http://fforum.winglion.ru/ |
|
*выборка из массива указателей http://fforum.winglion.ru/viewtopic.php?f=19&t=2322 |
Страница 3 из 3 |
Автор: | chess [ Чт ноя 26, 2009 21:17 ] |
Заголовок сообщения: | |
mOleg писал(а): тут мы сразу уходим в дебри. Для меня никаких дебрей нет. Набираю SEE clean. Не вижу call-ов. Кроме того определение можно написать на ассемблере - код будет проще и быстрее. Кроме того можно чуть изменить формирование словарной статьи с введением доп. поля или флага. Вообщем вариантов как всегда много. mOleg писал(а): все замечания сводятся лишь к тому, что ваш код будет работать в ограниченном количестве случаев.
Можете привести хотя бы один такой случай - если не трудно. |
Автор: | mOleg [ Чт ноя 26, 2009 21:59 ] |
Заголовок сообщения: | |
chess писал(а): Для меня никаких дебрей нет. Набираю SEE clean. Не вижу call-ов. Кроме того определение можно написать на ассемблере - код будет проще и быстрее. Кроме того можно чуть изменить формирование словарной статьи с введением доп. поля или флага. Вообщем вариантов как всегда много. мы вообще говорим о разном. Просто совсем без разницы что показывает SEE. важно, что трогать данные по указанным адресам нельзя(однако я просто не подумал об этом при написании ТЗ). chess писал(а): Можете привести хотя бы один такой случай - если не трудно.
не будет работать на больших адресах адресах не реентерабельно но опять же, это не претензия. |
Автор: | вопрос [ Чт ноя 26, 2009 23:56 ] |
Заголовок сообщения: | |
Если нельзя трогать изначальный массив (кстати, почему), то алгоритм может быть, кажется, только таким (или я что-то не понимаю): брать по очереди каждый элемент от начала и проверять, есть ли он же раньше в массиве, если нет - он кладётся "следующим" в новую структуру [результат-массив] , дойдя до конца, цикл прекращается. Зачем, для каких случаев нужнв реентерабельность? |
Автор: | VoidVolker [ Пт ноя 27, 2009 00:23 ] |
Заголовок сообщения: | |
Алгоритм chess'а достаточно легко адаптировать под "неизменение" просто введя "промежуточные" адреса, т.е. расположить указатели в новых адресах(переменных), и упорядочивать уже массив с этими новыми адресами. Но это оптимальнее делать на более ранней стадии работы программы - при определении самих первичных указателей. Или, что еще лучше, в структуре по указателю ввести дополнительный байт для флага. Т.о. во время работы программы можно при минимальных потерях производительности достаточно быстро обрабатывать эти самые массивы указателей. А для многопоточности - можно использовать дополнительные биты в поле флага. Так что считаю это решение наиболее эффективным. |
Автор: | WingLion [ Пт ноя 27, 2009 08:16 ] |
Заголовок сообщения: | |
VoidVolker писал(а): во время работы программы можно при минимальных потерях производительности
А требование иметь при этом минимум 16Гб памяти при 32-хбитных указателях никак не смущает? |
Автор: | VoidVolker [ Пт ноя 27, 2009 11:27 ] |
Заголовок сообщения: | |
WingLion писал(а): А требование иметь при этом минимум 16Гб памяти при 32-хбитных указателях никак не смущает?
Какие еще требования? И чем они обусловлены? +1 байт на указатель - для этого нужно 16 гигабайт памяти? |
Автор: | mOleg [ Пт ноя 27, 2009 13:26 ] |
Заголовок сообщения: | |
вообще не нужно путать частные и общие решения. Многие алгоритмы прекрасно работают в однозадачных системах, и не работают на многозадачных. Абсолютно любое решение имеет свои достоинства и недостатки, и их важно понимать, но не нужно осуждать! Я не занимался осуждением, а занимался обсуждением. К примеру, на той же сортировке при ограничении значений в 256 бит (то есть на символах) вполне быстро и красиво решается с помощью 256 ячеечной таблицы с последующей "распаковкой в простом цикле", но на строках такой алгоритм не работает вообще. |
Автор: | вопрос [ Пт ноя 27, 2009 19:12 ] |
Заголовок сообщения: | |
Хм, я ещё раз повторю вопрос: для каких случаев могла бы понадобиться реентерабельность? Можно было бы сформулировать задачу в виде "преобразовать один масив, оставляя его нетронутым, в другой, где элементы расположены в том же порядке, но изъяты повторы, причём должна быть учтена возможность [вот тот самый случай, где нужна реэнтерабельность] " мне кажется, вполне возможно одно решение |
Автор: | mOleg [ Пт ноя 27, 2009 19:54 ] |
Заголовок сообщения: | |
вопрос писал(а): Хм, я ещё раз повторю вопрос: для каких случаев могла бы понадобиться реентерабельность? это как бы правило хорошего тона. вопрос писал(а): мне кажется, вполне возможно одно решение
задачка интересна тем, что решений может быть много достаточно непохожих. и оптимальное решение для разных условий может разным. То есть, к примеру, если речь идет о ускорении поиска в контексте (то есть исключения повторов в контексте) то лучше вариация моего первого решения с сохранением нуля в место повтора. Причем, выглядело бы это следующим образом: 1) при каждом изменении в контексте все его содержимое копируется в "теневой" буфер 2) для каждого поиска в следующем словаре убираются возможные повторы, причем, возможно уже после того, как в нем не найден искомое слово (да, возможно для vid словарей с уже убранными повторами стоит добавить битовый флаг.) то есть решение во времени будет "размазано", и тут решения с глобальными зависимостями просто в пролете. |
Страница 3 из 3 | Часовой пояс: UTC + 3 часа [ Летнее время ] |
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group http://www.phpbb.com/ |