В Москве цикл некоторых светофоров дольше ста секунд. Проедешь на зелёный или постоишь на красном — рандом, даже если нет прочих факторов. Не очень понятно, что можно на таком масштабе предсказывать. Впрочем, на более-менее далёких поездках тот же яндекс навигатор тоже может сильно ошибаться со временем или советовать 3 неоптимальных маршрута, а для оптимального надо будет добавить промежуточную точку.
Не нужно там 11 текстур (и 3 тоже не нужно), достаточно одной, которая будет, например, в альфа-канале хранить высоту ворсинки (вряд ли ворсинка будет менять свой цвет с высотой, а если и будет, то можно сделать изменение для всех ворсинок сразу).
При рисовании просто сравнивать "высоту" текущего полигона с высотой ворсинки и на основении этого решать, рисовать её или нет.
Это позволит менять детализацию ковра на лету. Если он далеко — рисуем 2-3 прямоугольника, если близко и видом сбоку — то все 20.
Но когда пишу что-то на динамически меня постоянно мучает вопрос — а вдруг мне кто-то, передаст в функцию не то, что ожидается на входе, и всё пойдёт не так, как предпологалось.
Даже хуже. Если разбираться в исходниках какого-нибудь tensorflow, то там у функции может быть 50 строчек проверок входных параметров (потому что там, например, в качестве входных данных может прийти и тензор, и список тензоров, и кортеж списков тензоров, а ещё есть куча параметры по-умолчанию, некоторые сочетания которых могут быть невалидными), и только потом будет вызываться функция с примерно таким же именем, в которой проверки уже не делаются.
Документация местами тоже божественная, например, "loss_func is loss function" — а с какими аргументами она будет вызвана, я сам должен угадать. При том что в нормальном языке просто в типах уже была бы информация о типах аргументов коллбека.
И самое противное — мой изначально простой код типа load_image() обрастает такой же кучей проверок (каждая была добавлена после очередного падения в рантайме и поиска бага), потому что часть png картинок грузятся как трёхмерные массивы numpy с тремя или четырьмя каналами, иногда чёрно-белые картинки вместо этого грузятся как двухмерные массивы, а ещё иногда тип данных в массиве оказывается не uint8 с интервалом 0..255, а float с интервалом 0..1.
Что-то алгоритмически сложное намного приятнее отлаживать тестами, чем методом пристального взгляда. Оптимизации производить тоже намного спокойнее — если алгоритм ломается, сразу об этом узнаёшь и понимаешь, в каком месте причина. Наличие тестов экономит кучу времени и даёт реальную свободу для внесения изменений. (Впрочем, в остальном коде тесты я почти не пишу, хотя надо бы)
Выделенные полосы для ОТ надо делать в городах, обязательно.
И не чистить их зимой от снега, прям как на фотографии выше. На дороге постоянный поток машин хоть как-то прокатывает в снегу колеи, на выделенках такого нет. Как же "весело" было ездить после снегопадов в автобусах в Москве — автобус сначала не может прижаться к остановке (там каша из снега), потом не мог от неё отъехать — задние колёса буксуют в снегу, иногда корму вообще на встречку выносит.
Ещё веселее увидеть в приложении два подъезжающих автобуса, оценить давку при посадке в первый и решить подождать второго. Второй оказывается "невидимкой" и ты кукуешь на остановке дальше.
А я слышал, что графики уравнений третьей степени и ниже можно отнести к конечному количеству типов.
функция монотонная (растёт, убывает или константа)
функция убывает, а потом возрастает.
функция возрастает, потом убывает.
функция возрастает, убывает и снова возрастает
функция убывает, возрастает и снова убывает
Прочие более-менее гладкие функции можно интерполировать кубическим сплайном — т.е., свести к комбинации полиномов третьего порядка.
Не, ну серьёзно — при взгляде на эти плавные красивые графики возникает ощущение, что их строили по очень малому количеству опорных точек. (Кроме последних двух) Можно сделать какие-то предположения о схожести/различности произведений, но не более того.
Вдобавок, в книге могут переплетаться несколько сюжетных линий, и эмоциональный окрас каждой может быть своим. Например, один гг скатывается, второй в это время возвышается, про третьго автор вообще на какое-то время забыл. Можно происходящие события описывать не в хронологическом порядке. В этих случаях метод с графиками по пяти-шести точкам окажется довольно бесполезным.
Хотелось бы увидеть более подробное описание того, как kotlin native сделано "внутри".
Объекты создаются в куче или на стеке? Если второе, то что будет с общепринятой в jvm языках практикой, когда внутри функции создаётся объект и возвращается ссылка на него? Можно ли управлять, в какой памяти, где создаётся объект? Можно ли определить свои аллокаторы?
В jvm есть сборщик мусора, и обычно код пишется так, что в нём граф взаимосвязей между объектами может содержать циклы. Как реализовано удаление объектов в native? Там есть свой сборщик мусора?
Какой оверхед по размеру создаваемой библиотеки по сравнению с чистым си?
Как конечное время жизни указателей, пришедших из си, сочетается с кодом в котлине? Например, если есть неизменяемый объект, содержащий указатель, который в один прекрасный момент станет невалидным?
В одной проблеме виноваты ламеры включившие с бодуна редирект, но не переместившие в новое место свои файлы.
Поэтому мы их удалим, пускай страдают. Хорошая логика.
В двух ошибках виноваты производители железа со своими кривыми драйверами.
Зачем заранее тестировать драйвера, если можно сразу разослать их некоторым пользователям и посмотреть на их реакцию?
P.S. Если я как пользователь вручную обновляю драйвера или систему — значит, я никуда не тороплюсь и я буду знать, что было причиной неполадок. Но если косяки происходят в системе, которая обновляется без моего участия в самый неподходящий момент, то в неполадках можно винить только саму систему.
Кстати, в книге "3D Math Primer for Graphics and Game Development" (она приведена в конце статьи) очень хорошо объяснены кватернионы и приведена их реализация на C++. Имхо, намного подробнее и понятнее, чем в статье выше. Я когда читал книгу, потихоньку написал свою велосипеднуюреализацию на java.
И в час пик любой транспорт полностью заполняется на крайней паре остановок. Потом на протяжении всего маршрута в него уже не сесть — будет «как сельди».
Если бы автобусы шли почаще, то на крайних остановках не успевал бы накапливаться народ.
Воу, очень прикольно получилось. Похожие мысли приходили в голову, но я хотел на выходе иметь не строку с glsl кодом, а синтаксическое дерево, которое потом можно конвертировать либо в glsl, либо как-то отлаживать и тестировать на CPU.
В нашем проекте компиляция шейдеров может происходить в игровом цикле по требованию, и подобные выделения объектов порождают major вызовы GC, появляются лаги.
Подождите, но ведь шейдер можно при загрузке скомпилировать только один раз, и нагрузка от этого одного раза не должна быть большой. Вдобавок, телефон при загрузке шейдера всё равно будет сам его как-то парсить и компилировать для gpu.
Поэтому мы решили перенести сборку исходников шейдеров на этап компиляции с использованием обработчика аннотаций.
Если список шейдеров известен заранее, то их же можно грузить не в иговом цикле, а только один раз — при загрузке приложения.
Но у меня шейдеров не очень много, поэтому оказалось проще писать их в glsl файликах. Единсвенное синтаксическое улучшение — я реализовал синтаксис типа shader.uniformName=uniformValue для установки юниформ, но он без проверок на корректность.
Хайп-то не вокруг книги самой по себе, а всего скорее вокруг темы про Поттера.
Гарри Поттера не читал, от книги получил огромное удовольствие. Я поражался, насколько глубоко способен мыслить автор, и после чтения книги взглянул на мир по-новому.
Например, машина времени. Большинство авторов не способны произвести что-то большее, чем убийство бабочки/влияние на собственного дедушку, происходящее при этом выглядит неестесственным.
Спойлер
Элиезер Юдковский описал способ решать NP задачи за полиномиальное время: сделать петлю во времени и придумать алгоритм, чтобы решение было неподвижной точкой. Это же шедевр!
Тут скорее будет не "ускорение интернета" а "незамедление интернета избранному трафику" — возможность сегментировать рынок и устроить дефицит интернета, которого вроде бы должно хватать на всех.
Будут тарифы (да уже и сейчас появляются, только ограничение по трафику), позволяющие на нормальной скорости посещать только контактик/мейлрушечку. А тарифы с адекватным интернетом можно будет продавать подороже. (оправдание они без проблем придумают — например, скажут, что сервера контактика в России и он вообще важный сервис, а гугл/ютуб/ваш-любимый-сайт расположены за границей и вообще пропускного канала к ним не хватает)
Компьютер — это же не зубная щётка. Это обычная вещь, как кровать, стул или телевизор.
Компьютер — это это, за чем я провожу значительное время. Он настроен под меня, в нём есть набор нужного мне софта, мои проекты, личные записи, история браузера в конце концов. Делить это пространство с кем-то (даже с кем-то близким) я не хочу.
Определяю на глаз по сочетанию следующих признаков:
аккаунт создан недавно
это девушка (хотя, возможно, пользователям-девушкам пишут боты-парни)
кроме фотографий для аватарки, больше фоток нет
на стене репосты со странным временем (например, несколько репостов в одну и ту же минуту, а потом за полгода ничего). Ещё бывают репосты непрерывным потоком.
аналогично с автаркой — обычный человек не будет менять 4 аватарки за минуту и потом их вообще не обновлять.
Весь "авторский контент" — нескольо фоток, которые заодно есть на аватарке. Всё остальное — какие-то рандомные репосты.
в друзьях дофига каких-то странных людей или друзей очень мало.
Если бы я писал бота, я бы так явно не палился, но, по-видимому, с ботами не особенно борются и ботоводы делают как можно проще.
Для картинки делается размытие, и потом она с каким-то небольшим коэффициентом (типа 0.05 — 0.15) смешивается с исходной картинкой. Идея небольшого коэффициента в том, что яркая размытая область будет заметно влиять на тёмную, но при этом тёмная на яркую — практически нет. Это делается в HDR, где яркости тёмных и светлых объектов действительно сильно различаются. Таким образом, никакого "искусственного" отсечения по яркости не будет.
Имхо, единственное, что надо вывести — синус 12 градусов. Но поскольку в дневнике уже даны синусы и косинусы для 30 и 18 градусов и формула для синусов и косинусов суммы и разницы углов, то найти для 12 не так уж и сложно.
Но лично я так и не смог представить, где мне в жизни может пригодиться точное знание стороны пятнадцатиугольника.
В Москве цикл некоторых светофоров дольше ста секунд. Проедешь на зелёный или постоишь на красном — рандом, даже если нет прочих факторов. Не очень понятно, что можно на таком масштабе предсказывать. Впрочем, на более-менее далёких поездках тот же яндекс навигатор тоже может сильно ошибаться со временем или советовать 3 неоптимальных маршрута, а для оптимального надо будет добавить промежуточную точку.
Не нужно там 11 текстур (и 3 тоже не нужно), достаточно одной, которая будет, например, в альфа-канале хранить высоту ворсинки (вряд ли ворсинка будет менять свой цвет с высотой, а если и будет, то можно сделать изменение для всех ворсинок сразу).
При рисовании просто сравнивать "высоту" текущего полигона с высотой ворсинки и на основении этого решать, рисовать её или нет.
Это позволит менять детализацию ковра на лету. Если он далеко — рисуем 2-3 прямоугольника, если близко и видом сбоку — то все 20.
Даже хуже. Если разбираться в исходниках какого-нибудь tensorflow, то там у функции может быть 50 строчек проверок входных параметров (потому что там, например, в качестве входных данных может прийти и тензор, и список тензоров, и кортеж списков тензоров, а ещё есть куча параметры по-умолчанию, некоторые сочетания которых могут быть невалидными), и только потом будет вызываться функция с примерно таким же именем, в которой проверки уже не делаются.
Документация местами тоже божественная, например, "loss_func is loss function" — а с какими аргументами она будет вызвана, я сам должен угадать. При том что в нормальном языке просто в типах уже была бы информация о типах аргументов коллбека.
И самое противное — мой изначально простой код типа load_image() обрастает такой же кучей проверок (каждая была добавлена после очередного падения в рантайме и поиска бага), потому что часть png картинок грузятся как трёхмерные массивы numpy с тремя или четырьмя каналами, иногда чёрно-белые картинки вместо этого грузятся как двухмерные массивы, а ещё иногда тип данных в массиве оказывается не uint8 с интервалом 0..255, а float с интервалом 0..1.
Что-то алгоритмически сложное намного приятнее отлаживать тестами, чем методом пристального взгляда. Оптимизации производить тоже намного спокойнее — если алгоритм ломается, сразу об этом узнаёшь и понимаешь, в каком месте причина. Наличие тестов экономит кучу времени и даёт реальную свободу для внесения изменений. (Впрочем, в остальном коде тесты я почти не пишу, хотя надо бы)
И не чистить их зимой от снега, прям как на фотографии выше. На дороге постоянный поток машин хоть как-то прокатывает в снегу колеи, на выделенках такого нет. Как же "весело" было ездить после снегопадов в автобусах в Москве — автобус сначала не может прижаться к остановке (там каша из снега), потом не мог от неё отъехать — задние колёса буксуют в снегу, иногда корму вообще на встречку выносит.
Ещё веселее увидеть в приложении два подъезжающих автобуса, оценить давку при посадке в первый и решить подождать второго. Второй оказывается "невидимкой" и ты кукуешь на остановке дальше.
А я слышал, что графики уравнений третьей степени и ниже можно отнести к конечному количеству типов.
Прочие более-менее гладкие функции можно интерполировать кубическим сплайном — т.е., свести к комбинации полиномов третьего порядка.
Не, ну серьёзно — при взгляде на эти плавные красивые графики возникает ощущение, что их строили по очень малому количеству опорных точек. (Кроме последних двух) Можно сделать какие-то предположения о схожести/различности произведений, но не более того.
Вдобавок, в книге могут переплетаться несколько сюжетных линий, и эмоциональный окрас каждой может быть своим. Например, один гг скатывается, второй в это время возвышается, про третьго автор вообще на какое-то время забыл. Можно происходящие события описывать не в хронологическом порядке. В этих случаях метод с графиками по пяти-шести точкам окажется довольно бесполезным.
Хотелось бы увидеть более подробное описание того, как kotlin native сделано "внутри".
Поэтому мы их удалим, пускай страдают. Хорошая логика.
Зачем заранее тестировать драйвера, если можно сразу разослать их некоторым пользователям и посмотреть на их реакцию?
P.S. Если я как пользователь вручную обновляю драйвера или систему — значит, я никуда не тороплюсь и я буду знать, что было причиной неполадок. Но если косяки происходят в системе, которая обновляется без моего участия в самый неподходящий момент, то в неполадках можно винить только саму систему.
Кстати, в книге "3D Math Primer for Graphics and Game Development" (она приведена в конце статьи) очень хорошо объяснены кватернионы и приведена их реализация на C++. Имхо, намного подробнее и понятнее, чем в статье выше. Я когда читал книгу, потихоньку написал свою
велосипеднуюреализацию на java.Если бы автобусы шли почаще, то на крайних остановках не успевал бы накапливаться народ.
Воу, очень прикольно получилось. Похожие мысли приходили в голову, но я хотел на выходе иметь не строку с glsl кодом, а синтаксическое дерево, которое потом можно конвертировать либо в glsl, либо как-то отлаживать и тестировать на CPU.
Подождите, но ведь шейдер можно при загрузке скомпилировать только один раз, и нагрузка от этого одного раза не должна быть большой. Вдобавок, телефон при загрузке шейдера всё равно будет сам его как-то парсить и компилировать для gpu.
Если список шейдеров известен заранее, то их же можно грузить не в иговом цикле, а только один раз — при загрузке приложения.
Но у меня шейдеров не очень много, поэтому оказалось проще писать их в glsl файликах. Единсвенное синтаксическое улучшение — я реализовал синтаксис типа
shader.uniformName=uniformValueдля установки юниформ, но он без проверок на корректность.Я не читал научных статей на эту тему (наверно, как и многие другие). Красивое описание идеи оказалось для меня очень приятным открытием.
Лично я немного размышлял про путешествия во времени и неподвижную точку, но почему-то не пробовал связать это с алгоритмами.
Гарри Поттера не читал, от книги получил огромное удовольствие. Я поражался, насколько глубоко способен мыслить автор, и после чтения книги взглянул на мир по-новому.
Например, машина времени. Большинство авторов не способны произвести что-то большее, чем убийство бабочки/влияние на собственного дедушку, происходящее при этом выглядит неестесственным.
Элиезер Юдковский описал способ решать NP задачи за полиномиальное время: сделать петлю во времени и придумать алгоритм, чтобы решение было неподвижной точкой. Это же шедевр!
Тут скорее будет не "ускорение интернета" а "незамедление интернета избранному трафику" — возможность сегментировать рынок и устроить дефицит интернета, которого вроде бы должно хватать на всех.
Будут тарифы (да уже и сейчас появляются, только ограничение по трафику), позволяющие на нормальной скорости посещать только контактик/мейлрушечку. А тарифы с адекватным интернетом можно будет продавать подороже. (оправдание они без проблем придумают — например, скажут, что сервера контактика в России и он вообще важный сервис, а гугл/ютуб/ваш-любимый-сайт расположены за границей и вообще пропускного канала к ним не хватает)
Элементарно — создать второго пользователя.
Компьютер — это это, за чем я провожу значительное время. Он настроен под меня, в нём есть набор нужного мне софта, мои проекты, личные записи, история браузера в конце концов. Делить это пространство с кем-то (даже с кем-то близким) я не хочу.
Осталось, чтобы google play и app store подтянулись, а то практически во всех мобильных играх приторная мультяшная графика без крови и прочего.
Определяю на глаз по сочетанию следующих признаков:
Если бы я писал бота, я бы так явно не палился, но, по-видимому, с ботами не особенно борются и ботоводы делают как можно проще.
Искал как сделать bloom, нашёл красивую идею: https://www.gamedev.net/forums/topic/693388-bloom/?do=findComment&comment=5362111
Для картинки делается размытие, и потом она с каким-то небольшим коэффициентом (типа 0.05 — 0.15) смешивается с исходной картинкой. Идея небольшого коэффициента в том, что яркая размытая область будет заметно влиять на тёмную, но при этом тёмная на яркую — практически нет. Это делается в HDR, где яркости тёмных и светлых объектов действительно сильно различаются. Таким образом, никакого "искусственного" отсечения по яркости не будет.
Имхо, единственное, что надо вывести — синус 12 градусов. Но поскольку в дневнике уже даны синусы и косинусы для 30 и 18 градусов и формула для синусов и косинусов суммы и разницы углов, то найти для 12 не так уж и сложно.
Но лично я так и не смог представить, где мне в жизни может пригодиться точное знание стороны пятнадцатиугольника.