С тех пор, как я освоил rectangling (https://tidyr.tidyverse.org/articles/rectangle.html) при помощи tidyr, анализ JSON'ов любой сложности перестал представлять какие-либо проблемы.
В приведённом примере с датами операций их можно извлечь примерно одной строкой, а второй строкой преобразовать строки в настоящие даты и построить в соседнем окошке график
Здесь, на мой взгляд, есть два принципиально разных подхода. Первый, условно, заказная разработка: там есть место и торговле, и уступкам и т. п., короче говоря, разработка и заказчик по разные стороны. Второй вариант — когда заказчик и разработка "в одной лодке" и в конечном счёте ищут оптимальное по времени и качеству решение общих задач.
Да, для вывода имплементации From можно воспользоваться одним из этих крейтов. Ещё хочу обратить внимание на статью, где автор избавляется от unsafe, одновременно делая код более выразительным и не снижая (а иногда и повышая) производительность
Насколько я понимаю, move-семантика в Rust как раз это и обеспечивает: мы просто даём фрагменту памяти другое имя. Во всяком случае, в godbolt мне не удалось увидеть перемещение данных в памяти при использовании into вместо transmute, даже с итерацией по вектору они скомпилировались в одинаковый код.
Насчёт unsafe и transmute: семантичнее было бы это делать с помощью derive автоматической реализации From. С точки зрения кода это чище и красивее (и короче): просто пишем let x: W = s.into(), а на выходе то же самое (то есть эффективное ничего). Или у предложенного способа с трансмутацией есть какие-то иные неочевидные преимущества?
Следует заметить, что статья 2007-го года, и с тех пор что-то могло поменяться... но не поменялось для конкретно этого синтетического регулярного выражения.
Код на PHP 8.1.9 работает быстро, но для n > 18 не находит матч. Код на Python 3.10 всё так же тормозит.
Из того, что было проверить под рукой, только крейт regex в Rust показал себя отлично, что, в общем неудивительно, учитывая, что под капотом в этом крейте есть несколько разных движков, включая и NFA Томпсона: про это недавно был отличный перевод. Впрочем, это неудивительно: эта серия статей и библиотека RE2 и вдохновили автора на написание этого крейта.
Реальная проблема для удержания (во всяком случае, в Москве, где масса альтернатив) — качество продукции и ассортимент. Ну и ещё несколько раз подряд привозили не совсем то без предупреждения. А в статье, извините, передвижение кроватей
Жаль, что автор не упомянул о фигурных числах вообще, хотя этим ещё античные математики занимались. По поводу «гексов» даже в русской вики есть отдельная статья.
Это смотря какая хеш-функция. Формально это определено, как «семейство k хеш-функций, каждая из которых возвращает число от 1 до m, где m — количество разрядов в фильтре», но мне удобнее представлять это семейство как одну хеш-функцию, чьё бинарное значение разрядностью m никогда не содержит более k единиц.
Спасибо за отличное сравнение! Есть один вопрос-предложение: вроде как -Ozоптимизирует размер, а не производительность (как -O3). Может быть, если собрать с -O3, то Emscripten побыстрее будет?
Я бы Ваш пример сыграл с восстановлением первоначального контекста. Обычно подобные знаки применяются для более крупных разделов формы, здесь лучше выписать повторы, тогда точно не будет никаких проблем.
Кстати, ключ с восьмёркой внизу, означающий перенос на октаву, выворачивает мозг. Обычно так нотируется исключительно партия голоса-тенора, который пишется в скрипичном ключе, но поётся на октаву ниже (да и восьмёрку в этих случаях часто всё равно не ставят). Тем более это выглядит абсурдно, когда там ноты на добавочных линейках сверху.
Что касается педали, лиги и ферматы. Это три разные вещи.
Педаль — это исполнительский приём, нажатие на педаль, и оно имеет смысл только для фортепиано и аналогичных инструментов. Оно, конечно, продлевает ноты, но это не единственная её функция. Нажатая педаль изменяет тембр звучания, ведь все струны начинают резонировать.
Лига (точнее, та её разновидность, которая tie, а не slur) — для увеличения длины ноты, то есть чтобы она занимала больше долей. Это ваш случай. Та, которая slur обозначает слитную манеру исполнения (на струнных, например, не меняя направление движения смычка, на духовых — на одном выдохе и т. п.).
Фермата растягивает метрическую сетку. Это как замедление на одну конкретную долю. Именно поэтому фермата всегда выписывается у всех инструментов разом.
С тех пор, как я освоил rectangling (https://tidyr.tidyverse.org/articles/rectangle.html) при помощи tidyr, анализ JSON'ов любой сложности перестал представлять какие-либо проблемы.
В приведённом примере с датами операций их можно извлечь примерно одной строкой, а второй строкой преобразовать строки в настоящие даты и построить в соседнем окошке график
В 1.21 выводит, как у автора, а в 1.22 — как по «здравому смыслу»: поправили. Про это писали недавно
Не «о чём», а «зачем». Ответ есть в конце статьи
Современная нотация фиксирует существенно больше, чем 88 вариантов высот, распределённых во времени...
Тот случай, когда комментарии полезнее статьи. По-моему, эта история может стать отличной статьёй
Здесь, на мой взгляд, есть два принципиально разных подхода. Первый, условно, заказная разработка: там есть место и торговле, и уступкам и т. п., короче говоря, разработка и заказчик по разные стороны. Второй вариант — когда заказчик и разработка "в одной лодке" и в конечном счёте ищут оптимальное по времени и качеству решение общих задач.
Да, для вывода имплементации
Fromможно воспользоваться одним из этих крейтов. Ещё хочу обратить внимание на статью, где автор избавляется от unsafe, одновременно делая код более выразительным и не снижая (а иногда и повышая) производительностьНасколько я понимаю, move-семантика в Rust как раз это и обеспечивает: мы просто даём фрагменту памяти другое имя. Во всяком случае, в godbolt мне не удалось увидеть перемещение данных в памяти при использовании
intoвместоtransmute, даже с итерацией по вектору они скомпилировались в одинаковый код.Насчёт
unsafeиtransmute: семантичнее было бы это делать с помощьюderiveавтоматической реализацииFrom. С точки зрения кода это чище и красивее (и короче): просто пишемlet x: W = s.into(), а на выходе то же самое (то есть эффективное ничего). Или у предложенного способа с трансмутацией есть какие-то иные неочевидные преимущества?Следует заметить, что статья 2007-го года, и с тех пор что-то могло поменяться... но не поменялось для конкретно этого синтетического регулярного выражения.
Код на PHP 8.1.9 работает быстро, но для n > 18 не находит матч. Код на Python 3.10 всё так же тормозит.
Из того, что было проверить под рукой, только крейт regex в Rust показал себя отлично, что, в общем неудивительно, учитывая, что под капотом в этом крейте есть несколько разных движков, включая и NFA Томпсона: про это недавно был отличный перевод. Впрочем, это неудивительно: эта серия статей и библиотека RE2 и вдохновили автора на написание этого крейта.
Реальная проблема для удержания (во всяком случае, в Москве, где масса альтернатив) — качество продукции и ассортимент. Ну и ещё несколько раз подряд привозили не совсем то без предупреждения. А в статье, извините, передвижение кроватей
Жаль, что автор не упомянул о фигурных числах вообще, хотя этим ещё античные математики занимались. По поводу «гексов» даже в русской вики есть отдельная статья.
http://cliffle.com/p/dangerust/
Автор сначала "переводит буквально" код с C на Rust, а потом превращает его в идиоматический Rust, попутно даже выигрывая немного в производительности
Это смотря какая хеш-функция. Формально это определено, как «семейство k хеш-функций, каждая из которых возвращает число от 1 до m, где m — количество разрядов в фильтре», но мне удобнее представлять это семейство как одну хеш-функцию, чьё бинарное значение разрядностью m никогда не содержит более k единиц.
Фильтр Блума — это, условно, побитный OR по хешам элементов. Он позволяет быстро проверить отсутствие, но не гарантирует наличие в случае попадания.
Таким образом, насколько я понимаю, среди таблиц-кандидатов достаточно бинарным поиском посмотреть индекс (где ключи сортированы).
И объединение SSTable не требует пересортировки данных, потому что слияние индексов выполняется за линейное время.
Спасибо за отличное сравнение! Есть один вопрос-предложение: вроде как
-Ozоптимизирует размер, а не производительность (как-O3). Может быть, если собрать с-O3, то Emscripten побыстрее будет?Зачем нужен отдельный пакет, когда есть стандартный линуксовый
perf?Это для того, чтобы достигать пика Балмера
Две и одну. Общепринятого способа записать сокращённо чередование трёх нот не существует
Я бы Ваш пример сыграл с восстановлением первоначального контекста. Обычно подобные знаки применяются для более крупных разделов формы, здесь лучше выписать повторы, тогда точно не будет никаких проблем.
Кстати, ключ с восьмёркой внизу, означающий перенос на октаву, выворачивает мозг. Обычно так нотируется исключительно партия голоса-тенора, который пишется в скрипичном ключе, но поётся на октаву ниже (да и восьмёрку в этих случаях часто всё равно не ставят). Тем более это выглядит абсурдно, когда там ноты на добавочных линейках сверху.
Что касается педали, лиги и ферматы. Это три разные вещи.
Педаль — это исполнительский приём, нажатие на педаль, и оно имеет смысл только для фортепиано и аналогичных инструментов. Оно, конечно, продлевает ноты, но это не единственная её функция. Нажатая педаль изменяет тембр звучания, ведь все струны начинают резонировать.
Лига (точнее, та её разновидность, которая tie, а не slur) — для увеличения длины ноты, то есть чтобы она занимала больше долей. Это ваш случай. Та, которая slur обозначает слитную манеру исполнения (на струнных, например, не меняя направление движения смычка, на духовых — на одном выдохе и т. п.).
Фермата растягивает метрическую сетку. Это как замедление на одну конкретную долю. Именно поэтому фермата всегда выписывается у всех инструментов разом.