Так это macro_rules, а не derive. Это совершенно не связанные вещи.
Ну и касательно самих macro_rules, я не вижу здесь указаний, что они задумывались как временное решение. Они были в языке с момента релиза и, насколько я знаю, тогда не было планов их заменить на что-то другое.
Просто уже после релиза языка, при практическом опыте использования, пришли к выводу, что систему макросов можно улучшить. Сначала добавили макросы в основной неймрез. А потом предложили макросы 2.0 — но это аж 2016 год, через год после релиза.
Есть ли у Вас ссылки, которые именно что подкрепляют Ваше заявление, что (derive) макросы именно что задумывались как временно решение?
P.S. ну и sunshine/rust-course не является официальным источником, и не похож, как заслуживающий доверия (в таких тонких вопросах)
Олимпиада и бизнес суть разные вещи. Разные подходы. И то, что человек блестящий олимпиадник, практически никаких преимуществ в бизнесе ему не дает
Ну вот я выше привёл пример того, как известным в узких кругах алгоритмах можно было бы сразу наметить план решения. Поэтому какие-то преимущества всё же даёт.
получая ТЗ на новый модуль всегда надо понимать с какими объемами данных он будет работать, какая будет плотность вызовов, какие типичные сценарии использования предполагаются - все это влияет на выбор деталей реализации.
Хороший олимпиадник сходу задаётся этими же вопросами. Более того, зачастую олимпиадники задают даже более тонкие вопросы, т.к. сразу могут подобрать варианты решения.
P.S. разумеется на реализацию этих решений могут уйти дни-недели-месяцы. Но в среднем хорошие олимпиадники не испытывают проблем с длительными задачами...
Я не уверен, что Вы здесь имеете ввиду под "бизнесом". Но если говорить с точки зрения подбора разработчиков, то хорошие технические навыки (в том числе опыт в олимпиадах) довольно важны и полезны с точки зрения продуктивности (разумеется при условии что они как работники нормальные — по это само собой разумеется)
У меня складывается впечатление, что Вы подразумеваете мысль "если человек олимпиадник, то он ничего кроме олимпиад не делал".
Разумеется, принимать человека на работу исключительно по его успехам в олимпиадах — затея не очень хорошая. Но абсолютно аналогично не очень хорошая затея смотреть исключительно на технические навыки. Можно сказать аналогичную фразу
Все к тому, что человек с блестящими навыками программирования в бизнесе может хорошо себя показать, а может и наоборот. Потому что это очень разные вещи.
Разумеется при приёме на работу нужно также смотреть на социальные особенности человека (и вроде как почти во всех внятных местах смотрят)
Речь скорее о том, что опыт в олимпиадах — это однозначный плюс, как ещё один технический навык. На умение работать с рутиной такой опыт не влияет ни положительно ни отрицательно — на это влияют другие, не связанные особенности характера.
И эти же самые особенности характера часто встречаются у любых технически сильных кандидатов.
"Инвертированный индекс" — это вполне себе стандартная структура данных для решения подобных задач, тут не вопрос того, как я себе это представляю.
В данном случае это что-то в таком стиле: разбиваем каждый адрес на слова(уже после нормализации), и строим для каждого слова сортированный список клиентов, у которых данное слово входит в адрес.
Дальше, если мы хотим например найти клиентов у которых в адресе встречаются w1 и w2, мы находим соответствующие списки клиентов и пересекаем их — это делается за линейное время от размера результата (по модулю логарифмов). Аналогично для поискаслов можно объединить списки за,, гдеесть размер результата.
Как строить и где хранить этот индекс — это отдельный вопрос. Можно его материализовать в бд (например в виде таблицы (word, client_id)). Можно материализовать в как отдельную структуру на диске. Вообще говоря, можно даже попробовать собрать этот индекс в памяти, прямо во время сверки — там не.
Подход к построению индекса сильно зависит от среды. Доступной памяти, возможностей организации структур данных, возможность итерации по бд и прочего. Тут Вы сами знаете лучше.
Дальше надо написать модуль поддержки этой витрины - [...]
В этом и отличие - на олимпиаде вы решаете отдельную задачу, которая ни к чему не привязана, [...]
Я прекрасно понимаю связанные сложности с поддержанием витрин и в целом жизненным циклом программных продуктов. И о том, что разработка отличается от олимпиады.
Но во-первых, про инвертированный индекс я писал несколько в отрыве от истории с олимпиадами.
А во-вторых, не вижу причин, почему олимпиадники должны в среднем (или обязательно) плохо справляться с задачами разработки. Ну кроме истории с ресёрчем, про которую говорили в другой ветке — но она мешает не только олимпиадникам.
Не очень понимаю, почему олимпиаднику это не мешает. На моём опыте, когда людей с исследовательским характером ставят на рутину, они очень быстро выгорают, независимо от наличия олимпиадного опыта.
Ну не получалось у него месяцами держать концентрацию на одной большой задаче - ему просто было это скучно, много рутины.
На моей практике, это слабо связано с олимпиадами. Просто есть такие люди, которые больше по ресёрчу — они не могут долго в рутину. Среди них есть как олимпиадники, так и много тех, кто олимпиады не трогал. Поэтому выскажу гипотезу, что это просто нерепрезентативная выборка.
Причем, в заранее не можете сказать хватит вам простого решения или нет.
На самом деле, зачастую прикинуть как раз можно. По крайней мере в таких условиях, когда есть простые и конкретные ограничения, как в Вашем примере. И как раз этот навык олимпиады очень хорошо тренируют.
P.S. кстати говоря, хотя я понимаю, что задача с адресами уже была рассказана с учётом решения, но чисто по описанию и объёмам данных там сразу напрашивается классический инвертированный индекс. Вы, я так понял, пришли к похожему решению, но без слияний по бинпоиску. (к сожалению, не был готов пробираться через терминологию, чтобы понять решение по нормальному)
Там весьма криво описан протокол. Конкретно описанная проблема там решается через внешнего актора. То есть есть внешний независимый сервис ("проверяемой энтропии"), которые каждые 3 секунды публикует случайный ключ и у которого можно запросить, а что он опубликовал в какой-то прошлый момент времени. Оператор лотерии не выбирает drand, он выбирает только время ("номер раунда"), когда наш сервис энтропии опубликует ключ — и вот ключ в этот момент времени и станет нашим drand.
Но сам протокол, вообще говоря, не предназначен для произвольных лотерей типа 6/36. Конкретно uvLotery работает только для случайных перемешиваний кандидатов. Впрочем, на суть проблем это не сильно влияет.
Для своей работы он требует целых два внешних сервиса: проверямоего источника времени и проверяемого источника энтропии. Что кмк не очень хорошо ввиду всяких угроз сговоров =/
Кмк, было бы интересно рассмотреть вариант, когда drand формируется именно что участниками. Условно, чтобы после того, как список участников закомичен, у участников была бы возможность добавить своих байт в пул энтропии. При этом, чтобы порядок добавления зависел от предыдущих добавленных байт — таким образом нельзя будет добавить своего участника в конце. Правда это плохо масштабируется (на миллионы участников).
Tl;Dr; сам протокол в статье толком не описан, нужно читать оригинал. Мб сделать нормальный разбор протокола...
От этого в вебе никуда не деться, и я это не прячу.
Так это, в определённом смысле, ставит крест на всей затее. Если у нас нет доверия к серверу, то браузерный E2EE не имеет смысла декларировать.
Здесь нужно менять подход. Хотя бы банально сделать расширение для браузера, чтобы шифрование в нём происходило.
Или, что круче, это расширение браузера для контролируемых обновлений: ведёт локальный, или распределённый) реестр версий сайтов и выдаёт алерт при любом обновлении. Тогда можно было бы попробовать восстановить доверие к браузерному e2ee.
P.S. не увидел в коде собственно стримминга. Ожидал бы, что крипто библиотека выдаёт именно стрим, который сразу гонится на сервер/в загрузку, без полной буферизации...
Вы здесь путаете фальсифицируемость и возможность ошибки. Если единственный способ опровергнуть утверждение — это найти ошибку в его выводе/получении, то утверждение не фальсифицируемо. По крайней мере, так воспринимают данный термин большинство физиков и математиков, с которыми я знаком.
Впрочем, спор об определениях и потому не имеет смысла.
Так а где здесь фальсификация? От того, что Евклидова геометрия неприменима для решения задач на поверхности земли она разве стала менее верной?
Математикам, которые занимаются Евклидовой геометрией вобщем-то без разницы, выполняются ли её аксиомы на поверхности земли, или нет. Фальсифицируемы науки, которые применяют соответствующие результаты математики, но на то математика и язык.
Честно говоря, я видел достаточно примеров, как самые самые разные системы и модели описывались буквально "несколькими буквами". Поэтому для меня это не то чтобы удивительно. Здесь вопрос лишь в том, насколько хорошо авторы сумеют замести всю сложность под ковёр.
Ну а если мы начинаем учитывать не только основную формулу, но и описание целиком — то получается не так уж и мало. Поэтому мне тяжело согласится с тем, что Ньютоновская динамика есть простое описание — я видел много гораздо более простых моделей.
Но действительно, как всегда спор об определениях =/
Математике всё равно. В математике нет как таковых истин, она просто она просто занимается перекладыванием закорючек по каким-то правилам — а истинны эти закорючки, или ложны — ей без разницы. Ну или, попробуйте привести "истину" в математике (которая не являлась бы определением)
Во-вторых, язык (потенциально, в пределе) способен на полное описание действительности. А математика — нет.
Почему нет?
Ту, которая очищена от качеств (и содержаний?), и состоит из количеств (и форм?).
Не уверен до конца, что это значит. Но вообще говоря, математика описывает далеко не только количества. Более того, современная математика количества практически не описывает.
Взять например ту же топологию. Она, по сути говорит, что если у Вас есть топологическое свойство, то оно не может нарушиться/поменяться при непрерывных преобразованиях. Поэтому если в какой-то физической системе обнаруживается топологический инвариант, то пока эта физическая система развивается непрерывно, данный инвариант не нарушится. Заметьте, здесь нет никаких количеств, мы не имеем никаких количественных описаний системы — а математику применить всё равно можем.
Что будет, если после ввода пинкода наоборот выйти и ввести его ещё раз? Откроется ли то же самое? Если нет, то это не имеет смысла
Edit: ну и в целом отличить пинкод и пинкод наоборот можно через скорость ввода (на отдельном устройстве)
Так это macro_rules, а не derive. Это совершенно не связанные вещи.
Ну и касательно самих macro_rules, я не вижу здесь указаний, что они задумывались как временное решение. Они были в языке с момента релиза и, насколько я знаю, тогда не было планов их заменить на что-то другое.
Просто уже после релиза языка, при практическом опыте использования, пришли к выводу, что систему макросов можно улучшить. Сначала добавили макросы в основной неймрез. А потом предложили макросы 2.0 — но это аж 2016 год, через год после релиза.
Есть ли у Вас ссылки, которые именно что подкрепляют Ваше заявление, что (derive) макросы именно что задумывались как временно решение?
P.S. ну и sunshine/rust-course не является официальным источником, и не похож, как заслуживающий доверия (в таких тонких вопросах)
Что делать, если глубина стека будет больше доступного количества регистров?
Да не то чтобы особенность. Достаточно частый подход, вплоть до nanopass с десятками ir
Edit: ну и с приходом mlir теперь похожая история едет и во всякие clang/mojo/arc и прочее
А макросы разве планировались как временное решение? Есть ссылки на это?
Ну вот я выше привёл пример того, как известным в узких кругах алгоритмах можно было бы сразу наметить план решения. Поэтому какие-то преимущества всё же даёт.
Хороший олимпиадник сходу задаётся этими же вопросами. Более того, зачастую олимпиадники задают даже более тонкие вопросы, т.к. сразу могут подобрать варианты решения.
P.S. разумеется на реализацию этих решений могут уйти дни-недели-месяцы. Но в среднем хорошие олимпиадники не испытывают проблем с длительными задачами...
Я не уверен, что Вы здесь имеете ввиду под "бизнесом". Но если говорить с точки зрения подбора разработчиков, то хорошие технические навыки (в том числе опыт в олимпиадах) довольно важны и полезны с точки зрения продуктивности (разумеется при условии что они как работники нормальные — по это само собой разумеется)
У меня складывается впечатление, что Вы подразумеваете мысль "если человек олимпиадник, то он ничего кроме олимпиад не делал".
Разумеется, принимать человека на работу исключительно по его успехам в олимпиадах — затея не очень хорошая. Но абсолютно аналогично не очень хорошая затея смотреть исключительно на технические навыки. Можно сказать аналогичную фразу
Разумеется при приёме на работу нужно также смотреть на социальные особенности человека (и вроде как почти во всех внятных местах смотрят)
Речь скорее о том, что опыт в олимпиадах — это однозначный плюс, как ещё один технический навык. На умение работать с рутиной такой опыт не влияет ни положительно ни отрицательно — на это влияют другие, не связанные особенности характера.
И эти же самые особенности характера часто встречаются у любых технически сильных кандидатов.
"Инвертированный индекс" — это вполне себе стандартная структура данных для решения подобных задач, тут не вопрос того, как я себе это представляю.
В данном случае это что-то в таком стиле: разбиваем каждый адрес на слова(уже после нормализации), и строим для каждого слова сортированный список клиентов, у которых данное слово входит в адрес.
Дальше, если мы хотим например найти клиентов у которых в адресе встречаются w1 и w2, мы находим соответствующие списки клиентов и пересекаем их — это делается за линейное время от размера результата (по модулю логарифмов). Аналогично для поиска
слов можно объединить списки за,
, где
есть размер результата.
Как строить и где хранить этот индекс — это отдельный вопрос. Можно его материализовать в бд (например в виде таблицы (word, client_id)). Можно материализовать в как отдельную структуру на диске. Вообще говоря, можно даже попробовать собрать этот индекс в памяти, прямо во время сверки — там не.
Подход к построению индекса сильно зависит от среды. Доступной памяти, возможностей организации структур данных, возможность итерации по бд и прочего. Тут Вы сами знаете лучше.
Я прекрасно понимаю связанные сложности с поддержанием витрин и в целом жизненным циклом программных продуктов. И о том, что разработка отличается от олимпиады.
Но во-первых, про инвертированный индекс я писал несколько в отрыве от истории с олимпиадами.
А во-вторых, не вижу причин, почему олимпиадники должны в среднем (или обязательно) плохо справляться с задачами разработки. Ну кроме истории с ресёрчем, про которую говорили в другой ветке — но она мешает не только олимпиадникам.
Не очень понимаю, почему олимпиаднику это не мешает. На моём опыте, когда людей с исследовательским характером ставят на рутину, они очень быстро выгорают, независимо от наличия олимпиадного опыта.
Или я Вас неправильно понял?
На моей практике, это слабо связано с олимпиадами. Просто есть такие люди, которые больше по ресёрчу — они не могут долго в рутину. Среди них есть как олимпиадники, так и много тех, кто олимпиады не трогал. Поэтому выскажу гипотезу, что это просто нерепрезентативная выборка.
На самом деле, зачастую прикинуть как раз можно. По крайней мере в таких условиях, когда есть простые и конкретные ограничения, как в Вашем примере. И как раз этот навык олимпиады очень хорошо тренируют.
P.S. кстати говоря, хотя я понимаю, что задача с адресами уже была рассказана с учётом решения, но чисто по описанию и объёмам данных там сразу напрашивается классический инвертированный индекс. Вы, я так понял, пришли к похожему решению, но без слияний по бинпоиску. (к сожалению, не был готов пробираться через терминологию, чтобы понять решение по нормальному)
Там весьма криво описан протокол. Конкретно описанная проблема там решается через внешнего актора. То есть есть внешний независимый сервис ("проверяемой энтропии"), которые каждые 3 секунды публикует случайный ключ и у которого можно запросить, а что он опубликовал в какой-то прошлый момент времени. Оператор лотерии не выбирает drand, он выбирает только время ("номер раунда"), когда наш сервис энтропии опубликует ключ — и вот ключ в этот момент времени и станет нашим drand.
Но сам протокол, вообще говоря, не предназначен для произвольных лотерей типа 6/36. Конкретно uvLotery работает только для случайных перемешиваний кандидатов. Впрочем, на суть проблем это не сильно влияет.
Для своей работы он требует целых два внешних сервиса: проверямоего источника времени и проверяемого источника энтропии. Что кмк не очень хорошо ввиду всяких угроз сговоров =/
Кмк, было бы интересно рассмотреть вариант, когда drand формируется именно что участниками. Условно, чтобы после того, как список участников закомичен, у участников была бы возможность добавить своих байт в пул энтропии. При этом, чтобы порядок добавления зависел от предыдущих добавленных байт — таким образом нельзя будет добавить своего участника в конце. Правда это плохо масштабируется (на миллионы участников).
Tl;Dr; сам протокол в статье толком не описан, нужно читать оригинал. Мб сделать нормальный разбор протокола...
Так это, в определённом смысле, ставит крест на всей затее. Если у нас нет доверия к серверу, то браузерный E2EE не имеет смысла декларировать.
Здесь нужно менять подход. Хотя бы банально сделать расширение для браузера, чтобы шифрование в нём происходило.
Или, что круче, это расширение браузера для контролируемых обновлений: ведёт локальный, или распределённый) реестр версий сайтов и выдаёт алерт при любом обновлении. Тогда можно было бы попробовать восстановить доверие к браузерному e2ee.
P.S. не увидел в коде собственно стримминга. Ожидал бы, что крипто библиотека выдаёт именно стрим, который сразу гонится на сервер/в загрузку, без полной буферизации...
Вы здесь путаете фальсифицируемость и возможность ошибки. Если единственный способ опровергнуть утверждение — это найти ошибку в его выводе/получении, то утверждение не фальсифицируемо. По крайней мере, так воспринимают данный термин большинство физиков и математиков, с которыми я знаком.
Впрочем, спор об определениях и потому не имеет смысла.
Фальсифицируют аксиомы и гипотезы, а не теоремы/доказательства. Ошибка есть просто ошибка.
Я об этом же. Именно поэтому математика не есть наука (не использует научный метод)
Так а где здесь фальсификация? От того, что Евклидова геометрия неприменима для решения задач на поверхности земли она разве стала менее верной?
Математикам, которые занимаются Евклидовой геометрией вобщем-то без разницы, выполняются ли её аксиомы на поверхности земли, или нет. Фальсифицируемы науки, которые применяют соответствующие результаты математики, но на то математика и язык.
Честно говоря, я видел достаточно примеров, как самые самые разные системы и модели описывались буквально "несколькими буквами". Поэтому для меня это не то чтобы удивительно. Здесь вопрос лишь в том, насколько хорошо авторы сумеют замести всю сложность под ковёр.
Ну а если мы начинаем учитывать не только основную формулу, но и описание целиком — то получается не так уж и мало. Поэтому мне тяжело согласится с тем, что Ньютоновская динамика есть простое описание — я видел много гораздо более простых моделей.
Но действительно, как всегда спор об определениях =/
Математике всё равно. В математике нет как таковых истин, она просто она просто занимается перекладыванием закорючек по каким-то правилам — а истинны эти закорючки, или ложны — ей без разницы. Ну или, попробуйте привести "истину" в математике (которая не являлась бы определением)
Почему нет?
Не уверен до конца, что это значит. Но вообще говоря, математика описывает далеко не только количества. Более того, современная математика количества практически не описывает.
Взять например ту же топологию. Она, по сути говорит, что если у Вас есть топологическое свойство, то оно не может нарушиться/поменяться при непрерывных преобразованиях. Поэтому если в какой-то физической системе обнаруживается топологический инвариант, то пока эта физическая система развивается непрерывно, данный инвариант не нарушится. Заметьте, здесь нет никаких количеств, мы не имеем никаких количественных описаний системы — а математику применить всё равно можем.
Нет. Она нефальсифицируема. Более того, в математике нет такого понятия как "ложная аксиома" — а это есть одно из ключевых требований дл науки.