Все есть строка?

Нейтральный элемент у конкатенации - пустая строка. a + «» = a (и с пустой строкой слева - то же самое).

Нейтральный есть, а нулевого-то нет (который x * 0 = 0).

А забавное то, что есть системы с делителями нуля и обратными элементами

Ну так операция деления — это отдельная операция, а о взаимоотношении нулевого (абсорбирующего) и обратных элементов пусть рассказывают специалисты по теории групп, которых тут, я так понимаю, целый тред набралось.

Вот последний вариант в контексте сложения массивов ([1,2,3]+[4,5,6]=[5,7,9]), вообще выглядит очень логично и даже обладает свойствами математического значка.

проблема лишь в том, что большинство массивов разного размера.

Нейтральный есть, а нулевого-то нет (который x * 0 = 0).

Ах, таки да.

рассказывают специалисты по теории групп, которых тут, я так понимаю, целый тред набралось.

Да, все мы экспЭрты

а вот действительные - уже никак.

рациональные можно. А иррациональных в компьютере по любому нет.

GC веде одинаково говнистый, увы.

Впрочем, у конкатенаии нет ни того, ни другого.

нулевой есть, это "". x+0==0+x==x

«not пустой_массив» в лучшем случае возвращает true, false, 1 или 0.

в какой смысл в операции not непустой массив?

ЗЫ. Оказывается в Юникоде есть не только символ «говно», но и символ «Жопа». Можно истории рассказывать в картинках. TALKS 🚻 ⩊ 💩 🍞 🚎

в слаке это не работает. (жопа работает, но маленькая, в 5 пикселей где-то).

Умножение строки с числом в питоне коммуникативно.

нечего, что для кольца/поля оба аргумента должны быть в этом кольце/поле?

дык ты про что, про целые или про строки?

А забавное то, что есть системы с делителями нуля и обратными элементами. Это меня смущает и тревожит. В таких системах вот так в принципе можно отыскать обратный элемент?

да. Тебя тревожит многозначность что-ли?

GC для хвостовой рекурсии нехилое подспорье, кагбэ.

4.2

gcc прекрасно работает без всякого GC.

Нейтральный есть, а нулевого-то нет (который x * 0 = 0).

дык при чём тут умножение?

дык при чём тут умножение?

Эта конкретная ветка срача началась с того, что «в отличие от сложения и умножения чисел конкатенация некоммутативна, а кроме того, не имеет нулевого элемента, в отличие от умножения».

А какая разница? Есть некая бинарная операция и аксиомы для неё.

Если бы мы просто определили полугруппу строка и работали только в ней, все было бы хорошо. Т.е. создаем DSL для работы со стороками, определяем операцию конкатенации, пусть даже ломающий шаблоны плюс — не важно, и все у нас хорошо. Но мы тянем операцию сложения строк в язык, в котором уже есть операция сложения чисел.

Ну и что с того, что это полиморфизм? Я могу определить оператор сложения чего-нибудь, который будет менять сами операнды, создавать побочные эффекты и вообще возвращать что угодно, а выглядеть везде A+B, полиморфно, чо. Плюсуя строки вы встаете на эту дорожку, вы вводите в язык контекстную зависимость. Осталось поломать коммутативность оператора сравнения, вот тогда начнется самое веселое.

Тебя тревожит многозначность что-ли?

Мне не понятно, как вообще это делается. И как понять, что в системе есть обратные элементы в принципе

Ну и что с того, что это полиморфизм? Я могу определить оператор сложения чего-нибудь, который будет менять сами операнды, создавать побочные эффекты и вообще возвращать что угодно, а выглядеть везде A+B, полиморфно, чо. Плюсуя строки вы встаете на эту дорожку, вы вводите в язык контекстную зависимость. Осталось поломать коммутативность оператора сравнения, вот тогда начнется самое веселое.

Да я сам не любитель этих перегрузок операторов, чо

проблема лишь в том, что большинство массивов разного размера.

Никакой проблемы. [1,2]+[3,4,5] равен [4,6] или [4,6,5] — зависит от того, как мы сформулируем правило. Свойства значка сохраняются. А можно вообще сделать любый погромистами UB.

Эта конкретная ветка срача началась с того, что «в отличие от сложения и умножения чисел конкатенация некоммутативна, а кроме того, не имеет нулевого элемента, в отличие от умножения».

Вот я и вопрошаю: при чём тут вообще умножение, в этой конкретной ветке? Умножение по своей сути совершенно другая операция, и она никак не относится к сложению. Сложение практически всегда замкнуто, а умножение — практически всегда нет. Т.е. при умножении двух сущностей мы получаем совсем иную сущность. Однако при сложении мы получаем почти всегда тоже самое. Т.е. умножение никак нельзя ставить в один ряд со сложением, ксли мы говорим о типах. Умножение замкнуто лишь для безразмерных единиц. E.g. вольты на амперы дадут не вольты, и не амперы, а ватты. А вот вольты плюс амперы дадут неопределённость.

Но мы тянем операцию сложения строк в язык, в котором уже есть операция сложения чисел.

и при чём тут числа? Мухи отдельно, котлеты отдельно. Иначе это говно, а не ЯП.

Осталось поломать коммутативность оператора сравнения

Это как? x<y == y<x?

Мне не понятно, как вообще это делается. И как понять, что в системе есть обратные элементы в принципе

а что тут непонятного? Если a*b=1, то очевидно a это (взаимо)обратный элемент к b(«взаимо» оно будет если коммутативное умножение). Также и для любого иного произведения. Ну кроме нуля, с ним сложности. Но сложности в принципе решаемые путём введения счётного множества различных нулей, которые позволяют умножать на ноль любое целое число однозначно. Ну и делить ноль на такой делитель нуля однозначно. (делить целое на ноль всё равно нельзя, т.к. там неопределённость получается ещё на этапе деления, а не после него)

Т.е. ввести обратный элемент можно при наличии единицы. Можно даже ввести обратный элемент даже если умножение не коммутативно, и есть только левая(или только правая) единица. Т.е. нам нужен какой то объект, для которого справедливо тождество a*1==a (для любого a), если такой объект (1) есть, то и обратный элемент тоже возможен (хотя конечно и не обязателен. Или для некоторых a он есть, а для других его нет, или для некоторых(всех)a есть множество(возможно бесконечное) разных 1/a).

Никакой проблемы. [1,2]+[3,4,5] равен [4,6] или [4,6,5] — зависит от того, как мы сформулируем правило. Свойства значка сохраняются. А можно вообще сделать любый погромистами UB.

вообще-то UB это само по себе проблема. В сишечке так много UB вовсе не потому, что Керниган с Ричи упоролись, а потому, что так много UB IRL. Увы. Это вынужденная мера. Выражение x-- - --x; вычисляется по разному совсем не из-за кривости ЯП, а из-за кривости самого окружающего мира. Если это не UB, то это в любом случае костыли, и это плохо, ибо надо всегда держать в голове, что пожелала левая пятка аффтора ЯП в данном конкретном случае. В сишке проще — кривое выражение даёт хрен знает какой результат, и это закреплено стандартом.

и это закреплено стандартом

Ага, в разделе errata.

Ага, в разделе errata.

да ладно. В самом стандарте зафиксирован любой порядок вычислений между точками следования. Тут таких точек нет, и очевидно, что порядок может быть любым из трёх различных вариантов. И даже более, ибо в i585 и старше операторы могут выполнятся СРАЗУ, по два, ИЧСХ именно так и выполняются.

С одной стороны в реальном коде такую конструкцию никто использовать не будет, с другой стороны неопределённость порядка операций — всё же недостаток стандарта.

С одной стороны в реальном коде такую конструкцию никто использовать не будет

IRL используют сплошь и рядом. Не в таком рафинированном виде конечно.

с другой стороны неопределённость порядка операций — всё же недостаток стандарта.

к сожалению — неизбежный недостаток. Всё остальное — нелепые костыли, которые только тормозят(в лучшем случае. В худшем — полностью ломают логику работы кода).

Ну пример с пхп был выше — ты сам можешь убедиться, к чему приводит попытка сделать бессмысленное осмысленным. В пхп логика — ковылять до последнего, лишь бы не падать с UB. Типа «всё имеет смысл». Ты сам можешь наблюдать, к чему это приводит. Пхп — терминальный вариант такого подхода, там практически любой говнокод как-то работает. И практически любой код работает не так, как думает программист.

UB это не когда падает. UB это когда работает, хотя работать может быть уже и не должно. PHP — случай из совершенно другой оперы, там совершенно поломанная обработка ошибок.

Придумывал бы я си, у меня инкремент и декремент вообще не были бы выражением, только оператором.

UB это не когда падает.

UB это UB. Может и упасть, хрен его знает.

UB это когда работает, хотя работать может быть уже и не должно. PHP — случай из совершенно другой оперы, там совершенно поломанная обработка ошибок.

нет. В пхп ошибок обычно тупо нет. Там даже массив сам к целому числу кастуется, и это не баг, а фича.

Придумывал бы я си, у меня инкремент и декремент вообще не были бы выражением, только оператором.

что поделать, если в сишечке любое выражение имеет результат? (ну кроме пустого и функции void). Просто семантика ЯП такова, что инкремент имеет два результата, и с этим ничего не поделать. Впрочем, UB может возникнуть и без инкремента, или ты решил и функции отменить? Или делать функции без побочных эффектов, тупо с передачей по значению? Как в ФП? Дык не взлетит жеж...

Т.е. ввести обратный элемент можно при наличии единицы

А, так ты тоже из экспЭртов? Сразу бы сказал, а не строил из себя умника.

Т.е. ввести обратный элемент можно при наличии единицы

А, так ты тоже из экспЭртов? Сразу бы сказал, а не строил из себя умника.

а ты что сказать-то хотел?