Особо не смотрел. Но просто для поддержания беседы — вроде так и не сделали, чтобы можно было конкатенацию массивов (или там Span) простым знаком +?

byte[] array1 = ...
byte[] array2 = ...
byte[] array3 = array1 + array2;

?

Здравствуйте, Shmj, Вы писали:

S>Особо не смотрел. Но просто для поддержания беседы — вроде так и не сделали, чтобы можно было конкатенацию массивов (или там Span) простым знаком +?

S>byte[] array1 = ...
S>byte[] array2 = ...
S>byte[] array3 = array1 + array2;

S>?
Индексы к этому отношения не имеют. Знак + транслируется либо во встроенную операцию (для числовых типов), либо в конкатенацию (для строк), либо в вызов operator+.
То есть для того, чтобы конкатенировать спаны вот таким образом, надо дать им operator+.
А для массивов придётся пилить компилятор — способа приделать оператор + к встроенному типу нет.

Здравствуйте, Sinclair, Вы писали:

S>То есть для того, чтобы конкатенировать спаны вот таким образом, надо дать им operator+.

А почему же не дали?

S>чтобы можно было конкатенацию массивов (или там Span) простым знаком +

или поэлементное сложение чисто чтоб программиста запутать

Здравствуйте, Muxa, Вы писали:

M>или поэлементное значение чисто чтоб программиста запутать

Почему то в Python-е никого не путают

Поэлементное сложение — это частный редкий случай, да и то, только если массивы равной длины. А вот конкатенация как строки — вполне себе.

S>А вот конкатенация как строки
еще более частный и еще более редкий случай

Здравствуйте, Shmj, Вы писали:

S>Особо не смотрел. Но просто для поддержания беседы — вроде так и не сделали, чтобы можно было конкатенацию массивов (или там Span) простым знаком +?
А зачем?

Здравствуйте, Shmj, Вы писали:

S>А почему же не дали?
Я полагаю, что причин к тому было несколько:
1. Span<T> не является "самостоятельным" типом данных. Эта конструкция реализует абстракцию "некоторая непрерывная область памяти, заполненная T" над уже существующими структурами.
Для Span нет конструктора вроде "создай мне Span из 10 элементов" — зато есть конструкции типа "представь мне вот этот фрагмент вот этого массива T в виде Span<T> или "отдай мне ReadOnlySpan<char>, который ссылается на вот такую подстроку этой строки". Результат операции конкатенации произвольных Span невозможно представить в виде нового Span, который был бы построен над какими-то существующими данными. В отличие, скажем, от операции Slice. Что должна делать операция конкатенации? Выделять новый массив, и переносить данные в него? Или новый List<>? С учётом того, что Span были разработаны специально для того, чтобы минимизировать копирования, это выглядит как вредоносное направление мысли.

2. Необходимость конкатенировать Span-ы возникает настолько редко, что даже если бы у нас была операция Concat (или мы бы сделали метод расширения), то её не имело бы смысла представлять в виде инфиксного оператора.

Здравствуйте, vaa, Вы писали:

S>>Особо не смотрел. Но просто для поддержания беседы — вроде так и не сделали, чтобы можно было конкатенацию массивов (или там Span) простым знаком +?
vaa>А зачем?

Для работы с массивами данных. Это и в случае с бинарными данными, к примеру, добавить prefix/header — не нужно копировать массивы — просто оператор +. Или нередко в Machine Learning подобная задача. Еще лучше чтобы с помощью индекса как-то указать с какого по какой элемент.

В Python такой оператор есть.

Здравствуйте, Shmj, Вы писали:

S>Здравствуйте, vaa, Вы писали:

S>>>Особо не смотрел. Но просто для поддержания беседы — вроде так и не сделали, чтобы можно было конкатенацию массивов (или там Span) простым знаком +?
vaa>>А зачем?

S>Для работы с массивами данных. Это и в случае с бинарными данными, к примеру, добавить prefix/header — не нужно копировать массивы — просто оператор +. Или нередко в Machine Learning подобная задача. Еще лучше чтобы с помощью индекса как-то указать с какого по какой элемент.

S>В Python такой оператор есть.
А вот в личпе операторов нет.
не нужно запоминать семантику кучи операторов.
по сигнатуре понятно что будет.

в + тоже будет копирование. по крайней мере в шарпе. в ди возможно для обработки chain создать или slice из существующих массивов.

Здравствуйте, Sinclair, Вы писали:

S>>А почему же не дали?
S>Я полагаю, что причин к тому было несколько:
S>1. Span<T> не является "самостоятельным" типом данных. Эта конструкция реализует абстракцию "некоторая непрерывная область памяти, заполненная T" над уже существующими структурами.
S>Для Span нет конструктора вроде "создай мне Span из 10 элементов" — зато есть конструкции типа "представь мне вот этот фрагмент вот этого массива T в виде Span<T> или "отдай мне ReadOnlySpan<char>, который ссылается на вот такую подстроку этой строки". Результат операции конкатенации произвольных Span невозможно представить в виде нового Span, который был бы построен над какими-то существующими данными. В отличие, скажем, от операции Slice. Что должна делать операция конкатенации? Выделять новый массив, и переносить данные в него? Или новый List<>? С учётом того, что Span были разработаны специально для того, чтобы минимизировать копирования, это выглядит как вредоносное направление мысли.

А сделать чтобы внутри держать ссылки на оба массива, а не только на один — ума не хватило?

S>2. Необходимость конкатенировать Span-ы возникает настолько редко, что даже если бы у нас была операция Concat (или мы бы сделали метод расширения), то её не имело бы смысла представлять в виде инфиксного оператора.

В Python такая операция есть и используют ее очень часто.

S>В Python такая операция есть и используют ее очень часто.

Так и писал бы на питоне.
Или в чем проблема была изначально выбрать более подходящий под твои задачи инструмент?

Здравствуйте, Shmj, Вы писали:
S>А сделать чтобы внутри держать ссылки на оба массива, а не только на один — ума не хватило?
Вы не могли бы расписать это поподробнее? Как именно должен быть устроен Span, чтобы это работало?

S>>2. Необходимость конкатенировать Span-ы возникает настолько редко, что даже если бы у нас была операция Concat (или мы бы сделали метод расширения), то её не имело бы смысла представлять в виде инфиксного оператора.
S>В Python такая операция есть и используют ее очень часто.
Python трудно назвать образцом быстродействия он проектировался под другой набор задач, и, естественно, оборудован другим набором решений.

Здравствуйте, Muxa, Вы писали:

M>Так и писал бы на питоне.
M>Или в чем проблема была изначально выбрать более подходящий под твои задачи инструмент?

Так C# же тоже умеет в Machine Learning. В Python немного глянул как удобно с данными работать — круть.

А так же часто не хватает при работе с бинарными данными.

M>>Так и писал бы на питоне.
M>>Или в чем проблема была изначально выбрать более подходящий под твои задачи инструмент?
S>Так C# же тоже умеет в Machine Learning. В Python немного глянул как удобно с данными работать — круть.

Аргумент в стиле "на ассемблере тоже можно писать машин лернинг, только неудобно"

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Shmj, Вы писали:
S>>А сделать чтобы внутри держать ссылки на оба массива, а не только на один — ума не хватило?
S>Вы не могли бы расписать это поподробнее? Как именно должен быть устроен Span, чтобы это работало?

Span должен уметь принимать на вход 2 Span. Не обязательно при этом копировать все в новый массив — просто хранить 2 ссылки и 4 индекса.

Здравствуйте, Muxa, Вы писали:

M>Аргумент в стиле "на ассемблере тоже можно писать машин лернинг, только неудобно"

Что мешает добавить удобства в C#? Это же языки одного уровня.

Здравствуйте, Shmj, Вы писали:
S>Span должен уметь принимать на вход 2 Span. Не обязательно при этом копировать все в новый массив — просто хранить 2 ссылки и 4 индекса.
Погодите. С этого места поподробнее. Что за ссылки, что за индексы?

Забегая вперёд: какого типа будет результат операции span1 + span2 + span1, и какие значения будут иметь его поля?

Здравствуйте, Shmj, Вы писали:
S>Что мешает добавить удобства в C#? Это же языки одного уровня.
Ничего не мешает. Но отсутствие операции + для линейных массивов — это не та причина, по которой ML на C# делать неудобно.
Чтобы сделать C# пригодным для ML, нужно не ломать низкоуровневые конструкции типа массивов и спанов, а делать свои FloatRange и DoubleRange, которые будут оборудованы необходимой арифметикой.
Плюс поддержка linq-style expressions, плюс отложенные вычисления, плюс SIMD/GPU, плюс рантайм-генерация кода преобразований.

Безо всего этого реализация экзотических операторов никак не улучшит жизнь ML-девелоперов в C# и дотнете.

Здравствуйте, Sinclair, Вы писали:

S>Забегая вперёд: какого типа будет результат операции span1 + span2 + span1, и какие значения будут иметь его поля?

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