Re[6]: hash() - Продукты TerraInformatica

Привет.

hash() возвращает разные значения:

<html>
<head>
  <script type="text/tiscript">
    var obj = {data:100};
    self.insert(String.$(Hash: {hash(obj)}, data - {obj.data} ));
    self#test.onClick = :: self.insert(String.$(Hash: {hash(obj)}, data - {obj.data} ));
  </script>
</head>
<body>
<button#test>Test</button>
</body>
</html>

Здравствуйте, cgibin, Вы писали:

hash() определена для атомарных типов: string, symbol, int, float.
Для всех остальных она возвращает heap pointer value — что строго говоря неправильно, надо фиксить по-хорошему (?).

Соответственно это и есть то что ты наблюдаешь — разные адреса у удного и того же объекта, до и после GC.

А что ты пытаешься с hash() сделать?

Здравствуйте, c-smile, Вы писали:

CS>А что ты пытаешься с hash() сделать?

Я использовал объект в качестве ключа в другом объекте для быстрой проверки принадлежности определенной группе. Если я правильно понимаю, в этом случае hash() вызывается неявно. Это работало, но похоже, не без определенной доли удачи.

Здравствуйте, cgibin, Вы писали:

C>Здравствуйте, c-smile, Вы писали:

CS>>А что ты пытаешься с hash() сделать?

C>Я использовал объект в качестве ключа в другом объекте для быстрой проверки принадлежности определенной группе. Если я правильно понимаю, в этом случае hash() вызывается неявно. Это работало, но похоже, не без определенной доли удачи.

Да, тебе повезло. объект в качестве ключа теоретичекски возможен но практически может не сработать если ключей больше 8.

А вот кстати интересный вопрос... что есть hash от объекта, как он должен вычисляться?

Здравствуйте, c-smile, Вы писали:

CS>А вот кстати интересный вопрос... что есть hash от объекта, как он должен вычисляться?

На мой взгляд, hash от объекта должен определять его identity. Как и оператор сравнения, не должен интересоваться содержимым. В грубом приближении — некий глобальный счётчик, значение которого увеличивается и цепляется к объекту при его создании.

*равенства же

Здравствуйте, cgibin, Вы писали:

CS>>А вот кстати интересный вопрос... что есть hash от объекта, как он должен вычисляться?

C>На мой взгляд, hash от объекта должен определять его identity. Как и оператор сравнения, не должен интересоваться содержимым. В грубом приближении — некий глобальный счётчик, значение которого увеличивается и цепляется к объекту при его создании.

hash value по определению не может определять identity. Разные объекты могут имет одинаковые hash values, crc и пр.
Если тебе нужен identity то надо использовать адрес, если он неизменямый. Что как раз таки и not the case.
А глобальный счетчик имеет свойство переполняться.

Здравствуйте, c-smile, Вы писали:

CS>Здравствуйте, cgibin, Вы писали:

CS>hash value по определению не может определять identity. Разные объекты могут имет одинаковые hash values, crc и пр.
CS>Если тебе нужен identity то надо использовать адрес, если он неизменямый. Что как раз таки и not the case.
CS>А глобальный счетчик имеет свойство переполняться.

Это понятно. Я предложил вариант, который имеет практическое применение и не сложен в реализации. Если делать честный hash, то тут появляются требования к скорости, нужен будет анализ типов внутренностей объекта и потом эту всю кухню объяснять, когда хеши у людей не будут сходиться.
Хотя, возможно, я предвзято смотрю в свете собственной задачи )

Здравствуйте, c-smile, Вы писали:

CS>Здравствуйте, cgibin, Вы писали:

CS>hash() определена для атомарных типов: string, symbol, int, float.
CS>Для всех остальных она возвращает heap pointer value — что строго говоря неправильно, надо фиксить по-хорошему (?).
У объектов же ж есть (наверное?) GC-хэндлы — нельзя ли из них извлечь что-нибудь полезное?

Здравствуйте, fddima, Вы писали:

F> У объектов же ж есть (наверное?) GC-хэндлы — нельзя ли из них извлечь что-нибудь полезное?

А что такое GC-хэндл и для чего он нужен?

Здравствуйте, c-smile, Вы писали:

F>> У объектов же ж есть (наверное?) GC-хэндлы — нельзя ли из них извлечь что-нибудь полезное?
CS>А что такое GC-хэндл и для чего он нужен?
Хм, ну раз сборка мусора как-то случается — не работает же ж код с raw-pointers, а использует какие-то внутренние структуры вместо них?
Если в терминах V8, то там PersistentHandle<T> указывает на storage cell, в котором уже лежит указатель на объект в хипе.
Заранее извиняюсь, вопрос может дурацкий.

Здравствуйте, fddima, Вы писали:

F>Здравствуйте, c-smile, Вы писали:

F>>> У объектов же ж есть (наверное?) GC-хэндлы — нельзя ли из них извлечь что-нибудь полезное?
CS>>А что такое GC-хэндл и для чего он нужен?
F> Хм, ну раз сборка мусора как-то случается — не работает же ж код с raw-pointers, а использует какие-то внутренние структуры вместо них?

Как раз с raw pointers и работет.

Есть понятие pinned ссылки которая устроена как элемент связанного списка

struct pinned {
pinned *next,*prev;
object* val;

operator object*() const { return val; }

};

pinned используется в случаях когда надо "прикопать" некий объект для последющего использования.
Во время GC сборщик пробегает по этому списку и обновляет val адреса.

F> Если в терминах V8, то там PersistentHandle<T> указывает на storage cell, в котором уже лежит указатель на объект в хипе.

Этот PersistentHandle<T> как раз и есть pinned variable. Они хранят в таблице, я храню в списке — сущность та же.
Не все живые объекты имеют pinned части. Один и тот же объект может иметь несколько pin'ов.
Т.е. это механизм никак не может использоваться для идентификации объектов.

Здравствуйте, c-smile, Вы писали:

CS>А вот кстати интересный вопрос... что есть hash от объекта, как он должен вычисляться?

условно говоря, это должен быть хеш от его сериализации

Здравствуйте, BulatZiganshin, Вы писали:

BZ>Здравствуйте, c-smile, Вы писали:

CS>>А вот кстати интересный вопрос... что есть hash от объекта, как он должен вычисляться?

BZ>условно говоря, это должен быть хеш от его сериализации

Понятно что хеш контейнера это сумма хешей всех его компонентов ⊕ хеш от длины.

Но хеш не может служить identity маркером как товарищу требуется...

Хешем для неатомарных типов может служить их размер, в любом случае хеш не должен меняться после GC

Здравствуйте, newton1, Вы писали:

N>Хешем для неатомарных типов может служить их размер, в любом случае хеш не должен меняться после GC

А размер чего собственно?

И потом это какой-то неправильный hash получается. Скажем все объекты вида { firstName:"...", lastName:"..." } будут иметь одинаковое значение hash. Совсем не хорошо.

Здравствуйте, c-smile, Вы писали:

CS>Здравствуйте, newton1, Вы писали:

N>>Хешем для неатомарных типов может служить их размер, в любом случае хеш не должен меняться после GC

CS>А размер чего собственно?

Размер объекта

CS>И потом это какой-то неправильный hash получается. Скажем все объекты вида { firstName:"...", lastName:"..." } будут иметь одинаковое значение hash.

Не все объекты, а те у которых firstName и lastName идентичны.

CS>Совсем не хорошо.

Но и не так плохо, тем не менее. Коллизии в природе хеша, тогда как изменяемость хеша нет.

Здравствуйте, newton1, Вы писали:

CS>>А размер чего собственно?

N>Размер объекта

А что такое размер объекта?

Скажем есть два массива: [1,2,3] и [4,5,6]. Какие у них будут hash values в твоем случае?

Здравствуйте, c-smile, Вы писали:

CS>А вот кстати интересный вопрос... что есть hash от объекта, как он должен вычисляться?

Принцип наименьшего удивления советует сделать так, как в Java и .NET

Здравствуйте, GarryIV, Вы писали:

GIV>Здравствуйте, c-smile, Вы писали:

CS>>А вот кстати интересный вопрос... что есть hash от объекта, как он должен вычисляться?

GIV>Принцип наименьшего удивления советует сделать так, как в Java и .NET

То как сделано в Java например вызывает как раз наибольшее количество вопросов.
Там вообще назначение этого hashValue() не ясно.

Вот правила Java:

"123".hashValue() == "123".hashValue();
"123".hashValue() != "345".hashValue();

{a:"123"}.hashValue() != {a:"123"}.hashValue();
{a:"123"}.hashValue() != {a:"345"}.hashValue();

Я теряюсь в понимании того что такое hash в их понимании. Это identity или content метрика или что-то другое вообще?

	От:	cgibin
	Дата:	25.08.13 16:06
	Оценка:

От:	c-smile	http://terrainformatica.com
Дата:	25.08.13 16:32
Оценка:	4 (1)

	От:	cgibin
	Дата:	25.08.13 17:13
	Оценка:

От:	c-smile	http://terrainformatica.com
Дата:	25.08.13 17:29
Оценка:

	От:	cgibin
	Дата:	25.08.13 18:41
	Оценка:

	От:	fddima
	Дата:	06.09.13 10:53
	Оценка:

	От:	fddima
	Дата:	09.09.13 10:37
	Оценка:

	От:	BulatZiganshin
	Дата:	10.10.13 20:50
	Оценка:

	От:	newton1
	Дата:	28.01.14 21:35
	Оценка: