Ниже приведенный способ интернизации так или сяк работает. Можно ли это сделать как-то не так криво? (как это сделать?) Как сравнить строки с помощью интернизации?

(defpackage :tom

  (:use :common-lisp)

  (:export #:main #:initsymbol #:init *b*)

)

 

(in-package :tom)

(defvar  *b*  )

(defun init()

	(setf *b* (make-array 20 

	   :initial-contents '(

			"<209640086183268229693796400861832682296937964008618326822969379640086183268229693796400861832682296937sadsdf>"

			"<19063170525534130133489693796400861832682296937964008618326822969379640086183268229693796400861832682296937f>"

			"<18438685652650748328849693796400861832682296937964008618326822969379640086183268229693796400861832682296937v>"

			"<17006734566489331366739693796400861832682296937964008618326822969379640086183268229693796400861832682296937b>"

			"<16099681527776661137689693796400861832682296937964008618326822969379640086183268229693796400861832682296937a>"

			"<15831180732119483729699693796400861832682296937964008618326822969379640086183268229693796400861832682296937c>"

			"<14169506888433311173619693796400861832682296937964008618326822969379640086183268229693796400861832682296937v>"

			"<13056835862493340327789693796400861832682296937964008618326822969379640086183268229693796400861832682296937b>"

			"<12514683278217971613539693796400861832682296937964008618326822969379640086183268229693796400861832682296937t>"

			"<11622988084595964206679693796400861832682296937964008618326822969379640086183268229693796400861832682296937q>"

			"<10964008618326822969379693796400861832682296937964008618326822969379640086183268229693796400861832682296937w>"

			"<9063170525534130133489693796400861832682296937964008618326822969379640086183268229693796400861832682296937d>"

			"<8438685652650748328849693796400861832682296937964008618326822969379640086183268229693796400861832682296937r>"

			"<7006734566489331366739693796400861832682296937964008618326822969379640086183268229693796400861832682296937f>"

			"<6099681527776661137689693796400861832682296937964008618326822969379640086183268229693796400861832682296937g>"

			"<5831180732119483729699693796400861832682296937964008618326822969379640086183268229693796400861832682296937h>"

			"<416950688843331117361i9693796400861832682296937964008618326822969379640086183268229693796400861832682296937>"

			"<305683586249334032778y9693796400861832682296937964008618326822969379640086183268229693796400861832682296937>"

			"<251468327821797161353u9693796400861832682296937964008618326822969379640086183268229693796400861832682296937>"

			"<162298808459596420667u9693796400861832682296937964008618326822969379640086183268229693796400861832682296937>"

 

		 )

		)

	)

)

 

(defun initsymbol()

        (dotimes (n (array-total-size *b*))

		 (intern (aref *b* n))

	)

)

 

(defun main()

	(find-symbol "<162298808459596420667u9693796400861832682296937964008618326822969379640086183268229693796400861832682296937>")

)

 

(in-package :tom)

(tom::init) 

(tom::initsymbol)

(tom::main)

Идея была простая. Узнав что возможно интерпретатор следит за уникальностью всех символов, меня заинтересовал процесс их сравнения. Оказалось что в реальности мы сравниваем не имена, а значения (которые по сути выступают как имена), примерно как я сделал это ниже. Мне осталось пока не понятным воспринимает ли лисп *p* и *t* как один и тот же символ. Это главный вопрос. Как это выяснить?
В каком-то смысле это простая и прозрачная идея.

 

(defpackage :tom

  (:use :common-lisp)

  (:export #:main #:init)

)

 

(in-package :tom)

(defvar *p*)

(defvar *b*)

(defvar *c*) 

(defvar *d*)

(defvar *t*)

(defun init()

          (setf *d*

 	    (list

 		 :one    "1" 

 		 :two    "2" 

 		 :free   "3"

                 :six    "6"		 

 	     )

	   )

           (setf *c*

 	    (list

 		 :one    "1" 

 		 :two    "2" 

 		 :free   *d* 

 	     )

	   ) 

 

  	   (setf *p*

 	    (list

 		 :one    *c*    

 		 :two    *c* 

 		 :free   *c* 

 	     )

	   )

	   (setf *b*

 	    (list

 		 :one    *c* 

 		 :two    *c* 

 		 :free   *d* 

 	     )

	   )

	   (setf *t*

 	    (list

 		 :one    *c* 

 		 :two    *c* 

 		 :free   *c*  

 	     )

	   )

 

)

 

(defun main()

        (progn 

		(format t " p == b ~S ~%" (equalp *p* *b*))

		(format t " p == t ~S ~%" (equalp *p* *t*))

		(format t " d == c ~S ~%" (equalp *d* *c*))

        )	

)

 

(in-package :tom)

(tom::init)

(tom::main)

У меня 120 ГБ xml файл. Если я научусь сравнивать не строки в символы, то это значительно ускорит его обработку. Вопрос: воспринимает ли лисп *p* и *t* как один и тот же символ. по сути вопрос какую стратегию сравнения интерпретатор выберет... У меня есть строка (или дерево) и я хочу узнать не находится ли оно среди уже известных мне строк(деревьев) по возможности очень быстро. Как-то так.

Зачем там в примере (symbol-value '*c*) вместо *c* и т. п. — не понял.

Цитата

---

Как сделать так что бы лисп делал выводы о равенстве по значению указателей на строки

---

Очевидно, сравнивать с помощью eq. Или вы хотите завернуть строки в списки и сравнивать списки по equal, но чтобы строки сравнивались по eq?

Офтопик: последние две строчки — это ровно то же, что

(setf *p* (list :one *d*))

(setf *b* (list :one *c*))

И так трудно въехать, а тут ещё symbol-value до кучи.

eq сравнивает указатели как раз. На числах и литерах, правда, ведёт себя непредсказуемо, так что имеет смысл использовать eql вместо него. А строка — это массив. Массивы вполне нормально сравнивать по указателю.

*d* и *p* получены разными вызовами функции list, поэтому это разные конс-ячейки, поэтому они не eq. Я и спрашиваю: вы хотите иметь возможность сравнивать соответствующие элементы списков по указателям, то есть с помощью eq?

В любом случае, (eq "1" "1") вполне может дать nil (не знаю, обязательно это или нет). То есть сравнение по указателям тут не работает.

Короче говоря, если вам всё время поступают новые строки, которые вы собираетесь интернить, по-моему, имеет смысл вместо этого использовать хеш-таблицу. И если производительность будет неудовлетворительная, переписать через символы. Хотя сомневаюсь, что через символы будет быстрее: неясно, почему превращение строки в символ должно быть дешевле, чем посмотреть эту строку в хеше.

Если же вы хотите сразу загнать кучу строк в символы и потом многократно использовать эти символы... Хозяин — барин, конечно, но я бы всё равно сначала сделал через хеш, или через string= , а потом бы думал, если бы получилось медленно.

Цитата

---

Яков Замир Кацман (нью) :
Ниже приведенный способ интернизации так или сяк работает. Можно ли это сделать как-то не так криво?

---

Напрашивается

(mapcar #'intern '("A11" "B22" "C33 ...))

Цитата

---

skelter :

---

А какое другое применение ты предлагаешь для этих значений?
Применительно к sxhash это равенство заложено сразу в определении. Зря я что ли ссылку на стандарт давал.

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

> У меня ощууение что ты не читал описание из стандарта по ссылке (не смог?).

Я умею читать. А что конкретно я упустил?

> Но зачем-то выдумываешь.

Что выдумываю?

> В таком ключе общение смысла не имеет

Не, всё нормально. Я доброжелательный и не совсем тупой, просто мы где-то друг друга недопоняли.

> Она уникальна.

Где это написано?

> 'Ведь в хеше могут встретиться ключи с одинаковым значением хеш-функции' - НЕ МОГУТ

Стандарт, естественно, не диктует, какой алгоритм хеширования использовать. Но вообще в компьютер саенс — могут.
https://ru.wikipedia.org/wiki/Хеш-таблица
https://ru.wikipedia.org/wiki/Коллизия_хеш-функции

Да, коллизия говорят вероятна для случайного набора знаков. Для осмысленной инфорации вероятность колизии вроде бы падает. Это сложный вопрос. В любом случае, тут речь была совсем о другом. Как максимально автоматизировать эту процедуру средствами интерпретатора.

Основной алгоритм:

1) Создать множество (hash set) строк
2) Создать индекс(ы) и сортировать.
3) Проверить, что строка (как последовательность символов), с которой вы имеете дело, уже в множестве
4) Если да, то использовать строку из множества
5) В противном случае, добавить эту строку в множество и затем использовать ее шаг 2)
6) создать соответствующее API

(взято с https://habrahabr.ru/post/260767/)

Вы правы. Значит надо будет написать.