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/