Мне кажется, подвох в том, что боты телеграмма немного ограничены в возможностях, (например, не могут искать по истории чата, видят только новые сообщения, не видят сообщения других ботов и т.п.), а так бот может пригласить в канал аккаунт "человека" и тот всё посмотрит через более мощное api для пользователей.
Администрацию хабра всё устраивает - они получают деньги за корпоративные аккаунты и паразитируют на контенте обычных авторов, публикующихся бесплатно. И намешивают к этому контенту корпоративных рекламных статей без возможности их скрыть.
Я полгода назад написал статью типа этой, только с более жёсткими формулировками и конкретными примерами: https://habr.com/ru/articles/878768/. Администрация хабра статью убрала в чулан (скрыли из ленты), не смотря на рейтинг +395. А когда в копроблоге выходит статья с заголовком типа "Проект Горижопа" https://habr.com/ru/companies/geltek/articles/505526/ - это для администрации хабра нормально, так можно. Так что люди голосуют ногами и разбегаются по телеграм каналам, личным страничкам и другим сайтам.
Всё-таки вторая задача не даёт мне покоя. Там вроде можно не переходить к матрицам, смотрите (хабр не даёт формулы в комментарии писать, поэтому пишу как могу):
Ротор это exp(e23 * wt / 2) Если выхотите посмотреть, как он действует на элемент e1, то можно просто написать так: exp(e23 * -wt / 2) e1 exp(e23 * wt / 2) И дальше всё просто: (cos(-wt / 2) - e23 sin(wt/ 2)) e1 exp(e23 * wt / 2) дальше я перенесу e1 влево. косинус не изменится, и у синуса знак останется прежним, потому что (e2 e3) e1 = -e2 e1 e3 = e1 (e2 e3) Получается, что exp(e23) и e1 коммутативны, а экспоненты exp(e23 wt / 2) exp(e23 - wt/ 2) перемножатся в единицу. e1 exp(e23 -wt/ 2) exp(e23 wt/2) = e1 И компонента e1 не вращается.
Если вместо e1 подставить e2, то формула будет отличается тем, что e23 e2 = - e2 e23 exp(e23 * -wt / 2) e2 exp(e23 * wt / 2) Я точно так же вынесу e2 влево, но знак у синуса поменяется. e2 (cos(wt / 2) + e23 sin(wt / t)) exp(e23 wt / 2) e2 exp(e23 wt) e2 (cos(wt) + e23 sin (wt)) e2 cos (wt) + e3 sin (wt) - т.е., компонента e2 будет вращаться в плоскости e2 e3. И аналогично с e3.
В статье выглядит странным переход к матрицам, когда можно точно так же продолжать в терминах e1 e2 e3
Ого, красиво! Жаль, когда я проходил квантмех, такого не рассказывали.
Единственное, что я бы хотел добавить (или наоборот услышать опревержение) - возможно, матричное представление для матриц Паули не является фундаментальным и лучше сразу мыслыть в терминах e1 e2 e3 c их свойствами.
И ещё мне кажется, что ротор и экспонента бивектора сами-по-себе более фундаментальные, чем их представление в виде синуса и косинуса. Например, если бы во второй задаче магнитное поле бы менялось со временем, в выражении под экспонентой ещё бы появился интеграл от времени. (Не помню как это правильно называется, там есть нюанс с некоммутативностью и тем как это правильно вычислять)
От себя добавлю, что я взял PGA для 3д, которое еще описывает перемещения, написал библиотеку и классическая механика туда тоже очень хорошо уложилась. Сила, приложенная к точке - это буквально точка, умноженная на вектор анти-внешним произведением (point v force), и результат - это линия. Силы в таком представлении аддитивны, причём и сила и вращательный умещаютсся в одном бивекторе. Если вдруг интересно - есть в моей статье на хабре и там же ссылки на код.
Raspberry pi 5 сильно быстрее и интереснее четвёртой. И кажется что для роли "ПК" хорошо подходит. Из того что я заметил:
процессор по ощущениям в 2-2.5 раза быстрее.
Видеоядро по ощущениям раза в 2-3 быстрее - если на четвёртой для просмотра видео в браузере нужы были приседания типа правильного кодека, драйверов и т.п. и экрана желательно не больше чем 1080p (а лучше 720), то в пятой спокойной тянет 1080р с любым кодеком в любом софте - на мой взгляд, уже близко к полноценному компьютеру.
Появилась аппаратная поддержка aes - в cryptsetup benchmark вместо 80 мегабайт в секунду теперь показывает все 1000.
Есть PCI-e gen2 x1 (это 500 мегабайт в секунду), можно по нему подключить ssd (и загружаться с него тоже, не используя sd карту). Ещё потенциально можно его переключить в gen3 (это гигабайт в секунду), но по-дефотлу gen2 и на ОС отличной от Rapsbian я не пробовал это делать.
сеть гигабитная (что на 4, что на 5), но на четвёртой я упирался в скорость процессора и шифрования, по локальной сети при копировании по sshfs видел цифры порядка 45 мегабайт в секунду на 4. На пятой смог увидеть больше ста.
Я правда использовал её в качестве сервера с убунтой, а не как ПК. Какие-то цифры и сравнения записывал сюда (листать в конец)
Ещё есть вариант на карту (если делать в 3д) накидать нерегулярную сетку, чтобы на ней попадались 5-6-7 угольники, и тогда явно заметных 12 полюсов не будет.
Можно в одной игре сделать одновременно мир-баранку, трубку и замкнутую карту. Я тоже когда-то хотел сделать клон цивилизации и пришёл к идее, что просто нужен интерфейс и за ним можно спрятать любую плоскую топологию
MapView{
getCell(position): Cell;
getDistance(pos1, pos2): int
getShortestPath(pos1, pos2): List<Cell>
}
Тогда просто при "провороте" направо или налево карта будет делать pos.х = pos.х % width и возвращать те же клетки. Рендер даже не будет подозревать подвоха. Единственный нюанс - замкнутая карта интереснее, при переходе через полюс мир поворачивается на 180 градусов и это надо будет отдельно обработать.
Но вообще мне кажется, что если делать именно глобальную стратегию, то хочется возможность обойти землю по кругу, непроходимый угол карты выглядит искусственным ограничением. С плоским миром на черепахе ладно, с современным миром - не очень.
Вентиляция в доме с механической вытяжкой и естественным притоком. На крыше стоят восемь вентиляторов, каждый на отдельное помещение. Когда включается вытяжка, в комнате создается разрежение, и свежий воздух сам заходит через приточные клапаны.
Не было бы лучше сделать в другую сторону - чтобы воздух подавался избыточным давлением (отфильтрованный), а потом сам расходился по соседним комнатам, вентиляции и щелям типа двери, приоткрытых окон и т.п.? Кажется, что вариант с "вытяжкой" с приоткрытым окном или щелью под дверью будет наоборот пыльцу/пыль с улицы затягивать.
Нейросеть должна выполнять задачи, а не размышлять над этическими проблемами.
Что пропаганда от дипсик, что отказы отвечать от chatgpt - и то и то ухудшает качество работы модели. Модель это инструмент, и она должна быть максимально рациональной и свободной от предрассудков и ограничений, а как её использовать - выбор и ответственность пользователя. При обучении и так сами собой получаются искажения в виде языка/смещённой обучающей выборки, добавление ограничений поверх делает только хуже.
Даже если LLM генерирует код вируса - её могут использовать разработчики антивирусов для тестирования.
А в какой форме хранить погрешность? Либо в длинной арифметике, но тогда уж сразу нужно в ней считать, либо во флоатах, и тогда нам нужна будет погрешность на погрешность :)
Физики у погрешности пишут только первую цифру и порядок. Обычно цель - оценить порядок бедствия и понять, в каком месте теряется точность. Для этой цели вполне хорошо подходит пара float, где первый float это значение и второй это погрешность. Формулы для погрешности сложения/умножения/синусов/косинусов и сходны с теми, что получаются при вычислении производных, там ничего сложного нет. Из минусов только то, что арифметических операций будет больше.
Мне кажется, нет. Наоборот, здесь связь с аналогиями - внимание как консьерж на входе, ограниченное количество мест в баре, две руки у бармена (которые обе не могут делать что-то сложное), стресс как вышибала, убийства в отеле как забывание. Вначале сложно вникнуть, но как будто после всех усилий оно лучше отложилось в памяти.
Я попробовал как в статье декомпилировать, там куча файлов и некоторые на десятки тысяч строк. Для меня загадка как там можно ошибку найти без понимания, как такое пишется и как оно должно работать
Кстати такое тоже у меня было, но с ноутбуком asus, купленным в 2016 году. Причём это винда как-то хитро планировала включение ночью для обновлений. Я настройками винды это поправить не смог и перешёл на Linux (были и другие причины, это был один из факторов), больше ноутубок по ночам не просыпался.
Да. На самых первых андроидах байт-код вообще интерпретировался и скорость была ужасная. Да и потом, до ART был Dalvik и он тоже был медленным. И были жёсткие ограничения по памяти (порядка десятков мегабайт на всё приложение). И, к сожалению, рынок устройств у пользователей тоже на несколько лет отстаёт от новинок ОС/железа, поэтому разработчики извращались как могли, чтобы приложения хоть как-то работали сразу на всём. И вдобавок java в Андроиде на кучу лет застряла на 6-7 версии (они давно говорят, что поддерживают java 8, но если например подсунуть байт-код третьей скалы собранный под 1.8, то окажется что поддержка не такая уж и полная, работать оно не будет). И вот из тех дремучих времён идут всякие стереотипы и костыли.
Итератор - аллок на хипе, класс, который вполне мог бы быть обычной структурой - аллок на хипе, даже простые операции типа перемножения матриц это либо аллоки, либо кэшированные в виде полей класса инстансы
Нет, современная JVM хорошо справляется с короткоживущими объектами. Например, если временный объект не покидает функцию, его на хипе можно не создавать. И если даже надо, то у каждого потока есть свой собственный кусочек памяти, когда он быстро и легко может насоздавать временных объектов.
Я бы наоборот сказал, что в java начинаются проблемы, когда разработчики вспоминают всякие устаревшие мифы про производительность и извращаются без какой-либо необходимости. Примеры: сделать пул объектов. Ожидание - нет расходов на создание/удаление. Реальность - объекты постоянно занимают память, объекты раскиданы по памяти как попало, можно случайно использовать объекты два раза или забыть освободить объект в пуле и получить утечку в памяти. Вместо удобства java получается стрельба по ногам в стиле С++. Кэшированные в виде полей класса инстансы: отвратительное решение. Во-первых будут весёлые баги при многопоточности, во-вторых JVM не может производить оптимизации и вынуждена реально писать/читать в этот объект в куче, потому что он доступен всем потокам. Самый треш, когда в libgdx в промежуточном вычислении используется вектор из трёх чисел и не покидает функцию, JVM могла бы его вообще не создавать, если бы не горе-оптимизаторы.
Я написал физический движок на Scala с неизменяемыми объектами для векторов-кватернионов и прочего: https://github.com/Kright/ScalaGameMath/blob/master/pga3d/shared/src/main/scala/com/github/kright/pga3d/Pga3dMotor.scala Думал, потому перепишу классы на изменяемые. Но сначала померял производительность. Оказалось, что вообще не нужно, и производительность такая же. Буквально в паре мест поправил после профайлера. Новые объекты для векторов буквально при каждой арифметической операции "создаются" - по факту хоть бы хны, работает быстро. Вот демка с машинкой: https://www.youtube.com/watch?v=wqt0ylxBqnU Шаг физики для десятка тел, сотня пружин и прочих связей, интегрирование методом Рунге-Кутты четвёртого порядка (т.е., с вычислением сил в четырёх точках на шаг) занимает 60 микросекунд. Я могу хоть 10к шагов в секунду сделать и при этом код очень просто написан.
Я понимаю когда у людей есть необходимость типа недостаточной производительности и отдела тестирования Sony, но намного чаще, к сожалению, люди не понимают что делают и просто пишут кривой сложный код, который ни разу не быстрее, но намного хуже поддаётся рефакторингу и оптимизации.
Мне кажется, подвох в том, что боты телеграмма немного ограничены в возможностях, (например, не могут искать по истории чата, видят только новые сообщения, не видят сообщения других ботов и т.п.), а так бот может пригласить в канал аккаунт "человека" и тот всё посмотрит через более мощное api для пользователей.
Администрацию хабра всё устраивает - они получают деньги за корпоративные аккаунты и паразитируют на контенте обычных авторов, публикующихся бесплатно. И намешивают к этому контенту корпоративных рекламных статей без возможности их скрыть.
Я полгода назад написал статью типа этой, только с более жёсткими формулировками и конкретными примерами: https://habr.com/ru/articles/878768/. Администрация хабра статью убрала в чулан (скрыли из ленты), не смотря на рейтинг +395. А когда в копроблоге выходит статья с заголовком типа "Проект Горижопа" https://habr.com/ru/companies/geltek/articles/505526/ - это для администрации хабра нормально, так можно. Так что люди голосуют ногами и разбегаются по телеграм каналам, личным страничкам и другим сайтам.
Всё-таки вторая задача не даёт мне покоя. Там вроде можно не переходить к матрицам, смотрите (хабр не даёт формулы в комментарии писать, поэтому пишу как могу):
Ротор это
exp(e23 * wt / 2)Если выхотите посмотреть, как он действует на элемент e1, то можно просто написать так:
exp(e23 * -wt / 2) e1 exp(e23 * wt / 2)И дальше всё просто:
(cos(-wt / 2) - e23 sin(wt/ 2)) e1 exp(e23 * wt / 2)дальше я перенесу e1 влево. косинус не изменится, и у синуса знак останется прежним, потому что
(e2 e3) e1 = -e2 e1 e3 = e1 (e2 e3)Получается, что exp(e23) и e1 коммутативны, а экспоненты
exp(e23 wt / 2) exp(e23 - wt/ 2)перемножатся в единицу.e1 exp(e23 -wt/ 2) exp(e23 wt/2) = e1И компонента e1 не вращается.
Если вместо e1 подставить e2, то формула будет отличается тем, что
e23 e2 = - e2 e23exp(e23 * -wt / 2) e2 exp(e23 * wt / 2)Я точно так же вынесу e2 влево, но знак у синуса поменяется.
e2 (cos(wt / 2) + e23 sin(wt / t)) exp(e23 wt / 2)e2 exp(e23 wt)e2 (cos(wt) + e23 sin (wt))e2 cos (wt) + e3 sin (wt)- т.е., компонента e2 будет вращаться в плоскости e2 e3. И аналогично с e3.В статье выглядит странным переход к матрицам, когда можно точно так же продолжать в терминах e1 e2 e3
Ого, красиво! Жаль, когда я проходил квантмех, такого не рассказывали.
Единственное, что я бы хотел добавить (или наоборот услышать опревержение) - возможно, матричное представление для матриц Паули не является фундаментальным и лучше сразу мыслыть в терминах e1 e2 e3 c их свойствами.
И ещё мне кажется, что ротор и экспонента бивектора сами-по-себе более фундаментальные, чем их представление в виде синуса и косинуса. Например, если бы во второй задаче магнитное поле бы менялось со временем, в выражении под экспонентой ещё бы появился интеграл от времени. (Не помню как это правильно называется, там есть нюанс с некоммутативностью и тем как это правильно вычислять)
От себя добавлю, что я взял PGA для 3д, которое еще описывает перемещения, написал библиотеку и классическая механика туда тоже очень хорошо уложилась. Сила, приложенная к точке - это буквально точка, умноженная на вектор анти-внешним произведением (point v force), и результат - это линия. Силы в таком представлении аддитивны, причём и сила и вращательный умещаютсся в одном бивекторе. Если вдруг интересно - есть в моей статье на хабре и там же ссылки на код.
Raspberry pi 5 сильно быстрее и интереснее четвёртой. И кажется что для роли "ПК" хорошо подходит. Из того что я заметил:
процессор по ощущениям в 2-2.5 раза быстрее.
Видеоядро по ощущениям раза в 2-3 быстрее - если на четвёртой для просмотра видео в браузере нужы были приседания типа правильного кодека, драйверов и т.п. и экрана желательно не больше чем 1080p (а лучше 720), то в пятой спокойной тянет 1080р с любым кодеком в любом софте - на мой взгляд, уже близко к полноценному компьютеру.
Появилась аппаратная поддержка aes - в
cryptsetup benchmarkвместо 80 мегабайт в секунду теперь показывает все 1000.Есть PCI-e gen2 x1 (это 500 мегабайт в секунду), можно по нему подключить ssd (и загружаться с него тоже, не используя sd карту). Ещё потенциально можно его переключить в gen3 (это гигабайт в секунду), но по-дефотлу gen2 и на ОС отличной от Rapsbian я не пробовал это делать.
сеть гигабитная (что на 4, что на 5), но на четвёртой я упирался в скорость процессора и шифрования, по локальной сети при копировании по sshfs видел цифры порядка 45 мегабайт в секунду на 4. На пятой смог увидеть больше ста.
Я правда использовал её в качестве сервера с убунтой, а не как ПК. Какие-то цифры и сравнения записывал сюда (листать в конец)
Вместо большого монитора могу посоветовать сразу три поставить - тогда ещё шея немного крутится (причём равномерно в обе стороны).
Ого, а как понять какое упражнение для глаз разминка и какое напряжение/расслабление? Сколько минут гимнастику для глаз делаете?
Ещё есть вариант на карту (если делать в 3д) накидать нерегулярную сетку, чтобы на ней попадались 5-6-7 угольники, и тогда явно заметных 12 полюсов не будет.
Можно в одной игре сделать одновременно мир-баранку, трубку и замкнутую карту.
Я тоже когда-то хотел сделать клон цивилизации и пришёл к идее, что просто нужен интерфейс и за ним можно спрятать любую плоскую топологию
Тогда просто при "провороте" направо или налево карта будет делать pos.х = pos.х % width и возвращать те же клетки. Рендер даже не будет подозревать подвоха.
Единственный нюанс - замкнутая карта интереснее, при переходе через полюс мир поворачивается на 180 градусов и это надо будет отдельно обработать.
Но вообще мне кажется, что если делать именно глобальную стратегию, то хочется возможность обойти землю по кругу, непроходимый угол карты выглядит искусственным ограничением. С плоским миром на черепахе ладно, с современным миром - не очень.
Не было бы лучше сделать в другую сторону - чтобы воздух подавался избыточным давлением (отфильтрованный), а потом сам расходился по соседним комнатам, вентиляции и щелям типа двери, приоткрытых окон и т.п.?
Кажется, что вариант с "вытяжкой" с приоткрытым окном или щелью под дверью будет наоборот пыльцу/пыль с улицы затягивать.
Да, потому что первый комментарий у пользователя.
Нейросеть должна выполнять задачи, а не размышлять над этическими проблемами.
Что пропаганда от дипсик, что отказы отвечать от chatgpt - и то и то ухудшает качество работы модели.
Модель это инструмент, и она должна быть максимально рациональной и свободной от предрассудков и ограничений, а как её использовать - выбор и ответственность пользователя. При обучении и так сами собой получаются искажения в виде языка/смещённой обучающей выборки, добавление ограничений поверх делает только хуже.
Даже если LLM генерирует код вируса - её могут использовать разработчики антивирусов для тестирования.
Физики у погрешности пишут только первую цифру и порядок. Обычно цель - оценить порядок бедствия и понять, в каком месте теряется точность.
Для этой цели вполне хорошо подходит пара float, где первый float это значение и второй это погрешность.
Формулы для погрешности сложения/умножения/синусов/косинусов и сходны с теми, что получаются при вычислении производных, там ничего сложного нет.
Из минусов только то, что арифметических операций будет больше.
Мне кажется, нет.
Наоборот, здесь связь с аналогиями - внимание как консьерж на входе, ограниченное количество мест в баре, две руки у бармена (которые обе не могут делать что-то сложное), стресс как вышибала, убийства в отеле как забывание.
Вначале сложно вникнуть, но как будто после всех усилий оно лучше отложилось в памяти.
Кучу лет жду value classes (да и от vector api не откажусь), но складывается чувство что их если и добавят, то через очень много лет :(
Я попробовал как в статье декомпилировать, там куча файлов и некоторые на десятки тысяч строк. Для меня загадка как там можно ошибку найти без понимания, как такое пишется и как оно должно работать
Кстати такое тоже у меня было, но с ноутбуком asus, купленным в 2016 году. Причём это винда как-то хитро планировала включение ночью для обновлений. Я настройками винды это поправить не смог и перешёл на Linux (были и другие причины, это был один из факторов), больше ноутубок по ночам не просыпался.
Да. На самых первых андроидах байт-код вообще интерпретировался и скорость была ужасная. Да и потом, до ART был Dalvik и он тоже был медленным.
И были жёсткие ограничения по памяти (порядка десятков мегабайт на всё приложение).
И, к сожалению, рынок устройств у пользователей тоже на несколько лет отстаёт от новинок ОС/железа, поэтому разработчики извращались как могли, чтобы приложения хоть как-то работали сразу на всём.
И вдобавок java в Андроиде на кучу лет застряла на 6-7 версии (они давно говорят, что поддерживают java 8, но если например подсунуть байт-код третьей скалы собранный под 1.8, то окажется что поддержка не такая уж и полная, работать оно не будет).
И вот из тех дремучих времён идут всякие стереотипы и костыли.
Да и с неработающей ассоциативностью несложно привести пример
1е20 + (-1е20) + 1.
Нет, современная JVM хорошо справляется с короткоживущими объектами. Например, если временный объект не покидает функцию, его на хипе можно не создавать. И если даже надо, то у каждого потока есть свой собственный кусочек памяти, когда он быстро и легко может насоздавать временных объектов.
Я бы наоборот сказал, что в java начинаются проблемы, когда разработчики вспоминают всякие устаревшие мифы про производительность и извращаются без какой-либо необходимости.
Примеры: сделать пул объектов. Ожидание - нет расходов на создание/удаление. Реальность - объекты постоянно занимают память, объекты раскиданы по памяти как попало, можно случайно использовать объекты два раза или забыть освободить объект в пуле и получить утечку в памяти. Вместо удобства java получается стрельба по ногам в стиле С++.
Кэшированные в виде полей класса инстансы: отвратительное решение. Во-первых будут весёлые баги при многопоточности, во-вторых JVM не может производить оптимизации и вынуждена реально писать/читать в этот объект в куче, потому что он доступен всем потокам. Самый треш, когда в libgdx в промежуточном вычислении используется вектор из трёх чисел и не покидает функцию, JVM могла бы его вообще не создавать, если бы не горе-оптимизаторы.
Я написал физический движок на Scala с неизменяемыми объектами для векторов-кватернионов и прочего: https://github.com/Kright/ScalaGameMath/blob/master/pga3d/shared/src/main/scala/com/github/kright/pga3d/Pga3dMotor.scala
Думал, потому перепишу классы на изменяемые. Но сначала померял производительность. Оказалось, что вообще не нужно, и производительность такая же. Буквально в паре мест поправил после профайлера. Новые объекты для векторов буквально при каждой арифметической операции "создаются" - по факту хоть бы хны, работает быстро.
Вот демка с машинкой: https://www.youtube.com/watch?v=wqt0ylxBqnU
Шаг физики для десятка тел, сотня пружин и прочих связей, интегрирование методом Рунге-Кутты четвёртого порядка (т.е., с вычислением сил в четырёх точках на шаг) занимает 60 микросекунд. Я могу хоть 10к шагов в секунду сделать и при этом код очень просто написан.
Я понимаю когда у людей есть необходимость типа недостаточной производительности и отдела тестирования Sony, но намного чаще, к сожалению, люди не понимают что делают и просто пишут кривой сложный код, который ни разу не быстрее, но намного хуже поддаётся рефакторингу и оптимизации.