Да. Но я сам перед написанием сообщения его запустил и проверил. До этого просто помнил, что после цикла можно написать else и никогда ни сам не писал, ни в реальном коде не видел.
Это пример бесполезного вопроса про "базовый синтаксис", на котором могут завалиться куча народу, но который ничего не говорит о реальных навыках.
Код пишется в первую очередь для чтения человеком, и только потом - для компьютера. Особенно это применимо к питону, который медленный донельзя и синтаксическими конструциями косит под английский язык.
55 == True is True
Что вернёт выражение? Правильный ответ: ...
Правильный ответ: не надо так писать. Chain comparison придумали для того, чтобы записывать условия типа 1 < n < 10, а не для того чтобы запутывать программиста.
Почему? Потому что Python использует ромбовидное наследование и алгоритм разрешения порядка поиска методов (MRO), основанный на линеаризации C3.
Замечательно. А теперь скажите честно - как часто Вы это используете в питоне? И ещё вопрос - а вы пробовали так сделать с классами, у которых в конструкторах есть разные аргументы? И в init в super() получить предыдущий тип в цепочке линеаризации и по этой цепочке попередавать аргументы? Вместо этих извращений намного проще и понятнее использовать композицию объектов, что все и делают. В языках типа Scala такая же линеаризация, но компилятор всё проверяет в compile time, в питоне я такое просто не захочу писать. Неосторожное изменение в любом классе и всё это наследование в динамическом языке рассыпается как карточный домик.
{("a", [1, 2]): "value"}
Может ли такой код выполниться без ошибок?
В реальности человек его запустит, код упадёт, а дальше он поймёт что список изменяемый и никакой проблемы не будет.
То есть my_list не создаётся заново при каждом вызове — вы каждый раз работаете с тем самым списком.
Окей, впервые полезный пример. Вернее, ужасные грабли питона, которые надо обходить стороной. Кстати, тот же Pycharm вам подсветит что аргумент по-умолчанию изменяемый.
print((x for x in range(3))) # Вывод: <generator object ...>
И что? Можно прекрасно писать код и никогда не использовать генераторы. Это не ключевая фича языка. То что они при итерировании ведут себя как одноразовый список, но при этом печатаются на экран как generator object - просто ещё одна особенность питона.
Вдобавок, в зависимости от того, что писал человек на питоне, его знания могут сильно отличаться. Например, для ML надо знать numpy и pythorch/tensorflow и можно годами не сталкиваться с асинхронными функциями, а можно писать на сайты и там буквально всё будет асинхронным.
Давайте, представьте что Вы сам на собеседовании и попробуйте скажите без запуска кода, что он выведет:
for i in range(2):
print(i)
break
else:
print("end")
А это же "база", "основы синтакстиса языка", и не важно что в реальности так практически никто не пишет.
Вполне возможно. Но организация труда включает в себя много чего кроме наличия переработок - хорошая зарплата, комфортные условия работы, хорошее оборудование, минимум бюрократии, повышение способных сотрудников, и мне кажется по всем этим пунктам российские госкомпании очень сильно проигрывают. Наверняка и в роскосмосе есть люди, работащие за идею и мечтающие о покорении космоса, но их результатов не видно.
Потом, когда электромобилей станет много, вспомнят про налоги, а заодно тоже введут платные номера, ограничения по чётности дней и по районам, чтобы ездили поменьше
Компании с правильной организацией труда должны были ли бы оказаться эффективнее, почему это не происходит?
Происходит.
Можно найти примеры, когда маленькие компании достигали того, что не удавалось большим или казалось невозможным.
Например, в роскосмосе 170 тысяч сотрудников, в spaceX было в 6000 человек в 2018 году (примерно тогда же разработали и начали запускать falcon heavy), сейчас около 13000. При этом spaceX разработали и начали запускать возвращаемые ракеты. Роскосмос сидел на советстком наследии, говорил что возвращаемые ракеты невозможны/нерентабельны и уже потерял почти весь рынок запусков.
Причём если посмотреть на язык Koka, то там эффектами выражаются штуки типа чистоты функций, возможности расходимости (незавершения), бросание исключений и т.п.: https://koka-lang.github.io/koka/doc/book.html#sec-effect-types И эффекты позволяют выразить то же самое, что делают монады типа Try или Option.
Так вот, можно ли смотреть на алгебраические эффекты как на альтернативу монадам в общем случае?
Так rsync тоже так умеет, если ему указать директорию предыдущего снапшота. Он сам создаст жёсткие ссылки для неизменившихся файлов. Зачем это делать через cp?
Вы написали про Cl(0, 0, 4) и я очень впечатлён, насколько оно похоже на Cl(3, 0, 1).
Но я бы ещё добавил, что в общем виде в уравнении точки в 3д четвёртый элемент тоже может быть отличным от единицы. Например, разностью двух точек будет вектор с четвёртым элементом-нулём и это валидная сущность.
Я надеюсь, вы как-нибудь потом напишете про Cl(3, 0, 1). Там смысл weight и bulk более понятен - это элементы которые в квадрате равны единице и элементы котороые в квадрате равны нулю. Причём, что интересно и красиво, и та и та нормализация (по bulk и по weight элементам) имеет смысл.
Например, для уравнения плоскости в общем виде можно либо привести к единице длину нормали, либо сделать "единичным" сдвиг от нуля координат) Для линии нормализация сделает единичное направление. Для уравнения точки - уберёт четвёртый элемент в единицу. Либо не уберёт для случая идеальной точки, но тогда можно хотя бы сделать другую нормализацию, чтобы сумма квадратов остальных трёх элементов давала единицу.
А ещё про смысл weight - если сказать что четвёртый элемент точки это вес, то сумма таких точек с массой будет точкой-центром масс.
Если не заблочить Яндекс метрику и иметь приложение Яндекса, то скрипт из браузера достучится до приложения и даже из приватной вкладки.
И ещё установленные приложения типа Яндекса или каких-нибудь госуслуг могут периодически подключаться к серверам и при включении ВПН будет заметно, что трафик откуда-то из другого места пошёл.
Вообще выглядит так, что проще два телефона иметь - один для всякой херни и второй со всем удалённым, потому что надёжно разграничить в пределах одного телефона как-то сложно.
Да вообще человечество свернуло куда-то не туда. Вместо того, чтобы просто ездить на автомобиле (автомобиль не обязан быть тяжёлым и большим, есть же Кей кары в Японии) и развивать инфраструктуру под них, придумывают кучу правил и ограничений на то как ездить, где парковаться и делают автомобили (при всей их универсальности и эффективности в плане перевозки людей и грузов) малоиспользуемыми. Весь прогресс откинули на сто лет назад и курьеры в городах на мускульной тяге возят/носят заказы по одному/два, хотя казалось бы в автомобиль можно на порядок больше заказов положить и на порядок дальше и быстрее отвезти.
И по этому "электровелосипеду" видно - нужен автомобиль с кузовом для грузов и с возможностью ездить и парковаться несмотря на ограничения для авто.
Согласен, у меня пока что три здания и несколько юнитов, и уже задача баланса является не простой. Одна надежда на помощь друзей в тестировании и анализ баланса параметров с использованием ИИ агентов :)
Для начала удобнее взять механики и характеристики юнитов из понравившейся игры. Потом, когда будет более-менее играбельный прототип, кастомизировать под свои желания.
В третьей цивилизации есть забавный момент - ресурсы игры типа картинок, звуков и описаний лежат в папке с игрой, а вот типы юнитов и их характеристики (и ссылки на файлы картинок, звуков и т.п.), дерево развития технологий, список чудес света, список видов ланшафта и прочее лежат прямо в файле сохранения. То есть можно прямо в этом файле юниту поменять характеристики типа атаки или количества очков передвижения, загрузить сохранение и увидеть изменения.
Кастомные сценарии так и сделаны - это просто поправленный сейв файл. И по этой же причине в игровом редакторе третей цивилизации можно спокойно менять характеристики юнитов на карте. И вот эта часть с деревом технологий и юнитами очень хорошо отвязана от движка игры - по-сути ей занимается геймдизайнер, а не разработчик, и поправить её можно в любой момент.
Самая ключевая часть - это "скелет" в виде игровых механик, а когда они есть подкрутить характеристики юниту и заменить графику должно быть несложно.
P.S. Вот описание формата в третьей цивилизации: https://github.com/Kright/civ3/blob/master/bicformat.txt Оно неполное, там рядом в репозитории я ещё что-то релевантное собрал. Я тогда ещё попробовал написать парсер сейвов с помощью kaitai struct, почти дошёл до завершения, но к сожалению не сохранил и потерял данные, а второй раз было уже лень.
Ещё для вдохновения и для изучения игровых механик можно посмотреть на 1-4 версии цивилизации - они довольно сильно отличаются от пятой, и я не скажу что отличие в качестве - скорее, они просто другие.
Причём добавление одной механики часто тянет за собой всё остальное - в третьей цивилизации можно было ставить неограниченное количество юнитов на клетку, города сами защищаться не умели, не-артиллериейские юниты не могли стрелять через несколько клеток, а в кораблик можно было сажать несколько наземных юнитов для перевозки по воде.
Имея ввиду экстраполяцию, можно предположить, что данная особенность распространяется на все множество таблиц степеней GF(p).
Так это же логично. Примерно как для обычных чисел у нас есть два корня из единицы (равные 1 и -1), а так же четыре корня четвёртой степени (-1, 1, i, -i), так и для вычетов простого числа так же, только вместо -1 там будет (p-1) и для четвёртой степени чуть сложнее.
Если внимательно посмотреть на таблицу степеней в gf(17), то в 8 колонке будут корни второй степени (которых ровно два и они 1 и 16), а в колонке 4 - корни четвёртой степени (1, 16, 4, 13)
А например в таблице степеней по модулю 19 можно корни третьей степени найти в колонках 6 и 12, их ровно три: 1, 7, 11
P. S. Ещё можно заметить что сумма всех корней степени n снова равна нулю, как и с комплексными числами.
P. P. S. а ещё можно в кольце вычетов по модулю простого числа найти подходящий корень из единицы и сделать преобразование Фурье на целых числах, примерно как с e(-ikw) на комплексных.
А что если порядок алгебры чётный и левое дополнение не равно правому? Какой смысл можно вложить в их разницу?
P.S. И ещё вопрос. Если в алгебре с чётным порядком в определении регрессивного произведения поменять местами левое и правое дополнения, произведение будет всё тем же или другим?
Да. Но я сам перед написанием сообщения его запустил и проверил. До этого просто помнил, что после цикла можно написать else и никогда ни сам не писал, ни в реальном коде не видел.
Это пример бесполезного вопроса про "базовый синтаксис", на котором могут завалиться куча народу, но который ничего не говорит о реальных навыках.
Код пишется в первую очередь для чтения человеком, и только потом - для компьютера. Особенно это применимо к питону, который медленный донельзя и синтаксическими конструциями косит под английский язык.
Правильный ответ: не надо так писать. Chain comparison придумали для того, чтобы записывать условия типа 1 < n < 10, а не для того чтобы запутывать программиста.
Замечательно. А теперь скажите честно - как часто Вы это используете в питоне? И ещё вопрос - а вы пробовали так сделать с классами, у которых в конструкторах есть разные аргументы? И в init в super() получить предыдущий тип в цепочке линеаризации и по этой цепочке попередавать аргументы? Вместо этих извращений намного проще и понятнее использовать композицию объектов, что все и делают.
В языках типа Scala такая же линеаризация, но компилятор всё проверяет в compile time, в питоне я такое просто не захочу писать. Неосторожное изменение в любом классе и всё это наследование в динамическом языке рассыпается как карточный домик.
В реальности человек его запустит, код упадёт, а дальше он поймёт что список изменяемый и никакой проблемы не будет.
Окей, впервые полезный пример. Вернее, ужасные грабли питона, которые надо обходить стороной. Кстати, тот же Pycharm вам подсветит что аргумент по-умолчанию изменяемый.
И что? Можно прекрасно писать код и никогда не использовать генераторы. Это не ключевая фича языка. То что они при итерировании ведут себя как одноразовый список, но при этом печатаются на экран как generator object - просто ещё одна особенность питона.
Вдобавок, в зависимости от того, что писал человек на питоне, его знания могут сильно отличаться. Например, для ML надо знать numpy и pythorch/tensorflow и можно годами не сталкиваться с асинхронными функциями, а можно писать на сайты и там буквально всё будет асинхронным.
Давайте, представьте что Вы сам на собеседовании и попробуйте скажите без запуска кода, что он выведет:
А это же "база", "основы синтакстиса языка", и не важно что в реальности так практически никто не пишет.
Напомнило песню "колхозный фронтенд": https://www.youtube.com/watch?v=AWXTIlwDRAM&list=RDAWXTIlwDRAM&start_radio=1
В качестве легализатора можно раздавать торренты
Вполне возможно. Но организация труда включает в себя много чего кроме наличия переработок - хорошая зарплата, комфортные условия работы, хорошее оборудование, минимум бюрократии, повышение способных сотрудников, и мне кажется по всем этим пунктам российские госкомпании очень сильно проигрывают. Наверняка и в роскосмосе есть люди, работащие за идею и мечтающие о покорении космоса, но их результатов не видно.
Потом, когда электромобилей станет много, вспомнят про налоги, а заодно тоже введут платные номера, ограничения по чётности дней и по районам, чтобы ездили поменьше
Происходит.
Можно найти примеры, когда маленькие компании достигали того, что не удавалось большим или казалось невозможным.
Например, в роскосмосе 170 тысяч сотрудников, в spaceX было в 6000 человек в 2018 году (примерно тогда же разработали и начали запускать falcon heavy), сейчас около 13000. При этом spaceX разработали и начали запускать возвращаемые ракеты. Роскосмос сидел на советстком наследии, говорил что возвращаемые ракеты невозможны/нерентабельны и уже потерял почти весь рынок запусков.
Или например можно почитать, что в WhatsApp когда-то было 32 разработчика, а потом его в 2014 году фейсбук купил за 19 миллиардов долларов: https://habr.com/ru/companies/ruvds/articles/758800/
Мах займёт нишу там-тама и icq перед закрытием - никому не нужный кривой мессенджер.
Монады не композируются, но есть интересное направление с алгебраическими эффектами, для которых такого ограничения вроде бы нет: https://en.m.wikipedia.org/wiki/Effect_system
Причём если посмотреть на язык Koka, то там эффектами выражаются штуки типа чистоты функций, возможности расходимости (незавершения), бросание исключений и т.п.: https://koka-lang.github.io/koka/doc/book.html#sec-effect-types
И эффекты позволяют выразить то же самое, что делают монады типа Try или Option.
Так вот, можно ли смотреть на алгебраические эффекты как на альтернативу монадам в общем случае?
Так rsync тоже так умеет, если ему указать директорию предыдущего снапшота. Он сам создаст жёсткие ссылки для неизменившихся файлов.
Зачем это делать через cp?
Вы написали про Cl(0, 0, 4) и я очень впечатлён, насколько оно похоже на Cl(3, 0, 1).
Но я бы ещё добавил, что в общем виде в уравнении точки в 3д четвёртый элемент тоже может быть отличным от единицы. Например, разностью двух точек будет вектор с четвёртым элементом-нулём и это валидная сущность.
Я надеюсь, вы как-нибудь потом напишете про Cl(3, 0, 1).
Там смысл weight и bulk более понятен - это элементы которые в квадрате равны единице и элементы котороые в квадрате равны нулю.
Причём, что интересно и красиво, и та и та нормализация (по bulk и по weight элементам) имеет смысл.
Например, для уравнения плоскости в общем виде можно либо привести к единице длину нормали, либо сделать "единичным" сдвиг от нуля координат)
Для линии нормализация сделает единичное направление. Для уравнения точки - уберёт четвёртый элемент в единицу. Либо не уберёт для случая идеальной точки, но тогда можно хотя бы сделать другую нормализацию, чтобы сумма квадратов остальных трёх элементов давала единицу.
А ещё про смысл weight - если сказать что четвёртый элемент точки это вес, то сумма таких точек с массой будет точкой-центром масс.
Ещё добавлю, что есть вектор атаки через приложения и прослушивание портов на localhost:
https://habr.com/ru/articles/915732/
Если не заблочить Яндекс метрику и иметь приложение Яндекса, то скрипт из браузера достучится до приложения и даже из приватной вкладки.
И ещё установленные приложения типа Яндекса или каких-нибудь госуслуг могут периодически подключаться к серверам и при включении ВПН будет заметно, что трафик откуда-то из другого места пошёл.
Вообще выглядит так, что проще два телефона иметь - один для всякой херни и второй со всем удалённым, потому что надёжно разграничить в пределах одного телефона как-то сложно.
Очень толковая - у автора есть рабочий код и он понимает что делает. И как раз когда код пишешь, наступаешь на все грабли и начинаешь что-то понимать.
Бестолковые статьи - это никогда авторы занимаются пересказом чужих мыслей, а сами ничего выучить не смогли или даже не попытались.
А что если сделать эмбеддинг для относительной позиции, а не для абсолютной? Для этого можно взять rotary embeddings (отдельно по осям x и y).
Я так пробовал, но кажется у меня были где-то ошибки и результат не получился.
Да вообще человечество свернуло куда-то не туда. Вместо того, чтобы просто ездить на автомобиле (автомобиль не обязан быть тяжёлым и большим, есть же Кей кары в Японии) и развивать инфраструктуру под них, придумывают кучу правил и ограничений на то как ездить, где парковаться и делают автомобили (при всей их универсальности и эффективности в плане перевозки людей и грузов) малоиспользуемыми.
Весь прогресс откинули на сто лет назад и курьеры в городах на мускульной тяге возят/носят заказы по одному/два, хотя казалось бы в автомобиль можно на порядок больше заказов положить и на порядок дальше и быстрее отвезти.
И по этому "электровелосипеду" видно - нужен автомобиль с кузовом для грузов и с возможностью ездить и парковаться несмотря на ограничения для авто.
Для начала удобнее взять механики и характеристики юнитов из понравившейся игры. Потом, когда будет более-менее играбельный прототип, кастомизировать под свои желания.
В третьей цивилизации есть забавный момент - ресурсы игры типа картинок, звуков и описаний лежат в папке с игрой, а вот типы юнитов и их характеристики (и ссылки на файлы картинок, звуков и т.п.), дерево развития технологий, список чудес света, список видов ланшафта и прочее лежат прямо в файле сохранения. То есть можно прямо в этом файле юниту поменять характеристики типа атаки или количества очков передвижения, загрузить сохранение и увидеть изменения.
Кастомные сценарии так и сделаны - это просто поправленный сейв файл. И по этой же причине в игровом редакторе третей цивилизации можно спокойно менять характеристики юнитов на карте. И вот эта часть с деревом технологий и юнитами очень хорошо отвязана от движка игры - по-сути ей занимается геймдизайнер, а не разработчик, и поправить её можно в любой момент.
Самая ключевая часть - это "скелет" в виде игровых механик, а когда они есть подкрутить характеристики юниту и заменить графику должно быть несложно.
P.S. Вот описание формата в третьей цивилизации: https://github.com/Kright/civ3/blob/master/bicformat.txt Оно неполное, там рядом в репозитории я ещё что-то релевантное собрал. Я тогда ещё попробовал написать парсер сейвов с помощью kaitai struct, почти дошёл до завершения, но к сожалению не сохранил и потерял данные, а второй раз было уже лень.
Ещё можно глянуть на https://github.com/C7-Game/Prototype - там делают клон третьей цивилизации.
Ещё для вдохновения и для изучения игровых механик можно посмотреть на 1-4 версии цивилизации - они довольно сильно отличаются от пятой, и я не скажу что отличие в качестве - скорее, они просто другие.
Причём добавление одной механики часто тянет за собой всё остальное - в третьей цивилизации можно было ставить неограниченное количество юнитов на клетку, города сами защищаться не умели, не-артиллериейские юниты не могли стрелять через несколько клеток, а в кораблик можно было сажать несколько наземных юнитов для перевозки по воде.
Так это же логично. Примерно как для обычных чисел у нас есть два корня из единицы (равные 1 и -1), а так же четыре корня четвёртой степени (-1, 1, i, -i), так и для вычетов простого числа так же, только вместо -1 там будет (p-1) и для четвёртой степени чуть сложнее.
Если внимательно посмотреть на таблицу степеней в gf(17), то в 8 колонке будут корни второй степени (которых ровно два и они 1 и 16), а в колонке 4 - корни четвёртой степени (1, 16, 4, 13)
А например в таблице степеней по модулю 19 можно корни третьей степени найти в колонках 6 и 12, их ровно три: 1, 7, 11
P. S. Ещё можно заметить что сумма всех корней степени n снова равна нулю, как и с комплексными числами.
P. P. S. а ещё можно в кольце вычетов по модулю простого числа найти подходящий корень из единицы и сделать преобразование Фурье на целых числах, примерно как с e(-ikw) на комплексных.
А что если порядок алгебры чётный и левое дополнение не равно правому? Какой смысл можно вложить в их разницу?
P.S.
И ещё вопрос. Если в алгебре с чётным порядком в определении регрессивного произведения поменять местами левое и правое дополнения, произведение будет всё тем же или другим?