Про половину. Видимо поэтому безопасно использовать signed integer вместо unsigned для размеров? Допустим, если используем 64-битные адреса, то ОС принципиально не выделит памяти больше чем 2^63 - 1, и тогда удобно использовать int64_t (или ptrdiff в более общем случае) для реверсивного обхода контейнеров:
for (int64_t i = vector.size() - 1; i >= 0; i--) {
do_work(vector.at(i));
}
Тогда значит было ошибкой делать такое ПО платным, его всё равно ломают. Могли бы обойтись лицензией типа MIT. Это всё равно околоуниверситетские вещи, которые нужны больше для образования, чем для проектирования реальных вещей (реальные вещи конечно проектируют, но чаще моделируют частично, по подсистемам, не всю систему целиком, если система очень большая).
Да, изобретать не надо, но чтобы подробно изучить и понять откуда это получилось, можно потратить много времени, как я собственно и сделал. В итоге, понял, но оставил затею сделать туториал по арифметическому кодированию... Rans куда практичнее, понятнее и быстрее; единственное, он не позволяет делать моделирование контекста, и Rans также можно свести к Хафману, если проквантовать частоты по степеням двойки (проверено).
Да. Жестоко) Мне кажется, что лидером по сложности будет арифметическое кодирование с ограниченной разрядностью. Мало того, оно ещё редко где используется - если нужно экстремальное сжатие (алгоритмы с моделированием контекста). А так, да, оптимизированный BWT - это довольно таки хитрая вещь.
Университеты совместно с нии и могли бы разрабатывать подобный софт, причём на открытой основе. В свободное так сказать время, и для разного рода ниокр могли бы использовать этот софт. От университета - теоретики СВЧ, от нии - практики как по СВЧ, так и по разработке ПО. Это конечно идеал, но на то он и идеал, чтобы к нему стремиться.
Всегда удивляло почему так сложно в СВЧ всё? Очень затратно, даже создаётся ощущение, что при проектировании СВЧ нужна больше интуиция и практика. Это дешевле и быстрее.
Да это просто интересный факт.
Ну, если нет битовой магии, то int можно использовать. Фактически, как индекс.
Используя float, можно напечатать точное значения любой целой степени двойки насколько позволяет ёмкость выбранного float.
А, в коде всё нормально, а в статье идёт упоминание об int32_t.
Для моделирования float.
А почему вы выбрали знаковый int?
Про половину. Видимо поэтому безопасно использовать signed integer вместо unsigned для размеров? Допустим, если используем 64-битные адреса, то ОС принципиально не выделит памяти больше чем 2^63 - 1, и тогда удобно использовать int64_t (или ptrdiff в более общем случае) для реверсивного обхода контейнеров:
Эх... Хорошо что я ушёл из этих дебрей.
Тогда значит было ошибкой делать такое ПО платным, его всё равно ломают. Могли бы обойтись лицензией типа MIT. Это всё равно околоуниверситетские вещи, которые нужны больше для образования, чем для проектирования реальных вещей (реальные вещи конечно проектируют, но чаще моделируют частично, по подсистемам, не всю систему целиком, если система очень большая).
Да, изобретать не надо, но чтобы подробно изучить и понять откуда это получилось, можно потратить много времени, как я собственно и сделал. В итоге, понял, но оставил затею сделать туториал по арифметическому кодированию... Rans куда практичнее, понятнее и быстрее; единственное, он не позволяет делать моделирование контекста, и Rans также можно свести к Хафману, если проквантовать частоты по степеням двойки (проверено).
Реализация может и да, но чтобы осознать её корректность... А контекстное моделирование довольно таки очевидная вещь, хоть и объёмная по коду.
Да. Жестоко) Мне кажется, что лидером по сложности будет арифметическое кодирование с ограниченной разрядностью. Мало того, оно ещё редко где используется - если нужно экстремальное сжатие (алгоритмы с моделированием контекста). А так, да, оптимизированный BWT - это довольно таки хитрая вещь.
Университеты совместно с нии и могли бы разрабатывать подобный софт, причём на открытой основе. В свободное так сказать время, и для разного рода ниокр могли бы использовать этот софт. От университета - теоретики СВЧ, от нии - практики как по СВЧ, так и по разработке ПО. Это конечно идеал, но на то он и идеал, чтобы к нему стремиться.
Осциллограф да, фактически теряет смысл на СВЧ.
Всегда удивляло почему так сложно в СВЧ всё? Очень затратно, даже создаётся ощущение, что при проектировании СВЧ нужна больше интуиция и практика. Это дешевле и быстрее.
Да, хороший improve.
"Ищут волшебника, находят сказочника" - оригинально сказано.
Это-то понятно. Смущает, что исключений много. Может, конечно, комментатор выше ошибся
Если исключений много, то это странно... Зачем тогда правила? Точнее, тогда исключения и правила меняются местами)
С какого объёма - не знаю, это чисто субъективная оценка.