Откройте, пожалуйста, тикеты, описывающие эти проблемы в github.com/ktorio/ktor/issues. Все предложения и пожелания есть смысл описывать там.
Подробный план на данный момент нигде не опубликован, однако, основные планы вокруг коммонизации (Kotlin Multiplatform) сервера и более тесной интеграции с kotlinx.serialization.
Может-может. Почитайте про PAE и memory mapping лучше и станет ясно как это происходит. Если подумать, то наверное и больше 4х можно было бы попытаться запихнуть… хотя что-то может и отвалиться… ой может…
Ясно, что если бы расчёт был бы честным, то там нулей было бы куда больше. И если бы максимум был бы 1, а не 255, то относительная погрешность ещё бы выросла. Хотя сейчас, после исправления, разница между левой и правой частью составляет 0.01% от максимума. Возможно, это и есть предел точности для метода?
Идея реализовать всё это в экселе частично помогла.
Теперь, когда я стал пытаться повторить это в экселе, я вижу, что у меня есть ошибка, которую я благополучно исправил. Но небольшая асимметрия всё равно сохраняется, а на концах до нулей далековато.
Небольшой комментарий по реализации в экселе. В таблице есть три столбца. Первый соответствует входным данным, второй (G) первому проходу, а столбец J — второму и финальному проходу (справа налево). На первом проходе первые три точки считаются не так как все. На втором проходе последние три считаются не как все.
Отличнейшая статья! Очень пригодилось на практике. Благодаря ей удалось разобраться в методе довольно быстро. Но после реализации возникли вопросы:
А чему равна sigma при подсчёте коэффициентов? Она должна быть равна радиусу или половине радиуса? У меня получилось, что размытие вдвое сильнее, так как у нас два прохода.
Кроме того, во второй формуле указан знак минус, но на практике надо +.
На практике я также столкнулся с небольшой проблемой. А именно: после двух проходов симметрии не получилось, а справа всегда возникает небольшое остаточное значение:
Возможно, я что-то делаю неверно? Похоже мне не удаётся верно реализовать разворот между проходами на правой границе. Глазом это не заметно, но как0то не правильно это.
Мне удалось связать JavaFX с Jython, но… как-то слишком сложно на мой взгляд получилось.
Вообще, мне кажется, что если хочется простоты, то надо писать всё на JavaFX и не запариваться, он точно не сложнее чем python или тем более ruby. Если простота не цель — то можно писать «мясо» на Java.
На вскидку, я бы применил утилиту jythonc, которая генерирует java-байткод… а потом эти классы слинковал с JavaFX-классами, которые получены из javafxc… думаю, может получиться…
Описание интерфейса на языке Ruby или python по сравнению с JavaFX — это будет обычная каша, какая бы получилась на Java или любом другом классическом языке.
Jython или JRuby думаю можно было бы использовать с JavaFX для описания логики, а JavaFX — для описания UI. Хотя это непростая задача: нужно правильно настроить classpath.
Вообще, это довольно странное и оригинальное пожелание. Честно говоря ни разу не слышал ничего подобного среди пожеланий :) Однако, на досуге попробую скрестить c Jython… если что выйдет — отпишусь.
Вы про абсолютное время? Так ведь тачки разные… нельзя тут в лоб сравнивать… я о том, что первые два случая равнозначны, а третий выполняется быстрее, таким образом результат соответствует ожидаемому…
Да, действительно, я когда-то давно читал, а эта статья напомнила мне именно его книгу :) Я бы сказал, что там примеры, демонстирирующие были менее интересными — примеры, как правило, были больше.
В книге очень много железячных подробностей о том, как работает память, кэш и т.д.
Увеличил 200.000.000 до 800.000.000 и получил следующее диапазоны (по четыре запуска на каждый из трёх случаев):
(277ms — 286ms); (279ms — 291ms); (133ms — 142ms)
Подробный план на данный момент нигде не опубликован, однако, основные планы вокруг коммонизации (Kotlin Multiplatform) сервера и более тесной интеграции с kotlinx.serialization.
Лучше бы не влезать в это безумие, по-хорошему-то
Теперь, когда я стал пытаться повторить это в экселе, я вижу, что у меня есть ошибка, которую я благополучно исправил. Но небольшая асимметрия всё равно сохраняется, а на концах до нулей далековато.
1iir-gaussian2.ods
Небольшой комментарий по реализации в экселе. В таблице есть три столбца. Первый соответствует входным данным, второй (G) первому проходу, а столбец J — второму и финальному проходу (справа налево). На первом проходе первые три точки считаются не так как все. На втором проходе последние три считаются не как все.
Внизу и на втором листе есть график.
iir-gaussian.ods
А чему равна sigma при подсчёте коэффициентов? Она должна быть равна радиусу или половине радиуса? У меня получилось, что размытие вдвое сильнее, так как у нас два прохода.
Кроме того, во второй формуле указан знак минус, но на практике надо +.
На практике я также столкнулся с небольшой проблемой. А именно: после двух проходов симметрии не получилось, а справа всегда возникает небольшое остаточное значение:
Возможно, я что-то делаю неверно? Похоже мне не удаётся верно реализовать разворот между проходами на правой границе. Глазом это не заметно, но как0то не правильно это.
Вообще, мне кажется, что если хочется простоты, то надо писать всё на JavaFX и не запариваться, он точно не сложнее чем python или тем более ruby. Если простота не цель — то можно писать «мясо» на Java.
Jython или JRuby думаю можно было бы использовать с JavaFX для описания логики, а JavaFX — для описания UI. Хотя это непростая задача: нужно правильно настроить classpath.
Вообще, это довольно странное и оригинальное пожелание. Честно говоря ни разу не слышал ничего подобного среди пожеланий :) Однако, на досуге попробую скрестить c Jython… если что выйдет — отпишусь.
В книге очень много железячных подробностей о том, как работает память, кэш и т.д.
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-платформы…
(277ms — 286ms); (279ms — 291ms); (133ms — 142ms)