Re[13]: Хэш-таблица vs. дерево поиска
От: Mab Россия http://shade.msu.ru/~mab
Дата: 24.12.05 14:07
Оценка: 22 (1) +2
Здравствуйте, adontz, Вы писали:

A>С первой попытки? Иил всё таки игрался с хеш функцией?

Честно говоря не знаю, с какой попытки, т.к. занимаюсь алгоритмами уже больше десяти лет. И ошибок за это время в них успал сделать кучу Конечно, почти наверняка сначала была книжка Но не могу припомнить, чтобы хоть раз возникал bottleneck в производительности именно из-за хештаблицы (а ничего сложнее, чем полином по модулю, циклические сдвиги и xor-ы я не использовал).

A>Я говорю о другом. Есть множество программистов, которые пишут классы, которые потенциально могут использоваться в операторе switch.

A>Какой процент из них напишет сколько-нибудь разумную хеш-функцию?
В случае, если класс не определяет deep-семантики для равенства (т.е. равенство -- это равенство ссылок), то соответвующий GetHashCode из object обеспечивает замечательное распределение, т.к. вычисляется на основе sync block index, который чуть ли не уникален в пределах домена.

Если deep-семантика есть, то простой xor хешей компонент с циклическим сдвигом меня всегда выручал.

A>А вот в VC++ switch занимает от силы log(N) операций. И это гарантированно, а тут зависит от направления ветра во вторник.

Все-таки не нужно выдавать желаемое за действительно. VC++ свитч не может быть применен к произвольным классам. И в C# тоже не может, так что ничья.

Спору нет -- если хочешь гарантий производительности, то хеширование -- не твой метод. Но тогда придется вводить линейный порядок, а это тоже код, который нужно написать. И, кстати, что неприятно: ошибка в таком коде может обернуться кошмарной отладкой. Тот же std::set ничего не гарантирует, если предикат сравенения неправильный.

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

Так что бесплатный сыр...

Кстати, вот еще одно наблюдение на эту тему. В managed-средах вроде .NET и Java нет способа установить линейный порядок на объектах (в отличие от C++, где адрес служит уникальным идентификатором). Так что без хеширования ты вряд ли сможешь написать тот же Set<object>. Соответственно, нельзя будет организовать коллекцию объектов, если они первоначально не предназначались для этого (скажем, не реализуют IComparable<T>).
Re[15]: Хэш-таблица vs. дерево поиска
От: Mab Россия http://shade.msu.ru/~mab
Дата: 27.12.05 09:34
Оценка: 23 (1) +1
Здравствуйте, alexeiz, Вы писали:

A>Где-то до 100.

stdext::hash_set, видимо, далеко не самая удачная реализация хештаблицы. Если кому-нибудь интересно, вот тесты, накиданные на коленке за 5 минут:
Тестируем 100000 итераций, на каждой примерно 50 случайных вставок и 50 случайных поисков. Во всех случаях компилируем VC++/C# 2005 Release.

std::set                                 1593
stdext::hash_set                         2047

Wintellect.PowerCollections.Set          1328
Wintellect.PowerCollections.OrderedSet   1890

Так, хештаблица в .NET оказывается быстрее дерева в native C++, которое оказывается быстрее дерева в .NET. Кстати, один из вариантов ускорения деревьев в .NET более-менее ясен: использовать бинарный предикат сравнения вместо тернарного.

Исходники:
using System;
using Wintellect.PowerCollections;


delegate void Tester();

class MyRandom
{
    int seed;

    public int Next()
    {
        seed = (int) (seed * 214013L + 2531011L);
        return (seed >> 16) & 0x7fff;
    }
}

class Test
{
    static void InvokeTest(Tester tester, string comment)
    {
        int timer0 = Environment.TickCount;
        tester();
        int timer1 = Environment.TickCount;
        Console.WriteLine("{0,-40} {1}", comment, timer1 - timer0);
    }
        
    const int N_OPS = 100;
    const int N_ITERATIONS = 100000;
    
    static void Main()
    {
        InvokeTest(
            delegate
            {
                MyRandom random = new MyRandom();
                Set<int> s  = new Set<int>();
                for (int i = 0; i < N_ITERATIONS; i++)
                {
                    s.Clear();
                    for (int j = 0 ;j < N_OPS; j++)
                    {
                        if (random.Next() % 2 == 0)
                        {
                            s.Add(random.Next());
                        }
                        else
                        {
                            s.Contains(random.Next());
                        }
                    }
                }
            },
            "Wintellect.PowerCollections.Set");
            
        InvokeTest(
            delegate
            {
                MyRandom random = new MyRandom();
                OrderedSet<int> s  = new OrderedSet<int>();
                for (int i = 0; i < N_ITERATIONS; i++)
                {
                    s.Clear();
                    for (int j = 0 ;j < N_OPS; j++)
                    {
                        if (random.Next() % 2 == 0)
                        {
                            s.Add(random.Next());
                        }
                        else
                        {
                            s.Contains(random.Next());
                        }
                    }
                }
            },
            "Wintellect.PowerCollections.OrderedSet");
    }
}

#include <set>
#include <hash_set>
#include <stdlib.h>
#include <time.h>

class MyRandom
{
    int seed;
    
public:    
    MyRandom()
        : seed(0)
    {
    }
    
    int Next()
    {
        seed = (int) (seed * 214013L + 2531011L);
        return (seed >> 16) & 0x7fff;
    }
};

const int N_OPS = 100;
const int N_ITERATIONS = 100000;


template <class T>
void InvokeTest(const T& tester, char* comment)
{
    int t1 = clock();    
    tester.Run();
    int t2 = clock();    
    int time = t2 - t1;
    printf("%-40s %10d\n", comment, time);
}


template <class S>
class Tester
{
public:
    void Run() const
    {
        S s;
        MyRandom random;
        
        for (int i = 0; i < N_ITERATIONS; i++)
        {
            s.clear();
            for (int j = 0 ;j < N_OPS; j++)
            {
                if (random.Next() % 2 == 0)
                {
                    s.insert(random.Next());
                }
                else
                {
                    s.find(random.Next());
                }
            }
        }
    }
};

int main()
{
    InvokeTest(Tester<std::set<int> >(), "std::set");
    InvokeTest(Tester<stdext::hash_set<int> >(), "stdext::hash_set");
}
Re[11]: Хэш-таблица vs. дерево поиска
От: WolfHound  
Дата: 24.12.05 11:50
Оценка: +1 :)
Здравствуйте, adontz, Вы писали:

WH>>Почему такой стериотип что switch должен быть построен на дереве, а не на хеш таблице?

A>Ну предложи что-то своё. Только так, чтобы работало
А что хеш таблица уже не работает?
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[11]: Хэш-таблица vs. дерево поиска
От: Mab Россия http://shade.msu.ru/~mab
Дата: 24.12.05 13:29
Оценка: +2
Здравствуйте, adontz, Вы писали:
A>Да, но только при условии, что хеш-функция нормальная (как я уже говорил, для случайного аргумента значения бит независимы и равновероятны). А для произвольных объектов написанных неизвестно кем это далеко не так
Роман, а ты пробовал сам на практике хешфункции? Потому что я -- да, и опыт их использования положительный (по сравнению с деревьями поиска достигалось ускорение) Тот факт, что написав return 0; в GetHashCode можно убить производительность, ни у кого сомнений не вызывает. Только я бы поостерегся делать столь сильные выводы из этого.
Re[15]: Хэш-таблица vs. дерево поиска
От: adontz Грузия http://adontz.wordpress.com/
Дата: 24.12.05 17:09
Оценка: +2
Здравствуйте, Cyberax, Вы писали:

C>Сначала сравнивать типы объектов (можно тупо сравнивать имена классов),

C>при совпадении типов — использовать оператор < для нужного типа.

Сравнивать типы, если равны, то значения.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[16]: Хэш-таблица vs. дерево поиска
От: adontz Грузия http://adontz.wordpress.com/
Дата: 24.12.05 19:26
Оценка: -1 :)
Здравствуйте, WolfHound, Вы писали:

WH>1)Причем тут сериализация?


При том что есть задачи в которых поддерживать классы реализующие интерфейс IDictionary такая большая проблема, что легче их не поддерживать.

WH>2)Hashtable прекрасно сериализуется. Учи матчасть.


Я рыдаю.
Друг, ты хоть с документацией сверяйся, а потом говори, если так не помнишь

public class A
{
    [XmlElement("ht")]
    public Hashtable _ht = new Hashtable();
    
    public A()
    {
        _ht.Add(1, "a");
        _ht.Add(2, "b");
        _ht.Add(3, "c");
    }
}

class Program
{
    static void Main(string[] args)
    {
        /*
        В этой строке получаем исключение.
        Cannot serialize member A._ht of type System.Collections.Hashtable, because it implements IDictionary.
        При использовании Dictionary<int, string> ситуация аналогичная.
        */
        XmlSerializer xs = new XmlSerializer(typeof(A));


        /* Сюда уже не доходит, я просто для полноты картины написал этот код */
        A a = new A();
        
        using (TextWriter tw = File.CreateText("test.xml"))
        {
            xs.Serialize(tw, a);
            tw.Close();
        }
    }
}


WH>3)Может ты всетки определишь отношение порядка для StateSet? Или слабо?


Что значит слабо? Есть инструмент — оператор switch и есть множество классов которые в нём можно использовать. Классы реализующие интерфейс IDictionary в это множество не входят. Не надо доводить до маразма. И уж точно аргументация "слабо", "не слабо" не привносит в дискуссию элементы интеллекта.

WH>А если слабо то больше не делай заявлений типа

WH>

Вобщем "operator <" это проверенное временем решение, а GetHashCode() приблуда .Net


Вобщем все аргументы против "operator <" свелись к тому что
  1. Индусы пишут в "operator <" вызов Sleep(1000); и поэтому он медленный
  2. Роме слабо реализовать этот оператор для класса StateSet. Правда он в операторе switch представляется с трудом, но это не важно.
Очень интересно, но совершенно не убедительно.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[12]: Хэш-таблица vs. дерево поиска
От: adontz Грузия http://adontz.wordpress.com/
Дата: 25.12.05 12:13
Оценка: :))
Здравствуйте, vdimas, Вы писали:

V>Это зависит не только от числа элементов, но и от относительного качества Hash-функции применительно к текущему размеру Hash-таблицы,


Нет-нет. Ты не прав. В .Net ве хеш функции чудесны, кто бы их не писал, по определению. Это преимущество компонентной среды.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[20]: Хэш-таблица vs. дерево поиска
От: minorlogic Украина  
Дата: 05.01.06 09:29
Оценка: +1 :)
Здравствуйте, VladD2, Вы писали:

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


A>>Влад, я не против хеш-таблиц, я прекрастно понимаю, все их преимущества! Но хеш-таблицам нужны хеш-функции, а писать их будет кто-попало. И я думаю, что от этого проблем будет больше чем пользы.


VD>Любые функции может писать кто попало. При этом результат может быть печальным. И какие из этого можно сделать выводы?


Мне кажется имелось ввиду , что оператор сравнения можно написать правильно и неправильно , а хеш еще и можно написать плохо.
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[21]: Хэш-таблица vs. дерево поиска
От: vdimas Россия  
Дата: 05.01.06 20:21
Оценка: +2
Здравствуйте, VladD2, Вы писали:

V>>Кстати, несмортя на то, что вопрос не плохой, стоит сделать акцент на том, что удовлетворение всех вовсе не обязательно. Т.е. для кого-то эти массивы равны, если рассматриваются как множества, а для кого-то нет. Действительно, для некоторых задач предпочтительней map-ы, основанные на отношении порядка. Это никак не противоречит тому, что для других задач отношение порядка по боку.


VD>Ага. И если вернуться к вопросу реализации switch-а, то казалось бы зачем для этого упорядычивание?


А что, компилятор не в состоянии определить, какой подход лучше? Если у нас, например, целые или enum из непрерывного последовательного диапазона, то в этом случае как хеш, так и мап и на фиг не сдались.

И еще, для switch по длинным строковым константам map работает лучше хеш ф-ии. Т.е., я вообще за то, чтобы конкретную реализацию switch компилятор выбирал исходя из типов и значений констант.
Re[18]: Хэш-таблица vs. дерево поиска
От: vdimas Россия  
Дата: 05.01.06 20:37
Оценка: +2
Здравствуйте, VladD2, Вы писали:

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


V>>Если твой StateSet рассматривать как упорядоченное множество State-ов, то отношение порядка для него строится более чем легко при существовании отношения порядка для самих State-ов.


V>>Для введения отношения порядка самих States достаточно их пронумеровать, желательно в порядке ввода в грамматику (например, начиная с состояния Start и далее последовательно таким образом, чтобы новые состояния в грамматику вводились как результат перехода из уже существующего множества состояний... хотя и это не обязательно, просто такое отношение порядка удобно может использоваться и в др. случаях, например при построении визуального отображения графа грамматики)


VD>Здорово! И по ходу преобразования НКА в ДКА мы много раз будет удалять и добавлять состояния. При этом будут меняться характеристики множеств. Они то будут "больше" других, то "меньше". Для решаемой задачи — это не имеет никакого значения. Но мы, чисто от вредности, будет пересчитаывать все внутренние структуры.


Немного не так. При построении ДКА (если это вообще возможно для данного НКА) мы "склеиваем" несколько состояний НКА в одно состояние ДКА. Т.е., новое (промежуточное) представление ДКА — отображение "старых" состояний и переходов НКА на оные ДКА. По окончании алгоритма промежутоное представление обычно приводят к более простому представлению, т.к. нас не интересуют исходные состояния НКА, именно в этот момент новые состояния ДКА можно пронумеровать. (Хинт — это здорово помогает при сохранении и восстановлении графа НКА)

VD>А смысл? Хэш-таблица решает задачу без побочных эффектов и к тмоу же далате это быстрее чем другие методы.


Немного не понял про побочные эффекты. А про быстродействие на конкретной задаче высказался здесь http://www.rsdn.ru/Forum/Message.aspx?mid=1575314&amp;only=1
Автор: vdimas
Дата: 05.01.06


Я ведь вообще не собираюсь спорить ни с одной из сторон. Мне лишь кажется странным упорное отстаивание участниками своих точек зрения, в то время как очень многие неоднократно убеждались в неуниверсальности и негарантированной эффективности каждого из подходов. Простота реализации и эффективность работы каждого из вариантов зависят от характера (типа) данных и банально от самих данных.
Re[16]: Хэш-таблица vs. дерево поиска
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.01.06 14:45
Оценка: 18 (1)
Здравствуйте, Mab, Вы писали:

Кстати, тиками измерять время не здорово. Особнно не здорово из-за того, что они иногда врут. По крайней мере во втором дотнете лучше использовать Stopwatch.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: Хэш-таблица vs. дерево поиска
От: Mab Россия http://shade.msu.ru/~mab
Дата: 24.12.05 11:34
Оценка: +1
Здравствуйте, adontz, Вы писали:

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


Mab>>Очень странная идея. Зачем сортировать хеши?

A>>>Вобщем "operator <" это проверенное временем решение, а GetHashCode() приблуда .Net
Mab>>Это не верно. Есть принципально два способа огранизации коллекций, поддерживающих быстрый поиск.

A>Ты внимательно почитай о чём речь. Мы говорили не о коллекциях, а об операторе switch по любым объектам.

Ух ты Как далеко дискуссия зашла...

A>Чтобы это было реализовано не абы как, а качественно, из констант после case надо построить двочное дерево поиска. А для этого надо сами эти константы упорядочить.

Совершенно не обязательно. В switch стоит задача идентификации объекта, а не введения линейного порядка.

A>Иначе switch ничем не будет отличаться от последовательности if, а нам такой switch не нужен!

Почему же? Насколько понимаю, при большом количестве вариантов сейчас switch создает хештаблицу, после чего выбор нужного варианта делается запросом к ней. Этот подход эффективнее, чем бинарный поиск.
Re[13]: Хэш-таблица vs. дерево поиска
От: WolfHound  
Дата: 24.12.05 14:56
Оценка: +1
Здравствуйте, adontz, Вы писали:

A>Поэтому, ради экономии памяти, применяются разного рода компромиссные решения. В частности в MS реализации hash_map используется массив пар key-value размера 2^N, а сам хеш маскируется до младших N бит. Как результат хеш-функция не просто должна по возможности возвращать разные значения для разных аргументов, но и для случайных аргументов значения всех бит должны быть равновероятными и независимыми. Влад же (и судя по всему ты тоже) мне доказывает, что написание такой функции, это пара пустяков, а оператора < большая проблема.

Я не знаю что там в STL от MS он как извесно отстой. Но в .NET используются простые числа.
А написать хеш так чтобы он плохо работал на простых числах это не просто.
Ну разве что так
    public override int GetHashCode()
    {
        return 0;
    }

Других идей что-то в голову не приходит
A>Теперь вопрос — насколько хороша завязаная на хеш реализация? Правильный ответ — если хеш функция не удовлетворяет требованиям выше, то просто ужасна.
А если в оператор < какойнибудь индус вставит Sleep(1000)?
A>Скорее всего после равенства хешей будет несколько проверок на равенство объектов и про average O(1) можно забыть, а про worsest O(N) вспомнить. И спомнить насильно.
A>А теперь домашнее задание
Вот только не надо мне тут экзамины устраивать.
А вобще обычно както так
class Path
{
    public char Drive;
    public string Directory;
    public string Filename;
    public int Attributes;

    public override int GetHashCode()
    {
        int hash = 0;
        hash ^= Drive.GetHashCode();
        if (Directory != null)
            hash ^= Directory.GetHashCode();
        if (Filename != null)
            hash ^= Filename.GetHashCode();
        hash ^= Attributes.GetHashCode();
        return hash;
    }

    public override bool Equals(object obj)
    {
        Path path = obj as Path;
        if (path == null)
            return false;
        if (Drive != path.Drive)
            return false;
        if (Directory != path.Directory)
            return false;
        if (Filename != path.Filename)
            return false;
        if (Attributes != path.Attributes)
            return false;
        return true;
    }
}

Если не хватает производительности (что в моей практике было только один раз когда я писал бинарный diff для файлов болие 4Г) можно и поизвращаться.
И вобще вот тебе домашние задание напиши оператор < для класса StateSet
Автор: WolfHound
Дата: 05.08.05
.
A>Подумай и над тем сколько вообще программистов знают в теории как писать такие функции, не говоря уже о практике.
А сколько программистов могут написать корректный Less?
A>А вот оператор < это просто и понятно.
    public bool Less(Path path)
    {
        if (path == null)
            return false;
        if (Drive < path.Drive)
            return true;
        if (Drive > path.Drive)
            return false;
        if (Directory < path.Directory)
            return true;
        if (Directory > path.Directory)
            return false;
        if (Filename < path.Filename)
            return true;
        if (Filename > path.Filename)
            return false;
        if (Attributes < path.Attributes)
            return true;
        if (Attributes > path.Attributes)
            return false;
        return false;
    }

ЭТО просто и понятно?
A>Таким образом switch для произвольных объектов на основе хешей на практике не имеет никаких шансов быть сколько-нибудь оптимальным.
Каким таким образом? Я что-то не понял.
Ты вобще на практике использовал хеш-таблици?
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[13]: Хэш-таблица vs. дерево поиска
От: WolfHound  
Дата: 24.12.05 15:01
Оценка: +1
Здравствуйте, adontz, Вы писали:

Кстати чуть не забыл... а как при помощи оператора < хранить в коллекции объекты разных типов. Я конечно понимаю что это попахивает извращением но всеже?
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[14]: Хэш-таблица vs. дерево поиска
От: adontz Грузия http://adontz.wordpress.com/
Дата: 24.12.05 19:36
Оценка: +1
Здравствуйте, AndrewVK, Вы писали:

AVK>На практике все очень просто — дефолтная реализация GetHashCode() прекрасно для switch подходит.


Так ли уж?

public class A
{
    public int data = 3;
        
    public A()
    {
    }
}

A a1 = new A();
A a2 = new A();
            
int h1 = a1.GetHashCode();
int h2 = a2.GetHashCode();


Как нетрудно убедиться h1 != h2. А вот с моей точки зрения объекты равны, потому что у обоих поле data = 3, а других полей нет.
Так что дефолтная реализация вообще не подходит. Надо каждый раз писат свою. И как я уже показал, xor от хешей всех полей не лучшее решение.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[18]: Хэш-таблица vs. дерево поиска
От: adontz Грузия http://adontz.wordpress.com/
Дата: 24.12.05 19:53
Оценка: +1
Здравствуйте, Mab, Вы писали:

Mab>XmlSerializer не умеет работать с IDictionary. Только непонятно, при чем тут это...?

Mab>Возьми BinaryFormatter, он замечательно сериализует твой класс.

Это при том, что Wolfhound прицепился к моей фразе.
Тут как бы вообще другой вопрос и я уже жалею что привёл это непонятую аналогию.

Суть в том, что классы реализующие IDictionary в частности, и коллекции вообще это проблема от которой надо избавляться, а не решать. И дело тут не в подходе (хеш или оператор), а в осмысленности. Вот два массива {1,2,3} и {3,1,2} равны или нет? Причём ответь так, чтобы всех удовлетворило. Очевидно, что ответа нет. Причём его нет и для хешей. А Wolfhound этим почему-то доказывает, что оператор < это плохо
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[17]: Хэш-таблица vs. дерево поиска
От: WolfHound  
Дата: 24.12.05 20:46
Оценка: +1
Здравствуйте, adontz, Вы писали:

WH>>2)Hashtable прекрасно сериализуется. Учи матчасть.

A>Я рыдаю.
A>Друг, ты хоть с документацией сверяйся, а потом говори, если так не помнишь
Ну рыдай дальше. Только сначала изучи предмет.
hint: в поставку .NET входят 2 сериалайзера один из которых (XmlSerializer) действительно не умеет работать с IDictionary (правда не понятно почему особенно учитывая то что реализовать IXmlSerializable для словаря не составляет проблем).
Но это не отменяет второй вернее основной сериалайзер который использует платформа.

WH>>3)Может ты всетки определишь отношение порядка для StateSet? Или слабо?

A>Что значит слабо? Есть инструмент — оператор switch и есть множество классов которые в нём можно использовать. Классы реализующие интерфейс IDictionary в это множество не входят.
А чем они хуже? А! Знаю! Такие объекты практически не возможно запихнуть в ту систему что ты тут позиционируешь как единственно верную.
A>Не надо доводить до маразма. И уж точно аргументация "слабо", "не слабо" не привносит в дискуссию элементы интеллекта.
А как с тобой еще разговаривать если ты уперся и твердишь что деревья единственно верный способ на все случаи жизни?

A>Вобщем все аргументы против "operator <" свелись к тому что

A>Индусы пишут в "operator <" вызов Sleep(1000); и поэтому он медленный
Это был ответ на то что некие черти напишут плохую хеш функцию.
A>Роме слабо реализовать этот оператор для класса StateSet. Правда он в операторе switch представляется с трудом, но это не важно.
А это пример к тому что есть объекты для которых очень сложно задать отношение порядка.

A>Очень интересно, но совершенно не убедительно.

А твои аргументы вобще не выдерживают никакой критики.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[18]: Хэш-таблица vs. дерево поиска
От: adontz Грузия http://adontz.wordpress.com/
Дата: 24.12.05 23:28
Оценка: :)
Здравствуйте, WolfHound, Вы писали:

WH>А чем они хуже? А! Знаю! Такие объекты практически не возможно запихнуть в ту систему что ты тут позиционируешь как единственно верную.


Я не сказал, что она единственно верная, я даже не говорю что она самая оптимальная, я говорю что в ней нету подводных камней. Ты вообще не те параметры хвалишь.

WH>Это был ответ на то что некие черти напишут плохую хеш функцию.


Плохая не хначит медленная. Плохая значит, что биты значения не независимы (то есть их фактически в хеш-таблице будут незаполняемые дырки) либо не равновероятны (что опять таки приводит в незаполняемым дыркам). Характеристика плохой в контексте моего высказывания не имела никакого отношения к скорости работы хеш-функции.

A>>Роме слабо реализовать этот оператор для класса StateSet. Правда он в операторе switch представляется с трудом, но это не важно.

WH>А это пример к тому что есть объекты для которых очень сложно задать отношение порядка.

На самом деле для любой упорядоченной коллекции отношения порядка задаётся очень просто. Беда в том, что IDictionary это не упорядоченная коллекция.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[17]: Хэш-таблица vs. дерево поиска
От: VladD2 Российская Империя www.nemerle.org
Дата: 25.12.05 01:56
Оценка: +1
Здравствуйте, adontz, Вы писали:

A>Это понятно. Я просто говорю, что реализация по умолчанию это совсем не то что нужно для switch.


И ошибашся. Все зависит от того что ты хочешь получить. Если тебе достаточно сравения экземпляров, то реализация по уполчанию подойдет. Если же ты хочешь сравнивать объекты семантически, то ты просто обязан переопределить поведение GetHashCode() и Equal().

Это общее правило, и switch тут ничего ровным счетом не меняет. Ты точно так же сможешь сравнить объекты по "==" с помощью Equal() если тебе нужно семантическое сравнение, а ты не переопределил GetHashCode() и Equal().

ЗЫ

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

Думаю, что обсуждать что-то дальше не имеет смысла. Ты внушил себе какие-то странные догмы и никто кроме тебя самого не разрушит их. Так что или продолжай верить в догмы, или попытайся осмыслить все сказанное и разрушить их.

Заметь, создатели компиятора того же C# беспрепятсвенно используют хэш-таблицы при реализации строковых свитчей.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Хэш-таблица vs. дерево поиска
От: adontz Грузия http://adontz.wordpress.com/
Дата: 25.12.05 02:03
Оценка: :)
Здравствуйте, VladD2, Вы писали:

VD>Небыло у человека опыта использования хэш-таблиц, вот и получился стереотип.


Ага, щас. Был и ещё какой. Несколько дней переписывал хеш-функцию пока вышло что-то приличное. Это у тебя всё как-то гладко, а в жизни оно не так.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[10]: Хэш-таблица vs. дерево поиска
От: alexeiz  
Дата: 25.12.05 09:47
Оценка: -1
Здравствуйте, WolfHound, Вы писали:

WH>Почему такой стериотип что switch должен быть построен на дереве, а не на хеш таблице?


Дерево работает быстрее, чем hash таблица, для малого количества элементов. Я проверял на std::set и stdext::hash_set из библиотеки VC8. Для .NET можно тоже проверить, знать бы только, где есть хорошая реализация контейнера, построеного на деревьях.
Re[18]: Хэш-таблица vs. дерево поиска
От: vdimas Россия  
Дата: 25.12.05 11:04
Оценка: +1
Здравствуйте, Mab, Вы писали:

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


A>>Друг, ты хоть с документацией сверяйся, а потом говори, если так не помнишь

Mab>XmlSerializer не умеет работать с IDictionary. Только непонятно, при чем тут это...? Возьми BinaryFormatter, он замечательно сериализует твой класс.

Дело не в сериализации, а в получении упорядоченного множества элементов коллекции. (наверно adontz имел в виду это). В приведенной ссылке одному богу известно зачем Wolfhound использовал Hashtable. Оно там вовсе не нужно.
Re[13]: Хэш-таблица vs. дерево поиска
От: vdimas Россия  
Дата: 25.12.05 19:55
Оценка: +1
Здравствуйте, adontz, Вы писали:

V>>Это зависит не только от числа элементов, но и от относительного качества Hash-функции применительно к текущему размеру Hash-таблицы,


A>Нет-нет. Ты не прав. В .Net ве хеш функции чудесны, кто бы их не писал, по определению. Это преимущество компонентной среды.


Понимаешь, у твоих оппонентов есть один "мощщщный" аргумент. Каким бы плохим не был разброс Hash-значений относительно текущей величины таблицы, эта фишка все-равно работает, даже если время поиска элементов приближается к линейному

Т.е., фигня, что иногда - это самый неэффективный способ, "в среднем" работает нормально и ладно, особенно учитывая легкость написания самих hash-функций.

Тут надо отдать должное, что это "иногда" — крайний редкий случай. Поясню.

Текущая позиция элемента — это не само хеш-значение, а модуль по делению его на текущий размер таблицы. Предположим даже "очень плохую" хеш-функцию, возвращающую некие кратные значения, типа 0, 100, 200 и т.д., и "плохой" размер таблицы — 100 элементов. При заполнении на 70% произойдет rehash, и наша периодичность сама собой исчезнет. Однако, до этого момента поиск в такой таблице будет линейным. Однако, на практике, задержка таблицы в размере с периодичными наложениями встречается крайне редко, ибо rehash производится при первом же конфликте вставки, а вероятность его тем выше, чем больше неких значений, дающих кратный остаток от деления. Т.е. для описанного случая достаточно, чтобы наша "плохая" хеш-функция вернула буквально пару некратных значений, при основной массе кратных и мы резко ускорим наступление конфликта.

В итоге получается, что некая "плохая" хеш-функция будет провоцировать rehash при вставке до тех пор, пока эта функция не войдет ммм... в гармонию с неким очередным размером таблицы.

Исключение составляет вырожденный случай — генерация константного значения хеш-функцией. Очевидно, этот случай не может являться аргументом.
Re[24]: Хэш-таблица vs. дерево поиска
От: adontz Грузия http://adontz.wordpress.com/
Дата: 26.12.05 11:53
Оценка: :)
Здравствуйте, WolfHound, Вы писали:

WH>Ничего не понял. Что не реально? Хеш посчитать не реально?


Посчитать хеш неупорядоченной коллекцииза O(1) нереально, нужно O(N), причём значение хеш-функции не должно зависеть от порядка аргументов (в голову приходит только xor)
Сравнить две неупорядоченные коллекции за O(N) не реально, нужно O(N*log(N)). Причём сравнение реально пишеться и работает, а вот написать хорошую хеш-фунцию, значение которой не зависит от порядка элементов коллекции это интересная задачка. Xor это бомба замедленного действия. Возможно имеет смысл делить достаточно большое число последовательно на все элементы и что-то делать с результатом и остатками Тут вообще надо подумать.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[13]: Хэш-таблица vs. дерево поиска
От: Pzz Россия https://github.com/alexpevzner
Дата: 02.01.06 15:22
Оценка: +1
adontz wrote:
>
> Хеш ключа это индекс в хеш-таблице (обычный массив), значения которой
> это списки пар (ключ, значение). А что у нас возвращает замечательная
> функция GetHashCode()? А она у нас возвращает int, 32битное число.
> Размер массива который бы индексировался таким числом просто огромен,
> значительно превышает не только средний, но и максимальный объём памяти
> (который обычно 4Гб, но даже в 64 это всё не влезет).

Ну, вообще-то говоря, если все case'ы — константы, известные во время
компиляции, то компилятор может сам сгенерировать hash-функцию, которая
никогда не будет давать коллизий, и будет при этом использовать
небольшую таблицу. В таком случае hash-поиск будет очень эффективен.
Posted via RSDN NNTP Server 2.0
Re[14]: Хэш-таблица vs. дерево поиска
От: alexeiz  
Дата: 02.01.06 21:20
Оценка: :)
Здравствуйте, Mab, Вы писали:

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

A>>Для количества элементов в контейнере равное 1 дерево будет быстрее хэш-таблицы, это очевидно. Для достаточно большого количества элементов хэш-таблица с хорошей хэш-функцией будет быстрее дерева. Значит, есть такое количество элементов, вплоть до которого дерево будет быстрее чем хэш-таблица.

Mab>Ты ошибаешься вот в чем: в отличие от дерева, у хештаблицы есть дополнительный параметр -- коэффициент заполнения, который напрямую влияет на скорость. Если его сделать достаточно большим и считать, что хешфункция хорошая, то время доступа будет O(1). Так что такое лобовое сравнение с деревом не годится. Засчет дополнительного расхода по памяти хештаблица может успешно обогнать дерево на любых размерах. Вопрос только в том, устраивает ли тебя такой tradeoff.


Опять мне приводят ассимптотики. Ассимтотики неприменимы в этой области N.

Mab>Это, кстати, и показывают тесты, которые я привел ранее -- хештаблица .NET обгоняет std::map на 50 элементах.


Что показывают твои тесты, так это то, что для .NET нет эффективной реализации коллекции основанной на дереве. Сравнения же .NET и std::map не к месту, т.к. объектные модели в .NET и в C++ абсолютно разные.
Re[15]: Хэш-таблица vs. дерево поиска
От: Mab Россия http://shade.msu.ru/~mab
Дата: 02.01.06 21:28
Оценка: +1
Здравствуйте, alexeiz, Вы писали:

A>Опять мне приводят ассимптотики. Ассимтотики неприменимы в этой области N.

При чем тут асимптотики? Твое утверждение
A>Значит, есть такое количество элементов, вплоть до которого дерево будет быстрее чем хэш-таблица.
не верно, т.к. подбором коэффициента заполнения можно добиться того, чтобы хештаблица обноняла дерево на любом размере. Асимптотика тут побоку.

A> Сравнения же .NET и std::map не к месту, т.к. объектные модели в .NET и в C++ абсолютно разные.

При чем тут объектные модели?? Приведено два фрагмента кода, решающие одну и ту же задачу. Если посмотреть внимательно, то видно, что даже действия с коллекцией одни и те же производятся вплоть до наличия общего генератора случайных чисел.

Или, думаешь, если хештаблицу из .NET переписать на C++, то она станет медленнее работать что ли?
Re[15]: Хэш-таблица vs. дерево поиска
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.01.06 15:18
Оценка: :)
Здравствуйте, alexeiz, Вы писали:

A>Что показывают твои тесты, так это то, что для .NET нет эффективной реализации коллекции основанной на дереве. Сравнения же .NET и std::map не к месту, т.к. объектные модели в .NET и в C++ абсолютно разные.


Изумительный вывод! Если его развить, то для С++ вообще нет эффективной реализации коллекции! Я плякаль.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[20]: Хэш-таблица vs. дерево поиска
От: GlebZ Россия  
Дата: 04.01.06 21:42
Оценка: :)
Здравствуйте, Mab, Вы писали:

Mab>В смысле? Ключ здесь уникальный. Только ему соответствует не одно значение, а список. Конечно, придется дописать некоторый код. Если лень -- можно взять PowerCollections, там есть MultiDictionary, где это уже сделано за нас.

Mab>В общем, никаких теоретических трудностей с множественными значениями нет.
Ой-ли. Обычно для хеш таблицы с одинаковыми значениями N скорость вставки равняется О(N). Для деревьев логарифмическая сложность сохраняется.

С уважением, Gleb.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[22]: Хэш-таблица vs. дерево поиска
От: GlebZ Россия  
Дата: 04.01.06 21:49
Оценка: :)
Здравствуйте, Mab, Вы писали:

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


GZ>>Ой-ли. Обычно для хеш таблицы с одинаковыми значениями N скорость вставки равняется О(N).

Mab>Еще раз. Повторяю. Постарайся осмыслить: ключи в хештаблице будут уникальны. Но каждому будет соответствовать список значений (раз это многозначное отображение).
Понятно. Ты просто не понял. Я под значением подразумевал классическое определение значения в хеш-таблицах, по которому генерится ключ.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[21]: Хэш-таблица vs. дерево поиска
От: adontz Грузия http://adontz.wordpress.com/
Дата: 05.01.06 10:30
Оценка: :)
Здравствуйте, minorlogic, Вы писали:

M>Мне кажется имелось ввиду , что оператор сравнения можно написать правильно и неправильно , а хеш еще и можно написать плохо.


Вот! Хорошо сформулировал! У оператора < есть всего два состояния: правильно написан и неправильно написал. А у функции GetHashCode() весь спектр приключений
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[23]: Хэш-таблица vs. дерево поиска
От: Mab Россия http://shade.msu.ru/~mab
Дата: 05.01.06 10:37
Оценка: :)
Здравствуйте, minorlogic, Вы писали:

M>Давайте думать есть ли случаи когда оператор < реализовать тяжело , а == легко.

ОК. Реализуй компаратор для пары object-ов
Re[26]: Хэш-таблица vs. дерево поиска
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 05.01.06 11:18
Оценка: +1
Здравствуйте, VladD2, Вы писали:

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


GZ>>Sorry, опять неверно высказался. Что такое классическая хеш таблица. Это некоторый массив значений. По этим значениям с помощью некоторой хеш функции определяется позиция (иногда позиция для дальнейшего поиска в случае неуникальных значений). Просто в данном случае (да и в большинстве реализаций) хеш таблица является также контейнером других объектов. И в этом случае действительно появляется ключ(но он необязательный аттрибут любой хеш таблицы).


VD>Господи, какой <пип>!

А зачем такой пип. Ключ нужен для только быстрого сравнения. Если этого не нужно (например спец хэш таблицы где ключ и есть сам объект и дополнительного ключа не надо (байт, ворд, 3 байта, дворд), или в качестве экономии 4 байт на запись.
и солнце б утром не вставало, когда бы не было меня
Re[32]: Хэш-таблица vs. дерево поиска
От: adontz Грузия http://adontz.wordpress.com/
Дата: 06.01.06 09:40
Оценка: :)
Здравствуйте, Mab, Вы писали:

Mab>Что, правда? Ладно, вот пример: открываем MSDN и смотрим на класс ObjectIDGenerator (тот самый, который используется при сериализации). Как ты его реализуешь с помощью дерева поиска?


А зачем ObjectIDGenerator реализовывать с помошью деревьев? Предположим, что нельзя/сложно, какое это отношение имеет к оператору switch?
A journey of a thousand miles must begin with a single step © Lau Tsu
Хэш-таблица vs. дерево поиска
От: adontz Грузия http://adontz.wordpress.com/
Дата: 24.12.05 11:28
Оценка:
Здравствуйте, Mab, Вы писали:

Mab>Очень странная идея. Зачем сортировать хеши?

A>>Вобщем "operator <" это проверенное временем решение, а GetHashCode() приблуда .Net
Mab>Это не верно. Есть принципально два способа огранизации коллекций, поддерживающих быстрый поиск.

Ты внимательно почитай о чём речь. Мы говорили не о коллекциях, а об операторе switch по любым объектам. Чтобы это было реализовано не абы как, а качественно, из констант после case надо построить двочное дерево поиска. А для этого надо сами эти константы упорядочить. Иначе switch ничем не будет отличаться от последовательности if, а нам такой switch не нужен!

02.01.06 16:47: Ветка выделена из темы Чего не хватает в C#?
Автор: Кирилл Осенков
Дата: 07.12.05
— VladD2
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[9]: Хэш-таблица vs. дерево поиска
От: WolfHound  
Дата: 24.12.05 11:34
Оценка:
Здравствуйте, adontz, Вы писали:

A>Ты внимательно почитай о чём речь. Мы говорили не о коллекциях, а об операторе switch по любым объектам. Чтобы это было реализовано не абы как, а качественно, из констант после case надо построить двочное дерево поиска. А для этого надо сами эти константы упорядочить. Иначе switch ничем не будет отличаться от последовательности if, а нам такой switch не нужен!

Почему такой стериотип что switch должен быть построен на дереве, а не на хеш таблице?
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[10]: Хэш-таблица vs. дерево поиска
От: adontz Грузия http://adontz.wordpress.com/
Дата: 24.12.05 11:37
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Почему такой стериотип что switch должен быть построен на дереве, а не на хеш таблице?


Ну предложи что-то своё. Только так, чтобы работало
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[12]: Хэш-таблица vs. дерево поиска
От: adontz Грузия http://adontz.wordpress.com/
Дата: 24.12.05 13:18
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


WH>>>Почему такой стериотип что switch должен быть построен на дереве, а не на хеш таблице?

A>>Ну предложи что-то своё. Только так, чтобы работало
WH>А что хеш таблица уже не работает?

Хеш ключа это индекс в хеш-таблице (обычный массив), значения которой это списки пар (ключ, значение). А что у нас возвращает замечательная функция GetHashCode()? А она у нас возвращает int, 32битное число. Размер массива который бы индексировался таким числом просто огромен, значительно превышает не только средний, но и максимальный объём памяти (который обычно 4Гб, но даже в 64 это всё не влезет).
Поэтому, ради экономии памяти, применяются разного рода компромиссные решения. В частности в MS реализации hash_map используется массив пар key-value размера 2^N, а сам хеш маскируется до младших N бит. Как результат хеш-функция не просто должна по возможности возвращать разные значения для разных аргументов, но и для случайных аргументов значения всех бит должны быть равновероятными и независимыми. Влад же (и судя по всему ты тоже) мне доказывает, что написание такой функции, это пара пустяков, а оператора < большая проблема.
Теперь вопрос — насколько хороша завязаная на хеш реализация? Правильный ответ — если хеш функция не удовлетворяет требованиям выше, то просто ужасна. Скорее всего после равенства хешей будет несколько проверок на равенство объектов и про average O(1) можно забыть, а про worsest O(N) вспомнить. И спомнить насильно.
А теперь домашнее задание
class Path
{
    public char Drive;
    public string Directory;
    public string Filename;
    public int Attributes;

    public override int GetHashCode()
    {
        return
        /* Что тут надо написать, чтобы значения всех битов были равновероятны и независимы?
           Причём не в теории, где Drive от 0 до 255, а на практике. */;
    }
}
Подумай и над тем сколько вообще программистов знают в теории как писать такие функции, не говоря уже о практике. А вот оператор < это просто и понятно. Таким образом switch для произвольных объектов на основе хешей на практике не имеет никаких шансов быть сколько-нибудь оптимальным.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[10]: Хэш-таблица vs. дерево поиска
От: adontz Грузия http://adontz.wordpress.com/
Дата: 24.12.05 13:23
Оценка:
Здравствуйте, Mab, Вы писали:

Mab>Почему же? Насколько понимаю, при большом количестве вариантов сейчас switch создает хештаблицу, после чего выбор нужного варианта делается запросом к ней. Этот подход эффективнее, чем бинарный поиск.


Да, но только при условии, что хеш-функция нормальная (как я уже говорил, для случайного аргумента значения бит независимы и равновероятны). А для произвольных объектов написанных неизвестно кем это далеко не так
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[12]: Хэш-таблица vs. дерево поиска
От: adontz Грузия http://adontz.wordpress.com/
Дата: 24.12.05 13:40
Оценка:
Здравствуйте, Mab, Вы писали:

Mab>Роман, а ты пробовал сам на практике хешфункции? Потому что я -- да, и опыт их использования положительный (по сравнению с деревьями поиска достигалось ускорение)


С первой попытки? Иил всё таки игрался с хеш функцией? А может написал с первого раза, но до того прочёл кучу умных книжек?

Mab>Тот факт, что написав return 0; в GetHashCode можно убить производительность, ни у кого сомнений не вызывает. Только я бы поостерегся делать столь сильные выводы из этого.


Я говорю о другом. Есть множество программистов, которые пишут классы, которые потенциально могут использоваться в операторе switch.
Какой процент из них напишет сколько-нибудь разумную хеш-функцию? ИМХО если 10% то это будет уже просто замечательно. Речь ведь не о тебе или мне, а о решении, которое выйдет боком. Я напишу switch, а он будет жутко медленный из-за какого-то #$@%.
А вот в VC++ switch занимает от силы log(N) операций. И это гарантированно, а тут зависит от направления ветра во вторник.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[14]: Хэш-таблица vs. дерево поиска
От: Cyberax Марс  
Дата: 24.12.05 15:08
Оценка:
WolfHound wrote:
> Кстати чуть не забыл... а как при помощи оператора < хранить в коллекции
> объекты разных типов. Я конечно понимаю что это попахивает извращением
> но всеже?
Сначала сравнивать типы объектов (можно тупо сравнивать имена классов),
при совпадении типов — использовать оператор < для нужного типа.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[14]: Хэш-таблица vs. дерево поиска
От: adontz Грузия http://adontz.wordpress.com/
Дата: 24.12.05 17:08
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Я не знаю что там в STL от MS он как извесно отстой.


Давай без огульных оскорблений. Тот STL что идёт с VS к MS не имеет прямого отношения. Кроме того, раз уж в этом hash_map отстой, ты уж покажи другой, тот который не отстой Надо же с чем-либо сравнивать.

WH>Но в .NET используются простые числа.


Откуда они берутся? Как назначаются? Кроме того проблема-то, если ты не заметил, в вычислении хеша от пользовательских классов, а не библиотечных.

WH>Других идей что-то в голову не приходит


Запросто
class A
{
 private string _s1;
 private string _s2;

 public override int GetHashCode()
 {
  return _s1.GetHashCode() ^ _s2.GetHashCode();
 }
}

А по логике работы _s1 и _s2 часто равны. Этого конечно не будет каждый раз, но когда случится, причины тормозов найти будет очень трудно.

A>>Теперь вопрос — насколько хороша завязаная на хеш реализация? Правильный ответ — если хеш функция не удовлетворяет требованиям выше, то просто ужасна.

WH>А если в оператор < какойнибудь индус вставит Sleep(1000)?

А почему бы не вставить Sleep(1000) в вычисление GetHashCode()? Какие-то ну очень неубедительные аргументы. Я бы вставил 17 смайликов со своей стороны, но я не такой.

WH>И вобще вот тебе домашние задание напиши оператор < для класса StateSet
Автор: WolfHound
Дата: 05.08.05
.


Hashtable помешает и правильно. Классы реализующие IDictionary нельзя и сериализовать. В том, что StateSet нельзя будет использовать в операторе switch для меня нет ничего удивительного.

WH>
WH>    public bool Less(Path path)
WH>    {
WH>        if (path == null)
WH>            return false;
WH>        if (Drive < path.Drive)
WH>            return true;
WH>        if (Drive > path.Drive)
WH>            return false;
WH>        if (Directory < path.Directory)
WH>            return true;
WH>        if (Directory > path.Directory)
WH>            return false;
WH>        if (Filename < path.Filename)
WH>            return true;
WH>        if (Filename > path.Filename)
WH>            return false;
WH>        if (Attributes < path.Attributes)
WH>            return true;
WH>        if (Attributes > path.Attributes)
WH>            return false;
WH>        return false;
WH>    }
WH>

WH>ЭТО просто и понятно?

Мне вполне понятно. По крайней мере я точно знаю что делать если какое-либо поле добавится или убавится. Это легко поддерживаемый код. Есть опасность, что после вставки нового поля оно не будет учтено, но такая же опасность есть и с GetHashCode().

A>>Таким образом switch для произвольных объектов на основе хешей на практике не имеет никаких шансов быть сколько-нибудь оптимальным.

WH>Каким таким образом? Я что-то не понял.

В теории всё замечательно, но на практике написание хороших хеш-функций это проблема.

WH>Ты вобще на практике использовал хеш-таблици?


Ну вообще улётный аргумент. И в каждую вставлял Sleep(1000)
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[15]: Хэш-таблица vs. дерево поиска
От: WolfHound  
Дата: 24.12.05 17:30
Оценка:
Здравствуйте, adontz, Вы писали:

WH>>И вобще вот тебе домашние задание напиши оператор < для класса StateSet
Автор: WolfHound
Дата: 05.08.05
.

A>Hashtable помешает и правильно. Классы реализующие IDictionary нельзя и сериализовать. В том, что StateSet нельзя будет использовать в операторе switch для меня нет ничего удивительного.
1)Причем тут сериализация?
2)Hashtable прекрасно сериализуется. Учи матчасть.
3)Может ты всетки определишь отношение порядка для StateSet? Или слабо?
А если слабо то больше не делай заявлений типа

Вобщем "operator <" это проверенное временем решение, а GetHashCode() приблуда .Net

... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[13]: Хэш-таблица vs. дерево поиска
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 24.12.05 18:00
Оценка:
Здравствуйте, adontz, Вы писали:

A>
A>class Path
A>{
A>    public char Drive;
A>    public string Directory;
A>    public string Filename;
A>    public int Attributes;

A>    public override int GetHashCode()
A>    {
A>        return
A>        /* Что тут надо написать, чтобы значения всех битов были равновероятны и независимы?
A>           Причём не в теории, где Drive от 0 до 255, а на практике. */;
A>    }
A>}
A>
Подумай и над тем сколько вообще программистов знают в теории как писать такие функции, не говоря уже о практике.


На практике все очень просто — дефолтная реализация GetHashCode() прекрасно для switch подходит.
... << RSDN@Home 1.2.0 alpha rev. 624 on Windows XP 5.1.2600.131072>>
AVK Blog
Re[17]: Хэш-таблица vs. дерево поиска
От: Mab Россия http://shade.msu.ru/~mab
Дата: 24.12.05 19:38
Оценка:
Здравствуйте, adontz, Вы писали:

A>Друг, ты хоть с документацией сверяйся, а потом говори, если так не помнишь

XmlSerializer не умеет работать с IDictionary. Только непонятно, при чем тут это...? Возьми BinaryFormatter, он замечательно сериализует твой класс.
Re[15]: Хэш-таблица vs. дерево поиска
От: Mab Россия http://shade.msu.ru/~mab
Дата: 24.12.05 19:41
Оценка:
Здравствуйте, adontz, Вы писали:

A>Как нетрудно убедиться h1 != h2. А вот с моей точки зрения объекты равны, потому что у обоих поле data = 3, а других полей нет.

Не удивительно: A -- это класс, так что семантика сравнения у него ссылочная. Хочешь генерации хеша на освнове содержимого -- сделай его структурой.
Re[16]: Хэш-таблица vs. дерево поиска
От: adontz Грузия http://adontz.wordpress.com/
Дата: 24.12.05 19:46
Оценка:
Здравствуйте, Mab, Вы писали:

A>>Как нетрудно убедиться h1 != h2. А вот с моей точки зрения объекты равны, потому что у обоих поле data = 3, а других полей нет.

Mab>Не удивительно: A -- это класс, так что семантика сравнения у него ссылочная. Хочешь генерации хеша на освнове содержимого -- сделай его структурой.

Это понятно. Я просто говорю, что реализация по умолчанию это совсем не то что нужно для switch.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[15]: Хэш-таблица vs. дерево поиска
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 24.12.05 20:00
Оценка:
Здравствуйте, adontz, Вы писали:

A>Так ли уж?


A>
A>public class A
A>{
A>    public int data = 3;
        
A>    public A()
A>    {
A>    }
A>}

A>A a1 = new A();
A>A a2 = new A();
            
A>int h1 = a1.GetHashCode();
A>int h2 = a2.GetHashCode();
A>


A>Как нетрудно убедиться h1 != h2.


Напоминаю, что исходно речь шла о типах.
... << RSDN@Home 1.2.0 alpha rev. 624 on Windows XP 5.1.2600.131072>>
AVK Blog
Re[16]: Хэш-таблица vs. дерево поиска
От: adontz Грузия http://adontz.wordpress.com/
Дата: 24.12.05 20:14
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Напоминаю, что исходно речь шла о типах.


Нет-нет, о любых объектах.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[19]: Хэш-таблица vs. дерево поиска
От: WolfHound  
Дата: 24.12.05 20:59
Оценка:
Здравствуйте, adontz, Вы писали:

A>Суть в том, что классы реализующие IDictionary в частности, и коллекции вообще это проблема от которой надо избавляться, а не решать. И дело тут не в подходе (хеш или оператор), а в осмысленности. Вот два массива {1,2,3} и {3,1,2} равны или нет? Причём ответь так, чтобы всех удовлетворило. Очевидно, что ответа нет. Причём его нет и для хешей. А Wolfhound этим почему-то доказывает, что оператор < это плохо

Ну почемуже сразу избавляться?
Все зависит от задачи. В моем случае равны. Соответственно я написал хеш и сравнение которым порядок до лампочки. Если бы порядок элементов в массиве имел значение то вычисление хеша и сравнение я бы реализовал иначе.
Сходи по моей ссылке и попробуй решить эту задачу без сравнения множеств...
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[20]: Хэш-таблица vs. дерево поиска
От: adontz Грузия http://adontz.wordpress.com/
Дата: 24.12.05 23:20
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Сходи по моей ссылке и попробуй решить эту задачу без сравнения множеств...


Никак. А что ты сможешь посчитать осмысленный хеш не перебрав все элементы множества?
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[9]: Хэш-таблица vs. дерево поиска
От: VladD2 Российская Империя www.nemerle.org
Дата: 25.12.05 01:32
Оценка:
Здравствуйте, adontz, Вы писали:

A>Ты внимательно почитай о чём речь. Мы говорили не о коллекциях, а об операторе switch по любым объектам. Чтобы это было реализовано не абы как, а качественно, из констант после case надо построить двочное дерево поиска. А для этого надо сами эти константы упорядочить. Иначе switch ничем не будет отличаться от последовательности if, а нам такой switch не нужен!


Ты вроде бы раньше разбирался в том, что такое хэш-таблица и как она работает. Странно слышать от тебя такие слова.

Общая идея тут такова. Код вроде этого:
void TestMethod(object obj)
{
    switch (obj)
    {
        case new Class1(someState1): SomeBehavior1() break;
        case new Class1(someState2): SomeBehavior2() break;
        case new Class1(someState3): SomeBehavior3() break;
        case new Class2(someState1): SomeBehavior4() break;
        default:                     SomeBehavior5() break;
    }
}

Переписывается компилятором следующим образом:
static Dictionary<object, int> _unic_comiler_name1;

void TestMethod(object obj)
{
    if (_unic_comiler_name1 == null)
    {
        // Инициализация хэш-таблицы используемой для реализации switch-а
        _unic_comiler_name1 = Dictionary<object, int>()
        
        _unic_comiler_name1.Add(new Class1(someState1), 1);
        _unic_comiler_name1.Add(new Class1(someState2), 2);
        _unic_comiler_name1.Add(new Class1(someState3), 3);
        _unic_comiler_name1.Add(new Class2(someState1), 4);
    }
    
    // Для подобных свитчей (с последовательными индексами)
    // компилятор генерирует оптимальный код (O(1)).
    
    int index;
    // Если ключа не будет в хэш-таблице, то будет возвращено значение "0".
    _unic_comiler_name1.TryGetValue(obj, out index)
    
    switch (index)
    {
        case 1:  SomeBehavior1() break;
        case 2:  SomeBehavior2() break;
        case 3:  SomeBehavior3() break;
        case 4:  SomeBehavior4() break;
        default: SomeBehavior5() break;
    }
}


Хэш-таблица (Dictionary<object, int>) обеспечивает поиск порядка O(1), т.е. за константное время. Ну, а дальше уже дело техники. Единственно, нужно реализовать в объектах корректное сравнение и корректный рассчет хэш-кода.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Хэш-таблица vs. дерево поиска
От: VladD2 Российская Империя www.nemerle.org
Дата: 25.12.05 01:32
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Почему такой стериотип что switch должен быть построен на дереве, а не на хеш таблице?


Дык стереотипы вырабатываются средой. Небыло у человека опыта использования хэш-таблиц, вот и получился стереотип.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Хэш-таблица vs. дерево поиска
От: VladD2 Российская Империя www.nemerle.org
Дата: 25.12.05 01:32
Оценка:
Здравствуйте, adontz, Вы писали:

Ваша дискуссия сильно затянулась. Скожу только, что ты действительно как-то странно относишся к хэш-таблицам. Но это общая проблема многих С++-ников. В STL ведь действительно серьезные проблемы с этим делом. Ну, да ладно.

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

Собственно реализация switch-а по строкам в C# уже использует хэширование и хэш-таблицы. Можешь декомпилировать вот такой код:
using System;

class Program
{
    static void Main()
    {
        Test("A");
        Test("X");
    }

    static void Test(string str)
    {
        switch (str)
        {
            case "A": Console.WriteLine("str содержит 'A'"); break;
            case "B": Console.WriteLine("str содержит 'B'"); break;
            case "C": Console.WriteLine("str содержит 'C'"); break;
            case "D": Console.WriteLine("str содержит 'D'"); break;
            case "E": Console.WriteLine("str содержит 'E'"); break;
            case "F": Console.WriteLine("str содержит 'F'"); break;
            default: Console.WriteLine("str содержит что-то иное"); break;
                
        }
    }
}

и убедиться, что компилятор C# сгеренировал код на основе хэш таблицы. Вот, например, что он сгенерировал в моем случае:
private static void Test(string str)
{
      string text1 = str;
      if (text1 != null)
      {
            int num1;
            if (<PrivateImplementationDetails>{DC3A279F-4631-445B-A3D2-D9E0196B55E0}.$$method0x6000002-1 == null)
            {
                  Dictionary<string, int> dictionary1 = new Dictionary<string, int>(6);
                  dictionary1.Add("A", 0);
                  dictionary1.Add("B", 1);
                  dictionary1.Add("C", 2);
                  dictionary1.Add("D", 3);
                  dictionary1.Add("E", 4);
                  dictionary1.Add("F", 5);
                  <PrivateImplementationDetails>{DC3A279F-4631-445B-A3D2-D9E0196B55E0}.$$method0x6000002-1 = dictionary1;
            }
            if (<PrivateImplementationDetails>{DC3A279F-4631-445B-A3D2-D9E0196B55E0}.$$method0x6000002-1.TryGetValue((string) text1, ref (int) ref num1))
            {
                  switch (num1)
                  {
                        case 0:
                        {
                              Console.WriteLine("str \u0441\u043e\u0434\u0435\u0440\u0436\u0438\u0442 'A'");
                              return;
                        }
                        case 1:
                        {
                              Console.WriteLine("str \u0441\u043e\u0434\u0435\u0440\u0436\u0438\u0442 'B'");
                              return;
                        }
                        case 2:
                        {
                              Console.WriteLine("str \u0441\u043e\u0434\u0435\u0440\u0436\u0438\u0442 'C'");
                              return;
                        }
                        case 3:
                        {
                              Console.WriteLine("str \u0441\u043e\u0434\u0435\u0440\u0436\u0438\u0442 'D'");
                              return;
                        }
                        case 4:
                        {
                              Console.WriteLine("str \u0441\u043e\u0434\u0435\u0440\u0436\u0438\u0442 'E'");
                              return;
                        }
                        case 5:
                        {
                              Console.WriteLine("str \u0441\u043e\u0434\u0435\u0440\u0436\u0438\u0442 'F'");
                              return;
                        }
                  }
            }
      }
      Console.WriteLine("str \u0441\u043e\u0434\u0435\u0440\u0436\u0438\u0442 \u0447\u0442\u043e-\u0442\u043e \u0438\u043d\u043e\u0435");
}
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[16]: Хэш-таблица vs. дерево поиска
От: VladD2 Российская Империя www.nemerle.org
Дата: 25.12.05 01:56
Оценка:
Здравствуйте, Mab, Вы писали:

A>>Как нетрудно убедиться h1 != h2. А вот с моей точки зрения объекты равны, потому что у обоих поле data = 3, а других полей нет.

Mab>Не удивительно: A -- это класс, так что семантика сравнения у него ссылочная. Хочешь генерации хеша на освнове содержимого -- сделай его структурой.

Или переопредели поведение методов GetHashCode() и Equal().
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[18]: Хэш-таблица vs. дерево поиска
От: adontz Грузия http://adontz.wordpress.com/
Дата: 25.12.05 02:02
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Заметь, создатели компиятора того же C# беспрепятсвенно используют хэш-таблицы при реализации строковых свитчей.


Влад, я не против хеш-таблиц, я прекрастно понимаю, все их преимущества! Но хеш-таблицам нужны хеш-функции, а писать их будет кто-попало. И я думаю, что от этого проблем будет больше чем пользы.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[14]: Хэш-таблица vs. дерево поиска
От: adontz Грузия http://adontz.wordpress.com/
Дата: 25.12.05 02:06
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Ваша дискуссия сильно затянулась. Скожу только, что ты действительно как-то странно относишся к хэш-таблицам. Но это общая проблема многих С++-ников. В STL ведь действительно серьезные проблемы с этим делом. Ну, да ладно.


Си++ тут ни при чём и к хеш-таблицам я отношусь замечательно.

VD>Так вот хэш-таблице доказали свое приемущество на практике, а не только в теории. Конечно выражденные случаи случаются, но это большая редкость. Да и не составляет проблем отловить эти случаи с помощью банального профайлера.


В том-то всё и дело, что проблема. Даже если ты спустишься на уровень IL, то тормозить у тебя будет Dictionary<string, int>.TryGetValue, причём совершенно не ясно почему.

VD>Собственно реализация switch-а по строкам в C# уже использует хэширование и хэш-таблицы. Можешь декомпилировать вот такой код:


Влад, GetHashCode для строк и GetHashCode для произвольного класса написанного Васей Пупкиным ну очень различаются по качеству.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[19]: Хэш-таблица vs. дерево поиска
От: VladD2 Российская Империя www.nemerle.org
Дата: 25.12.05 05:39
Оценка:
Здравствуйте, adontz, Вы писали:

A>Влад, я не против хеш-таблиц, я прекрастно понимаю, все их преимущества! Но хеш-таблицам нужны хеш-функции, а писать их будет кто-попало. И я думаю, что от этого проблем будет больше чем пользы.


Любые функции может писать кто попало. При этом результат может быть печальным. И какие из этого можно сделать выводы?

Прекрати упираться на ровном месте. Тебе же все уже обяснили. Семантика эквивалентности более широко применеима нежели сравнения на больше меньше. Есть типы которые просто нельзя сравнивать на болше меньше. Например, сравни на болше меньше два типа, или две персоны. В общем, случае это не имеет смысла.

Скорость работы хэш-таблиц обычно выше чем бинарного поиска.

Так зачем делать неполноценное, более медленное решение? Только из-за того, что кто-то не верит в хэширование? Может проще этому кому-то разобраться с эданным процессом?
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: Хэш-таблица vs. дерево поиска
От: VladD2 Российская Империя www.nemerle.org
Дата: 25.12.05 05:39
Оценка:
Здравствуйте, adontz, Вы писали:

A>Си++ тут ни при чём и к хеш-таблицам я отношусь замечательно.


Все же причем. Я уже не одного С++-ника встречал который борится с хэш-таблицами. Хотя конечно это только мой опыт.

VD>>Так вот хэш-таблице доказали свое приемущество на практике, а не только в теории. Конечно выражденные случаи случаются, но это большая редкость. Да и не составляет проблем отловить эти случаи с помощью банального профайлера.


A>В том-то всё и дело, что проблема.


Да? Приведи, плиз, примеры этого. Тольк из практики, а не из пальца.

A> Даже если ты спустишься на уровень IL, то тормозить у тебя будет Dictionary<string, int>.TryGetValue, причём совершенно не ясно почему.


Да не будет он тормозить. По крайней мере в 99% случаев. И проблема — это не реализации свитча, а качества подбора хэш-функции.

VD>>Собственно реализация switch-а по строкам в C# уже использует хэширование и хэш-таблицы. Можешь декомпилировать вот такой код:


A>Влад, GetHashCode для строк и GetHashCode для произвольного класса написанного Васей Пупкиным ну очень различаются по качеству.


И в какую сторону? Короче, не высасывай пробшем из пальца. А то это выглядит так же смешно, как рассказы о естественности select-а в конце SQL-запроса.

Тот кто будет использовать объекты в switch-е должен понимать, что делает. И если он что-то сделает не так, то в превую очередь он получит неверное поведение. Ну, а далее пусть разбирается.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: Хэш-таблица vs. дерево поиска
От: VladD2 Российская Империя www.nemerle.org
Дата: 25.12.05 05:39
Оценка:
Здравствуйте, adontz, Вы писали:

A>Ага, щас. Был и ещё какой. Несколько дней переписывал хеш-функцию пока вышло что-то приличное. Это у тебя всё как-то гладко, а в жизни оно не так.


Несколько дней на хэш-функцию? Ну, ты крут, однако!

Открою тебе сикрет. В дотнете практически вообще не приходится писать хэш-функции. Ну, разве что для составных объектов которые просто складывают хэшы подобъектов по "^". Я вот за все время написал штуки 3 хэш-функции из них только одну по реальным данным. Остальные "^".
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[19]: Хэш-таблица vs. дерево поиска
От: WolfHound  
Дата: 25.12.05 09:08
Оценка:
Здравствуйте, adontz, Вы писали:

WH>>А чем они хуже? А! Знаю! Такие объекты практически не возможно запихнуть в ту систему что ты тут позиционируешь как единственно верную.

A>Я не сказал, что она единственно верная, я даже не говорю что она самая оптимальная, я говорю что в ней нету подводных камней. Ты вообще не те параметры хвалишь.
Подводный камни есть всегда. И как мы толькочно убедились они есть и в схеме с деревом ибо иногда ниписать less практически не возможно.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[21]: Хэш-таблица vs. дерево поиска
От: WolfHound  
Дата: 25.12.05 09:08
Оценка:
Здравствуйте, adontz, Вы писали:

WH>>Сходи по моей ссылке и попробуй решить эту задачу без сравнения множеств...

A>Никак.
А какже тогда быть с

Суть в том, что классы реализующие IDictionary в частности, и коллекции вообще это проблема от которой надо избавляться, а не решать.

A>А что ты сможешь посчитать осмысленный хеш не перебрав все элементы множества?
А это тут причем?
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[16]: Хэш-таблица vs. дерево поиска
От: vdimas Россия  
Дата: 25.12.05 11:01
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>3)Может ты всетки определишь отношение порядка для StateSet? Или слабо?


Если твой StateSet рассматривать как упорядоченное множество State-ов, то отношение порядка для него строится более чем легко при существовании отношения порядка для самих State-ов.

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

WH>А если слабо то больше не делай заявлений типа

WH>

Вобщем "operator <" это проверенное временем решение, а GetHashCode() приблуда .Net


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

Кстати, экспериментировал с поиском для строк в разных коллекциях. В общем, самый быстрый — это ветвление по дереву по каждой следующей букве строки. Т.е. самым оптимальным оказался смешанный способ. В каждом узле дерева — хеш-таблица ветвлений по текущему символу.
Re[19]: Хэш-таблица vs. дерево поиска
От: vdimas Россия  
Дата: 25.12.05 11:07
Оценка:
Здравствуйте, adontz, Вы писали:


A>Суть в том, что классы реализующие IDictionary в частности, и коллекции вообще это проблема от которой надо избавляться, а не решать. И дело тут не в подходе (хеш или оператор), а в осмысленности. Вот два массива {1,2,3} и {3,1,2} равны или нет? Причём ответь так, чтобы всех удовлетворило. Очевидно, что ответа нет. Причём его нет и для хешей. А Wolfhound этим почему-то доказывает, что оператор < это плохо


Кстати, несмортя на то, что вопрос не плохой, стоит сделать акцент на том, что удовлетворение всех вовсе не обязательно. Т.е. для кого-то эти массивы равны, если рассматриваются как множества, а для кого-то нет. Действительно, для некоторых задач предпочтительней map-ы, основанные на отношении порядка. Это никак не противоречит тому, что для других задач отношение порядка по боку.
Re[20]: Хэш-таблица vs. дерево поиска
От: vdimas Россия  
Дата: 25.12.05 11:08
Оценка:
Здравствуйте, WolfHound, Вы писали:


A>>Суть в том, что классы реализующие IDictionary в частности, и коллекции вообще это проблема от которой надо избавляться, а не решать. И дело тут не в подходе (хеш или оператор), а в осмысленности. Вот два массива {1,2,3} и {3,1,2} равны или нет? Причём ответь так, чтобы всех удовлетворило. Очевидно, что ответа нет. Причём его нет и для хешей. А Wolfhound этим почему-то доказывает, что оператор < это плохо

WH>Ну почемуже сразу избавляться?
WH>Все зависит от задачи. В моем случае равны. Соответственно я написал хеш и сравнение которым порядок до лампочки. Если бы порядок элементов в массиве имел значение то вычисление хеша и сравнение я бы реализовал иначе.
WH>Сходи по моей ссылке и попробуй решить эту задачу без сравнения множеств...

Hint: там у тебя необязательно было использовать Hashtable в StateSet.
Re[11]: Хэш-таблица vs. дерево поиска
От: vdimas Россия  
Дата: 25.12.05 11:15
Оценка:
Здравствуйте, alexeiz, Вы писали:

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


WH>>Почему такой стериотип что switch должен быть построен на дереве, а не на хеш таблице?


A>Дерево работает быстрее, чем hash таблица, для малого количества элементов. Я проверял на std::set и stdext::hash_set из библиотеки VC8. Для .NET можно тоже проверить, знать бы только, где есть хорошая реализация контейнера, построеного на деревьях.


Это зависит не только от числа элементов, но и от относительного качества Hash-функции применительно к текущему размеру Hash-таблицы,
Re[20]: Хэш-таблица vs. дерево поиска
От: adontz Грузия http://adontz.wordpress.com/
Дата: 25.12.05 12:07
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>И как мы толькочно убедились они есть и в схеме с деревом ибо иногда ниписать less практически не возможно.


Никто ни в чём не убедился. Сравнением множеств, а не упорядоченных списков это вполне понятно более сложная вычислительная задача. но не неразрешимая. Прямо сейчас могу написать за O(n*log(n))
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[22]: Хэш-таблица vs. дерево поиска
От: adontz Грузия http://adontz.wordpress.com/
Дата: 25.12.05 12:09
Оценка:
Здравствуйте, WolfHound, Вы писали:

A>>А что ты сможешь посчитать осмысленный хеш не перебрав все элементы множества?

WH>А это тут причем?

А суть в том, что проблемы вообще нету, есть проблема написати быстро. Для неупорядоченных коллекций представляющих собой множества это нереально.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[19]: Хэш-таблица vs. дерево поиска
От: Mab Россия http://shade.msu.ru/~mab
Дата: 25.12.05 18:01
Оценка:
Здравствуйте, adontz, Вы писали:

A>Вот два массива {1,2,3} и {3,1,2} равны или нет? Причём ответь так, чтобы всех удовлетворило.

Честно говоря, не вижу проблемы. Есть два различных понятия: set и sequence (ordered set). Какое из понятий применимо в данной задаче -- виднее тому, кто эту задачу решает. Для того и создан интерфейс IEqualityComparer<T>.
Re[14]: Хэш-таблица vs. дерево поиска
От: Mab Россия http://shade.msu.ru/~mab
Дата: 25.12.05 20:04
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Текущая позиция элемента — это не само хеш-значение, а модуль по делению его на текущий размер таблицы. Предположим даже "очень плохую" хеш-функцию, возвращающую некие кратные значения, типа 0, 100, 200 и т.д., и "плохой" размер таблицы — 100 элементов.

На приведенный пример есть одно возражение: число корзин хеш-таблицы -- всегда простое число, так что 100 там не может быть даже теоретически.
Re[12]: Хэш-таблица vs. дерево поиска
От: alexeiz  
Дата: 25.12.05 20:53
Оценка:
Здравствуйте, vdimas, Вы писали:

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


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


WH>>>Почему такой стериотип что switch должен быть построен на дереве, а не на хеш таблице?


A>>Дерево работает быстрее, чем hash таблица, для малого количества элементов. Я проверял на std::set и stdext::hash_set из библиотеки VC8. Для .NET можно тоже проверить, знать бы только, где есть хорошая реализация контейнера, построеного на деревьях.


V>Это зависит не только от числа элементов, но и от относительного качества Hash-функции применительно к текущему размеру Hash-таблицы,


Для малого количества элементов hash функция не имеет большого значения.
Re[15]: Хэш-таблица vs. дерево поиска
От: adontz Грузия http://adontz.wordpress.com/
Дата: 26.12.05 01:40
Оценка:
Здравствуйте, Mab, Вы писали:

Mab>На приведенный пример есть одно возражение: число корзин хеш-таблицы -- всегда простое число


Кстати, а какая от этого польза?

Ведь если хеш-функция возвращает значения в диапазоне [0,N), а размер хеш-таблицы K, то вероятность того, что на одну ячейку придутся несколько значений N/K и не зависит от простоты K. Если хеш-функция плоха, то есть некоторые значения из диапазока [0,N) более вероятны чем другие для случайного аргумента, то простота K не исправит ситуации.
С одной стороны ясно, что простота K означает, что при увеличении размера хеш-балицы элементы попадут в другие места, но ведь для хорошей хеш-функции это должно быть безразлично.
Выходит проектировали сразу для плохой и хеш таблица заполненая меньше чем наполовину это норма?
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[23]: Хэш-таблица vs. дерево поиска
От: WolfHound  
Дата: 26.12.05 07:40
Оценка:
Здравствуйте, adontz, Вы писали:

A>>>А что ты сможешь посчитать осмысленный хеш не перебрав все элементы множества?

WH>>А это тут причем?
A>А суть в том, что проблемы вообще нету, есть проблема написати быстро. Для неупорядоченных коллекций представляющих собой множества это нереально.
Ничего не понял. Что не реально? Хеш посчитать не реально?
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[16]: Хэш-таблица vs. дерево поиска
От: Mab Россия http://shade.msu.ru/~mab
Дата: 26.12.05 08:58
Оценка:
Здравствуйте, adontz, Вы писали:

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


Mab>>На приведенный пример есть одно возражение: число корзин хеш-таблицы -- всегда простое число


A>Кстати, а какая от этого польза?

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

В контексте реализации .NET простой модуль необходим, т.к. там используется двойное хеширование, т.е. позиция (bucket) вычисляется так:
pos = (h1(obj) + k*h2(obj)) mod M

где h1, h2 -- две хеш-функции (первая совпадает с GetHashCode, вторая получается из нее), k -- число уже просмотренных позиций.

Такми образом, простота M гарантирует, что когда k пробегает значения 0..M-1 данная формула дает все позиции 0..M-1.

A>Выходит проектировали сразу для плохой и хеш таблица заполненая меньше чем наполовину это норма?

Конечно, странно ожидать от входных данных истинно равномерного распределения. Насчет 'наполовину' -- откуда это взялось, я не понял. Производительность хештаблицы тем хуже, чем больше в ней коэффициент заполнения. Какое именно значение выбрать в качестве оптимума -- решать пользователю исходя из memory-speed tradeoff.
Re[15]: Хэш-таблица vs. дерево поиска
От: vdimas Россия  
Дата: 26.12.05 11:45
Оценка:
Здравствуйте, Mab, Вы писали:

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


V>>Текущая позиция элемента — это не само хеш-значение, а модуль по делению его на текущий размер таблицы. Предположим даже "очень плохую" хеш-функцию, возвращающую некие кратные значения, типа 0, 100, 200 и т.д., и "плохой" размер таблицы — 100 элементов.

Mab>На приведенный пример есть одно возражение: число корзин хеш-таблицы -- всегда простое число, так что 100 там не может быть даже теоретически.

100 — это пример, можно было взять 101
Re[16]: Хэш-таблица vs. дерево поиска
От: vdimas Россия  
Дата: 26.12.05 11:48
Оценка:
Здравствуйте, adontz, Вы писали:

A>Ведь если хеш-функция возвращает значения в диапазоне [0,N), а размер хеш-таблицы K, то вероятность того, что на одну ячейку придутся несколько значений N/K и не зависит от простоты K. Если хеш-функция плоха, то есть некоторые значения из диапазока [0,N) более вероятны чем другие для случайного аргумента, то простота K не исправит ситуации.

A>С одной стороны ясно, что простота K означает, что при увеличении размера хеш-балицы элементы попадут в другие места, но ведь для хорошей хеш-функции это должно быть безразлично.
A>Выходит проектировали сразу для плохой и хеш таблица заполненая меньше чем наполовину это норма?

Это более чем норма. Посмотри на это по-другому. Хеш-таблица — это просто массив, нам не надо выделять память под ячейки связи, для образования некоей пространственной структуры как в деревьях. Т.е. все-равно довольно экономно.
Re[13]: Хэш-таблица vs. дерево поиска
От: vdimas Россия  
Дата: 26.12.05 11:58
Оценка:
Здравствуйте, alexeiz, Вы писали:

A>Для малого количества элементов hash функция не имеет большого значения.


Малое — это сколько?
Re[25]: Хэш-таблица vs. дерево поиска
От: WolfHound  
Дата: 27.12.05 06:33
Оценка:
Здравствуйте, adontz, Вы писали:

A>Посчитать хеш неупорядоченной коллекцииза O(1) нереально, нужно O(N), причём значение хеш-функции не должно зависеть от порядка аргументов

А что посчитать хеш упорядоченой коллекции за O(1) можно?
A>(в голову приходит только xor)
Плохо.
A>Сравнить две неупорядоченные коллекции за O(N) не реально, нужно O(N*log(N)).
Если это хеш таблици с веременем поиска O(1) то еще как реально.
A>Причём сравнение реально пишеться и работает, а вот написать хорошую хеш-фунцию, значение которой не зависит от порядка элементов коллекции это интересная задачка. Xor это бомба замедленного действия. Возможно имеет смысл делить достаточно большое число последовательно на все элементы и что-то делать с результатом и остатками Тут вообще надо подумать.
У меня ни разу не получалось написать совсем плохую хеш функцию.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[14]: Хэш-таблица vs. дерево поиска
От: alexeiz  
Дата: 27.12.05 09:02
Оценка:
Здравствуйте, vdimas, Вы писали:

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


A>>Для малого количества элементов hash функция не имеет большого значения.


V>Малое — это сколько?


Где-то до 100.
Re[20]: Хэш-таблица vs. дерево поиска
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.01.06 14:45
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Кстати, несмортя на то, что вопрос не плохой, стоит сделать акцент на том, что удовлетворение всех вовсе не обязательно. Т.е. для кого-то эти массивы равны, если рассматриваются как множества, а для кого-то нет. Действительно, для некоторых задач предпочтительней map-ы, основанные на отношении порядка. Это никак не противоречит тому, что для других задач отношение порядка по боку.


Ага. И если вернуться к вопросу реализации switch-а, то казалось бы зачем для этого упорядычивание?
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[19]: Хэш-таблица vs. дерево поиска
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.01.06 14:45
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Дело не в сериализации, а в получении упорядоченного множества элементов коллекции. (наверно adontz имел в виду это). В приведенной ссылке одному богу известно зачем Wolfhound использовал Hashtable. Оно там вовсе не нужно.


Зачем Wolfhound хэш-таблица как раз понятно. А вот зачем нужно упорядычивание для реализации switch-а?
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[21]: Хэш-таблица vs. дерево поиска
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.01.06 14:45
Оценка:
Здравствуйте, adontz, Вы писали:

A>Никто ни в чём не убедился. Сравнением множеств, а не упорядоченных списков это вполне понятно более сложная вычислительная задача. но не неразрешимая. Прямо сейчас могу написать за O(n*log(n))


То есть ты предлагал сделать switch со скоростными характеристиками порядка O(n*log(n)). Ясно. Тогда вопросов больеш нет.

ЗЫ

Может не нужно уходить в такую глубокую демагогию? Вопрос же вроде примитивный. Для реализации хэш-таблицы нет никакого смысла использовать упорядоченние. Это не применимо во многих случаях и работает медленее чем хэш-таблица. О чем тогда разговор? Неужели имеет смысл упираться в столь очевидные вопросы?
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: Хэш-таблица vs. дерево поиска
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.01.06 14:45
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Если твой StateSet рассматривать как упорядоченное множество State-ов, то отношение порядка для него строится более чем легко при существовании отношения порядка для самих State-ов.


V>Для введения отношения порядка самих States достаточно их пронумеровать, желательно в порядке ввода в грамматику (например, начиная с состояния Start и далее последовательно таким образом, чтобы новые состояния в грамматику вводились как результат перехода из уже существующего множества состояний... хотя и это не обязательно, просто такое отношение порядка удобно может использоваться и в др. случаях, например при построении визуального отображения графа грамматики)


Здорово! И по ходу преобразования НКА в ДКА мы много раз будет удалять и добавлять состояния. При этом будут меняться характеристики множеств. Они то будут "больше" других, то "меньше". Для решаемой задачи — это не имеет никакого значения. Но мы, чисто от вредности, будет пересчитаывать все внутренние структуры.

А смысл? Хэш-таблица решает задачу без побочных эффектов и к тмоу же далате это быстрее чем другие методы.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Хэш-таблица vs. дерево поиска
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.01.06 14:45
Оценка:
Здравствуйте, alexeiz, Вы писали:

WH>>Почему такой стериотип что switch должен быть построен на дереве, а не на хеш таблице?


A>Дерево работает быстрее, чем hash таблица, для малого количества элементов. Я проверял на std::set и stdext::hash_set из библиотеки VC8. Для .NET можно тоже проверить, знать бы только, где есть хорошая реализация контейнера, построеного на деревьях.


Что ты проверял? Ну, это уже просто выходит за границы разумного.
Блин, читайте классику и не смотрите на результаты эксперементов производимых на базе откровенно лажевых реализаций контейнеров.

Хэш-таблица имеет константное время доступа при хорошей хэш-функции. Для поиска элементов требуется только лишь взять хэш вычеслить по нему слот хэш-таблицы и извлечь из него значение. Даже сравнение не нужно. А в случае коллизий и возможности сравнить элементы на больше/меньше коллизии можно и отсортировать. Тогда уж дерево не соможет быть быстрее ни в каком случае. Даже в случае клиничевки хреновой хэш-функции.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: Хэш-таблица vs. дерево поиска
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.01.06 14:45
Оценка:
Здравствуйте, Mab, Вы писали:

Mab>На приведенный пример есть одно возражение: число корзин хеш-таблицы -- всегда простое число, так что 100 там не может быть даже теоретически.


Это эвристика котору не обязательно соблюдать. Так что "всегда" в данном случае говорить неуместно.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: Хэш-таблица vs. дерево поиска
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.01.06 14:45
Оценка:
Здравствуйте, Mab, Вы писали:

Mab>Конечно, странно ожидать от входных данных истинно равномерного распределения. Насчет 'наполовину' -- откуда это взялось, я не понял.


А откуда ты взял "наполовину"? Эксперементально доказано, что обычно эффективная работа хэш-таблиц начинается с момента когда количество слотов в 1.3 раза больше чем элементов подлежащих хранению. В два раз — это еще лучше, конечно. Но в 3 еще. И пока хэш-таблица попадает в кэш, разницы особо не будет.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[18]: Хэш-таблица vs. дерево поиска
От: Mab Россия http://shade.msu.ru/~mab
Дата: 02.01.06 15:27
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>А откуда ты взял "наполовину"?

Ну так adontz писал:

Выходит проектировали сразу для плохой и хеш таблица заполненая меньше чем наполовину это норма?

Re[17]: Хэш-таблица vs. дерево поиска
От: Mab Россия http://shade.msu.ru/~mab
Дата: 02.01.06 15:29
Оценка:
Здравствуйте, VladD2, Вы писали:

VDПо крайней мере во втором дотнете лучше использовать Stopwatch.
Здорово... не знал про него.
Re[16]: Хэш-таблица vs. дерево поиска
От: Mab Россия http://shade.msu.ru/~mab
Дата: 02.01.06 15:41
Оценка:
Здравствуйте, VladD2, Вы писали:

Mab>>На приведенный пример есть одно возражение: число корзин хеш-таблицы -- всегда простое число, так что 100 там не может быть даже теоретически.


VD>Это эвристика котору не обязательно соблюдать.

ОК, согласен, что реализовать абы какую хештаблицу можно хоть на 2^16 корзинах.

Я имел в виду (и, очевидно, выразил эту мысль плохо), что при использовании двойного хеширования (в частности, оно использовано в .NET Framework) размер обязан быть простым числом, т.к. при составном числе корзин m не все ненулеые вычеты оказываются порождающими mod m. Т.е. при данном конкретном способе реализации это не эвристика, а необходимое требование.
Re[22]: Хэш-таблица vs. дерево поиска
От: adontz Грузия http://adontz.wordpress.com/
Дата: 02.01.06 15:54
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Может не нужно уходить в такую глубокую демагогию?


Да-да, действительно. Я пошёл пить чай и жрать конфеты.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[12]: Хэш-таблица vs. дерево поиска
От: alexeiz  
Дата: 02.01.06 20:28
Оценка:
Здравствуйте, VladD2, Вы писали:

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


WH>>>Почему такой стериотип что switch должен быть построен на дереве, а не на хеш таблице?


A>>Дерево работает быстрее, чем hash таблица, для малого количества элементов. Я проверял на std::set и stdext::hash_set из библиотеки VC8. Для .NET можно тоже проверить, знать бы только, где есть хорошая реализация контейнера, построеного на деревьях.


VD>Что ты проверял? Ну, это уже просто выходит за границы разумного.


За границы разумного выходят твои книжные знания. Ассимптотичное поведение не имеет ни малейшего значения для малых N.

VD>Блин, читайте классику и не смотрите на результаты эксперементов производимых на базе откровенно лажевых реализаций контейнеров.


VD>Хэш-таблица имеет константное время доступа при хорошей хэш-функции. Для поиска элементов требуется только лишь взять хэш вычеслить по нему слот хэш-таблицы и извлечь из него значение. Даже сравнение не нужно. А в случае коллизий и возможности сравнить элементы на больше/меньше коллизии можно и отсортировать. Тогда уж дерево не соможет быть быстрее ни в каком случае. Даже в случае клиничевки хреновой хэш-функции.


Тебе объяснить на пальцах?

Для количества элементов в контейнере равное 1 дерево будет быстрее хэш-таблицы, это очевидно. Для достаточно большого количества элементов хэш-таблица с хорошей хэш-функцией будет быстрее дерева. Значит, есть такое количество элементов, вплоть до которого дерево будет быстрее чем хэш-таблица.
Re[13]: Хэш-таблица vs. дерево поиска
От: Mab Россия http://shade.msu.ru/~mab
Дата: 02.01.06 20:35
Оценка:
Здравствуйте, alexeiz, Вы писали:
A>Для количества элементов в контейнере равное 1 дерево будет быстрее хэш-таблицы, это очевидно. Для достаточно большого количества элементов хэш-таблица с хорошей хэш-функцией будет быстрее дерева. Значит, есть такое количество элементов, вплоть до которого дерево будет быстрее чем хэш-таблица.

Ты ошибаешься вот в чем: в отличие от дерева, у хештаблицы есть дополнительный параметр -- коэффициент заполнения, который напрямую влияет на скорость. Если его сделать достаточно большим и считать, что хешфункция хорошая, то время доступа будет O(1). Так что такое лобовое сравнение с деревом не годится. Засчет дополнительного расхода по памяти хештаблица может успешно обогнать дерево на любых размерах. Вопрос только в том, устраивает ли тебя такой tradeoff.

Это, кстати, и показывают тесты, которые я привел ранее -- хештаблица .NET обгоняет std::map на 50 элементах.
Re[14]: Хэш-таблица vs. дерево поиска
От: adontz Грузия http://adontz.wordpress.com/
Дата: 02.01.06 21:06
Оценка:
Здравствуйте, Mab, Вы писали:

Mab>Это, кстати, и показывают тесты, которые я привел ранее -- хештаблица .NET обгоняет std::map на 50 элементах.


Осталось только выяснить как часто встречается switch в котором 50 case. Я такой встречал только в двух случаях — генерённый конечный автомат и ручная обработка оконных сообщений. Оба случая далеко не самые распространённые.

К тому же есть ещё один момент — константность. То что стоит после case перед : не должно меняться во времени. а вот с константами в .Net немного фигово. Фактически она существует только для value типов.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[16]: Хэш-таблица vs. дерево поиска
От: adontz Грузия http://adontz.wordpress.com/
Дата: 02.01.06 21:32
Оценка:
Здравствуйте, Mab, Вы писали:

Mab>не верно, т.к. подбором коэффициента заполнения можно добиться


Можно. Кто же спорит? но делать это должен будет компилятор для предопределённой функции.

P.S. Никто не говорит, что хеш-таблицы это плохо. Не надо доказывать что хеш-таблицы вообще это при некотором перерасходе памяти быстрее, чем деревья вообще. У нас тут случай оператора switch — сомнительная хеш-функция и 5-20 case'ов.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[15]: Хэш-таблица vs. дерево поиска
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.01.06 15:18
Оценка:
Здравствуйте, adontz, Вы писали:

A>Осталось только выяснить как часто встречается switch в котором 50 case. Я такой встречал только в двух случаях — генерённый конечный автомат и ручная обработка оконных сообщений. Оба случая далеко не самые распространённые.


Компилятор C# для свитча по строкам использует хэш-таблицу если количество элементов превышает 6 элементов. До этого разруливает на if-ах. Ну, а деревья вообще никогда не использует, так как не разумно.

A>К тому же есть ещё один момент — константность. То что стоит после case перед : не должно меняться во времени. а вот с константами в .Net немного фигово. Фактически она существует только для value типов.


Тут ты отчасти прав. Вот только константность обеспечивается еще неизменяемостью объектов. Например, строки именно не изменяемые объекты.

Однако дотнет же не запрещает использовать изменяемые объекты в хэш-таблицах. Так можно было и в свитчах позволить использовать.

Но уверен, что это не сделано именно из соображений константности.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: Хэш-таблица vs. дерево поиска
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.01.06 15:18
Оценка:
Здравствуйте, adontz, Вы писали:

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


Mab>>не верно, т.к. подбором коэффициента заполнения можно добиться


A>Можно. Кто же спорит? но делать это должен будет компилятор для предопределённой функции.


Это уже делает текущая реализация хэш-таблицы. У нее есть параметр "коэффициент заполнения" который автоматически перестраивает хэш-таблицу если он превышен. По умолчанию задан довольно разумный коэффициент, но ты можешь задать его вручную.

A>P.S. Никто не говорит, что хеш-таблицы это плохо. Не надо доказывать что хеш-таблицы вообще это при некотором перерасходе памяти быстрее, чем деревья вообще. У нас тут случай оператора switch — сомнительная хеш-функция и 5-20 case'ов.


И кто будет виноват если делает что-то сомнительное? Мне все безрукие уроды по барабану. Если человек идиот, то это надолго. Я же хотел бы не писать каждый раз килограм кода, а иметь удобный синтаксический сахар. Эффективность же это моя проблема. Если я посчитаю, что для одной из миллиона задачь дерево более примлемо, то воспольуюсь им забив на свитчь.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Хэш-таблица vs. дерево поиска
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.01.06 15:19
Оценка:
Здравствуйте, alexeiz, Вы писали:

A>За границы разумного выходят твои книжные знания. Ассимптотичное поведение не имеет ни малейшего значения для малых N.


Можно без умных слов? Что ты скажешь на тесты маба
Автор: Mab
Дата: 27.12.05
?

Вроде как твои заявленные 100 элементов, а реализация на управляемом языке с кучае рантайм проверок и далеком от идеала оптимизирующим компилятором рвет твое дерево как тузик грелку. Хороши "книжные знания".

A>Для количества элементов в контейнере равное 1 дерево будет быстрее хэш-таблицы, это очевидно.


Да? И что же тут очевидного? И вообще, о какой скорости тут можно говорить?

A> Для достаточно большого количества элементов хэш-таблица с хорошей хэш-функцией будет быстрее дерева.


С хорошей то? Да, для любого!

A> Значит, есть такое количество элементов, вплоть до которого дерево будет быстрее чем хэш-таблица.


Да, с чего же это?
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[16]: Хэш-таблица vs. дерево поиска
От: GlebZ Россия  
Дата: 04.01.06 02:08
Оценка:
Здравствуйте, Mab, Вы писали:

A>>Опять мне приводят ассимптотики. Ассимтотики неприменимы в этой области N.

Mab>При чем тут асимптотики? Твое утверждение
A>>Значит, есть такое количество элементов, вплоть до которого дерево будет быстрее чем хэш-таблица.
Mab>не верно, т.к. подбором коэффициента заполнения можно добиться того, чтобы хештаблица обноняла дерево на любом размере. Асимптотика тут побоку.
Правда при этом нужно говорить подбором значений можно сделать так, что никакой коэффициент не спасет.
Второй недостаток невозможность хранить повторяемые значения.

С уважением, Gleb.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[17]: Хэш-таблица vs. дерево поиска
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.01.06 10:57
Оценка:
Здравствуйте, GlebZ, Вы писали:

GZ>Второй недостаток невозможность хранить повторяемые значения.




Dictionary<string, List<MyType>> dic =...

и понеслась...
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[18]: Хэш-таблица vs. дерево поиска
От: GlebZ Россия  
Дата: 04.01.06 21:37
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>
VD>Dictionary<string, List<MyType>> dic =...
VD>

VD>и понеслась...
Разве там ключ не должен быть уникальным?

С уважением, Gleb.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[19]: Хэш-таблица vs. дерево поиска
От: Mab Россия http://shade.msu.ru/~mab
Дата: 04.01.06 21:39
Оценка:
Здравствуйте, GlebZ, Вы писали:

GZ>Разве там ключ не должен быть уникальным?

В смысле? Ключ здесь уникальный. Только ему соответствует не одно значение, а список. Конечно, придется дописать некоторый код. Если лень -- можно взять PowerCollections, там есть MultiDictionary, где это уже сделано за нас.

В общем, никаких теоретических трудностей с множественными значениями нет.
Re[21]: Хэш-таблица vs. дерево поиска
От: Mab Россия http://shade.msu.ru/~mab
Дата: 04.01.06 21:44
Оценка:
Здравствуйте, GlebZ, Вы писали:

GZ>Ой-ли. Обычно для хеш таблицы с одинаковыми значениями N скорость вставки равняется О(N).

Еще раз. Повторяю. Постарайся осмыслить: ключи в хештаблице будут уникальны. Но каждому будет соответствовать список значений (раз это многозначное отображение).
Re[23]: Хэш-таблица vs. дерево поиска
От: Mab Россия http://shade.msu.ru/~mab
Дата: 04.01.06 21:52
Оценка:
Здравствуйте, GlebZ, Вы писали:

GZ>Понятно. Ты просто не понял. Я под значением подразумевал классическое определение значения в хеш-таблицах, по которому генерится ключ.

Точно. Ничего не понял Что за "значение" по которому генерится "ключ"?
Re[24]: Хэш-таблица vs. дерево поиска
От: GlebZ Россия  
Дата: 04.01.06 22:04
Оценка:
Здравствуйте, Mab, Вы писали:

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


GZ>>Понятно. Ты просто не понял. Я под значением подразумевал классическое определение значения в хеш-таблицах, по которому генерится ключ.

Mab>Точно. Ничего не понял Что за "значение" по которому генерится "ключ"?
Sorry, опять неверно высказался. Что такое классическая хеш таблица. Это некоторый массив значений. По этим значениям с помощью некоторой хеш функции определяется позиция (иногда позиция для дальнейшего поиска в случае неуникальных значений). Просто в данном случае (да и в большинстве реализаций) хеш таблица является также контейнером других объектов. И в этом случае действительно появляется ключ(но он необязательный аттрибут любой хеш таблицы).

С уважением, Gleb.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[25]: Хэш-таблица vs. дерево поиска
От: VladD2 Российская Империя www.nemerle.org
Дата: 05.01.06 01:16
Оценка:
Здравствуйте, GlebZ, Вы писали:

GZ>Sorry, опять неверно высказался. Что такое классическая хеш таблица. Это некоторый массив значений. По этим значениям с помощью некоторой хеш функции определяется позиция (иногда позиция для дальнейшего поиска в случае неуникальных значений). Просто в данном случае (да и в большинстве реализаций) хеш таблица является также контейнером других объектов. И в этом случае действительно появляется ключ(но он необязательный аттрибут любой хеш таблицы).


Господи, какой <пип>!
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[22]: Хэш-таблица vs. дерево поиска
От: minorlogic Украина  
Дата: 05.01.06 09:14
Оценка:
А мы switch делаем для произвольных объектов ? или конкретных ,int ? string ?

Не нужно забывать также что в хештабличке также используется оператор == который для множеств даст те же грабли . А с плохой хеш функцией вообще может дать наихудшую производительность в плохом случае. А дерево работает стабильно .

Давайте думать есть ли случаи когда оператор < реализовать тяжело , а == легко.
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[15]: Хэш-таблица vs. дерево поиска
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 05.01.06 09:25
Оценка:
Здравствуйте, adontz, Вы писали:


A>Влад, GetHashCode для строк и GetHashCode для произвольного класса написанного Васей Пупкиным ну очень различаются по качеству.

Любой набор данных это некая последовательность байтов. Применяя для них выверенные алгоритмы для строк, ты мало чем рискуешь. Другое дело, что не везде нужно подходить так тупо.
и солнце б утром не вставало, когда бы не было меня
Re[24]: Хэш-таблица vs. дерево поиска
От: minorlogic Украина  
Дата: 05.01.06 10:56
Оценка:
Здравствуйте, Mab, Вы писали:

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


M>>Давайте думать есть ли случаи когда оператор < реализовать тяжело , а == легко.

Mab>ОК. Реализуй компаратор для пары object-ов

В чем сложность , не уловил . Можно подробнее ?
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[25]: Хэш-таблица vs. дерево поиска
От: Mab Россия http://shade.msu.ru/~mab
Дата: 05.01.06 10:59
Оценка:
Здравствуйте, minorlogic, Вы писали:

M>В чем сложность , не уловил . Можно подробнее ?

Как устроить дерево поиска, хранящее произвольные объекты (object)? Равенство есть автоматически -- object.ReferenceEquals. Как предлагается устраивать сравнение?
Re[26]: Хэш-таблица vs. дерево поиска
От: GlebZ Россия  
Дата: 05.01.06 11:06
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Господи, какой <пип>!

Не согласен, аргументируй.

С уважением, Gleb.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[26]: Хэш-таблица vs. дерево поиска
От: adontz Грузия http://adontz.wordpress.com/
Дата: 05.01.06 11:15
Оценка:
Здравствуйте, Mab, Вы писали:

Mab>Как устроить дерево поиска, хранящее произвольные объекты (object)? Равенство есть автоматически -- object.ReferenceEquals. Как предлагается устраивать сравнение?


Если типы объектов не равны, то сравнивать просто строковые названия типов. Если же равны, то использовать operator < для типа.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[27]: Хэш-таблица vs. дерево поиска
От: Mab Россия http://shade.msu.ru/~mab
Дата: 05.01.06 11:16
Оценка:
Здравствуйте, adontz, Вы писали:

A>Если же равны, то использовать operator < для типа.

А откуда у object-а такой оператор?
Re[26]: Хэш-таблица vs. дерево поиска
От: minorlogic Украина  
Дата: 05.01.06 11:34
Оценка:
Здравствуйте, Mab, Вы писали:

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


M>>В чем сложность , не уловил . Можно подробнее ?

Mab>Как устроить дерево поиска, хранящее произвольные объекты (object)? Равенство есть автоматически -- object.ReferenceEquals. Как предлагается устраивать сравнение?

Скорее всего если есть механизм определения типа во время выполнения , то и сравнивать этот механизм позволит (по имени , по id и т.д)
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[27]: Хэш-таблица vs. дерево поиска
От: Mab Россия http://shade.msu.ru/~mab
Дата: 05.01.06 11:36
Оценка:
Здравствуйте, minorlogic, Вы писали:

M>Скорее всего если есть механизм определения типа во время выполнения , то и сравнивать этот механизм позволит (по имени , по id и т.д)

В смысле "скорее"? Покажите мне этот механизм в .NET. Подсказка: никаких имен и id у объектов в общем случае нет.
Re[28]: Хэш-таблица vs. дерево поиска
От: adontz Грузия http://adontz.wordpress.com/
Дата: 05.01.06 11:38
Оценка:
Здравствуйте, Mab, Вы писали:

A>>Если же равны, то использовать operator < для типа.

Mab>А откуда у object-а такой оператор?

Причём тут object? Я же сказал — "если типы равны". То есть у нас есть две переменные типа object, на на самом деле они обе типа T и мы вызываем
bool T::operator < (T t);
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[29]: Хэш-таблица vs. дерево поиска
От: Mab Россия http://shade.msu.ru/~mab
Дата: 05.01.06 11:40
Оценка:
Здравствуйте, adontz, Вы писали:

A>Причём тут object? Я же сказал — "если типы равны". То есть у нас есть две переменные типа object, на на самом деле они обе типа T и мы вызываем

A>
A>bool T::operator < (T t);
A>

Хм. А с чего ты взял, что тип T определил такой оператор? Я рассматриваю случай, когда, скажем, нужно устроить ассоциативную таблицу, где ключами будут приходящие извне экземпляры сслочного типа, про который мне ничего не известно.
Re[21]: Хэш-таблица vs. дерево поиска
От: VladD2 Российская Империя www.nemerle.org
Дата: 05.01.06 13:47
Оценка:
Здравствуйте, minorlogic, Вы писали:

M>Мне кажется имелось ввиду , что оператор сравнения можно написать правильно и неправильно , а хеш еще и можно написать плохо.


Готов за деньги написать/переписать любой код настолько плохо, что вы ужаснетесь.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[19]: Хэш-таблица vs. дерево поиска
От: VladD2 Российская Империя www.nemerle.org
Дата: 05.01.06 13:47
Оценка:
Здравствуйте, GlebZ, Вы писали:

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


VD>>
VD>>Dictionary<string, List<MyType>> dic =...
VD>>

VD>>и понеслась...
GZ>Разве там ключ не должен быть уникальным?

Он там и уникален. Просто вместо одного объекта хранится список. Для вэлютипов это понятно бессмысленно, так как равные вэлью-типы ничем не отличаются. Но для объектов это более чем разумно.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[20]: Хэш-таблица vs. дерево поиска
От: vdimas Россия  
Дата: 05.01.06 20:28
Оценка:
Здравствуйте, VladD2, Вы писали:

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


V>>Дело не в сериализации, а в получении упорядоченного множества элементов коллекции. (наверно adontz имел в виду это). В приведенной ссылке одному богу известно зачем Wolfhound использовал Hashtable. Оно там вовсе не нужно.


VD>Зачем Wolfhound хэш-таблица как раз понятно.


Мне не понятно. Там банальный список состояний. По НКА-графу автомат все-равно не работает реально, т.е. это промежуточное представление.

VD>А вот зачем нужно упорядычивание для реализации switch-а?


Пример Wolfhounda не имеет отношения к свичу. Отношение порядка нужно для построения мапов или сортированных последовательностей. И в чем прикол ситуации, так это в том, что графах НКА в реальной жизни от вершин отходит в среднем менее десятка дуг. Именно на таких объемах сама Microsoft рекомендует использовать SortedList вместо Hashtable. Тем более присоединяюсь, т.к. ключами в этом случае являются символы — суть целочисленные значения, для которых заведомо определено отношение порядка.
Re[16]: Хэш-таблица vs. дерево поиска
От: vdimas Россия  
Дата: 05.01.06 20:45
Оценка:
Здравствуйте, VladD2, Вы писали:

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


Mab>>На приведенный пример есть одно возражение: число корзин хеш-таблицы -- всегда простое число, так что 100 там не может быть даже теоретически.


VD>Это эвристика котору не обязательно соблюдать. Так что "всегда" в данном случае говорить неуместно.


Почему эвристика? Банально у простого числа (размера таблицы) и произвольного другого числа (значение хеш ф-ии) отсутствуют общие делители (т.е. хеш ф-ия которая выдает некие кратные значения не будет попадать на одни и те же ячейки по кругу). Остается только случай кратности значения хеш ф-ии длине таблицы, которых заведомо меньше.
Re[30]: Хэш-таблица vs. дерево поиска
От: adontz Грузия http://adontz.wordpress.com/
Дата: 05.01.06 22:55
Оценка:
Здравствуйте, Mab, Вы писали:


Mab>Хм. А с чего ты взял, что тип T определил такой оператор? Я рассматриваю случай, когда, скажем, нужно устроить ассоциативную таблицу, где ключами будут приходящие извне экземпляры сслочного типа, про который мне ничего не известно.


В .Net так не бывает
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[31]: Хэш-таблица vs. дерево поиска
От: Mab Россия http://shade.msu.ru/~mab
Дата: 06.01.06 08:33
Оценка:
Здравствуйте, adontz, Вы писали:

A>В .Net так не бывает

Что, правда? Ладно, вот пример: открываем MSDN и смотрим на класс ObjectIDGenerator (тот самый, который используется при сериализации). Как ты его реализуешь с помощью дерева поиска?
Re[33]: Хэш-таблица vs. дерево поиска
От: Mab Россия http://shade.msu.ru/~mab
Дата: 06.01.06 09:50
Оценка:
Здравствуйте, adontz, Вы писали:

A>А зачем ObjectIDGenerator реализовывать с помошью деревьев? Предположим, что нельзя/сложно, какое это отношение имеет к оператору switch?

Если ты поднимишься по ветке вверх, то увидишь, что я отвечал на вопрос:

Давайте думать есть ли случаи когда оператор < реализовать тяжело , а == легко.


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

Учитывая, что такие задачи идентификации объектов произвольного типа встречаются в .NET довольно часто, становится понятно, почему GetHashCode стал частью object. (Особенно есть учесть, что единственный способ реализации коллекции-чего-угодно в .NET 1.0 -- это полиморфный базисный класс).
Re[22]: Хэш-таблица vs. дерево поиска
От: VladD2 Российская Империя www.nemerle.org
Дата: 06.01.06 18:51
Оценка:
Здравствуйте, vdimas, Вы писали:

V>А что, компилятор не в состоянии определить, какой подход лучше? Если у нас, например, целые или enum из непрерывного последовательного диапазона, то в этом случае как хеш, так и мап и на фиг не сдались.


Надо быть больным чтобы целочисленне значения через хэш-таблицу проталкивать. Они и так МСИЛьным cswitch-ем поддерживаются.

V>И еще, для switch по длинным строковым константам map работает лучше хеш ф-ии.


Я не знаю кто такой "map" и чем он отличается от дерева или хэш-таблицы , но похоже ты толкашь еще одну высасанную из пальца теорию.

V> Т.е., я вообще за то, чтобы конкретную реализацию switch компилятор выбирал исходя из типов и значений констант.


Для простх типов и так все делается. Для сложных хэш-таблица идеальное универсальное решеиние.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[21]: Хэш-таблица vs. дерево поиска
От: VladD2 Российская Империя www.nemerle.org
Дата: 06.01.06 18:51
Оценка:
Здравствуйте, vdimas, Вы писали:

VD>>Зачем Wolfhound хэш-таблица как раз понятно.


V>Мне не понятно.


Сядь и разберись. Там все просто.

VD>>А вот зачем нужно упорядычивание для реализации switch-а?


V>Пример Wolfhounda не имеет отношения к свичу.


Напмоню, что разговор идет о реализации switch-а и предожение реализовывать его деревьями сделанном адонцом.

V> Отношение порядка нужно для построения мапов или сортированных последовательностей.


"Мап-ф" изумительно живут на базе хэш-талиц. Только в СТЛ хватило ума азлудить в реализацию мапа по-умолчению дерево.

V> И в чем прикол ситуации, так это в том, что графах НКА в реальной жизни от вершин отходит в среднем менее десятка дуг. Именно на таких объемах сама Microsoft рекомендует использовать SortedList вместо Hashtable. Тем более присоединяюсь, т.к. ключами в этом случае являются символы — суть целочисленные значения, для которых заведомо определено отношение порядка.


Почитай вримательно код. Погляди зачем там используется хэш-таблица.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: Хэш-таблица vs. дерево поиска
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 11.01.06 08:13
Оценка:
Здравствуйте, Mab, Вы писали:

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



A>>Я говорю о другом. Есть множество программистов, которые пишут классы, которые потенциально могут использоваться в операторе switch.

A>>Какой процент из них напишет сколько-нибудь разумную хеш-функцию?
Mab>В случае, если класс не определяет deep-семантики для равенства (т.е. равенство -- это равенство ссылок), то соответвующий GetHashCode из object обеспечивает замечательное распределение, т.к. вычисляется на основе sync block index, который чуть ли не уникален в пределах домена.
Не все так хорошо
http://www.rsdn.ru/Forum/Message.aspx?mid=581480&amp;pg=1
Автор: orangy
Дата: 24.03.04

http://www.rsdn.ru/Forum/Message.aspx?mid=581480#581480
Автор: orangy
Дата: 24.03.04

http://www.rsdn.ru/Forum/Message.aspx?mid=581480&amp;pg=4
Автор: orangy
Дата: 24.03.04
... << RSDN@Home 1.1.4 stable rev. 510>>
и солнце б утром не вставало, когда бы не было меня
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.