[iiscienceii]

Подскажите стоит такая задача. В цикле определенной количество раз отрисовуется идин итот же элемент. И каждый последующий элемент должен быть присвоен переменной element_N. Где N номер построеного элемента. Например
(setq element_1 (entlast))
(setq element_2 (entlast))
..........................................
(setq element_N (entlast))

[Дима_]

Сообщение от 480725 Хотелось бы, что гораздо проще, проверить приведенную в цитате теорию на практике.

Так что'ж Вам мешает? Могу даже помочь:

Код:

[Выделить все]

 (defun make-list(x)  
  (if (not (zerop x))
      (cons x (make-list (1- x)))))
(defun make-list2(x)
  (if (not (zerop x))
      (append (make-list2 (1- x)) (list x))))

Вот Вам два "одинаковых" лиспа создающих списки из x чисел - который первый - это как говорю я, второй по предложенному Вами методу. Запустите сами (length (make-list 10000)) и (length (make-list2 10000)) и посмотрите "визуально", что побыстрее. Они оба еще,на более больших числах, упрутся в отсутствие в автолиспе оптимизации хвостовой рекурсии , ну что'ж - специально для Вас "развернутые" версии:

Код:

[Выделить все]

 (defun make-list-nr(x / ret)
  (while (> x 0)
         (setq ret (cons (setq x (1- x)) ret))))
(defun make-list-nr2(x / ret)
  (while (> x 0)
         (setq ret (append ret (list (setq x (1- x)))))))

Попробуйте вначале например (length (make-list-nr 100000)), можно и 1000000 и 10000000 - на долго они Вас не задержут, а вот запущенные "Вашим" методом (length (make-list-nr2 100000)) - можете смело идти покурить, а то и поспать.

Хотелось бы узнать сколько времени займет извлечение 9999 значений из ассоциативного списка, и как его формировать в Автолиспе без append... время обработки списков ни меня ни пользователей не напрягало никогда. (Наборы данных - другая песня, если надо анализировать буквально все примитивы в чертеже, например при обработке планов здания выполненных в Архикаде - тут доходило до 15 минут и приходилось писать на экране процент выполненного)

+ не буду приводить Ваши записи в личке
с моей точки зрения у Вас в корне не верное представление о принципах работы лиспа (что авто, что не авто - в данном случае не важно), то что Вы советуете алгоритмически крайне не эффективно - Ваши алгоритмы подойдут например для VB - пишите на нем, или прочитайте хоть одну книжку по лиспу - ну или хотя-бы посмотрите как там реализованы примеры функций (хотя я встречал пару методичек для студентов от которых мне просто хотелось плакать) перед тем как спорить и просить примеры. Хотите пример - дайте ТЗ с примером чертежа того что занимает 15 минут у Ваших пользователей, за сколько Вы купите решение которое будет делать то-же за 5 секунд - если мне "вдруг" удастся его реализовать - причем готов всю сумму безвозмездно перевести на счет dwg.ru (то есть Вы сами и переведете - но естественно если мы договоримся).

[VVA]

Сообщение от Do$ Для замера времени выполнения давным-давно есть функция для автолиспа

Есть benchmark Michael Puckett'a. На theswamp'e требуется регистрация. Алексей выложил на autolisp.ru benchmark.lsp
Статья "how to do" - Сравнение скорости выполнения кода

Сообщение от Do$ для автолиспа (от Елпанова Евгения вроде).

В первом комментарии есть вариант решения и от Евгения с помощью _vl-times (по моему даже недокументированная функция)

[480725]

Сообщение от Дима_ с моей точки зрения у Вас в корне не верное представление о принципах работы лиспа (что авто, что не авто - в данном случае не важно), то что Вы советуете алгоритмически крайне не эффективно - Ваши алгоритмы подойдут например для VB - пишите на нем, или прочитайте хоть одну книжку по лиспу - ну или хотя-бы посмотрите как там реализованы примеры функций (хотя я встречал пару методичек для студентов от которых мне просто хотелось плакать) перед тем как спорить и просить примеры. Хотите пример - дайте ТЗ с примером чертежа того что занимает 15 минут у Ваших пользователей, за сколько Вы купите решение которое будет делать то-же за 5 секунд - если мне "вдруг" удастся его реализовать - причем готов всю сумму безвозмездно перевести на счет dwg.ru (то есть Вы сами и переведете - но естественно если мы договоримся).

1) По поводу эффективности. Несколько раз в переписке упоминалось, что речь идет об отверстиях в столешнице. Я ни разу не видел столешницы с более чем двумя отверстиями, но возьмем с запасом 4. Дневной заказ, который придется обрабатывать примем сразу с невероятным запасом в 100 столешниц ( не менее 20 бригад для установки). Итого получаем список из 400 элементов. Жду отчета о выигранных милисекундах, на фоне потерь времени от однократного почесывания затылка пользователем во время указания этих отверстий, или выбора файла чертежа, если отверстия программа распознает автоматом (есть еще вероятность что они создаются в программе, т.е. время тратится и на диалог создания). Все равно, мои поздравления: где-то 0.001 сек преимущества (да чего там зажимать - пусть 0.01 сек преимущества) на создании списка вы получили. В спринтерском беге, это на уровне разницы между рекордом мира и нормативом мастера спорта в беге на 10 метров. Заметная цифра на фоне, например, затрат времени на эту переписку! При этом не могу не признать, что скорость работы в вашем случае - понятие просто бессмысленное- никакой скорости нет, все происходит мгновенно. Если бы у меня были проблемы с размерами списков, я попытался бы применять именно предложенные вами механизмы. Но, повторяю, реальные размеры списков в моей области работы такие, что никакого ощутимого времени на списки не тратится!.. Кстати перечитал текст и решил еще раз насладиться скоростью работы вашей программы, назначив предложенные вами 100000. И получил отлуп.. Вернулся к 10000 - работает... Вот тут скорость пригодилась! Я легко подошел сверху к 20000 как неработоспособной границе а потом снизу методом последовательного приближения вычислил реальный предел для моего А2008:
Команда: (make-list 19997)
Возникла серьезная ошибка ***
достигнут внутренний предел стека (смоделирован)
19996 у меня еще работает, а как у вас? Вы действительно проверяли 100000?

2) Создание списка без append - второй из двух вопросов, на первый Хотелось бы узнать сколько времени займет извлечение 9999 значений из ассоциативного списка (т.е через оператор assoc) вы почему-то не ответили. А он был основным. И про механизм извлечения данных из ассоциативного списка не написали. И про то, зачем вы предлагаете ассоцитивный список там, где предполагается обработка перебором подряд - т.е. о том, именно против чего я и возражал, у вас нигде нет ни слова.
3) Вы пишете Ваши алгоритмы - где вы увидели алгоритмы? Был просто пример как делать список, для человека, который назвал его массивом.
4)Хоть и не по делу, но т.к. частично сам виноват - вот вам ТЗ: Есть такая программа АРХИКАД, со своими форматами данных и у нее есть экспорт в DWG. Двухмерный экспорт дает набор блоков, часть из которых представляют собой участки стен с проемами - окнами и дверями - все эти блоки индивидуальные и, в общем случае, ни разу не повторяются. Для работы смежников на этом DWG надо все разблокировать (оставив сблокированными только проемы, и не относящиеся к стенам блоки (мебель сантехнику и т.д.)) привести стены к заданному цвету и слою, найти оси здания и тоже привести их к заданным цвету и слою, по возможности привести к заданному цвету и слою размеры, разделив их на осевые и прочие. Количество примитивов после завершения несколько сотен тысяч все они проанализированы и треть из них изменена. Можете задавать в программе разумное количество вопросов, но отвечать на них будет не создававший чертеж архитектор (он в другой организации работает), а проектировщик-сантехник. И последнее. Есть несколько версий Архикада (я сейчас помню про 7-ю, 9-ю, 11-ю на момент создания) но за это время появились новые я их просто не отслеживаю. Организация экспортированного DWG у разных версий может меняться, т.е. префиксы блоков не могут служить средством для распознавания стен. Работа делается для сантехников, если у них появятся чертежи из другой, возможно не существующей в момент создания вашей программы версии Архикада и с ними программа откажется работать - вы будете должны в пожарном порядке бесплатно обеспечить ее работоспособность, иначе будет считаться, что вы подвели пользователей. Это тоже входит в ТЗ. Лет 7 последняя версия работает без необходимости вносить изменения в связи с новыми версиями Архикада, поэтому фактор 15 минут на файл с планами 7 разных этажей и 3-мя разрезами сложного здания ничтожен на фоне надежности программы. Да и последующая работа по проектированию сантехники занимает несоизмеримо больше для описанного случая - дни... Деньги платить не стану, т.к. такой тест на надежность как годы реальной эксплуатации моей программы провести не смогу, и вы не сможете... Файл, если захотите, пошлю, но у меня нет под рукой достаточного количества файлов разных версий Архикада, чтобы обеспечить тестирование их именно для произвольной версии. Я слишком давно закрыл проблему..

[Дима_]

Сообщение от 480725 19996 у меня еще работает, а как у вас? Вы действительно проверяли 100000?

Цитирую себя-же:

Они оба еще,на более больших числах, упрутся в отсутствие в автолиспе оптимизации хвостовой рекурсии , ну что'ж - специально для Вас "развернутые" версии: ... (length (make-list-nr 100000)), можно и 1000000 и 10000000

то есть милиооны проверяйте на двух следующих лиспах написанных с развернутой в цикл рекурсией

Все равно, мои поздравления: где-то 0.001 сек преимущества (да чего там зажимать - пусть 0.01 сек преимущества) на создании списка вы получили.

Это не я их получил - это Вы делаете через неправильное место и на Ваших примерах все прокатывает - заметьте Ваш пример хуже по всем критериям (кроме того что так делаеть Вы привыкли - все остальное и длина кода и скорость его работы и еще несколько аргументов которые я позволю себе не расписывать), но это Ваше дело - когда Вы начинаете учить других лечить зубы через ... аргументируя, что так почему-то проще, вот это меня немножко настораживает.

Хотелось бы узнать сколько времени займет извлечение 9999 значений из ассоциативного списка (т.е через оператор assoc) вы почему-то не ответили. А он был основным.

Я Вам отвечаю то, что Вы никак не хотите слушать - нет никакого смысла сравнивать циклическое извлечение из ассоциативного списка - я так никогда делать не буду, к списку есть два типа доступа car и cdr - все остальное их производные - естественно, если Вы руководствуясь своей логикой организуете извлечение в цикле через assoc оно займет столько-же как и предложенный Вами вариант с nth. У вас ошибка в первоначальном суждении. Использовать assoc следует только если ключ элемента несет некую уникальную сущность, когда ее (сущности) нет - в ней нет никакого смысла - перечитайте заново, всю тему. Списки подразумевают целостное испоьзование. На кой Вам хранить индекс для доступа через nth - это я у Вас спрашиваю с первых-же сообщений, а Вы начинаете мол теорию мне не надо - давайте скорость померим - Вы не понимая сути и предназначения списка пытаетесь использовать его не по назначению, если нужен быстрый доступ по ключю к большой структуре, которую Вы планируете использовать циклично, создается, например, двоичное дерево - на основе тех-же списков (либо вобще принимается решение использовать более эффективные инструменты), а не "лепится" из того что я уже 10 лет делаю. В вопросе автора я не до конца понимаю задачи, но из того что я понял - там вобще никаких списков "проемов" не нужно - про assoc я приводил пример как решить задачу с индексацией нескольких элементов (автор-то хотел придумать кучу переменных - от чего я его и начал отговаривать - хотя по Вашей логике можно и так - ведь не дольше будет).
Люди в этой теме спрашивают, как сделать, если и советовать кривые методы, то только в случае, что либо их реализация действительно на порядок проще для автора, либо если другого ничего нет. Предлагать вместо стандартных решений чехорду и еще говорить, а давайте сравним - это не верное решение.
з.ы. ТЗ меня впечатлило - платить не станете, Вам это не надо (т.к. тест на надежность не пройден), но я ее должен пожизненно поддерживать и критерии определения я должен придумать сам - а они естественно не совпадут с Вашими - в общем, в любом случае будет, что это я "не справился". Уверяю Вас на такое ТЗ согласиться только жулик, работа которого закончится когда Вы переведете ему деньги.

Я слишком давно закрыл проблему..

Скорее ее либо нет, либо Вы на нее просто положили - могу ошибатся.

[480725]

Сообщение от Дима_ Цитирую себя-же: то есть милиооны проверяйте на двух следующих лиспах написанных с развернутой в цикл рекурсией ... ..Вы никак не хотите слушать - нет никакого смысла сравнивать циклическое извлечение из ассоциативного списка - я так никогда делать не буду ... Использовать assoc следует только если ключ элемента несет некую уникальную сущность, когда ее (сущности) нет - в ней нет никакого смысла - перечитайте заново, всю тему.

1) Да, правда, второй текст без задержки сделал 1 000 000. Кто бы сомневался, что про стек ругалась рекурсия. А мой довод о реальном размере списков, не позволяющем наслаждаться этой великолепной скоростью конечно проигнорирован...
В отечественных описания Автолиспа упор делается на Cons как на основной инструмент создания точечного списка (у Полещука в обоих книгах), про преимущества Сons не пишут не только отечественные описания (известные мне) но и разработчики в AutoLISP Reference Guide, как минимум в А2008. Так что немудрено не знать что он намного быстрее чем append, который все-таки добавляет новый элемент в конец, а не в начало, что, будучи более естественным, провоцирует применять его. В этом смысле для меня спор был полезен, возможно он станет полезен и кому-то кто сможет реально этой скоростью воспользоваться, я, если представится случай - воспользуюсь обязательно.
2) Про отсутствие смысла циклического извлечения из ассоциатитивного списка предложенного вами #5 я как раз постоянно и говорю. По формулировке задачи понадобится именно циклическое извлечение. И поэтому ассоциативный список не нужен. У нас идет разговор глухих.

3) Зачем предлагать в #5 использовать ассоциативный список, если он без уникальных ключей, об чем я и толковал все это время? См. выше..
4)

Сообщение от Дима_ Уверяю Вас на такое ТЗ согласиться только жулик, работа которого закончится когда Вы переведете ему деньги. Скорее ее либо нет, либо Вы на нее просто положили - могу ошибатся.

Я вообще не понимаю пафоса разговора о ТЗ. Мне фактически предложили спорить на деньги, правда без встречных обязательств в плане денег, я объяснил, что спорить не отказываюсь, но поскольку спор сугубо умозрительный и применять его результат я не собираюсь, на деньги спорить не буду, но готов после того как будет работоспособный анализ на предмет выявления линий стен, а также блоков дверей, а там вся суть в нем, если надо, сколь угодно уточнить ТЗ (в остальном все просто), и договориться о критериях оценки (собственно кроме времени сравнивать нечего, надежность никто не требует я перечислил версии Архикада - любую из них на выбор, любую по вашему выбору из последних, и один файл, который завалялся у меня, его мне недавно присылали, а версию не знаю, чтобы не подозревали меня в обмане могу выслать его в запароленном архиве, пароль сообщу только на стадии проверки результата), опубликовать результат на форуме в этой теме. Можно только в случае вашей победы, мне все-равно.
Не я полез с этим спором, мне он сто лет не нужен, но и отказался от него не я. Участие в теме прекращаю, готов вернуться, только чтобы потвердить принятие участия в споре, ведь весь его интерес для вас в его публичном характере.
Если вы не догадались, я больше делаю ставку на то, что не выйдет сделать программу работоспособной на разных версиях Архикада, и вполне допускаю, что быстрее будет ваш вариант (если решите основную задачу). Я бы подобный спор никому не предлагал и никогда в него не влез бы (в качестве разработчика конкурирующей версии сложной программы).

Но вы предложили, я согласен. Теперь в случае спора без денег вы можете не опасаться прослыть жуликом, я, слава Богу, себе в случае победы в споре денег не просил, программа мне заведомо не нужна, так что пока под такое подозрение не попадаю. Переговоры по спору только в личке.

4) Насчет ее либо нет, либо Вы на нее просто положили Сейчас проблемы нет, но она была раньше. Примерно через версию Архикада структура файла менялась, приходилось вникать, и переделывать программу, пока однажду не осенило... А потом конечно положил - сделал алгоритм, который закрыл вопрос и положил. У меня Симферопольский друг сантехник, он мне покоя жизни не даст, если программа не работает.. Да и заказчиков подводить не резон.. Во многих регионах архитекторы предпочитают работать на Архикаде, и для сантехников на Автокаде нужна подработка.

----- добавлено через ~19 мин. -----

Сообщение от Do$ Вместо ввода кучи букв уже давно самостоятельно проверил бы. Для начала вот это в своем коде Код: [Выделить все] (setQ spisok(appenD spisok(list (entlast)))) замени на Код: [Выделить все] (setQ spisok (cons (entlast) spisok)) Command стоит оттуда выкинуть нафик. Для замера времени выполнения давным-давно есть функция для автолиспа (от Елпанова Евгения вроде). На форуме поиском ищется.

Я предпочел считать до семи. Про что и написал. Примерно семь секунд на 10000 операций. При всем уважении к Евгению, чтобы померить программно интервал времени, обойдусь своими силами, чего и вам желаю. Поскольку реально цикл будет в 25 и более раз меньше - не критично. В этих условиях мне больше нравится дописывать в конец а не в начало списка. Спасибо, вы первый привели текст этого варианта в этой теме.

[Дима_]

Ну вот, мне приятно что у Вас начали появляться логически обоснованные рассуждения и выводы. Раз уж Вы (если я правильно понял) принимаете, что я кое-что да смыслю в лиспе - с Вашего позволения продолжу:

Сообщение от 480725 который все-таки добавляет новый элемент в конец, а не в начало, что, будучи более естественным, провоцирует применять его.

язык не поворачивается назвать Вас новичком лиспа (т.к. стажу у Вас, с Ваших слов, коим я не склонен не верит, не менее 10-ти лет - у меня, кстати, его меньше, но да ладно), но это именно их тенденция создать свою библиотеку "правильных" функций языка для добавления в конец списка, "обратного" member'а и пр. "полезных фишек". ИХМО - в автолисп конечно не пестрит избыточным функционалом (хотя по мне-бы кое-что оттуда не мешало-бы и убрать - код "чище" будет - но это отдельная тема), но поверьте на слово - все необходимое там есть, а что Вам кажется более естественным - только от слабой теоритической подкованности - повторю еще раз - у списка только голова и хвост - это не структура в которой требуется добавлять в конец - попробуйте это просто принять на веру (для начала).

По формулировке задачи понадобится именно циклическое извлечение.

с чего Вы сделали такой вывод? Где вы увидели необходимость в цикличности - у вас сработал стереотип - это можно извлечь с помощью цикла - но в задачи этого нет. Лисп создан на основе лямбда исчисления, которое разработал действительно гений (заметьте компьютеры еще были больше "виртуальными") - это, по сути, форма представления любых алгоритмов. Вот Вам пример на обдумывание есть у нас список, который Вы проиндексировали-таки по порядковому номеру (пример специально для Вас - на практике такое делать я очень не рекомендую). Казалось-бы все просто пишем функцию по которой мы из списка ключей получим список значений

Код:

[Выделить все]

 (defun test(index lst)
  (mapcar '(lambda (i) (nth i lst)) index))

Вроде и код краток и работать он будет достаточно быстро (на списках умеренного размера). Но такой ворчун как я предложу Вам реализовать самостоятельно код который отсчитывая одновременно из списка значений, будет отфильтровывать только нужные по предварительно отсортированному списку индексов (поверьте код будет совсем не большой - но давайте сами - когда своей головой думаешь - понимание приходит гораздо быстрей) - получиться что по списку мы пройдемся 1 раз (вместо раз = количеству индексов). Да, чтоб заметить разницу в скорости надо очень большие списки, но представим, что у нас не проверка на равенство, а что-то более значительное (например сравнение 3д тел) - попробуйте ради эксперимента добавить запрос строки на каждой итерации и посмотрите сколько надо будет молотить по клавиатуре. Беда в том, что Вы даже не поймете, что в Вашем случае Вы делаете сильно многократную работу (как это было с append). Именно по этому, я даже не глядя в код и предположил, что то, что у Вас сделано с таким подходом тратит много больше нужного времени. В тех примерах что мы до сих пор рассматривали время действительно в абсолютных величинах не сильно отличается, но как я уже сказал, это только благодаря ничтожно малой затраты времени на 1 итерацию, в относительных величинах там "пропасти" между ними - не засоряйте себе голову неправильными вещами - просто как совет. Лисп очень "продвинутый" с алгоримической точки зрения язык программирвания (даже автолисп), но им надо уметь пользоваться (в него надо вникнуть если хотите - а в Вашем варианте - это его грубое и очень не эффективное использования, даже с точки зрения времени разработки) - сила лиспа как раз в чрезвычайно эффективной разработке структур и функций под конкретную задачу, и да - у меня действительно на уровне рефлекса начинает "дергаться глаз" когда вижу, что зубы стараются не через-то место лечить - уж простите мне "маленькую слабость".
Про спор - спорить я ни о чем не предлагал - это Вы "ловко" вывернули. Мотивации публичного характера у меня нет (здесь меня и так не плохо знают). Уверяю Вас - что пользователей устраивает 15 минут - только от отсутствия других вариантов (кроме еще делать руками). Да, я полагал, что Вы вряд-ли "заинтересуетесь", но "отвертываться" бы не стал - сделал (мне бы, как Вы помните от этого ничего не перепало) просто предложить хотите сделаю Вам без Вашего участия - это типо сам себе придумал работу - которая никому не нужна (такая проверка на необходимость), но быть может, все-же, у Вас появятся мысли в "правильном" направлении - для меня это будет лучшим моральным результатом всей этой переписки.
Если интересует литература по лиспу - погуглите SICP - шикарная книга для "начала" - как правила она "раскрывает" глаза на лисп как таковой (автолисп потом будет казаться детской игрушкой - простой и понятной).
Искренне желаю Вам удачи и эффективности во всех делах.
з.ы. если закрались сомнения по поводу "слабых" сторон в Вашем алгоритме можете выслать его мне личкой (можно и публично - это на Ваше усмотрение) - свои соображения безвозмездно выскажу.

[kakt00z]

Дима_, а можно вас попросить прокомментировать ф-цию my-append из поста #18

[Дима_]

Можно - просите!

Код:

[Выделить все]

 (defun my-append (lst1 lst2) ; объявляем функцию от 2 аргументов
 ((lambda (frec) (frec (reverse lst1) lst2)) ; получаем рекурсивную функцию (frec) и применяем к ней 1-ый перевернутый список и 2-ой 
  (lambda (lst1 lst2); определение frec - функция от двух аргументов
    (if lst1; если что-то есть в первом аргументе
        (frec (cdr lst1) (cons (car lst1) lst2)); запускаем сами себя (frec) с "хвостом" первого аргумента и "головой" первого добавленного ко второму
        lst2)))); когда первый аргумент пуст - возращаем второй аргумент (в который в итоге поэлементно добавился первый)

[kakt00z]

Сообщение от Дима_ Можно - просите!

тож люблю так делать , вопрос был рекурсивный :P
всёж, пока что, не могу "дочуствовать". (именно "голову" списка)
попутно, по лиспософии, возник еще вопрос - возможно ли (как если да) написать функцию на динамическое количество переменных?
Offtop: кстати, думаю, не плохо было бы даже отдельный топик сделать на тему мудрости

[Дима_]

Сообщение от kakt00z написать функцию на динамическое количество переменных

А теперь Ваша очередь объяснить, что Вы подразумеваете под словом переменная (на всякий случай, по крайней мере с точки зрения лиспа, в вышепреведенном коде их нет ни одной). А Вобще для создания "произвольной динамической переменной" есть функция (set ....) - не рекомендую ее использовать - ихмо больше "вредная" функция.

[kakt00z]

сори, имел ввиду аргументы.. аналог (+ a b c ...)

[Дима_]

Аааа, да уж. На Auto/VisualLispe никак - можно написать на .Net или Arx.

[VVA]

Сообщение от Дима_ написать функцию на динамическое количество переменных

Сделай одну переменную - ассоциативный список. Пример

[Дима_]

Сообщение от VVA Сделай одну переменную

Я уже про это писал - не всегда функцию обрабатывающею список с произвольным количество элементов можно безболезненно заменить на "многоаргументную функцию".

[kakt00z]

Сообщение от VVA Сделай одну переменную - ассоциативный список

вопрос стоял не так список = один аргумент