Я понимаю что это часть текста. Конкретно — это подпись «автора» живущего в том мире. В этом случае это оформляется иначе, вот так:
Скрытый текст
То есть это должно быть выровнено по правому краю, в то время, как основной текст — по левому. Иначе это просто очередной заурядный абзац главы/рассказа.
Водитель знать про двигатель внутреннего сгорания должен, но точно не должен его разрабатывать, а предприятие, на котором водитель вынужден настраивать карбюратор, скорее всего, не самое эффективное.
Зачем водителю велосипеда знать про двигатель внутреннего сгорания? ;-)
Бумаги без reference implementation я бы вообще не смотрел (хотя довольно часто заказывают написание такой имплементации по какой-нибудь статье). А с ней проверяется достаточно быстро, стоящая вещь ли написана, или отписка для каких-либо конъюктурных целей.
Не знаю, может мне так «везло», но большинство бумаг, что я читал, были без реализации которую можно было бы взять, и попробовать сразу, без кодинга. Обычно реализовывать нужно было самому.
Является ли исследователь, проводящий сотни времени за такими экспериментами, программистом в общеприятом понимании этого слова. Workflow у такого человека, как и требуемые навыки, сильно другие.
Я бы отказался от самого понятия «общепринятое понимание» применительно к программистам. Программисты они сильно разные, область то очень широкая. Если проводить аналогию, то это всё равно что под «водителем транспортного средства», куда включены и те кто на самокатах да на велосипедах катается, гужевой транспорт, легковые автомобили, грузовые, автобусы, самолеты и космические корабли, подразумевать только какую-то одну категорию, ну например велосипедистов (а может какую-то другую, ведь про программистов то мы не уточняли!).
Должен ли водитель знать про двигатель внутреннего сгорания? :-)
О, исследовательские папиры это вообще пестня отдельная. Там обычно все хорошо работает на довольно узком множестве входных условий. Шаг влево-вправо, и всё, приплыли!
Это я помню, был один папир про компенсацию motion artefacts на фотоплетизмограмме через адаптивную фильтрацию. Всё было построено на том, что между ускорением и motion artefact'ом на фотоплетизмограмме имеется линейная корреляция. Приведены примеры, и у них там всё так хорошо было. Вот сигнал сырой (изображена страшная жесть), а вот сигнал восстановленный (вполне себе пульсовая волна, хоть и видно что слегка кривоватая). То есть у них всё было хорошо.
Но есть нюанс — не все motion artefacs линейно коррелируют с ускорением :-) То есть в результате эти самые артефакты поделились на три категории — там где есть линейная корелляция (ну, например если человек прыгает — там не то что корреляция, там есть прямая причинно-следственная связь), там где корреляция не линейная (и прямой причинно следственной связи нет, точнее так — и ускорение и motion artefact вызваны общей причиной, но ни один из них не является причиной другого. Это например отжимания), и там где корреляции нет вовсе.
И вот таких вот нюансов на самом деле море. Поэтому частенько нельзя взять, реализовать то что есть в папире и чтобы сразу все стало хорошо. Так или иначе нужно проводить свои исследования и составлять свой рецепт под свою задачу основываясь на результатах чужих исследований.
Тут есть один нюанс — нужно не только уметь читать рецепты и по им готовить, но нужно и понимать их и уметь изменять. То есть знаний на уровне пользователя стандартных алгоритмов из stl — не всегда достаточно.
Какой бы пример привести… Ну, например ту же реализацию сортировки из stl — по крайней мере в gcc эта сортировка не является квиксортом, или сортировкой слиянием. Она не является каким-то одним алгоритмом вычитанным в книжке. Там используется несколько стандартных алгоритмов + эвристики (на маленьких наборах используем одно, на больших другое и так далее). И обогнать эту стандартную сортировку, реализовав какой-то один чистый алгоритм из книжки — малореально.
Поэтому если задача не клепать клей между DB и вёбом, и не просто набор ифов (бизнеслогика), то сборник рецептов нужно не только уметь читать и использовать, но и пополнять собственными рецептами, а также видоизменять существующие (понимая к чему это приведет).
Впрочем, я вполне понимаю, что вероятно большинство программистов таки да, лепят очередной GUI (быстрый, удобный, прорывной), клеят базу данных с вёбом, пишут развесистую бизнес логику и так далее. Им вероятно не слишком то, что я описал выше, нужно. А если вдруг нужно — то в конторе есть кто-то кто в этом разбирается (не академик, нет) и сможет подсказать что где глянуть и почему вдруг не работает.
Да, поясню — свёртка в лоб, это по сути FIR. Сложность соответственно: O(w*h*r^2) для 2D случая. (для 1D будет естественно O(w*r)). Это если без оптимизаций. С оптимизациями, учитывающими симметрию ядра, будет что-то вроде O(w*h*r).
Но всем известно что FIR в ряде случаев можно заменить на IIR, который имеет сложность O(w*h) в 2D и O(w) в 1D соответственно. То есть от «радиуса размытия» трудоёмкость не зависит. У IIR есть свои достоинства и свои недостатки, в частности его сложнее рассчитывать, можно получить неустойчивый фильтр. Ну и если хочется получить какую-то особую форму импульсной характеристики (например с плоской вершиной), то возможно придется городить фильтр высокого порядка. В частности и из за этого, мы от него и отказались (по крайней мере пока).
Во-первых я немного по работе с DSP возился (FFT, DCT, и всякие FIR & IIR — то было связано с обработкой данных с нашего фотоплетизмографа, нужно было выделять полезный сигнал, анализировать его (там много данных), давить шумы, детектировать и игнорировать motion artefacts и так далее).
Во-вторых конкретно с проблемой быстрого блюра со здоровенным ядром (то есть радиусом) я также сталкивался в нашем (пока-что) хобби-проекте, что родился на хакатоне: habrahabr.ru/company/intel/blog/176985/ — наш проект — Virtualens. С тех пор у нас алгоритмы улучшились, оно стало работать сильно быстрее и качество картинки существенно возросло. Теперь это реально расфокусировка.
Ну, а по теме — если вы пишете фотошоп, то вам необходимо как минимум уметь читать papers различных исследовательских работ по теме обработки изображений. То есть понимать их язык, не пугаться математики, и без проблем залезть в спец. литературу. То есть совсем-совсем без технического образования будет действительно тяжко, но и академиком быть не нужно.
А ещё очень здорово научиться читать патенты — там много интересного, но там такой язык и такой стиль изложения… Нет, я лучше очередной дисер прочитаю.
Да, и один из рецептов увеличения популярности — сделать облегченную версию планетсов, с упрощенными правилами и ориентированными на блиц-партии. Блиц-партия должна полностью играться минут за 15-30. На смартфоне всё равно не поиграешь, но вполне поиграешь вечером, или в выходные. Как народ играет в тот же www.wesnoth.org/.
Angry Birds популярна за счет того, что там можно в любой момент прекратить играть. То есть если есть свободные 3 минуты, то можно погонять Angry Birds, если прервут — ничего страшного. С планетсами так не выйдет. Загрузка партии в мозг, то есть восстановление контекста, длится минут 10. Если тебя отвлекли когда ты начал делать ход, то считай ты ничего и не сделал. В следующий раз придется думать почти с нуля. Когда делаешь ход требуется довольно высокая концентрация. Это чем-то схоже с программированием, и это слабо зависит от уровня графики и простоты управления (хотя и уровень графики и простота управления действительно важны).
Ну, про планетсы я бы такого не сказал. Умирали они лет 6 назад. А сейчас ситуация пожалуй стабилизировалась — они так и не умерли до конца. Скажем на нашем сервере приток игроков сейчас пожалуй больше, чем отток (приток зачастую за счет ностальгирующих). Полноценные партии крутятся регулярно, на уровне не хуже чем лет 10 назад (хотя их конечно меньше чем 10 лет назад).
А с появлением planets.nu/ число игроков стало увеличиваться и у буржуев. Причем крутится там достаточно много партий ( planets.nu/#/games/openplanets.nu/#/games/full). Хотя там конечно, традиционно для буржуев, баланс… Да и условия победы/окончания партии довольно? на мой вкус, не вменяемые. Зато все чисто в браузере :-)
Дык есть же онлайн-версия :-) Впрочем, офлайн все ж лучше, а почта сейчас для пересылки ходов и в оффлайн не обязательна — файлики ходов можно через веб-морду сервера грузить.
А полный набор в планетсах как раз более важен чем в G+ — в них же каждый игрок, каждая раса, уникальна. То есть у них в отличае от G+ на старте все сразу разные. И на этом строится баланс. Если набор не полный, то баланс может перекосить.
Другое дело, что рас в планетсах всего 11, так что и игроков на партию нужно 11. Поэтому набрать проще.
Впрочем, мы пробовали и партии с усеченным набором рас (например 5 штук), если их правильно подобрать, то баланс не хуже полной партии, и при этом игра едет значительно шустрее и динамичней.
Никогда не думал, что в 2013 году настолько вновь станут актуальны такие произведения АБС как: «За миллиард лет до конца света», «Град обреченный» (привет, Дональд! 10 лет назад я не понимал тебя, а теперь понимаю) и «Трудно быть Богом». Они стали актуальны так, как задумывали их авторы, когда пытались бороться с предыдущим драконом.
То есть это должно быть выровнено по правому краю, в то время, как основной текст — по левому. Иначе это просто очередной заурядный абзац главы/рассказа.
Да, и вот это место нужно как-то переписать:
Зачем водителю велосипеда знать про двигатель внутреннего сгорания? ;-)
Не знаю, может мне так «везло», но большинство бумаг, что я читал, были без реализации которую можно было бы взять, и попробовать сразу, без кодинга. Обычно реализовывать нужно было самому.
Я бы отказался от самого понятия «общепринятое понимание» применительно к программистам. Программисты они сильно разные, область то очень широкая. Если проводить аналогию, то это всё равно что под «водителем транспортного средства», куда включены и те кто на самокатах да на велосипедах катается, гужевой транспорт, легковые автомобили, грузовые, автобусы, самолеты и космические корабли, подразумевать только какую-то одну категорию, ну например велосипедистов (а может какую-то другую, ведь про программистов то мы не уточняли!).
Должен ли водитель знать про двигатель внутреннего сгорания? :-)
Короче, чтобы воду в ступе не толочь, вот статейка на тему: habrahabr.ru/post/151157/
:-)
Это я помню, был один папир про компенсацию motion artefacts на фотоплетизмограмме через адаптивную фильтрацию. Всё было построено на том, что между ускорением и motion artefact'ом на фотоплетизмограмме имеется линейная корреляция. Приведены примеры, и у них там всё так хорошо было. Вот сигнал сырой (изображена страшная жесть), а вот сигнал восстановленный (вполне себе пульсовая волна, хоть и видно что слегка кривоватая). То есть у них всё было хорошо.
Но есть нюанс — не все motion artefacs линейно коррелируют с ускорением :-) То есть в результате эти самые артефакты поделились на три категории — там где есть линейная корелляция (ну, например если человек прыгает — там не то что корреляция, там есть прямая причинно-следственная связь), там где корреляция не линейная (и прямой причинно следственной связи нет, точнее так — и ускорение и motion artefact вызваны общей причиной, но ни один из них не является причиной другого. Это например отжимания), и там где корреляции нет вовсе.
И вот таких вот нюансов на самом деле море. Поэтому частенько нельзя взять, реализовать то что есть в папире и чтобы сразу все стало хорошо. Так или иначе нужно проводить свои исследования и составлять свой рецепт под свою задачу основываясь на результатах чужих исследований.
Какой бы пример привести… Ну, например ту же реализацию сортировки из stl — по крайней мере в gcc эта сортировка не является квиксортом, или сортировкой слиянием. Она не является каким-то одним алгоритмом вычитанным в книжке. Там используется несколько стандартных алгоритмов + эвристики (на маленьких наборах используем одно, на больших другое и так далее). И обогнать эту стандартную сортировку, реализовав какой-то один чистый алгоритм из книжки — малореально.
Поэтому если задача не клепать клей между DB и вёбом, и не просто набор ифов (бизнеслогика), то сборник рецептов нужно не только уметь читать и использовать, но и пополнять собственными рецептами, а также видоизменять существующие (понимая к чему это приведет).
Впрочем, я вполне понимаю, что вероятно большинство программистов таки да, лепят очередной GUI (быстрый, удобный, прорывной), клеят базу данных с вёбом, пишут развесистую бизнес логику и так далее. Им вероятно не слишком то, что я описал выше, нужно. А если вдруг нужно — то в конторе есть кто-то кто в этом разбирается (не академик, нет) и сможет подсказать что где глянуть и почему вдруг не работает.
Но всем известно что FIR в ряде случаев можно заменить на IIR, который имеет сложность O(w*h) в 2D и O(w) в 1D соответственно. То есть от «радиуса размытия» трудоёмкость не зависит. У IIR есть свои достоинства и свои недостатки, в частности его сложнее рассчитывать, можно получить неустойчивый фильтр. Ну и если хочется получить какую-то особую форму импульсной характеристики (например с плоской вершиной), то возможно придется городить фильтр высокого порядка. В частности и из за этого, мы от него и отказались (по крайней мере пока).
Во-первых я немного по работе с DSP возился (FFT, DCT, и всякие FIR & IIR — то было связано с обработкой данных с нашего фотоплетизмографа, нужно было выделять полезный сигнал, анализировать его (там много данных), давить шумы, детектировать и игнорировать motion artefacts и так далее).
Во-вторых конкретно с проблемой быстрого блюра со здоровенным ядром (то есть радиусом) я также сталкивался в нашем (пока-что) хобби-проекте, что родился на хакатоне: habrahabr.ru/company/intel/blog/176985/ — наш проект — Virtualens. С тех пор у нас алгоритмы улучшились, оно стало работать сильно быстрее и качество картинки существенно возросло. Теперь это реально расфокусировка.
Ну, а по теме — если вы пишете фотошоп, то вам необходимо как минимум уметь читать papers различных исследовательских работ по теме обработки изображений. То есть понимать их язык, не пугаться математики, и без проблем залезть в спец. литературу. То есть совсем-совсем без технического образования будет действительно тяжко, но и академиком быть не нужно.
А ещё очень здорово научиться читать патенты — там много интересного, но там такой язык и такой стиль изложения… Нет, я лучше очередной дисер прочитаю.
Вообще, реализация цильно зависит от деталей ТЗ. Например для нашей задачи и IIR оказался слишком медленным. Так что у нас теперь другое ;-)
Оно даже живое :-)
А с появлением planets.nu/ число игроков стало увеличиваться и у буржуев. Причем крутится там достаточно много партий ( planets.nu/#/games/open planets.nu/#/games/full). Хотя там конечно, традиционно для буржуев, баланс… Да и условия победы/окончания партии довольно? на мой вкус, не вменяемые. Зато все чисто в браузере :-)
А полный набор в планетсах как раз более важен чем в G+ — в них же каждый игрок, каждая раса, уникальна. То есть у них в отличае от G+ на старте все сразу разные. И на этом строится баланс. Если набор не полный, то баланс может перекосить.
Другое дело, что рас в планетсах всего 11, так что и игроков на партию нужно 11. Поэтому набрать проще.
Впрочем, мы пробовали и партии с усеченным набором рас (например 5 штук), если их правильно подобрать, то баланс не хуже полной партии, и при этом игра едет значительно шустрее и динамичней.
Никогда не думал, что в 2013 году настолько вновь станут актуальны такие произведения АБС как: «За миллиард лет до конца света», «Град обреченный» (привет, Дональд! 10 лет назад я не понимал тебя, а теперь понимаю) и «Трудно быть Богом». Они стали актуальны так, как задумывали их авторы, когда пытались бороться с предыдущим драконом.