Это потому что в JSON (как и в JavaScript) все числа - это float64, поэтому нужно их читать как float64 и сразу конвертировать в int, или (предпочтительнее) сразу демаршалировать в аннотированную структуру вместо map[string]any.
Еще замечу пропущенные > при конвертации / из XPath в CSS.
Плюс, некоторые из "отсутствующих" CSS селекторов на самом деле существуют, например: a:is([name],[href]) ⇐ //a[@name or @href] body > div:nth-last-of-type(2) ⇐ //body/div[last()-1] body > div:nth-of-type(-n+2) ⇐ //body/div[position()<3] *:has(> a) ⇐ //a/parent::* h1 ~ h2:last-of-type ⇐ //h1/following-sibling::h2[last()]
Аналогом //div[2] является div:nth-of-type(2), а не div:nth-child(2). Возможно, поэтому у вас "в хроме тоже может глючить". Да и в Firefox я не припомню проблем с querySelector для селектора с псевдоклассом (кроме бага с использованием псевдоклассов внутри :has), может разве что в совсем ранних версиях что-то такое и было.
Я просто про то, что в случае отверстия логично брать интеграл по отверстию, а в случае тени от объекта - интеграл по тени и вычитать его из незатененного значения, которое обычно известно.
Помехи на экране вызваны тем, что интеграл считается по некоторой ограниченной области, что хорошо работает для щелей, но показывает себя плохо для ситуаций, когда некоторый объект перекрывает источник света.
А если заменить на и посчитать первый интеграл аналитически для (будет, очевидно, )?
Можно компилировать в перемещаемый (relocatable) код и не зависеть от адреса, можно шарить код между процессам (про потоки молчу — там и так единое адресное пространство), и т.д. В общем было бы желание, а решить такую проблему можно.
Если я правильно понял, то можно считать, что на ребре задается просто некоторый набор чисел (в данном случае параметров B-сплайна), детально описывающих функцию активации. Вот только меня смущает, что они строят такой сплайн по 50 точкам, т.к. в этом случае почти наверняка получится и переобучение, и чувствительность к шуму в данных, и куча локальных минимумов при обучении.
Тут нужно понимать, как создаются запутанные состояния, и не забывать, что спины квантуются. Представьте, что мы создали 2 фотона и измерили их суммарный спин. Если получили +2, то мы знаем, что каждый из фотонов имеет спин +1 и, соответственно, состояние не запутано. Аналогично для -2. И только если суммарный спин равен 0, то мы можем говорить о получении запутанного состояния {+,-} и {-,+}. В случае 3 частиц суммарный спин может быть -3, -1, +1, +3. Варианта получить спин 0 нет. Варианты -3 и +3 отбрасываем по той же причине. Далее, не нарушая общности, рассмотрим вариант полного спина +1, которому соответствует запутанное состояние {+,+,-}, {+,-,+} и {-,+,+}. И никаких странностей или невозможных состояний тут не возникает.
В общем, если мы не фиксируем полный спин, то мы не можем передавать информацию, а если фиксируем - то нужно учитывать возникающее пространство состояний.
Там еще нужно убирать гамма-коррекцию из исходного изображения, а в конце ее восстанавливать (т.к. засветка изображения является линейной функцией оптической толщи, если конечно пренебречь поглощением, но для атмосферы это наверное нормально, хотя и не совсем точно).
Кстати, у покомпонентного анализа может быть и физический смысл: коэффициент излучения является функцией частоты света, поэтому в идеальном случае можно было бы заложить в модель, например, релеевское рассеяние (или желтый свет свет от фонарей), чтобы более точно восстанавливать цвета. Но это в любом случае будет более сложным процессом, чем текущий поиск минимального значения среди компонент.
А почему работа ведется в RGB-пространстве? Мне кажется, было бы логичнее сначала перейти в любое цветовое пространство, где яркость является одним из компонентов, провести там коррекцию, а потом уже вернуться в RGB.
Можно было бы ввести кодирование base43 (символы пробела и % проблематично использовать в URL), но простой расчет показывает, что base10 все-равно выгоднее, т.к. (10/3) / log(10) < (11/2) / log(43). Хотя, разница не велика, а если есть возможность записать весь URL капсом, то можно сэкономить на переключении между режимами кодирования (и к тому же на длину сообщения в этом случае выделяется на 1 бит меньше, чем для цифрового кодирования).
Интересно, если б провести сканирование сайтов на Вордпресс с определением версий, то какая там картина сложилась бы.
Главная фича WordPress - обратная совместимость. Там нет мажорных версий, как в Joomla. Там просто каждый раз увеличивают версию на 0.1. Обратная совместимость ломается только если это связано с безопасностью. Поэтому там не так страшно обновляться, и как правило это делается даже без развертывания stage-окружения.
У меня когда-то был небольшой сайт на WordPress, который просуществовал с 2007 по 2019, и парочка плагинов разработанных для WordPress 2.3 без каких-либо исправлений прожили до 4.9 (наверняка и с последующими версиями проблем бы не было, но к тому моменту сайт уже давно отслужил своё).
Плюс, в WordPress всегда можно быстренько поговнокодить в functions.php, чтобы на лету добавить/убрать необходимое без создания полноценного плагина. Поэтому и порог вхождения там гораздо ниже (но и, как следствие, качество кода большинства плагинов - тоже).
На самом деле, в самолетах действительно есть стоп-кран, и он действительно обычно красного цвета (можете погуглить фото). GPT4 выдает вполне верный ответ:
Стоп-кран (также известный как "fire handle" или "engine fire handle") в самолете — это устройство, используемое для прекращения подачи топлива, гидравлической жидкости и пневматического давления в двигатель в случае пожара или другой аварийной ситуации. В большинстве коммерческих и военных самолетов стоп-краны обычно имеют красный цвет, чтобы их было легко идентифицировать в критических ситуациях. Красный цвет является универсальным сигналом опасности и требует немедленного внимания, что делает его идеальным выбором для таких важных устройств управления.
Насколько я помню, в Unicode 1.0 для codepoint не было такого ограничения, но уже в какой-то из последующих версий это было добавлено, т.к. кодировка UTF-16 не способна представлять большие значения через механизм суррогатных пар.
Это потому что в JSON (как и в JavaScript) все числа - это float64, поэтому нужно их читать как float64 и сразу конвертировать в int, или (предпочтительнее) сразу демаршалировать в аннотированную структуру вместо map[string]any.
А почему выбран тип float64 для идентификаторов?
Еще замечу пропущенные
>при конвертации/из XPath в CSS.Плюс, некоторые из "отсутствующих" CSS селекторов на самом деле существуют, например:
a:is([name],[href])⇐//a[@name or @href]body > div:nth-last-of-type(2)⇐//body/div[last()-1]body > div:nth-of-type(-n+2)⇐//body/div[position()<3]*:has(> a)⇐//a/parent::*h1 ~ h2:last-of-type⇐//h1/following-sibling::h2[last()]Аналогом
//div[2]являетсяdiv:nth-of-type(2), а неdiv:nth-child(2). Возможно, поэтому у вас "в хроме тоже может глючить". Да и в Firefox я не припомню проблем сquerySelectorдля селектора с псевдоклассом (кроме бага с использованием псевдоклассов внутри:has), может разве что в совсем ранних версиях что-то такое и было.Я просто про то, что в случае отверстия логично брать интеграл по отверстию, а в случае тени от объекта - интеграл по тени и вычитать его из незатененного значения, которое обычно известно.
А если заменить
на 
и посчитать первый интеграл аналитически для 
(будет, очевидно, 
)?
Можно компилировать в перемещаемый (relocatable) код и не зависеть от адреса, можно шарить код между процессам (про потоки молчу — там и так единое адресное пространство), и т.д. В общем было бы желание, а решить такую проблему можно.
Как они ловко с версии 0.7 сразу перескочили на 24.x. Я тоже хочу так уметь.
Если я правильно понял, то можно считать, что на ребре задается просто некоторый набор чисел (в данном случае параметров B-сплайна), детально описывающих функцию активации. Вот только меня смущает, что они строят такой сплайн по 50 точкам, т.к. в этом случае почти наверняка получится и переобучение, и чувствительность к шуму в данных, и куча локальных минимумов при обучении.
Тут нужно понимать, как создаются запутанные состояния, и не забывать, что спины квантуются. Представьте, что мы создали 2 фотона и измерили их суммарный спин. Если получили +2, то мы знаем, что каждый из фотонов имеет спин +1 и, соответственно, состояние не запутано. Аналогично для -2. И только если суммарный спин равен 0, то мы можем говорить о получении запутанного состояния {+,-} и {-,+}. В случае 3 частиц суммарный спин может быть -3, -1, +1, +3. Варианта получить спин 0 нет. Варианты -3 и +3 отбрасываем по той же причине. Далее, не нарушая общности, рассмотрим вариант полного спина +1, которому соответствует запутанное состояние {+,+,-}, {+,-,+} и {-,+,+}. И никаких странностей или невозможных состояний тут не возникает.
В общем, если мы не фиксируем полный спин, то мы не можем передавать информацию, а если фиксируем - то нужно учитывать возникающее пространство состояний.
Ну, если так рассуждать, то развитие именно так и происходит:
Убийца машинного кода был написан на машинном коде.
Убийца ассемблера был написан на ассемблере.
Там еще нужно убирать гамма-коррекцию из исходного изображения, а в конце ее восстанавливать (т.к. засветка изображения является линейной функцией оптической толщи, если конечно пренебречь поглощением, но для атмосферы это наверное нормально, хотя и не совсем точно).
Кстати, у покомпонентного анализа может быть и физический смысл: коэффициент излучения является функцией частоты света, поэтому в идеальном случае можно было бы заложить в модель, например, релеевское рассеяние (или желтый свет свет от фонарей), чтобы более точно восстанавливать цвета. Но это в любом случае будет более сложным процессом, чем текущий поиск минимального значения среди компонент.
А почему работа ведется в RGB-пространстве? Мне кажется, было бы логичнее сначала перейти в любое цветовое пространство, где яркость является одним из компонентов, провести там коррекцию, а потом уже вернуться в RGB.
Можно было бы ввести кодирование base43 (символы пробела и % проблематично использовать в URL), но простой расчет показывает, что base10 все-равно выгоднее, т.к. (10/3) / log(10) < (11/2) / log(43). Хотя, разница не велика, а если есть возможность записать весь URL капсом, то можно сэкономить на переключении между режимами кодирования (и к тому же на длину сообщения в этом случае выделяется на 1 бит меньше, чем для цифрового кодирования).
Главная фича WordPress - обратная совместимость. Там нет мажорных версий, как в Joomla. Там просто каждый раз увеличивают версию на 0.1. Обратная совместимость ломается только если это связано с безопасностью. Поэтому там не так страшно обновляться, и как правило это делается даже без развертывания stage-окружения.
У меня когда-то был небольшой сайт на WordPress, который просуществовал с 2007 по 2019, и парочка плагинов разработанных для WordPress 2.3 без каких-либо исправлений прожили до 4.9 (наверняка и с последующими версиями проблем бы не было, но к тому моменту сайт уже давно отслужил своё).
Плюс, в WordPress всегда можно быстренько поговнокодить в functions.php, чтобы на лету добавить/убрать необходимое без создания полноценного плагина. Поэтому и порог вхождения там гораздо ниже (но и, как следствие, качество кода большинства плагинов - тоже).
Юмористы
А у меня получилось N=log(0.95)/log(0.9999)≈513.
Кажется, в BASIC 2 строки внизу экрана были зарезервированы, поэтому доступная высота сокращалась до 176.
На самом деле, в самолетах действительно есть стоп-кран, и он действительно обычно красного цвета (можете погуглить фото). GPT4 выдает вполне верный ответ:
Насколько я помню, в Unicode 1.0 для codepoint не было такого ограничения, но уже в какой-то из последующих версий это было добавлено, т.к. кодировка UTF-16 не способна представлять большие значения через механизм суррогатных пар.
Могу сослаться на определение в текущем стандарте:
https://www.unicode.org/versions/Unicode15.1.0/ch03.pdf
"Unicode codespace: A range of integers from 0 to 10FFFF."