Ровно по 4 плюса твоим репликам и по 4 минуса в абсолютно все реплики твоим оппонентам во всех твоих ветках
В этом после у меня 0 комментариев, которые бы имели 4 плюса и здесь есть только два твоих комменатрия с 4 минусам. В них ты общаешься как хамло и дурачок, за что, видимо, тебе минусы и влепили. Но это не главное, сам факт того, что ты сидишь и подчитываешь кто и сколько плюсанул твои комментарии и твоего оппонента, да еще и какие-то конспирологические теории строишь, говорит о том, что у тебя какие-то серьзные проблемы, какая-то прям беда. Ты бы к специалисту обратился за помощью или хотя бы на улицу наконец вышел, траву потрогал, на солнышко посмотрел. Удачи.
Я соглашусь что конкретно эта задача не самая лучшая. Так же как например поиск цикла в связанном списке https://leetcode.com/problems/linked-list-cycle/ Мне порой сложно оценивать, потому что у меня в универе все это было еще на первых курсах, но наличие нескольких не самых хороших задач не опровергают сам метод, это остается на совести собеседующего.
Не знаю, скорее всего, вопрос только во времени. Как минимум как наивное решение, которое сразу в голову приходит, это радиальная сортировка и прямой поиск - алгоритм будет иметь линейное время. Но наверное есть решение и получше, раз вы про Pigeonhole sort пишите.
Так в этом и есть часть измерения. Вот смотрите - одному человеку чтобы научиться базовой игре на гитаре 3 аккордами нужен день, а другом неделя. И не смотря на одинаковый конечный результат, мы можем сделать вывод что у первому изначально лучше музыкальные способности. Так и тут - да, у одно человека нахождение решения займет 40 минут, а у другого несколько часов, люди не одинаковые, именно это тест и показывает.
на хабре буквально был пост от сотрудника гугла, который объясняет зачем они дают алгоритмы на собеседовании, почитайте - https://habr.com/ru/articles/779512/
не знаю как у вас это происходит, но обычно у человека решение задачи не происходит как "пустота-пустота-о, догадался и решил". Человек рассуждает, анализирует, пробует один подход, другой, исправляет свою ошибку - именно это и хочется увидеть, это те навыки, которые используются про программировании. Конечно это не нужно во всех компаниях, есть проекты, где надо просто клепать crud, а любой вопрос решает копированием ответа со стек оверфлоу - в этом случае да, процесс поиска надо строить по-другому.
Он и не должен, собеседование это не экзамен в школе - оценивается как вы будете искать решение, насколько сложно вам будет делать логические переходы, сколько времени у вас это займет.
Потому что задача на органический синтез проверяет ваш crystallized intelligence, насколько хорошо вы можете запомнить и повторить информацию. А алгоритмическая задача проверяет ваш fluid intelligence, насколько вы хорошо можете найти решение незнакомой для вас задачи, используя логику, умение находить паттерны и скорость мышления. Заучивание алгоритмов от вас не требуется, более того, если собеседующий видит что вы данную задачу уже знаете как решать("это я помню, тут надо в стек все сложить"), то он сменит задание или добавит условия, чтобы задача была для вас не знакомой.
Причем тут писать и читать? Какая еще "черепомерка"? Почитайте что такое G-Factor, что такое fluid intelligence и чем он отличается от crystallized intelligence и заодно что такое шкала бине и как из нее был разработан тест IQ. Почитайте хоть что-нибудь по данной теме и тогда вы сами поймете что показывает умение решать незнакомые алгоритмические задачи и почему данный вид тестов активно используется в процесса отбора в крупных ΙΤ компаниях.
Никакой не нужно развивать. Алгособесы это буквально тестирование вашего умение решать незнакомые задачи, что зависит от ваших природных качеств. Примерно в той же плоскости что тест IQ.
Даже не смотря на пару уровней индирекции это всё равно может быть быстрее голых Element в векторе.
Индирекции в общем случае будут медленее, так как соседние элементы банально могут не обладать пространственной когерентностью и даже могут быть на разных страницах. А вы приводите зачем-то узкий случай оптимизации под конкретный алгоритм, "If your access pattern does not require blind iteration (which can be the case for flattened, index-based tree structures)", при том что в исходном коде буквально делается итерация по всему вектору: document.elements.iter()Так что спешу поставить под сомнение(с) ваши советы запихивать все в Вox<dyn Element> , хотя использовать профайл дело вполне полезное.
В таком подходе тип элементов описывается в трех местах, что во-первых требует больше времени для добавления нового типа, а во-вторых отсуствует статическая проверка типизации - при match element.element_type() нет никакой гарантии компилятора что там будет действительно лежать нужный тип при даункасте. Плюс Vec<Box<dyn Element>> не эффективная по перфомансу, будет постоянный кэш мисс и эвристики подгрузки не работают.
Может быть лучше попробовать, как первое решение, просто алгебраческий тип:
pub enum Element<'a> {
Header { level: u8, /* todo */ },
Paragraph { child: &'a Element<'a> },
...
}
и Vec<Element>
Еще все элементы создаются в куче с динамик трейтами вместо статического полиморфизма, а конструктуры объявлены через Result, хотя ошибку они никогда не кидают. Например
Надеюсь это не будет звучать грубо, но такое решение сильно похоже на попытку использовать ссылочный объектно-ориентированый подход как в java/.net , что смотрится несколько неорганично в расте.
Потому что сложность апроксимируется сверху линейной функцией.
Если мы получаем от словаря ссылку на структуру и потом работаем по ссылке, то чем, собственно говоря, это отличается от класса?В таком сценарии скорее всего все данные сразу попаду на кэш-линию, по-этому код будет работать быстрее.
Ровно по 4 плюса твоим репликам и по 4 минуса в абсолютно все реплики твоим оппонентам во всех твоих веткахВ этом после у меня 0 комментариев, которые бы имели 4 плюса и здесь есть только два твоих комменатрия с 4 минусам. В них ты общаешься как хамло и дурачок, за что, видимо, тебе минусы и влепили. Но это не главное, сам факт того, что ты сидишь и подчитываешь кто и сколько плюсанул твои комментарии и твоего оппонента, да еще и какие-то конспирологические теории строишь, говорит о том, что у тебя какие-то серьзные проблемы, какая-то прям беда. Ты бы к специалисту обратился за помощью или хотя бы на улицу наконец вышел, траву потрогал, на солнышко посмотрел. Удачи.
Я, кажется, понял почему ты так против теста ΙQ.
Я бы еще derive_more упомянул, сильно уменьшает boilerplate код. А для базы по мне sqlx лучше, генерация sql это неоднозначное решение.
Я соглашусь что конкретно эта задача не самая лучшая. Так же как например поиск цикла в связанном списке https://leetcode.com/problems/linked-list-cycle/ Мне порой сложно оценивать, потому что у меня в универе все это было еще на первых курсах, но наличие нескольких не самых хороших задач не опровергают сам метод, это остается на совести собеседующего.
Решили бы вы такую задачу?Не знаю, скорее всего, вопрос только во времени. Как минимум как наивное решение, которое сразу в голову приходит, это радиальная сортировка и прямой поиск - алгоритм будет иметь линейное время. Но наверное есть решение и получше, раз вы про Pigeonhole sort пишите.
Так в этом и есть часть измерения. Вот смотрите - одному человеку чтобы научиться базовой игре на гитаре 3 аккордами нужен день, а другом неделя. И не смотря на одинаковый конечный результат, мы можем сделать вывод что у первому изначально лучше музыкальные способности. Так и тут - да, у одно человека нахождение решения займет 40 минут, а у другого несколько часов, люди не одинаковые, именно это тест и показывает.
на хабре буквально был пост от сотрудника гугла, который объясняет зачем они дают алгоритмы на собеседовании, почитайте - https://habr.com/ru/articles/779512/
не знаю как у вас это происходит, но обычно у человека решение задачи не происходит как "пустота-пустота-о, догадался и решил". Человек рассуждает, анализирует, пробует один подход, другой, исправляет свою ошибку - именно это и хочется увидеть, это те навыки, которые используются про программировании. Конечно это не нужно во всех компаниях, есть проекты, где надо просто клепать crud, а любой вопрос решает копированием ответа со стек оверфлоу - в этом случае да, процесс поиска надо строить по-другому.
а IQ-тест и вся вышеперечисленная лабуда себя скомпрометировали задолго до конца прошлого векаШариков.jpeg
Он и не должен, собеседование это не экзамен в школе - оценивается как вы будете искать решение, насколько сложно вам будет делать логические переходы, сколько времени у вас это займет.
Потому что задача на органический синтез проверяет ваш crystallized intelligence, насколько хорошо вы можете запомнить и повторить информацию. А алгоритмическая задача проверяет ваш fluid intelligence, насколько вы хорошо можете найти решение незнакомой для вас задачи, используя логику, умение находить паттерны и скорость мышления. Заучивание алгоритмов от вас не требуется, более того, если собеседующий видит что вы данную задачу уже знаете как решать("это я помню, тут надо в стек все сложить"), то он сменит задание или добавит условия, чтобы задача была для вас не знакомой.
Причем тут писать и читать? Какая еще "черепомерка"? Почитайте что такое G-Factor, что такое fluid intelligence и чем он отличается от crystallized intelligence и заодно что такое шкала бине и как из нее был разработан тест IQ. Почитайте хоть что-нибудь по данной теме и тогда вы сами поймете что показывает умение решать незнакомые алгоритмические задачи и почему данный вид тестов активно используется в процесса отбора в крупных ΙΤ компаниях.
Никакой не нужно развивать. Алгособесы это буквально тестирование вашего умение решать незнакомые задачи, что зависит от ваших природных качеств. Примерно в той же плоскости что тест IQ.
Даже не смотря на пару уровней индирекции это всё равно может быть быстрее голых Element в векторе.Индирекции в общем случае будут медленее, так как соседние элементы банально могут не обладать пространственной когерентностью и даже могут быть на разных страницах. А вы приводите зачем-то узкий случай оптимизации под конкретный алгоритм, "If your access pattern does not require blind iteration (which can be the case for flattened, index-based tree structures)", при том что в исходном коде буквально делается итерация по всему вектору:
document.elements.iter()Так что спешу поставить под сомнение(с) ваши советы запихивать все в Вox<dyn Element> , хотя использовать профайл дело вполне полезное.Может пригодится - синтаксис паттерн матчинга позволяет в таких случаях делать вайлкард
let x = Element::Header { level: 8, text: "hello" } };match x { Element::Header { level, .. } => { println!("{level}") } Element::Paragraph { .. } => { println!("Paragraph") }};Закон Мура ограничен сверху законами квантовой физики, а "распаллеливания" законом Амдала.
fn element_type(&self) -> ElementType;}pub enum ElementType { Text, Paragraph,fn paragraph_as_ref(&self) -> anyhow::Result<&ParagraphElement>В таком подходе тип элементов описывается в трех местах, что во-первых требует больше времени для добавления нового типа, а во-вторых отсуствует статическая проверка типизации - при match element.element_type() нет никакой гарантии компилятора что там будет действительно лежать нужный тип при даункасте. Плюс
Vec<Box<dyn Element>>не эффективная по перфомансу, будет постоянный кэш мисс и эвристики подгрузки не работают.Может быть лучше попробовать, как первое решение, просто алгебраческий тип:
pub enum Element<'a> {Header { level: u8, /* todo */ },Paragraph { child: &'a Element<'a> },...}и
Vec<Element>Еще все элементы создаются в куче с динамик трейтами вместо статического полиморфизма, а конструктуры объявлены через Result, хотя ошибку они никогда не кидают. Например
pub fn new(element: &Box<dyn Element>) -> anyhow::Result<ListItemElement> {Ok(ListItemElement {
element: element.clone(),
})
}
Надеюсь это не будет звучать грубо, но такое решение сильно похоже на попытку использовать ссылочный объектно-ориентированый подход как в java/.net , что смотрится несколько неорганично в расте.
Если у вас есть время залипать в комментах на форумах. Значит время ставить арч точно есть.Оставить комментарий на форуме хабрахабр я могу с телефона пока гуляю с собакой, в отличии от установки арча, так что этот аргумент не работает.