А где комментарии? Ладно, тогда распишу че хочу. Вариант ответа на вопрос в конце: когда известен ключ и не надо перебирать все возможные варианты, что бы найти один единственный. Видос полезный, но надо будет еще утром посмотреть, а то всё забуду. И хотелось бы попросить рассказать про деревья. Бинарные, черно-белые и т.д. Смотрел в интернете - нудно, много воды и надо прям вчитываться в каждую букву что бы понять. Вроде всё. За видосы +реп ❤
Ответ на вопрос в конце 1)Хэш-таблицы, работают быстрее при поиске элементов, в массивах нужно перебрать все элементы, чтобы найти тот самый, в то время как в хэш-таблице вы переходите непосредственно к элементу. 2)Вставка элемента выполняется быстрее в хэш-таблицах, так как вы просто хешируете ключ и вставляете его; в массивах важно сначала переместить элементы, прежде чем вставлять еще один.
Про первое, если у нас есть индекс, то мы сразу перейдем к элементу в массиве и будет O(1) как и в хэш-таблице. Индекс это же альтернатива ключу в хэш-таблице
@@Xname00 поэтому нихуя и не понятно - нахуя хэш-таблицы, если можно юзать обычные массивы -- доступ по ключу равен доступу по индексу. Жопой чую, что тут извечная дилемма по выбору "память-vs-процессор", но автор в видосе это не затронул.
@@Xname00 В том же и суть, что при поиске вы не знаете наличествует ли элемент в массиве/хэше, так о каком индексе речь? При поиске подразумевается не доступ (access), а конструкция типа "if something in array", в этом случае в массиве нужно будет перебирать каждый элемент до тех пор, пока "something" не будет найден, что в худшем случае и будет O(n). В хэшиках элемент вытаскивается сразу без этой беготни.
@@TheUnderLike почти все правда, но если трогать биг О то можно понять, что поиск в HshTable это 0(N) так же как и в массиве из за колизий. А мы программисты как наверное знаешь выбираем надеямся на самый наихудший вариант.
невсегда при заполнение HashTable обычно это на 70%, то HashTable пересоздается с увеличиной длиной в 2 раза как правило.Поэтому по Big O это будет 0(N)-вставка. Да конечно можно сказать что HashTable не заполнен и тд. Но в Big O всегда выбирают самый хужший вариант.Так же как с поиском и удаление все это 0(N) но в среднем да 0(1).
Невероятный кладезь знаний за 10 минут. Если бы меня спросили как понять такие сложные штуки, то я бы, не думая, ткнул пальцем в канал Winderton. Спасибо, мужчина)
Массив быстрее хеш таблицы в случае поиска/замены так как арифметика указателей быстрее хеш функции Но если нужно удалить/добавить элемент то в случае с массивом нужно найти !неприрывную! область в памяти размером {старый массив+новый/новые элементы}, скопировать всё старое и добавить новое и только потом удалить из памяти старый массив весь этот процесс на словах долгих, а не только на деле Хеш таблица же таким не страдает и память выделяется только на новый объект который будет добавлен, а всё старое остаётся на месте Например тот же вектор в с++ частично решает проблему со вставкой, но только в конец и до того момента пока не понадобится амортизация
Ответ на вопрос в конце ролика. Хэш-таблицы могут быть быстрее массивов в двух случаях: 1. Когда известно только значение которое необходимо найти. В случае массива придется перебирать весь массив в случае с мапой ключом будет являться само значение пропущенное через хэш-функцию. 2. Массив хранит в себе сам объект а мапа указатель на память где лежит объект. Соответственно при условии что объекты могут динамически изменять свой размер массив будет требовать переаллокации памяти и переноса себя в эту память что довольно медленно а мапа нет. Возможно есть еще какие то кейсы но сходу в голову пришли эти.
У классического массива, доступ к памяти, осуществляется как: + * size_of(), Если значение функции size_of() не является константой для данного типа, то создать классический массив, из этих элементов невозможно. Переменные(объекты/структуры) чей размер нельзя определить на этапе компиляции - всегда хранятся в куче. Массив из таких элементов всегда будет массивом из указателей. (Даже если сам массив тоже хранится в куче и доступен по указателю). Поэтому второй ваш пример, мне кажется не состоятельным.
В Python dict был неупорядоченным до версии 3.6, для упорядоченного существовал OrderedDict(). Затем dict стал упорядоченным, при этом он остался хеш-таблицей, в итоге теперь в Python две реализации упорядоченного словаря)
Да только упорядоченность дерева подразумевает упорядоченность по значению, а OrderedDict это упорядоченность по времени вставки. Иногда бывает полезно и то и другое, но все же упорядоченность по значению более полезная штука. Например если у тебя ордеред сет в виде дерева то ты можешь искать upper/lower bound за логарифмическое время что покрывает очень большой класс задач. Ордеред дикт по факту совмещает две структуры и в этом плане не совсем уже чистая хэшмапа
Привет чумваки, через два месяца упорного бодания рогами в землю, я пробил этот кокон и понял что дойду до конца и все уже стало понятным и логичным. Если вдруг у вас начался кризис обучения и вы хотите бросить, может быть вы прочтете и это придаст вам сил. Не опускай руки, бро!
о кто то поставил лайк, а после нг праздников так и не сел обратно, но всё ещё знаю что могу, новое видео Виндерпуфена смотрю и оно придаёт мотивации. Всем йоу!
@@kamenyFX все ещё нет, но тут случились обстоятельства после которых приходится работать по 10-12 часов в день. Это серьезно замедляет. Но так будет только до конца месяца. Но я после того как раскидаю долг уже пойду по собесам, такие вот дела.
Очень полезная инфа. От души. Единственное замечание. Почему вставка и удаление из сбалансированных деревьев - это O(log(n)). Может больше? А как же дополнительные операции на перебалансировку дерева? Так называемые вращения (rotations)
скорее всего на русскоязычном сегменте, ты первый кто будет объяснять это для "чайников". Я только начал учиться, но благо тебе есть "неусталость" обучению. TY❣
Блин я прошёл эту тему на курсе Пайтон, то что ты рассказываешь, вообще нифига не понятно, для других программистов со стажем 5 лет может всё ясно. Для новичков всё быстро сумбурно как то. На других канал даже более сложные темы умудряются рассказать, что всё понятно, тут даже такую простую тему с выносом мозга.
Понимание линейних массивов тоже очень важно. Везде где можно скешировать и проитерироваться, очевидно лучше соблюдать линейность, нежели таблицу или слинкованные структуры данних. А вообще, лучше изучать и практиковать разные структуры и самому тоже делать (без использования стандарта std или boost)
В питоне до 3.7 dict был беспорядочный. В 3.7 его упорядочили (ради оптимизации памяти немного переработали dict, упорядочивание вышло просто полезным плюсом).
А потом возникают вопросы: *"Какого хрена такой низкий ФПС?!"* или *"Откуда такие сумасшедшие мин требования?!"* или *"Почему такая УЙНЯ занимает NN гигабайт?!"
Потому что вычисление хэша это константа, а она в нотации большого О не учитывается. Большое О говорит о том, как увеличивается сложность в зависимости от количества данных, поэтому там константа не важна. Действительно, реальная производительность у массива может быть выше на всех операциях при малом размере данных, когда эффект константы больше, чем вклад увеличения сложности.
6:36 С какого это лысого O(1), если нужно пролистать по структуре до попадания на нужный хэш? Мы не адрес всё-таки там храним. Сразу нужно понимать, что структура с абстрактным множеством эл-тов не будет выдавать такие низкие сложности.
@@Ilya-kondakov подумал, что возможно в данном случае и не в чем, а мысль в голове просто засела с курса "математические методы защиты информации", где в криптографии связано со сложностью обнаружения
Контент годный, объяснение самобытное, чёткое, понятное. Вообще канал классный. А вот запомоиться об остопи3девшую всему интернету Скулль-FUСК-тори - это позор. Лучше бы казино какое рекламировал, чем этих вонючих лохотронщиков (они сами признались, что львиная доля бюджета у них идёт на рекламу - скупили почти всех блогеров-проституток - даже Гоблин не устоял, продал свою жопку и честное имя за пачку баксов).
Если грубо переложить на русский unorder set= aн' оодэд cэт или эн' оодэд сет. Видишь, Р отсутствует. Не надо благодарности, это в качестве бл. за твой контент :) Я вижу старание есть, но мисс прононс всетаки есть. По береги наши уши плз :)
достаточно важный момент для понимания упущен, который объясняет, почему поиск элемента константен по времени. речь про сведение хэша к индексу итогового массива
гений на челе смог мне объяснить мне принцип работы этой структуры... прошел универ, но так и не понимал, как работают словари и причем тут хеш)) спасибо
Вот вы говорите что в Хеш таблицах переход происходит по индексу? Если массив с Int индексами, то теоретически переход происходит к элементу методом умножения к адресу, где непрерывно находятся данные. Но если Хеш это некая сумма элементов (символов) то как происходит "мгновенный" переход? :) Ведь всё в итоге компилится в ассемблер и код. И как бы не очень понятно как без "тупого" перебора таких хеш индексов происходит поиск нужных данных? Или я что-то пропустил? ;)
Задача в том, чтобы найти индекс по значению. Поиск перебором это простой проход по массиву/списку и сравнение каждого элемента О(N). Очевидно, это не касается деревьев и сортированных массивов (где есть бинарный поиск), O(log n). В хэш-таблице индекс получается из значения вызовом хэш-функции. Соответственно проверяется малое количество элементов (те, у которых совпало значение хэш-функции), O(1).
НАЧАЛ УЧИТЬ ХЭШТЭЙБЛ, В ИТОГЕ ВЫУЧИЛ СВЯЗНЫЙ СПИСОК, МАССИВ, СЕТ, МАП, И ДЕРЕВЬЯ....
Топчик
ГОУ видосик про декомпозицию предметной области😊
Спасибо за годный контент, а в чем если не секрет, ты монтируешь и делаешь графику?
Такой же путь прошел)
я вот не понял что происходит, слова знакомые что для чего не понятно
можно еще быстрее говорить? ну и мужиков не надо, а так лойс поставлен)
А где комментарии? Ладно, тогда распишу че хочу. Вариант ответа на вопрос в конце: когда известен ключ и не надо перебирать все возможные варианты, что бы найти один единственный. Видос полезный, но надо будет еще утром посмотреть, а то всё забуду. И хотелось бы попросить рассказать про деревья. Бинарные, черно-белые и т.д. Смотрел в интернете - нудно, много воды и надо прям вчитываться в каждую букву что бы понять. Вроде всё. За видосы +реп ❤
Ответ на вопрос в конце
1)Хэш-таблицы, работают быстрее при поиске элементов, в массивах нужно перебрать все элементы, чтобы найти тот самый, в то время как в хэш-таблице вы переходите непосредственно к элементу.
2)Вставка элемента выполняется быстрее в хэш-таблицах, так как вы просто хешируете ключ и вставляете его; в массивах важно сначала переместить элементы, прежде чем вставлять еще один.
Про первое, если у нас есть индекс, то мы сразу перейдем к элементу в массиве и будет O(1) как и в хэш-таблице. Индекс это же альтернатива ключу в хэш-таблице
@@Xname00 поэтому нихуя и не понятно - нахуя хэш-таблицы, если можно юзать обычные массивы -- доступ по ключу равен доступу по индексу. Жопой чую, что тут извечная дилемма по выбору "память-vs-процессор", но автор в видосе это не затронул.
@@Xname00 В том же и суть, что при поиске вы не знаете наличествует ли элемент в массиве/хэше, так о каком индексе речь? При поиске подразумевается не доступ (access), а конструкция типа "if something in array", в этом случае в массиве нужно будет перебирать каждый элемент до тех пор, пока "something" не будет найден, что в худшем случае и будет O(n). В хэшиках элемент вытаскивается сразу без этой беготни.
@@TheUnderLike почти все правда, но если трогать биг О то можно понять, что поиск в HshTable это 0(N) так же как и в массиве из за колизий. А мы программисты как наверное знаешь выбираем надеямся на самый наихудший вариант.
невсегда при заполнение HashTable обычно это на 70%, то HashTable пересоздается с увеличиной длиной в 2 раза как правило.Поэтому по Big O это будет 0(N)-вставка. Да конечно можно сказать что HashTable не заполнен и тд. Но в Big O всегда выбирают самый хужший вариант.Так же как с поиском и удаление все это 0(N) но в среднем да 0(1).
"А вот С++ .... сделал строки неизменяемыми" - это ошибка.`std::string` имеет изменяемый контент, как и область памяти, на которую указывает `char *`
Думаю он имел ввиду const char*
dict в python это хештаблица с двойным хешированием, сохранение порядка вставки поддерживается особенностями реализации, а не мапой
Питон лоховской язык
@@имяфамилия-т3ж1ц адепты js подъехали
@@имяфамилия-т3ж1ц😂😂😂 absolution верно
@@имяфамилия-т3ж1цчто ещё расскажешь?
@@имяфамилия-т3ж1ц уроки сделал?)
Больше видосов по алгоритмам и структурам данных и ещё сними видос где ты решаешь задачи на литкоде с объяснениеми для чайников
Донат скинь
И в сообщении попроси
Полезно всё, что ты делаешь! Из этого складывается собственная логика и понимание ,как в это влиться🎓🧠👁
Невероятный кладезь знаний за 10 минут. Если бы меня спросили как понять такие сложные штуки, то я бы, не думая, ткнул пальцем в канал Winderton. Спасибо, мужчина)
Массив быстрее хеш таблицы в случае поиска/замены так как арифметика указателей быстрее хеш функции
Но если нужно удалить/добавить элемент то в случае с массивом нужно найти !неприрывную! область в памяти размером {старый массив+новый/новые элементы}, скопировать всё старое и добавить новое и только потом удалить из памяти старый массив весь этот процесс на словах долгих, а не только на деле
Хеш таблица же таким не страдает и память выделяется только на новый объект который будет добавлен, а всё старое остаётся на месте
Например тот же вектор в с++ частично решает проблему со вставкой, но только в конец и до того момента пока не понадобится амортизация
Спасибо. Отличный ликбез. Хотелось бы послушать про красночерное дерево
нет, dict в Python это тоже хеш-мапа, не RB-tree
Ответ на вопрос в конце ролика. Хэш-таблицы могут быть быстрее массивов в двух случаях: 1. Когда известно только значение которое необходимо найти. В случае массива придется перебирать весь массив в случае с мапой ключом будет являться само значение пропущенное через хэш-функцию. 2. Массив хранит в себе сам объект а мапа указатель на память где лежит объект. Соответственно при условии что объекты могут динамически изменять свой размер массив будет требовать переаллокации памяти и переноса себя в эту память что довольно медленно а мапа нет. Возможно есть еще какие то кейсы но сходу в голову пришли эти.
У классического массива, доступ к памяти, осуществляется как: + * size_of(),
Если значение функции size_of() не является константой для данного типа, то создать классический массив, из этих элементов невозможно. Переменные(объекты/структуры) чей размер нельзя определить на этапе компиляции - всегда хранятся в куче. Массив из таких элементов всегда будет массивом из указателей. (Даже если сам массив тоже хранится в куче и доступен по указателю).
Поэтому второй ваш пример, мне кажется не состоятельным.
В Python dict был неупорядоченным до версии 3.6, для упорядоченного существовал OrderedDict().
Затем dict стал упорядоченным, при этом он остался хеш-таблицей, в итоге теперь в Python две реализации упорядоченного словаря)
Да только упорядоченность дерева подразумевает упорядоченность по значению, а OrderedDict это упорядоченность по времени вставки. Иногда бывает полезно и то и другое, но все же упорядоченность по значению более полезная штука. Например если у тебя ордеред сет в виде дерева то ты можешь искать upper/lower bound за логарифмическое время что покрывает очень большой класс задач. Ордеред дикт по факту совмещает две структуры и в этом плане не совсем уже чистая хэшмапа
Привет чумваки, через два месяца упорного бодания рогами в землю, я пробил этот кокон и понял что дойду до конца и все уже стало понятным и логичным. Если вдруг у вас начался кризис обучения и вы хотите бросить, может быть вы прочтете и это придаст вам сил. Не опускай руки, бро!
о кто то поставил лайк, а после нг праздников так и не сел обратно, но всё ещё знаю что могу, новое видео Виндерпуфена смотрю и оно придаёт мотивации. Всем йоу!
Ну что там? пол года прошло, добился успеха?
@@kamenyFX все ещё нет, но тут случились обстоятельства после которых приходится работать по 10-12 часов в день. Это серьезно замедляет. Но так будет только до конца месяца. Но я после того как раскидаю долг уже пойду по собесам, такие вот дела.
@@staffa_kar_terma Харош, удачи
Требуем адское мессиво на 10 часов по плюсам
Очень полезная инфа. От души. Единственное замечание. Почему вставка и удаление из сбалансированных деревьев - это O(log(n)). Может больше? А как же дополнительные операции на перебалансировку дерева? Так называемые вращения (rotations)
в С++ строки изменяемые
В с++ можно так:
using namespace std;
unordered_map data {
{"Ivan",1},
{"John",2}
}
Вот это контеент!😂🎉
Я присоединяюсь к требованию десятичасового курса по плюсам !❤
Как раз думал, где видосы, как раз дропнул. Тупо сказка перед сном)
Боже как долго я тебя искал, ты шикарен 😍😍😍 хз кто еще так может информативно рассказывать
скорее всего на русскоязычном сегменте, ты первый кто будет объяснять это для "чайников". Я только начал учиться, но благо тебе есть "неусталость" обучению. TY❣
А смысл? Ведь этого будет недостаточно, однако ты рано или поздно дойдешь до них и изучишь уже на более глубоком уровне сам.
Я думаю автору видео очень понравится Кложура.
C++ string изменяемый.
Хорош хорош братан, давай ещё! Можно такого побольше?
Как говорят мудрецы, если завис с задачей, то брось на нее хеш таблицу и все будет шикарно.
А лучше положи на нее хрен😂
Блин я прошёл эту тему на курсе Пайтон, то что ты рассказываешь, вообще нифига не понятно, для других программистов со стажем 5 лет может всё ясно. Для новичков всё быстро сумбурно как то. На других канал даже более сложные темы умудряются рассказать, что всё понятно, тут даже такую простую тему с выносом мозга.
Спасибо за видос. Непонятно, конечно, но очень интересно =)
Может чуть помедленней стоит, обдумывать не успеваю что ты рассказываешь) А так спасибо, интересный материал, однозначно лайк
зависит от матриала и твоих знаний - я некоторые наборот побыстрее включаю
5:35 в питоне это тоже хеш таблица. Для упорядоченной таблицы есть ordereddict.
Мне понравилось, интересно смотреть. Но это первое видео в моей жизни которое я замедлял, до 0.75. Речь изначально ускорена?
Ты лучший, продолжай свои уроки!!!❤❤❤
Восхищаюсь этим человеком. И его смотрят такие же свехнутые люди, кто любит компы и хочет понимать их лучше.😂 А уже потом кодеры.
Реально годные видосы, очень быстро и по делу,продолжай так же
Понимание линейних массивов тоже очень важно. Везде где можно скешировать и проитерироваться, очевидно лучше соблюдать линейность, нежели таблицу или слинкованные структуры данних.
А вообще, лучше изучать и практиковать разные структуры и самому тоже делать (без использования стандарта std или boost)
1:33 1:35 1:35 1:36 1:36 1:37 1:37 1:38 1:39 1:39 1:40 1:40 1:40
Неизменяемые строки в C++? Расскажите, будьте добры, если я чего-то не знаю...
В питоне до 3.7 dict был беспорядочный. В 3.7 его упорядочили (ради оптимизации памяти немного переработали dict, упорядочивание вышло просто полезным плюсом).
Э, в смысле Удзумаки 10, там все 100 должно быть!
А видео четкое:)
А потом возникают вопросы:
*"Какого хрена такой низкий ФПС?!"*
или
*"Откуда такие сумасшедшие мин требования?!"*
или
*"Почему такая УЙНЯ занимает NN гигабайт?!"
нужно чуть больше комментариев про O(1), почему не учитывается время вычисления хэш-функции?
Потому что вычисление хэша это константа, а она в нотации большого О не учитывается. Большое О говорит о том, как увеличивается сложность в зависимости от количества данных, поэтому там константа не важна. Действительно, реальная производительность у массива может быть выше на всех операциях при малом размере данных, когда эффект константы больше, чем вклад увеличения сложности.
@@KoMedVed только хэш от строки например не константа 🤔в питоне удобно там все хэши заранее вычислены)
@@tonybard Не знаю как в питоне, но в java строки неизменяемые и хэш считается 1 раз - при создании
@@KoMedVed также, но в плюсах не так)
Найс. Как всегда база на языке народа. Красавчик 🎉
бомба бро, супер базированная база, мб попробую использовать вместо векторов
Лучший канал по айти
офигенский материал, супер
Отлично рассказываешь, думаю нужно больше такого контента)
4:15 В первый момент подумал, что это Гарольд из мема :)
Спасибо. Нравится, что без воды.
2:22 в плюсах строки изменяемые
В стандарте да. Если использовать std::string.
Возможно он имел ввиду const char*
@@cheerwizard21 Согласен, но, например, char* - тоже строка, и она вполне изменяемая)
ответ на вопрос: при поиске {"one":1,"two":2} искать по ключу "two" будет быстрее чем искать 2 в массиве [1,2]. если я правильно пончл вопрос..
Спасибо!
при поиске и вставки элементов, это лучше всего сочетается в большом объёме данных или когда тебе по ключу что либо найти надо, вооот...
dict в python реализован с помощью хэш-таблицы, а не дерева
Во всех случаях, где больше 1 элемента, хэш таблица быстрее массива
Саурон был бы в восторге от массивов в PHP.
Вы как то говорили про обучение? Где можно посмотреть информацию об этом??
JS бы еще в примеры добавить...
Dude you ain't talking about quantum physics, it feels like this guy wants to sell you that it's a hard concept. Lol, it's not.
Но ведь часто нужно хранить сортированные данные, для поиска по больше, меньше, ренжам, префиксам.
Так что далеко не всё хэшмапа покрывает.
чел просто подогрел аудиторию и дал ссылки на рефы 🤡🤡🤡🤡🤡💩💩💩💩.
А если серьезно, то ничего плохого в этом нет. Но инфа по-любому полезная. Спасибо
Медленно говоришь, можно еще быстрее?
Шикарный материал 👍👍👍
6:36 С какого это лысого O(1), если нужно пролистать по структуре до попадания на нужный хэш? Мы не адрес всё-таки там храним. Сразу нужно понимать, что структура с абстрактным множеством эл-тов не будет выдавать такие низкие сложности.
хэшмапа это просто массив, где посчитанный хеш является индексом, по которому хранится значение.
Поиск в массиве по индексу происходит за О(1).
Годный контент 🎉
0:42 ну кто ж берет остаток от деления на 10? Вся эта история гораздо лучше работает в кольцах вычетов, где основание - простое число
а в чем разница...
@@Ilya-kondakov подумал, что возможно в данном случае и не в чем, а мысль в голове просто засела с курса "математические методы защиты информации", где в криптографии связано со сложностью обнаружения
Интересно, но пока непонятно. Язык на котором пишу (Autoit) знает только про массивы. Ничего лишнего)
Только благодарность!
Написал недавно мапу, сет и мультисет шаблонные) почему я не посмотрел это видео до?)
Все круто, но Juniorу работу хрен найдёшь. А так да, объявления есть 🙂
Уточнение. В c++ строки изменяемые 2:23 .
Контент годный, объяснение самобытное, чёткое, понятное. Вообще канал классный. А вот запомоиться об остопи3девшую всему интернету Скулль-FUСК-тори - это позор. Лучше бы казино какое рекламировал, чем этих вонючих лохотронщиков (они сами признались, что львиная доля бюджета у них идёт на рекламу - скупили почти всех блогеров-проституток - даже Гоблин не устоял, продал свою жопку и честное имя за пачку баксов).
было очень интересно
Если грубо переложить на русский unorder set= aн' оодэд cэт или эн' оодэд сет. Видишь, Р отсутствует. Не надо благодарности, это в качестве бл. за твой контент :)
Я вижу старание есть, но мисс прононс всетаки есть. По береги наши уши плз :)
Гениально
достаточно важный момент для понимания упущен, который объясняет, почему поиск элемента константен по времени. речь про сведение хэша к индексу итогового массива
8:52 - ни добавить, ни убавить. Квинтесенция.
Жду ролик на 10 часов по плюсам
гений на челе смог мне объяснить мне принцип работы этой структуры... прошел универ, но так и не понимал, как работают словари и причем тут хеш)) спасибо
В питоне хэш мама, по крайней мере взятие элемента и проверка делаются за константу точно
Lua: смотрите, как они извращаются, чтобы достичь 1% моей силы!
Выдал базу ;)
А есть видео, где вы рассказываете о том как перешли от джава к с++?
вот уж что-что, а таблицы стоило бы на Lua объяснять
Вот вы говорите что в Хеш таблицах переход происходит по индексу?
Если массив с Int индексами, то теоретически переход происходит к элементу методом умножения к адресу, где непрерывно находятся данные.
Но если Хеш это некая сумма элементов (символов) то как происходит "мгновенный" переход? :)
Ведь всё в итоге компилится в ассемблер и код.
И как бы не очень понятно как без "тупого" перебора таких хеш индексов происходит поиск нужных данных?
Или я что-то пропустил? ;)
Задача в том, чтобы найти индекс по значению. Поиск перебором это простой проход по массиву/списку и сравнение каждого элемента О(N). Очевидно, это не касается деревьев и сортированных массивов (где есть бинарный поиск), O(log n). В хэш-таблице индекс получается из значения вызовом хэш-функции. Соответственно проверяется малое количество элементов (те, у которых совпало значение хэш-функции), O(1).
Как это строки в плюсах неизменяемые
Мужик, это всё хорошо, но когда будет стрим по С++, ну или по написанию Компилятора, очень ждём
а что скажешь про разоблачения от black sun?
виндертон, удачи тебе, счастья, зайка моя любимая
А почему комментариев нет? Давайте поддержите молодого программиста
В python dict реализован с использованием структуры данных hash table
dict стал ordered начиная с python 3.7, до этого был unordered
Супер база
Полезный контент, автор достойно доступным языком всё разжевал👍
Осталось объяснить, что такое монада
"абстрактные типЫ данных..." 🙂
с недавнего питона словарь у него стал упорядоченным
йо, очень крутой видос! хотелось бы послушать про деревья и алгоритмы к ним
👍🏻👍🏻👍🏻👍🏻в поддержку, пока не учу плюсы, но попал в реки и в будущем буду смотреть твои видосы. Лайк, подписка)
Годнота!
изучая хештейбл познал основы мироздания
Можешь дать какие-то статьи или видео, а не книжки, пожалуйста