Size: a a a

2021 June 27

MB

Mikail Bagishov in pro.algorithms
Я вот такой алгоритм предлагал.
Если емейл есть у нескольких юзеров, то он ничего не будет перезаписывать.

> В конце просто переложи это в мапу, где ключ - юзер, а значение - список адресов.
По-моему я такого не писал. Если и писал, то это наверное ошибка. Мапы из емейлов в списки юзеров должно быть достаточно.
источник

ГР

Геннадий Романов... in pro.algorithms
это для общего случая n пользователей по m email на входе
источник

MB

Mikail Bagishov in pro.algorithms
Ну, мы просто немного по-разному смотрим на вход.

Ты говоришь, что на входе есть штуки вида
user1 -> a@a, b@b, c@c
а я смотрю на это как на
user1 -> a@a
user1 -> b@b
user1 -> c@c

это эквивалетные взгляды.

В твоем варианте внешний цикл будет выглядеть как два:
for user in input {
   for email in user.emails {
        ...
   }
}
источник

K

Kelbon in pro.algorithms
ну тут я в твоем стиле замечу, что у пользователей может быть разное количество email у каждого, а не только m
источник

ГР

Геннадий Романов... in pro.algorithms
да но в худшем случае по m
источник

K

Kelbon in pro.algorithms
какой же это худший случай, если они все одинаковые, так легче..
источник

MB

Mikail Bagishov in pro.algorithms
Да не важно, все равно алгоритм с хэш-таблицей работает за линию от размера входа
источник

ГР

Геннадий Романов... in pro.algorithms
да, я просто втыкаю в алгоритм в общем случае
источник

ГР

Геннадий Романов... in pro.algorithms
втыкнул, переложили в  хэштаблицу с мейлами и списком юзеров
дальше?
источник

MB

Mikail Bagishov in pro.algorithms
Как я уже говорил(https://t.me/proalgorithms/92761): заводим граф, в котором каждая вершина соответствует юзеру.
Далее для каждого емейла чекаем в хэш-таблице, у каких юзеров u_1, ..., u_k есть этот емейл.

после этого проводим ребра u_1 <-> u_2, ..., u_k-1 <-> u_k.

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

ГР

Геннадий Романов... in pro.algorithms
получили HashTable<email, List<user»
источник

MB

Mikail Bagishov in pro.algorithms
Да, потом по нему строим список ребер для графа
источник

ГР

Геннадий Романов... in pro.algorithms
а как это в коде?
источник

MB

Mikail Bagishov in pro.algorithms
for email, users in table {
    for i in 0..len(users)-1 {
        add_edge(users[i], users[i+1])
    }
}
источник

ГР

Геннадий Романов... in pro.algorithms
млин в джаве таких классов и функций нет, есть просто hashMap, Vektor,
hashTable
источник

MB

Mikail Bagishov in pro.algorithms
Да это псевдокод. Я не знаю джаву, поэтому не могу сказать какие конкретно методы там надо использовать
источник

MB

Mikail Bagishov in pro.algorithms
Если тебе непонятно, что делает этот псевдокод - обязательно спрашивай.

Если понятно, то тебе уже нужна документация по стандартной библиотеке джавы
источник

K

Kotomord_λapki in pro.algorithms
А можно стартовую задачу?
источник

ГР

Геннадий Романов... in pro.algorithms
непонятно
получили HashTable<email, List<user»,
как нам добавить компоненты связности на деле?
источник

ГР

Геннадий Романов... in pro.algorithms
Имеется n пользователей, каждому из них соответствует список email-ов (всего у всех пользователей m email-ов).
Например:
user1 -> xxx@ya.ru, foo@gmail.com, lol@mail.ru
user2 -> foo@gmail.com, ups@pisem.net
user3 -> xyz@pisem.net, vasya@pupkin.com
user4 -> ups@pisem.net, aaa@bbb.ru
user5 -> xyz@pisem.net
Считается, что если у двух пользователей есть общий email, значит это один и тот же пользователь. Требуется построить
и реализовать алгоритм, выполняющий слияние пользователей.
Требуется, чтобы асимптотическое время работы полученного решения было линейным, или близким к линейному.
источник