Pull to refresh
15
0
Сергей @cy6erGn0m

Пользователь

Send message
Спасибо большое за статью: алгоритм с вашими дополнениями отлично работает!
Откройте, пожалуйста, тикеты, описывающие эти проблемы в github.com/ktorio/ktor/issues. Все предложения и пожелания есть смысл описывать там.

Подробный план на данный момент нигде не опубликован, однако, основные планы вокруг коммонизации (Kotlin Multiplatform) сервера и более тесной интеграции с kotlinx.serialization.
Может-может. Почитайте про PAE и memory mapping лучше и станет ясно как это происходит. Если подумать, то наверное и больше 4х можно было бы попытаться запихнуть… хотя что-то может и отвалиться… ой может…

Лучше бы не влезать в это безумие, по-хорошему-то
Ясно, что если бы расчёт был бы честным, то там нулей было бы куда больше. И если бы максимум был бы 1, а не 255, то относительная погрешность ещё бы выросла. Хотя сейчас, после исправления, разница между левой и правой частью составляет 0.01% от максимума. Возможно, это и есть предел точности для метода?
И да, всё это для радиуса 3.0 (соответственно, сигма была взята 1.5)
Идея реализовать всё это в экселе частично помогла.

Теперь, когда я стал пытаться повторить это в экселе, я вижу, что у меня есть ошибка, которую я благополучно исправил. Но небольшая асимметрия всё равно сохраняется, а на концах до нулей далековато.

1iir-gaussian2.ods

Небольшой комментарий по реализации в экселе. В таблице есть три столбца. Первый соответствует входным данным, второй (G) первому проходу, а столбец J — второму и финальному проходу (справа налево). На первом проходе первые три точки считаются не так как все. На втором проходе последние три считаются не как все.

Внизу и на втором листе есть график.
Здесь уже немного другие входные данные, чем на скриншоте: максимум 255 в точке 10

iir-gaussian.ods
Впрочем, в процентном отношении около 0.5%, что не так уж много… видимо поэтому на глаз и не видно
Отличнейшая статья! Очень пригодилось на практике. Благодаря ей удалось разобраться в методе довольно быстро. Но после реализации возникли вопросы:

А чему равна sigma при подсчёте коэффициентов? Она должна быть равна радиусу или половине радиуса? У меня получилось, что размытие вдвое сильнее, так как у нас два прохода.

Кроме того, во второй формуле указан знак минус, но на практике надо +.

На практике я также столкнулся с небольшой проблемой. А именно: после двух проходов симметрии не получилось, а справа всегда возникает небольшое остаточное значение:
нарушение симметрии

Возможно, я что-то делаю неверно? Похоже мне не удаётся верно реализовать разворот между проходами на правой границе. Глазом это не заметно, но как0то не правильно это.
Мне удалось связать JavaFX с Jython, но… как-то слишком сложно на мой взгляд получилось.

Вообще, мне кажется, что если хочется простоты, то надо писать всё на JavaFX и не запариваться, он точно не сложнее чем python или тем более ruby. Если простота не цель — то можно писать «мясо» на Java.
На вскидку, я бы применил утилиту jythonc, которая генерирует java-байткод… а потом эти классы слинковал с JavaFX-классами, которые получены из javafxc… думаю, может получиться…
Описание интерфейса на языке Ruby или python по сравнению с JavaFX — это будет обычная каша, какая бы получилась на Java или любом другом классическом языке.
Jython или JRuby думаю можно было бы использовать с JavaFX для описания логики, а JavaFX — для описания UI. Хотя это непростая задача: нужно правильно настроить classpath.
Вообще, это довольно странное и оригинальное пожелание. Честно говоря ни разу не слышал ничего подобного среди пожеланий :) Однако, на досуге попробую скрестить c Jython… если что выйдет — отпишусь.
Есть идеи о чём написать подробнее? Если да, то можно было бы организовать Part 2 :)
Да да, в Java если не печатать содержимое A, B… и тд. на экран, то она тоже выкидывает цикл и ничего не делает… так что с компиляторами шутки плохи :)
Думаю, надо посмотреть что генерирует JIT-компилятор… можно как-нибудь .NET-VM пнуть, чтобы она дампила сгенерированный машинный код?
Вы про абсолютное время? Так ведь тачки разные… нельзя тут в лоб сравнивать… я о том, что первые два случая равнозначны, а третий выполняется быстрее, таким образом результат соответствует ожидаемому…
Да, действительно, я когда-то давно читал, а эта статья напомнила мне именно его книгу :) Я бы сказал, что там примеры, демонстирирующие были менее интересными — примеры, как правило, были больше.
В книге очень много железячных подробностей о том, как работает память, кэш и т.д.
Вероятно, на вашей машине сказываются какие-то побочные эффекты, связанные с процессором, системой, либо какая-то особенность .net JIT-компилятора.

PS: моя конфигурация
cy6ergn0m@cgmachine ~/test/mem $ uname -a
Linux cgmachine 2.6.31.12-desktop-3mnb #1 SMP Thu Mar 25 12:47:42 EDT 2010 x86_64 Intel® Core(TM)2 Duo CPU T5850 @ 2.16GHz GNU/Linux
cy6ergn0m@cgmachine ~/test/mem $ java -version
java version «1.6.0_20»
Java(TM) SE Runtime Environment (build 1.6.0_20-b02)
Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01, mixed mode)
cy6ergn0m@cgmachine ~/test/mem $

PPS: эта конфигурация навела меня на мысль, что возможно у меня результаты отличаются от ваших из-за x86_64-платформы…
Увеличил 200.000.000 до 800.000.000 и получил следующее диапазоны (по четыре запуска на каждый из трёх случаев):
(277ms — 286ms); (279ms — 291ms); (133ms — 142ms)
Примечательно, что разниа между mixed mode и comp mode в пределах погрешности измерения.

Information

Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Registered
Activity