Оптимизация fO_o

Wicked

Новичок
это не всегда и в худшем случае
а про вероятность достижения худшего случая там ничего не говорилось? :)

-~{}~ 17.04.08 16:07:

тем более, что мы теоретически можем предусмотреть, что если у нас возникает слишком много коллизий в при использовании хэш-таблицы, и мы выходим за рамки O(n ln n) (у этого события тоже вероятность не ахти :)), то далее резонно использовать "уникализацию" сортировкой.

-~{}~ 17.04.08 16:11:

кстати, кому интересно: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/52560
 

rotoZOOM

ACM maniac
тем более, что мы теоретически можем предусмотреть
Это ключевые слова - "теоретически". Ты представляешь себе, что во время работы алгоритма, он "вдруг" решает, что "чо-то много коллизий". Кладет на проделанную работу ржавый болт с левой резьбой и начанает заниматься сортировкой (сложность которой для общего случая уж никак не меньше O(n log n)).
Просто реально хочется увидеть твой алгоритм данной функции со сложностью O(n) для общего случая. Хотя бы алгоритм.

-~{}~ 17.04.08 15:21:

Почетал я ссылку.
If not possible, the sequence elements should enjoy a total
ordering, and if list(s).sort() doesn't raise TypeError it's
assumed that they do enjoy a total ordering. Then unique() will
usually work in O(N*log2(N)) time.

If that's not possible either, the sequence elements must support
equality-testing. Then unique() will usually work in quadratic
time.
Переводить тут надеюсь не надо?

-~{}~ 17.04.08 15:22:

Может определиться все таки. Или ты рассматриваешь алгоритм для частного случая или для общего.
 

Wicked

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

Кладет на проделанную работу ржавый болт с левой резьбой и начанает заниматься сортировкой (сложность которой для общего случая уж никак не меньше O(n log n)).
Если уж hashtable перевалил за (n ln n), то есть риск дальнейшего роста сложности до O(n * n), так что можно проделать всего лишь двойную работу вместо потенциального O(n * n): выкинуть результаты работа хэша и перейти к сортировке.

Просто реально хочется увидеть твой алгоритм данной функции со сложностью O(n) для общего случая. Хотя бы алгоритм.
для среднего _случая_ - http://phpclub.ru/talk/showthread.php?postid=791204#post791204
сложность алгоритма - O(n).

If that's not possible either, the sequence elements must support equality-testing. Then unique() will usually work in quadratic
time.
этот случай нам не грозит, потому что equality-testing в array_unique основан на операторе (string) (если верить документации), а в PHP в (string) можно конвертировать что угодно.
 

rotoZOOM

ACM maniac
Если уж hashtable перевалил за (n ln n), то есть риск дальнейшего роста сложности до O(n * n), так что можно проделать всего лишь двойную работу вместо потенциального O(n * n): выкинуть результаты работа хэша и перейти к сортировке.
Вот. Так каким образом ведется подсчет того, что алгоритм уже перевалил O(n log n) ? Когда количество итераций превысит n*log(n) ? Или все таки C*n*log(n), где C какой-то коэффициент (вопрос а какой? как выбирается?). Допустим даже, что определили, после чего запускаем сортировку, какова сложность алгоритма получится общая ? O(n*log (n)) с ужасно большим коэффициентом. Но никак не O(n), согласись.

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

этот случай нам не грозит, потому что equality-testing в array_unique основан на операторе (string) (если верить документации), а в PHP в (string) можно конвертировать что угодно.
Я не знаю Питона, поэтому можешь мне объяснить какая сложность у этой операции для него в вышеприведенной тобой ссылке?
PHP:
u[x] = 1
P.P.S. предвидя ответ, спрошу, а как они получили для ассоциативного массива сложность вставки O(n) в ЛЮБОМ случае?
 

Wicked

Новичок
Вот. Так каким образом ведется подсчет того, что алгоритм уже перевалил O(n log n) ? Когда количество итераций превысит n*log(n) ? Или все таки C*n*log(n), где C какой-то коэффициент (вопрос а какой? как выбирается?).
Да хотя бы считать кол-во операций хэширования. Если хэш-таблица разрежена и ключи ложатся в основном в пустые позиции, то на вставку N элементов уходит чуть больше N подсчетов хэша-функции. Но если мы видим, что нам при вставке 1000 элементов уже пришлось log10(1000)*1000 = 3000 раз подсчитать хэш-функцию, значит хэш работает неэффективно, и возникает слишком много коллизий. Но эта ситуация с превышением лимита в 3000 будет возникать в 0.000...1% случаев. В остальные 99.999...% будет сложность алгоритма около O(n).

Кстати, откуда УЖАСНО БОЛЬШОЙ коэффициент?

Я не знаю Питона, поэтому можешь мне объяснить какая сложность у этой операции для него в вышеприведенной тобой ссылке?

u[x] = 1
Такая же, как в пхп. Такая же, как любая вставка в хэш-таблицу.

P.P.S. предвидя ответ, спрошу, а как они получили для ассоциативного массива сложность вставки O(n) в ЛЮБОМ случае?
Ессно, в ЛЮБОМ случае они этого гарантировать не могут. Всего лишь в 99.9999...% случаев :)

Еще вопросы о событиях, которые мы в своей жизни не встретим?
 

rotoZOOM

ACM maniac
Но если мы видим, что нам при вставке 1000 элементов уже пришлось log10(1000)*1000 = 3000 раз подсчитать хэш-функцию, значит хэш работает неэффективно.
А если все последующие элементы будут ложится за O(1)? Это обычная эвристика работает эффективно не во всех случаях.
Кстати, откуда УЖАСНО БОЛЬШОЙ коэффициент?
Как откуда ... мы уже проделали O(n log n) шагов и после этого еще запускаем сортировку, которая тоже займет O(n log n) итераций. И каждый из алгоритмов со своим коэффициентом. Суммарно может получится довольно внушительно.
Ессно, в ЛЮБОМ случае они этого гарантировать не могут. Всего лишь в 99.9999...% случаев

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

P.S. 99.9999...% - оптимистичный процент :)
 

Wicked

Новичок
P.S. 99.9999...% - оптимистичный процент
А ты посчитай. Например, вероятность получить 100% коллизий (все элементы в одном "букете") для хэш-таблицы из 100 _рандомных_ (не-crafted) элементов = 10^(-98).

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

kode

never knows best
см выше...и также другие обьекты отличающиеся свойствами в родителе, или например с __toString()

-~{}~ 17.04.08 16:07:

я проверил: даже хуже :))

PHP:
<?php
class A{
	public $a = 0;
}

class B extends A{
	public $c = 1;
}

$test = new B();
$test2 = new B();

$test->a = 1;
$test2->a = 2;

$result = array_unique(array($test,$test2));


var_dump($result);
?>

-

Catchable fatal error: Object of class B could not be converted to string
 

Wicked

Новичок
kode
Да, я ошибся, но к топику это отношения не имеет, ибо:
PHP:
3  $a = array(new StdClass(), new StdClass());
4  array_unique($a);
Код:
Catchable fatal error: Object of class stdClass could not be converted to string in C:\2.php on line 4
-~{}~ 17.04.08 19:08:

гг
 

kode

never knows best
ладно, я пошёл домой :)

Так что хеш таблица как универсальное решение отпадает......хотя на уровне модуля (исходников) всё выглядит проще - прямой доступ к памяти (ссылкам на структуры обькета)
 

Wicked

Новичок
Так что хеш таблица как универсальное решение отпадает......
погоди... почему? я имею в виду "почему отпадает именно как замена array_unique()", у которого ровно те же проблемы?
 

rotoZOOM

ACM maniac
Wicked Не знаю как это сделано конкретно в php, но обычно хэш таблица еще и памяти жрет вдобавок ко всему. :)
 

kode

never knows best
единственное __универсальное решение__ тут - это работать напрямую с памятью, строки это слишком абстрактно......а там уже можешь использовать хоть хеш таблицы, хоть рекурсивый обход, хоть refcount, хоть что....
 
Сверху