Индексы и прочие новшества - умеют ли...
От: Shmj Ниоткуда  
Дата: 01.12.21 09:55
Оценка: -1
Особо не смотрел. Но просто для поддержания беседы — вроде так и не сделали, чтобы можно было конкатенацию массивов (или там Span) простым знаком +?

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

?
Re: Индексы и прочие новшества - умеют ли...
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 01.12.21 14:52
Оценка:
Здравствуйте, Shmj, Вы писали:

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


S>byte[] array1 = ...

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

S>?

Индексы к этому отношения не имеют. Знак + транслируется либо во встроенную операцию (для числовых типов), либо в конкатенацию (для строк), либо в вызов operator+.
То есть для того, чтобы конкатенировать спаны вот таким образом, надо дать им operator+.
А для массивов придётся пилить компилятор — способа приделать оператор + к встроенному типу нет.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[2]: Индексы и прочие новшества - умеют ли...
От: Shmj Ниоткуда  
Дата: 01.12.21 16:23
Оценка:
Здравствуйте, Sinclair, Вы писали:

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


А почему же не дали?
Re: Индексы и прочие новшества - умеют ли...
От: Muxa  
Дата: 01.12.21 17:11
Оценка: +1
S>чтобы можно было конкатенацию массивов (или там Span) простым знаком +

или поэлементное сложение чисто чтоб программиста запутать
Отредактировано 02.12.2021 7:12 Muxa . Предыдущая версия .
Re[2]: Индексы и прочие новшества - умеют ли...
От: Shmj Ниоткуда  
Дата: 01.12.21 19:13
Оценка:
Здравствуйте, Muxa, Вы писали:

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


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

Поэлементное сложение — это частный редкий случай, да и то, только если массивы равной длины. А вот конкатенация как строки — вполне себе.
Re[3]: Индексы и прочие новшества - умеют ли...
От: Muxa  
Дата: 01.12.21 22:03
Оценка: +1 -1
S>А вот конкатенация как строки
еще более частный и еще более редкий случай
Re: Индексы и прочие новшества - умеют ли...
От: vaa https://www.youtube.com/playlist?list=PLtrvASfI1KW7VOYRKjglcagQzWLoxlncl
Дата: 02.12.21 03:22
Оценка: +5
Здравствуйте, Shmj, Вы писали:

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

А зачем?
Re[3]: Индексы и прочие новшества - умеют ли...
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 02.12.21 06:25
Оценка:
Здравствуйте, Shmj, Вы писали:

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

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

2. Необходимость конкатенировать Span-ы возникает настолько редко, что даже если бы у нас была операция Concat (или мы бы сделали метод расширения), то её не имело бы смысла представлять в виде инфиксного оператора.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[2]: Индексы и прочие новшества - умеют ли...
От: Shmj Ниоткуда  
Дата: 02.12.21 08:15
Оценка:
Здравствуйте, vaa, Вы писали:

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

vaa>А зачем?

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

В Python такой оператор есть.
Re[3]: Индексы и прочие новшества - умеют ли...
От: vaa https://www.youtube.com/playlist?list=PLtrvASfI1KW7VOYRKjglcagQzWLoxlncl
Дата: 02.12.21 08:21
Оценка:
Здравствуйте, Shmj, Вы писали:

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


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

vaa>>А зачем?

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


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

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

в + тоже будет копирование. по крайней мере в шарпе. в ди возможно для обработки chain создать или slice из существующих массивов.
Отредактировано 02.12.2021 8:24 vaa . Предыдущая версия .
Re[4]: Индексы и прочие новшества - умеют ли...
От: Shmj Ниоткуда  
Дата: 02.12.21 08:34
Оценка:
Здравствуйте, 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 такая операция есть и используют ее очень часто.
Re[5]: Индексы и прочие новшества - умеют ли...
От: Muxa  
Дата: 02.12.21 09:00
Оценка: +1
S>В Python такая операция есть и используют ее очень часто.

Так и писал бы на питоне.
Или в чем проблема была изначально выбрать более подходящий под твои задачи инструмент?
Re[5]: Индексы и прочие новшества - умеют ли...
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 02.12.21 09:45
Оценка: +1
Здравствуйте, Shmj, Вы писали:
S>А сделать чтобы внутри держать ссылки на оба массива, а не только на один — ума не хватило?
Вы не могли бы расписать это поподробнее? Как именно должен быть устроен Span, чтобы это работало?

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

S>В Python такая операция есть и используют ее очень часто.
Python трудно назвать образцом быстродействия он проектировался под другой набор задач, и, естественно, оборудован другим набором решений.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[6]: Индексы и прочие новшества - умеют ли...
От: Shmj Ниоткуда  
Дата: 02.12.21 10:39
Оценка:
Здравствуйте, Muxa, Вы писали:

M>Так и писал бы на питоне.

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

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

А так же часто не хватает при работе с бинарными данными.
Re[7]: Индексы и прочие новшества - умеют ли...
От: Muxa  
Дата: 02.12.21 10:42
Оценка:
M>>Так и писал бы на питоне.
M>>Или в чем проблема была изначально выбрать более подходящий под твои задачи инструмент?
S>Так C# же тоже умеет в Machine Learning. В Python немного глянул как удобно с данными работать — круть.

Аргумент в стиле "на ассемблере тоже можно писать машин лернинг, только неудобно"
Re[6]: Индексы и прочие новшества - умеют ли...
От: Shmj Ниоткуда  
Дата: 02.12.21 10:43
Оценка:
Здравствуйте, Sinclair, Вы писали:

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

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

Span должен уметь принимать на вход 2 Span. Не обязательно при этом копировать все в новый массив — просто хранить 2 ссылки и 4 индекса.
Re[8]: Индексы и прочие новшества - умеют ли...
От: Shmj Ниоткуда  
Дата: 02.12.21 10:50
Оценка:
Здравствуйте, Muxa, Вы писали:

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


Что мешает добавить удобства в C#? Это же языки одного уровня.
Re[7]: Индексы и прочие новшества - умеют ли...
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 02.12.21 11:03
Оценка:
Здравствуйте, Shmj, Вы писали:
S>Span должен уметь принимать на вход 2 Span. Не обязательно при этом копировать все в новый массив — просто хранить 2 ссылки и 4 индекса.
Погодите. С этого места поподробнее. Что за ссылки, что за индексы?

Забегая вперёд: какого типа будет результат операции span1 + span2 + span1, и какие значения будут иметь его поля?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[9]: Индексы и прочие новшества - умеют ли...
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 02.12.21 11:09
Оценка: +3
Здравствуйте, Shmj, Вы писали:
S>Что мешает добавить удобства в C#? Это же языки одного уровня.
Ничего не мешает. Но отсутствие операции + для линейных массивов — это не та причина, по которой ML на C# делать неудобно.
Чтобы сделать C# пригодным для ML, нужно не ломать низкоуровневые конструкции типа массивов и спанов, а делать свои FloatRange и DoubleRange, которые будут оборудованы необходимой арифметикой.
Плюс поддержка linq-style expressions, плюс отложенные вычисления, плюс SIMD/GPU, плюс рантайм-генерация кода преобразований.

Безо всего этого реализация экзотических операторов никак не улучшит жизнь ML-девелоперов в C# и дотнете.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[8]: Индексы и прочие новшества - умеют ли...
От: samius Россия http://sams-tricks.blogspot.com
Дата: 02.12.21 11:12
Оценка:
Здравствуйте, Sinclair, Вы писали:

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


Кроме этого хотелось бы увидеть то, как это повлияет на операции чтения/записи, подразумевая что спан — это не один кусок памяти, а множество...
Re[8]: Индексы и прочие новшества - умеют ли...
От: Shmj Ниоткуда  
Дата: 02.12.21 11:12
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Погодите. С этого места поподробнее. Что за ссылки, что за индексы?

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

span1 + span2 дадут tempSpan (неявный), в котором ссылки на 2 этих спана. Результирующий span = tempSpan + span1, в котором ссылки уже на tempSpan + span1. Индексы пока даже не нужны — это при более сложных операциях.
Re[9]: Индексы и прочие новшества - умеют ли...
От: Shmj Ниоткуда  
Дата: 02.12.21 11:17
Оценка:
Здравствуйте, samius, Вы писали:

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


Можно сделать ReadOnlySpan для таких случаев, если смущает что запись в 1 ячейку приведет к изменению двух.
Re[9]: Индексы и прочие новшества - умеют ли...
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 02.12.21 11:26
Оценка:
Здравствуйте, samius, Вы писали:

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

Это будет следующий вопрос. Как будет выглядеть цикл сканирования такого спана после джита
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[9]: Индексы и прочие новшества - умеют ли...
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 02.12.21 11:28
Оценка:
Здравствуйте, Shmj, Вы писали:

S>span1 + span2 дадут tempSpan (неявный), в котором ссылки на 2 этих спана. Результирующий span = tempSpan + span1, в котором ссылки уже на tempSpan + span1. Индексы пока даже не нужны — это при более сложных операциях.

Что такое "ссылки на Span"? Боксинг ref struct запрещён.
Что значит "индексы не нужны"? Мы не можем произвольно отбрасывать и добавлять поля в struct типе.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[10]: Индексы и прочие новшества - умеют ли...
От: Shmj Ниоткуда  
Дата: 02.12.21 11:32
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Что такое "ссылки на Span"? Боксинг ref struct запрещён.

S>Что значит "индексы не нужны"? Мы не можем произвольно отбрасывать и добавлять поля в struct типе.

Т.е. сами себе создали проблему — сделали struct, чтобы усложнить себе жизнь.
Re[11]: Индексы и прочие новшества - умеют ли...
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 02.12.21 12:07
Оценка: +3
Здравствуйте, Shmj, Вы писали:

S>Т.е. сами себе создали проблему — сделали struct, чтобы усложнить себе жизнь.

Нет конечно. У struct есть масса преимуществ — в частности, можно делать инлайнинг и многие другие оптимизации, которые невозможны для reference-типов.
Вы вместо того, чтобы ворчать, постарайтесь разобраться с тем, как (и зачем) устроены [ReadOnly]Span<T>. Это весьма поучительно.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[9]: Индексы и прочие новшества - умеют ли...
От: Muxa  
Дата: 02.12.21 12:18
Оценка: +2
M>>Аргумент в стиле "на ассемблере тоже можно писать машин лернинг, только неудобно"
S>Что мешает добавить удобства в C#? Это же языки одного уровня.

Отсутствие препятствий недосточное условие вносить измения.
И профит от того что вместо z=concat(x,y) можно будет писать z=x+y (и нельзя будет писать z=concat(x,y,predicate)) кажется сомнительным.
Отредактировано 02.12.2021 16:28 Muxa . Предыдущая версия .
Re[10]: Индексы и прочие новшества - умеют ли...
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 02.12.21 12:20
Оценка:
Здравствуйте, Shmj, Вы писали:

S>Можно сделать ReadOnlySpan для таких случаев, если смущает что запись в 1 ячейку приведет к изменению двух.

Нет. Смущает то, что вместо тривиального pointer[index]=x, что на интеле кодируется одной инструкцией mov, мы получаем
if(index < length1)
  pointer1[index] = x
else
  pointer2[index-length1] = x

Причём в отличие от проверок на границы, которые реализованы в настоящем Span, эту проверку выкинуть при джите будет невозможно.
Так как Span — структура, схитрить и разделить "одиночный" Span и "двойной" Span не получится.
То есть одиночный Span — это просто двойной Span, у которого pointer2 = length2 = 0.
При этом мы по-прежнему не можем склеить вместе три Span, т.к. возможности сослаться на Span нету.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[11]: Индексы и прочие новшества - умеют ли...
От: Shmj Ниоткуда  
Дата: 02.12.21 12:52
Оценка: -2 :)
Здравствуйте, Sinclair, Вы писали:

S>Так как Span — структура, схитрить и разделить "одиночный" Span и "двойной" Span не получится.

S>То есть одиночный Span — это просто двойной Span, у которого pointer2 = length2 = 0.
S>При этом мы по-прежнему не можем склеить вместе три Span, т.к. возможности сослаться на Span нету.

Просто не нужно было делать структурой — делали бы классом как строку Очевидная ошибка проектирования, которая лишает многих возможностей расширения.
Re[11]: Индексы и прочие новшества - умеют ли...
От: Shmj Ниоткуда  
Дата: 02.12.21 13:04
Оценка: -1 :)
Здравствуйте, Sinclair, Вы писали:

S>Причём в отличие от проверок на границы, которые реализованы в настоящем Span, эту проверку выкинуть при джите будет невозможно.


Это не существенно. Вместо 1000 слов:

byte[] b1 = {1, 2, 3};
byte[] b2 = {4, 5, 6};
byte[] b3 = {7, 8, 9, 10};
            
var span = (Span2<byte>)b1 + b2 + b3;

span[4] = 15;

string res = string.Join(", ", span);

Console.WriteLine(res); // 1, 2, 3, 4, 15, 6, 7, 8, 9, 10


  Набросал за 15 мин. с кофем
https://dotnetfiddle.net/zxURoa
Отредактировано 02.12.2021 13:12 Shmj . Предыдущая версия . Еще …
Отредактировано 02.12.2021 13:11 Shmj . Предыдущая версия .
Re[7]: Индексы и прочие новшества - умеют ли...
От: Sharov Россия  
Дата: 02.12.21 14:01
Оценка:
Здравствуйте, Shmj, Вы писали:

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


Язык-то тут причем, питон например, если речь идет о соотв. библиотеках?
Плюс инф-ра в виде jupyter notebook'ов, когда люди разбирающие в математике, но не очень
разбирающиеся в программировании могут сравнительно легко решать свои проблемы -- обучать модели,
готовить данные и т.п. Минимум второстепенной писанины, а в C# сразу загрузят ООП и понятием класс
(метод Main надо же где-то написать). Т.е. питон когнитивно проще.


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


Чего не хватает?
Кодом людям нужно помогать!
Re[12]: Индексы и прочие новшества - умеют ли...
От: rameel https://github.com/rsdn/CodeJam
Дата: 02.12.21 14:20
Оценка: +1
Здравствуйте, Shmj, Вы писали:

S>Набросал за 15 мин. с кофем

S>https://dotnetfiddle.net/zxURoa

И эффективность ниже плинтуса
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[12]: Индексы и прочие новшества - умеют ли...
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 02.12.21 14:23
Оценка: +6
Здравствуйте, Shmj, Вы писали:
S>Просто не нужно было делать структурой — делали бы классом как строку Очевидная ошибка проектирования, которая лишает многих возможностей расширения.
Если бы Span делали классом, а метод this[int index] — виртуальным, то он бы работал примерно на порядок медленнее того, как он работает сейчас.
С учётом того, что он разрабатывался как раз для тех задач, где выжимают каждый так, такое решение как раз было бы ошибкой проектирования.
А вы судите с позиций невежества. Так делать не надо.

Если в ваших задачах производительность неважна, то вы можете сделать свой класс Rope<T> с нужными вам операциями. Реализация всего семейства классов заняла бы меньше времени, чем эта дискуссия.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[7]: Парсинг бинарных сообщений
От: _FRED_ Россия
Дата: 02.12.21 14:34
Оценка:
Здравствуйте, Shmj, Вы писали:

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


Обязательно: Span&lt;T&gt; Struct

Provides a type- and memory-safe representation of a contiguous region of arbitrary memory.


А то, о чём вы спрашиваете — это ReadOnlySequence&lt;T&gt; Struct:

Represents a sequence that can read a sequential series of T.


P.S. Давно фоматер поломали? Угловые скобки внутри ссылок показываются не правильно.
Help will always be given at Hogwarts to those who ask for it.
Re[12]: Индексы и прочие новшества - умеют ли...
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 02.12.21 14:43
Оценка:
Здравствуйте, Shmj, Вы писали:


S>Это не существенно.

Это очень существенно.

Вместо 1000 слов:
S>
  Набросал за 15 мин. с кофем
S> https://dotnetfiddle.net/zxURoa

А то. Давайте теперь сделаем простейший замер производительности:

'Span' : Counted 49999995000000 in 381ms
'span'via foreach: Counted 49999995000000 in 292ms
System.Span<int> : Counted 49999995000000 in 58ms
int[] : Counted 49999995000000 in 24ms

Никто не будет пользоваться структурой, которая в 15 раз медленнее массива.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[8]: Парсинг бинарных сообщений
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 02.12.21 14:57
Оценка:
Здравствуйте, _FRED_, Вы писали:
_FR>А то, о чём вы спрашиваете — это ReadOnlySequence&lt;T&gt; Struct:
_FR>

_FR>Represents a sequence that can read a sequential series of T.

И вдогонку: https://www.stevejgordon.co.uk/creating-a-readonlysequence-from-array-data-in-dotnet

_FR>P.S. Давно фоматер поломали? Угловые скобки внутри ссылок показываются не правильно.

ХЗ. А он работал?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[13]: Индексы и прочие новшества - умеют ли...
От: Shmj Ниоткуда  
Дата: 02.12.21 15:01
Оценка:
Здравствуйте, rameel, Вы писали:

R>И эффективность ниже плинтуса


За бесплатно — просто демо-вариант.
Re[14]: Индексы и прочие новшества - умеют ли...
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 02.12.21 15:06
Оценка: +3
Здравствуйте, Shmj, Вы писали:

S>За бесплатно — просто демо-вариант.

я бы порадовался, если бы существовал способ сделать ваш код существенно быстрее — хотя бы и за деньги. Но увы, не выйдет.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[9]: Парсинг бинарных сообщений
От: _FRED_ Россия
Дата: 02.12.21 15:06
Оценка:
Здравствуйте, Sinclair, Вы писали:

_FR>>P.S. Давно фоматер поломали? Угловые скобки внутри ссылок показываются не правильно.

S>ХЗ. А он работал?

Вот теперь я засомневался Ну ладно, учтём.
Help will always be given at Hogwarts to those who ask for it.
Re[13]: Индексы и прочие новшества - умеют ли...
От: 4058  
Дата: 02.12.21 15:14
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Никто не будет пользоваться структурой, которая в 15 раз медленнее массива.


Некоторые пользуются Питоном, который сам по себе, раз в 15-50 медленнее C/C++/Java

https://miro.medium.com/max/1050/1*N4ns2d0oFaoN3EalxVd-CQ.png
здесь
Re[13]: Индексы и прочие новшества - умеют ли...
От: Shmj Ниоткуда  
Дата: 02.12.21 15:47
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Никто не будет пользоваться структурой, которая в 15 раз медленнее массива.


Там можно оптимизировать — это уже нужно время потратить.
Re[14]: Индексы и прочие новшества - умеют ли...
От: Shmj Ниоткуда  
Дата: 02.12.21 15:50
Оценка:
Здравствуйте, 4058, Вы писали:

4>Некоторые пользуются Питоном, который сам по себе, раз в 15-50 медленнее C/C++/Java


Многие задачи упираются в диск и сеть, по сравнению со скоростью работы которых данные задержки не существенны.
Re[14]: Индексы и прочие новшества - умеют ли...
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 02.12.21 15:52
Оценка: +1
Здравствуйте, 4058, Вы писали:

4>Некоторые пользуются Питоном, который сам по себе, раз в 15-50 медленнее C/C++/Java

Там трюк в том, что собственно внутренние циклы на питоне особо никто не пишет. Для ML-задач и математики там используются внешние либы, куда данные просто маршалятся для быстрой обработки.

Похожую штуку можно замутить и на С# — я в этом топике уже писал. Может быть, она даже и есть.
Но ожидать от дотнетовских hi-perf примитивов аналогичного питону комфорта (и быстродействия), конечно же, странно.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[14]: Индексы и прочие новшества - умеют ли...
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 02.12.21 16:25
Оценка:
Здравствуйте, Shmj, Вы писали:

S>Там можно оптимизировать — это уже нужно время потратить.

Для тех сценариев, для которых пилился Span<T>, вы ничего не наоптимизируете. Ваша лучшая реализация будет в пару раз медленнее, чем Span<T>, в простых случаях, и в десяток раз — в более сложных.
Вы представляете себе, в какой нативный код компилируются все эти чудеса? Можете сравнить код итерации по массиву, по Span<T>, и по Span2<T>.
https://sharplab.io/#v2:C4LghgzgtgPgAgJgIwFgBQcAMACOSB0AwgPYA2pApgMbACWxAdhANzpa5IAsrGOe+AEVpgA5g2IQ6VFmz4EAMrQYBHHu34AVCgA9gPdAzBQKEAA5gqFbCSZkKAQVOnOADnQBvdNm+4EHAOxePp5oPmG4AMy+2ADK5gwIADwaAHzYIBwRySlB4dgheXmIsfEAksAUULmF3gU1haYATrQAbmAV2BoA2gC62AD6YI2NYACePPUNzW0dSsADkkPApQwAJjoTk+FNre1WcwOUDCLAABabWz7Vl3BRB/IUx2fYALxp/Ucn5+jXW7ed2DOtAgXQOSnW2h6v0mdUueREFGA0LhsLhNTg/gGQxGoy6/UWjWWax02AA1NhwToehc0T4AL7Iy4QRGMrao2nhQbDMZ4glEiFkinEyGvbBtUgAVwoNI5DNCtLlrKKUTiYAY5UqAApun1sWMADRC+Z8lYQw0HT5nACUSvC7NpXJxor141tNXxwCWppJL2wJuFModltOouDgcmivlaP+eCyqU6xAAogwJcYRgAjSiam1RlFuwoAM2IjWwmrBoswzAp2ES2AeT3OFNJpJzHLC9rbHCQuExQJBtGp+byctlP1zNyiOoT9m5o2zQ/yC7CGITydTFAzWat+A0xBnOOz4fqI62kcuOxmVkUkkSqvVFSg71oD4gooYFAA7nXgcBb2UHykh5jhOJRqgg2q9NgLrmgw8yUtoMHzMGrZsgu/TPpUED4PYqyrJq75fneGpQJq0FCma2DIVaR41PWXyvGGtpnn8KrxOB5gjFAr53kkqSQWYaoQChMILkWjQUBYIaam0JYCQkQp+vEQkLh2cLoS+2G4QASmqCKanJCD4OpmHUUuPh0WcpIvAZ+AWd846nkxwEsUadaPPR7gIno2AXnsfqIswJ6TP8GiAqcwKgrB5FUraqk1F5Klmd4YkSVQUkyYparEQpxlccJbZxbStAFqW8HYCkvpycRtnudaSV2vVNRlQAtJV/6VDVDY0Z22BUIwdAptKjX0s5PU+CuVUPpFEKDg5aLMZ2ZyNMQX4Edg3raAA8hKwCbQWOnHBQibaJYph0IwQFzceC7MkiV01IVkwpZJpYZZNlQ5RheX1Y9cLFaVwrlW1WUPp1Xz5WNv0ci1wP3h1dndZ2fWwUoUqI3CC1jZlcNQNNVKiuKaPDd4GLozUmMcktK3YGtG3bbt+26UdJ0UGd9AMJdo73SNaC2jGSBxmku5rmmYCZhQ87c7UonFql6VDNj2VKAMX3KVLDXqzUz1pa9CsukrDCK6DwspqL4vZhDtJQ38SDdiu+sPmThRBRjTm8+rIWQbu+5jJLlzWyTmIm+um4S9u3uzpzjnq3zUR4AAbBSUCmKQtBUM+2DEKYG7tMWnS9JqPHZNjCBWq8aQ2RHB6mR7cdIIntDJ6n6fzFnOfAHnRepBBuqzmXbw05+pZkZghoumD1r6LXHCJ13aRtyMHclqShdscXYCGnP2Dpv3aRraRho71PIGlCL7fFsXADiiJn4vxZ+6hmvjUHSamzn5vbtfwC37njRRxGo16inzfnfEssZ8Bfx/kvB+Ikn6B2wJAkBv9/7XSuhTca9dcCcGwAAWTAEoTUeBMCQSGCINWD1bQZXTKKbAP9xb4AOnpUe2AkCYDYewzA4c9yRxrpcShCs5KilXmBRIcwUhWnTDwAAkDI9AMipE4IkhACU4lNQACIADkPENFqM3vEfoCBDRyRrvIxRkAVES00XJDRYphDYG1qcXRoEEgADFZaSSMfEExMizHKNUWo/gd5shOLvIfbxCilEWPUXMXoTifajDCUeOUMjfIdATpRRgIhnEGOEQkURsEK5eLkVIkI8jSCZN6i8SsxSpFiTLFFWgVSqy0BrNjCejZaDNjLjUqRVArLY1BNSbANSVxUGkVI5JUjUlWHSeU44ziEBuPEpJXJSQxHYxzDI0pMi5lZKoE0qRNSHHSQVi05WxjhloHkb0/ptBxlSNGeMyZ0yZ4ZPmXeepwASF92KdsqRuzKnVKuTIt68RnSzmwhAD54S6lgiadWWscl2nNK6Zc65fTYaDKrCMzEYzinPOmH5WZFT4mfMgjvX5NSAVUArPc2FDT4UtNrOmZFTYWxovkRi7eWKOUPNxU8uRy466JzgNg3xFjkiGi0oBIhNMjAUENHAAArJK7A0qoI0HZoaUKpDNnthqW9L8vo1oxA7qYD87Q0qXXkRAD8+BTVLGtSChWNLfQWHOhzXV9zbX2rNU6h5SAACcmoAAkaj3CGGMHSDIJAJSwQoKsfIVA6QKXcD6xMpAwCmGZKsHBtByDAmoIwVYEA6RcTUd4l2co5RAA===
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[15]: Индексы и прочие новшества - умеют ли...
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 02.12.21 16:26
Оценка:
Здравствуйте, Shmj, Вы писали:
S>Многие задачи упираются в диск и сеть, по сравнению со скоростью работы которых данные задержки не существенны.
Но Span<T> проектировался не только для задач, упирающихся в диск и сеть (хотя для них он тоже подходит лучше почти всего остального).
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[15]: Индексы и прочие новшества - умеют ли...
От: 4058  
Дата: 02.12.21 16:31
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Там трюк в том, что собственно внутренние циклы на питоне особо никто не пишет. Для ML-задач и математики там используются внешние либы, куда данные просто маршалятся для быстрой обработки.


Вызовы и маршалинг тоже мягко скажем не бесплатны.

S>Но ожидать от дотнетовских hi-perf примитивов аналогичного питону комфорта (и быстродействия), конечно же, странно.


Я о том, что те кто используют подобные средства, не особо задумываются над вопросами производительности.
Re: Индексы и прочие новшества - умеют ли...
От: Osaka  
Дата: 02.12.21 16:40
Оценка:
S>Особо не смотрел. Но просто для поддержания беседы — вроде так и не сделали, чтобы можно было конкатенацию массивов (или там Span) простым знаком +?
S>byte[] array3 = array1 + array2;
Сложение векторов вычисляется не так.
Re[16]: Индексы и прочие новшества - умеют ли...
От: Shmj Ниоткуда  
Дата: 02.12.21 17:03
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Но Span<T> проектировался не только для задач, упирающихся в диск и сеть (хотя для них он тоже подходит лучше почти всего остального).


Но в итоге в Python оператор + умеет работать со списками — а в C# нет. Пусть он работает так быстро, насколько это возможно. Но это лучше чем вообще не работает под предлогом что быстро сделать не получится.
Re[2]: Индексы и прочие новшества - умеют ли...
От: Shmj Ниоткуда  
Дата: 02.12.21 17:04
Оценка: -1
Здравствуйте, Osaka, Вы писали:

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

O>Сложение векторов вычисляется не так.

Причем тут вектора? Есть общепринятый смысл операции + и * для списков, который задан во втором по популярности ЯП.
Re[15]: Индексы и прочие новшества - умеют ли...
От: 4058  
Дата: 02.12.21 17:05
Оценка:
Здравствуйте, Shmj, Вы писали:

S>Многие задачи упираются в диск и сеть, по сравнению со скоростью работы которых данные задержки не существенны.


Нынешние объемы RAM позволяют сокращать кол-во обращений к IO для множества задач.
Re[16]: Индексы и прочие новшества - умеют ли...
От: Sharov Россия  
Дата: 02.12.21 19:17
Оценка:
Здравствуйте, 4058, Вы писали:

S>>Там трюк в том, что собственно внутренние циклы на питоне особо никто не пишет. Для ML-задач и математики там используются внешние либы, куда данные просто маршалятся для быстрой обработки.

4>Вызовы и маршалинг тоже мягко скажем не бесплатны.

По сравнению с сопутствующими вычислениями o(1).
Кодом людям нужно помогать!
Re[16]: Индексы и прочие новшества - умеют ли...
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 03.12.21 01:43
Оценка:
Здравствуйте, 4058, Вы писали:

4>Вызовы и маршалинг тоже мягко скажем не бесплатны.

Там плата константная за вызов; поэтому передать наружу матрицу размером в полгигабайта стоит столько же, сколько прочитать один элемент из неё.
4>Я о том, что те кто используют подобные средства, не особо задумываются над вопросами производительности.
Речь про два разных сценария. Скриптовый — да, там никто не задумывается.
А там, где массовая обработка математики, никто в скриптовой среде ничего не итерирует.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[17]: Индексы и прочие новшества - умеют ли...
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 03.12.21 01:46
Оценка: 12 (1) +2
Здравствуйте, Shmj, Вы писали:

S>Но в итоге в Python оператор + умеет работать со списками — а в C# нет. Пусть он работает так быстро, насколько это возможно. Но это лучше чем вообще не работает под предлогом что быстро сделать не получится.

Я вижу, вы не понимаете какую-то фундаментальную вещь. Span — это не список. Его можно воспринимать как особенную форму безопасного указателя.
От указателей никто не ожидает оператора +. Для этого могут быть предназначены другие конструкции.
Вот вы набросали прототип такой конструкции за 15 минут под кофе. Она наверняка прекрасно подойдёт для ваших сценариев; но заменой Span она быть никак не сможет.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[17]: Индексы и прочие новшества - умеют ли...
От: 4058  
Дата: 03.12.21 07:15
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>А там, где массовая обработка математики, никто в скриптовой среде ничего не итерирует.


Сложно представить мало-мальски полезную программу совсем без итераций.
Например, есть массив неких MyObject содержащий вектор позиции пространстве, где к каждому нужно применить некую матрицу преобразования.
И есть замечательная функция на C:
void mul_vec3_mx4(float *va, int sz, float *mx)
позволяющая достаточно быстро это сделать. Т.е. придется постоянно преобразовывать массив MyObject к массиву float, и потом из него копировать результат обратно в MyObject, т.е. итерировать в любом случае придется.

Тот кто использует подобные инструменты, точно также готов жертвовать производительностью (на том-же C#, Java, C/C++) в угоду синтаксических удобств.
Re[18]: Индексы и прочие новшества - умеют ли...
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 03.12.21 09:43
Оценка:
Здравствуйте, 4058, Вы писали:

4>Сложно представить мало-мальски полезную программу совсем без итераций.

4>Например, есть массив неких MyObject содержащий вектор позиции пространстве, где к каждому нужно применить некую матрицу преобразования.
4>И есть замечательная функция на C:
4>
4>void mul_vec3_mx4(float *va, int sz, float *mx)
4>
позволяющая достаточно быстро это сделать. Т.е. придется постоянно преобразовывать массив MyObject к массиву float, и потом из него копировать результат обратно в MyObject, т.е. итерировать в любом случае придется.

Ну конечно же нет. Никто не занимается поэлементным построением "массива неких MyObject, содержащих вектор позиции в пространстве". Данные читаются сразу блоками, и к ним применяются массовые функции вроде "получить вектор float3 из вектора MyObject".
Всякие numpy именно этим и занимаются — все операции делаются безо всякого поэлементного итерирования, в итоге в описанном вами случае будет ровно 3 вызова с маршаллингом:
1. Построить массив float3 из MyObject
2. Умножить массив на матрицу
3. Построить массив MyObject из float3.

4>Тот кто использует подобные инструменты, точно также готов жертвовать производительностью (на том-же C#, Java, C/C++) в угоду синтаксических удобств.

По факту питон приемлемо быстр для всякой матричной и векторной арифметики, как раз благодаря тому, что все массовые операции выдвинуты во внешний код.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[19]: Индексы и прочие новшества - умеют ли...
От: 4058  
Дата: 03.12.21 10:54
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Всякие numpy именно этим и занимаются — все операции делаются безо всякого поэлементного итерирования, в итоге в описанном вами случае будет ровно 3 вызова с маршаллингом:

S>1. Построить массив float3 из MyObject
S>2. Умножить массив на матрицу
S>3. Построить массив MyObject из float3.

Тогда уж можно сделать одну специализированную внешнюю функцию, которая сразу будет оперировать MyObject, чтобы сократить кол-во внешних вызовов.

S>По факту питон приемлемо быстр для всякой матричной и векторной арифметики, как раз благодаря тому, что все массовые операции выдвинуты во внешний код.


Если про NumPy, то он даёт профит на сравнительно больших объемах данных (в т.ч. за счет векторизации), но то, что я обычно видел на Питоне в исполнении прикладников от мира программирования (типа математиков/физиков), для которых собственно этот язык и предназначается, то это было регулярное преобразование из чего-то в то, что может потребить NumPy и перегонка результатов обратно. В отдельных случаях для линейной алгебры использовались лютые самопалы.
Re[3]: Индексы и прочие новшества - умеют ли...
От: white_znake  
Дата: 03.12.21 14:31
Оценка: +5 -1
Здравствуйте, Shmj, Вы писали:


S>Причем тут вектора? Есть общепринятый смысл операции + и * для списков, который задан во втором по популярности ЯП.

Семантика не совсем понятная. Есть var arr1 = new int[] { 1, 2, 3 } и var arr2 = new int[] { 4, 5, 6, 7 }
Что должно быть при arr1 + arr2?
{1, 2, 3, 4, 5, 6, 7}
или
{5, 7, 9, 7}?

Как сделано во 2-ом по популярности ЯП не означает, что так же надо делать везде.
Re[20]: Индексы и прочие новшества - умеют ли...
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 03.12.21 14:44
Оценка:
Здравствуйте, 4058, Вы писали:
4>Тогда уж можно сделать одну специализированную внешнюю функцию, которая сразу будет оперировать MyObject, чтобы сократить кол-во внешних вызовов.
Примерно так и делается. В расчётах вместо MyObject используется ndarray.

4>Если про NumPy, то он даёт профит на сравнительно больших объемах данных (в т.ч. за счет векторизации), но то, что я обычно видел на Питоне в исполнении прикладников от мира программирования (типа математиков/физиков), для которых собственно этот язык и предназначается, то это было регулярное преобразование из чего-то в то, что может потребить NumPy и перегонка результатов обратно.

Ну, наркоманией никто не может запретить заниматься.
4>В отдельных случаях для линейной алгебры использовались лютые самопалы.
Боюсь, что если этим людям дать C# с LA-солвером, они продолжат использовать лютые велосипеды.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[4]: Индексы и прочие новшества - умеют ли...
От: Shmj Ниоткуда  
Дата: 04.12.21 00:09
Оценка: :)
Здравствуйте, white_znake, Вы писали:

_>Что должно быть при arr1 + arr2?

_>{1, 2, 3, 4, 5, 6, 7}

Конечно.

_>или

_>{5, 7, 9, 7}?

Исключено по одной простой причине. Вы не сталкивались, но кто работает с бинарными, знает про такую штуку как BigEndian/LittleEndian. Погуглите и просветитесь немножко. По одной системе будет {5, 7, 9, 7} а по другой {4, 6, 9, 0}.

А вот конкатенация — вполне себе однозначна.

_>Как сделано во 2-ом по популярности ЯП не означает, что так же надо делать везде.


Если немножко подумаете — то поймете что других вариантов просто нет. Конкатенация удобна во многих случаях — тот же префикс добавить.
Отредактировано 04.12.2021 0:14 Shmj . Предыдущая версия .
Re[18]: Индексы и прочие новшества - умеют ли...
От: Shmj Ниоткуда  
Дата: 04.12.21 00:28
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Я вижу, вы не понимаете какую-то фундаментальную вещь. Span — это не список. Его можно воспринимать как особенную форму безопасного указателя.

S>От указателей никто не ожидает оператора +. Для этого могут быть предназначены другие конструкции.

Если добавили для массивов возможность скопировать в новый массив элементы от..до — то почему не добавили + ?
Re[19]: Индексы и прочие новшества - умеют ли...
От: vaa https://www.youtube.com/playlist?list=PLtrvASfI1KW7VOYRKjglcagQzWLoxlncl
Дата: 04.12.21 01:37
Оценка:
Здравствуйте, Shmj, Вы писали:

S>Если добавили для массивов возможность скопировать в новый массив элементы от..до — то почему не добавили + ?


https://tour.dlang.org/tour/ru/basics/arrays

c[] = a[] + b[], который, например,
сложит все элементы a и b,
то есть получится c[0] = a[0] + b[0], c[1] = a[1] + b[1] и т.д.

Re[19]: Индексы и прочие новшества - умеют ли...
От: samius Россия http://sams-tricks.blogspot.com
Дата: 04.12.21 07:15
Оценка:
Здравствуйте, Shmj, Вы писали:

S>Если добавили для массивов возможность скопировать в новый массив элементы от..до — то почему не добавили + ?

Полагаю, со спанами разобрались. Теперь к массивам. Мое мнение тут такое: не должно быть удобно выстреливать себе в ногу и убивать производительность, удваивая используемую память на ровном месте, например, что бы добавить префикс.

Однако, использовать оператор + для конкатенации массивов все же можно, используя тривиальную пользовательскую надстроечку, аггрегирующую массив, и предоставляющую оператор +.
public static ArrayBuilder<T> operator +(ArrayBuilder<T> a, T[] b) {...}

var a = new []{ 1, 2, 3 };
var b = new []{ 4, 5, 6, 7 };
int[] c = new ArrayBuilder<int>() + a + b;

Здесь же можно пойти дальше и хитрее, например, накапливать списки или деревья массивов, которое будет выпрямляться в единый массив лишь при необходимости получения результата. При этом будет заранее известна длина результирующего массива, т.е. все операции копирования будут выполнены лишь однажды, даже при множестве операций +.
Массивы напрямую не являются единицей ввода/вывода. Все равно все пихать в стримы или в спаны. Т.е. собирать в единый массив множество конкатенаций — избыточная операция в значительной части сценариев ввода/вывода.
Re[20]: Индексы и прочие новшества - умеют ли...
От: Shmj Ниоткуда  
Дата: 04.12.21 14:46
Оценка:
Здравствуйте, vaa, Вы писали:

vaa>

vaa>c[] = a[] + b[], который, например,
vaa>сложит все элементы a и b,
vaa>то есть получится c[0] = a[0] + b[0], c[1] = a[1] + b[1] и т.д.


https://rsdn.org/forum/dotnet/8146559.1
Автор: Shmj
Дата: 04.12.21
Re[20]: Индексы и прочие новшества - умеют ли...
От: Shmj Ниоткуда  
Дата: 04.12.21 14:49
Оценка:
Здравствуйте, samius, Вы писали:

S>Полагаю, со спанами разобрались.


Нет. Типа для быстродействия — но если все-равно эти операции конкатенации нужны — то нужно сделать настолько быстро, насколько это возможно.

S>Теперь к массивам. Мое мнение тут такое: не должно быть удобно выстреливать себе в ногу и убивать производительность, удваивая используемую память на ровном месте, например, что бы добавить префикс.


Тогда почему удваивается память при использовании:

var newArray = oldArray[1..^1];

?
Re[19]: Индексы и прочие новшества - умеют ли...
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 04.12.21 14:54
Оценка: 4 (1)
Здравствуйте, Shmj, Вы писали:
S>Если добавили для массивов возможность скопировать в новый массив элементы от..до — то почему не добавили + ?
Вот это уже хороший вопрос.
В принципе, наверное, можно по аналогии с a[(Range)r] => a.Slice(r.Start, r.End-r.Start) добавить в компилятор специальную ветку, которая при обработке конструкций вида
a + b
a + b + c
a + b + c + d
...

при отсутствии operator+(a, b) или встроенных операций (для числовых типов) пытается трактовать их как
a.Concat(b)
a.Concat(b, c)
a.Concat(b, c, d)
...

А затем, в случае если подходящего метода не нашлось, то
(new[] {a, b, c, ...}).Concat();


Там есть некоторая сложность в объёме поиска — потому, что если первый проход не удался, то надо попробовать сократить набор аргументов. То есть возможно a + b + c непредставимо в виде a.Concat(b, c), но представимо в виде a.Concat(b).Concat(c)


Зато специализированный код по обработке строк можно выкинуть из компилятора, и заменить его набором екстеншнов:
public static class StringConcatenations
{
   public static string Concat(this string a, string b) => string.Concat(a, b);
   public static string Concat(this string a, string b, string c) => string.Concat(a, b, c);
   public static string Concat(this string a, string b, string c, string d) => string.Concat(a, b, c, d);
   public static string Concat(this string[] strings) => string.Concat(strings);
}

подключение System.Linq сразу же даст возможность склеивать любые два IEnumerable<T> через https://docs.microsoft.com/ru-ru/dotnet/api/system.linq.enumerable.concat .
Чтобы это не сломало массивы, нужен будет аналогичный статический класс в неймспейсе System:
public static class ArrayConcatenations
{
   public static T[] Concat(this T[] a, T[] b);
   public static T[] Concat(this T[] a, T[] b, T[] c);
   public static T[] Concat(this T[][] arrays);
}


Ну, и заодно это даст возможность добавлять оператор + к существующим типам, для которых его не определили, непротиворечивым образом.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Отредактировано 04.12.2021 14:56 Sinclair . Предыдущая версия .
Re[20]: Индексы и прочие новшества - умеют ли...
От: Shmj Ниоткуда  
Дата: 04.12.21 15:07
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>>Если добавили для массивов возможность скопировать в новый массив элементы от..до — то почему не добавили + ?

S>Вот это уже хороший вопрос.

Вроде очевидное улучшение — а почему-то никто увидеть не может долгие годы.
Re[21]: Индексы и прочие новшества - умеют ли...
От: samius Россия http://sams-tricks.blogspot.com
Дата: 04.12.21 15:14
Оценка:
Здравствуйте, Shmj, Вы писали:

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


S>>Полагаю, со спанами разобрались.


S>Нет. Типа для быстродействия — но если все-равно эти операции конкатенации нужны — то нужно сделать настолько быстро, насколько это возможно.

Возможно, они нужны. Спорить о нужности не стану. Но они семантически невозможны. Напомню, спан — это непрерывный кусок памяти, расписанный значениями некоторого типа. Нельзя объединить два непрерывных куска памяти в один непрерывный без того, что бы выделить этот новый кусок где-нибудь еще. А где он будет выделен, кто это будет решать?
Если у нас 2 спана на стэке и мы хотим их склеить, то мы не сможем разместить на стеке спан результата. Выделить его динамически? В управляемой памяти, или в неуправляемой?
Тут вопросов будет больше, чем ответов.

S>>Теперь к массивам. Мое мнение тут такое: не должно быть удобно выстреливать себе в ногу и убивать производительность, удваивая используемую память на ровном месте, например, что бы добавить префикс.


S>Тогда почему удваивается память при использовании:


S>var newArray = oldArray[1..^1];


на самом деле там
var slice = oldArray[1..^1];

S>?

Т.е. память не удваивается, массив не создается.
Re[5]: Индексы и прочие новшества - умеют ли...
От: rameel https://github.com/rsdn/CodeJam
Дата: 04.12.21 16:16
Оценка:
Здравствуйте, Shmj, Вы писали:

S>Исключено по одной простой причине. Вы не сталкивались, но кто работает с бинарными, знает про такую штуку как BigEndian/LittleEndian. Погуглите и просветитесь немножко. По одной системе будет {5, 7, 9, 7} а по другой {4, 6, 9, 0}.


Как вы так умудрились в программе запущенной на одной системе получить противоречивые данные в виде разницы BigEndian/LittleEndian? Замечу, что числа разрядностью больше восьми бит уже имеет разное бинарное представление, точнее layout, в системах BigEndian/LittleEndian Только почему-то никто не исключает из своей программы не 8-битные числа и их арифметику.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[22]: Индексы и прочие новшества - умеют ли...
От: Shmj Ниоткуда  
Дата: 04.12.21 16:27
Оценка: 4 (1)
Здравствуйте, samius, Вы писали:

S>на самом деле там

S>var slice = oldArray[1..^1];

S>>?

S>Т.е. память не удваивается, массив не создается.

Да вы что: https://dotnetfiddle.net/pxRj1U
Re[23]: Индексы и прочие новшества - умеют ли...
От: samius Россия http://sams-tricks.blogspot.com
Дата: 04.12.21 16:35
Оценка:
Здравствуйте, Shmj, Вы писали:

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


S>>на самом деле там

S>>var slice = oldArray[1..^1];

S>>>?

S>>Т.е. память не удваивается, массив не создается.

S>Да вы что: https://dotnetfiddle.net/pxRj1U

Однако, действительно создается копия. Я к такому не готов, вообще еще даже в 5-ый дотнет не заглядывал, не то, что в 6-ой. Думал, что там сегменты будут.
Re[5]: Индексы и прочие новшества - умеют ли...
От: rameel https://github.com/rsdn/CodeJam
Дата: 04.12.21 16:53
Оценка:
Здравствуйте, Shmj, Вы писали:

S>Исключено по одной простой причине. Вы не сталкивались, но кто работает с бинарными, знает про такую штуку как BigEndian/LittleEndian. Погуглите и просветитесь немножко. По одной системе будет {5, 7, 9, 7} а по другой {4, 6, 9, 0}.


И вообще, что это у тебя за математика такая, что сложение чисел дает разный результат в BigEndian/LittleEndian?!
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[24]: Индексы и прочие новшества - умеют ли...
От: Shmj Ниоткуда  
Дата: 04.12.21 17:01
Оценка:
Здравствуйте, samius, Вы писали:

S>>Да вы что: https://dotnetfiddle.net/pxRj1U

S>Однако, действительно создается копия. Я к такому не готов, вообще еще даже в 5-ый дотнет не заглядывал, не то, что в 6-ой. Думал, что там сегменты будут.

Вот по этому и тема возникла. Индексы-диапазоны умеют копировать и это встроено в язык. Почему же не реализовали очевидное, что в python давно поддерживается???
Re[6]: Индексы и прочие новшества - умеют ли...
От: Shmj Ниоткуда  
Дата: 04.12.21 18:28
Оценка: :)
Здравствуйте, rameel, Вы писали:

R>И вообще, что это у тебя за математика такая, что сложение чисел дает разный результат в BigEndian/LittleEndian?!


Конечно разный, ведь числа разные. Небольшой ликбез вам: http://tolik-punkoff.com/2018/08/30/c-o-poryadke-bajt-little-endian-big-endian/
Re[7]: Индексы и прочие новшества - умеют ли...
От: rameel https://github.com/rsdn/CodeJam
Дата: 04.12.21 19:06
Оценка:
Здравствуйте, Shmj, Вы писали:

S>Конечно разный, ведь числа разные. Небольшой ликбез вам: http://tolik-punkoff.com/2018/08/30/c-o-poryadke-bajt-little-endian-big-endian/


Неужели все так печально?! Или у тебя юмор такой не умелый

Смешно объяснять прописные истины, но сложение чисел всегда дает одинаковый результат, что в BigEndian, что в LittleEndian.

Попробуй сам пройти по ссылке и внимательно почитать, что там пишут...
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[8]: Индексы и прочие новшества - умеют ли...
От: Shmj Ниоткуда  
Дата: 04.12.21 19:26
Оценка:
Здравствуйте, rameel, Вы писали:

R>Смешно объяснять прописные истины, но сложение чисел всегда дает одинаковый результат, что в BigEndian, что в LittleEndian.

R>Попробуй сам пройти по ссылке и внимательно почитать, что там пишут...

Давай по простому, в десятичной системе. Сколько будет 123 + 4567?

Если старший разряд слева, то 123 + 4567 = 4690 — это привычная для нас запись.

Если старший разряд справа, то в привычной для нас записи будет 321 + 7654 = 7975, что в записи LittleEndian будет 5797.

Как видите — совсем разный результат во всех смыслах.
Re[9]: Индексы и прочие новшества - умеют ли...
От: rameel https://github.com/rsdn/CodeJam
Дата: 04.12.21 19:36
Оценка:
Здравствуйте, Shmj, Вы писали:

S>Давай по простому, в десятичной системе. Сколько будет 123 + 4567?


В десятичной системе 123 + 4567 всегда даст один и тот же результат. Везде! Не зависимо от его представления в той или иной системе.

S>Если старший разряд слева, то 123 + 4567 = 4690 — это привычная для нас запись.


S>Если старший разряд справа, то в привычной для нас записи будет 321 + 7654 = 7975, что в записи LittleEndian будет 5797.


Ну а в восьмиричной это вообще другое число. К чему все это? У нас было 2 массива чисел, при сложений пар элементов которых у вас почему то получается разный результат в зависимости от системы на которой исполнятся программа.


Вот давай, чтобы не путать представление числа и само число:

int a = 123;
int b = 4567;
int c = a + b;
Console.WriteLine(c);


Что будет выведено на экран в LE/BE системах?
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[10]: Индексы и прочие новшества - умеют ли...
От: Shmj Ниоткуда  
Дата: 04.12.21 20:09
Оценка:
Здравствуйте, rameel, Вы писали:

R>В десятичной системе 123 + 4567 всегда даст один и тот же результат. Везде! Не зависимо от его представления в той или иной системе.


123 в LittleEndian — это 321 в BigEndian, бро.

R>Ну а в восьмиричной это вообще другое число. К чему все это? У нас было 2 массива чисел, при сложений пар элементов которых у вас почему то получается разный результат в зависимости от системы на которой исполнятся программа.


Дело в том, бро, что система определяет только встроенные числа. Т.е. int, long и т.д.

Когда ты определяешь число в виде массива байт — система тут никаким боком — ты сам решаешь где у тебя старший а где младший.

R>Что будет выведено на экран в LE/BE системах?


В данном случае разницы не будет, очевидно.
Re[21]: Индексы и прочие новшества - умеют ли...
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 05.12.21 09:59
Оценка:
Здравствуйте, Shmj, Вы писали:
S>Вроде очевидное улучшение — а почему-то никто увидеть не может долгие годы.
Потребность низкая. Так-то проект открытый — клонируете репозиторий, пилите изменение, готовите тесты, отправляете pull request.
Делов-то.
BTW, https://github.com/dotnet/csharplang/discussions/823
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Отредактировано 05.12.2021 10:15 Sinclair . Предыдущая версия .
Re[22]: Индексы и прочие новшества - умеют ли...
От: Shmj Ниоткуда  
Дата: 05.12.21 10:01
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Потребность низкая. Так-то проект открытый — клонируете репозиторий, пилите изменение, готовите тесты, отправляете pull request.

S>Делов-то.

С чего вы взяли что потребность низкая? А создать часть массива в виде нового — высокая?
Re[23]: Индексы и прочие новшества - умеют ли...
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 05.12.21 10:30
Оценка:
Здравствуйте, Shmj, Вы писали:
S>С чего вы взяли что потребность низкая?
С того, что подобная штука даже не обсуждается в https://github.com/dotnet/csharplang.
S> А создать часть массива в виде нового — высокая?
Я сходу не смог понять, откуда это взялось.

С одной стороны, в массивах нет метода this[Range r].
Вроде бы, такой синтаксис мог появиться благодаря Implicit Range Support, но он опирается на метод Slice, которого в массивах тоже нету.
Получается, что для T[] есть специальный код в компиляторе, который приделывает к ним новый индексер, использование которого порождает вызов System.Runtime.CompilerServices.RuntimeHelpers.GetSubArray.
Действительно, кто-то решил, что будет круто приделать слайсинг к массивам. Несмотря на то, что фича пилилась в первую очередь для Span и для Linq в качестве замены Skip().Take().

В общем, это выглядит как последствия передачи компилятора в опен сорс. Каждый пилит ту идею, которая пришла ему в голову
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[11]: Индексы и прочие новшества - умеют ли...
От: Muxa  
Дата: 05.12.21 11:05
Оценка:
R>>Что будет выведено на экран в LE/BE системах?

S>В данном случае разницы не будет, очевидно.


Ты же сам комментом выше писал что разница будет. Давай ты сперва сам определишься?
Re[2]: Индексы и прочие новшества - умеют ли...
От: fk0 Россия  
Дата: 05.12.21 13:38
Оценка: +1 :)))
Здравствуйте, Sinclair, Вы писали:

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

S>А для массивов придётся пилить компилятор — способа приделать оператор + к встроенному типу нет.

Вот поэтому C# -- кривая паделка микрософта, а C++ -- язык будущего.
Куда в .NET не ткни -- прибито гвоздями и компиляторная магия.
Всё здорово и замечательно только в проектах уровня хелло-ворлд, как до дела
доходит, сразу проблемы.
Re[24]: Индексы и прочие новшества - умеют ли...
От: Shmj Ниоткуда  
Дата: 05.12.21 15:50
Оценка: -1
Здравствуйте, Sinclair, Вы писали:

S>>С чего вы взяли что потребность низкая?

S>С того, что подобная штука даже не обсуждается в https://github.com/dotnet/csharplang.

Не обсуждается — потому что боты не смогут породить новую идею. Пока не ткнешь носом — будут обсуждать по кругу только то что им скажут.

Ну ок. Что вы делаете с массивами вообще? Для чего они вам?
Re[12]: Индексы и прочие новшества - умеют ли...
От: Shmj Ниоткуда  
Дата: 05.12.21 15:53
Оценка:
Здравствуйте, Muxa, Вы писали:

S>>В данном случае разницы не будет, очевидно.

M>Ты же сам комментом выше писал что разница будет. Давай ты сперва сам определишься?

Бро, прежде чем обвинить кого-то в тупости, убедись что у тебя хватило мозгов его понять.

Есть системные типы — порядок байт в них зависит от системы. .Net на данный момент не используется ни на одной системе с BigEndian, к слову.

Если же ты сам записываешь некое число, представляешь его в массиве байт — то ты сам и решаешь с какой стороны будет наиболее высокий разряд. Обычно выбирают LittleEndian, когда 0 элемент массива младший. Но это никак не определятся системой — ты сам решаешь.
Re[13]: Индексы и прочие новшества - умеют ли...
От: Muxa  
Дата: 05.12.21 16:17
Оценка:
Зачем мне записывать число как байты? Чем не подходит int a = 1234?
Re[14]: Индексы и прочие новшества - умеют ли...
От: Shmj Ниоткуда  
Дата: 05.12.21 16:58
Оценка:
Здравствуйте, Muxa, Вы писали:

M>Зачем мне записывать число как байты? Чем не подходит int a = 1234?


Если число не вмещается в 8 байт, вестимо. Для этого ведь предлагают реализовать оператор + как сложение чисел?

Мое мнение — сложение массивов как чисел — не просто вызывает неоднозначность с Big/Little -Endian, но и как раз менее применимо, чем конкатенация. Сложение нужно только для математики длинных чисел — это отдельный класс типа BigInteger. А вот конкатенация нужна намного чаще и для всех типов массивов она актуальная.
Отредактировано 05.12.2021 17:02 Shmj . Предыдущая версия .
Re[15]: Индексы и прочие новшества - умеют ли...
От: Muxa  
Дата: 05.12.21 17:37
Оценка: +2
Что за бред ты несешь?
Сложение векторов это операция, которую применяют миллионы раз в каждой компьютерной игре при расчете графики.
Открой любую библиотеку линейной алгебры, там сложение векторов в каждой функции.
Re[16]: Индексы и прочие новшества - умеют ли...
От: Shmj Ниоткуда  
Дата: 05.12.21 18:03
Оценка: :)))
Здравствуйте, Muxa, Вы писали:

M>Что за бред ты несешь?

M>Сложение векторов это операция, которую применяют миллионы раз в каждой компьютерной игре при расчете графики.
M>Открой любую библиотеку линейной алгебры, там сложение векторов в каждой функции.

Это специализированные преобразования. Как вы будете вычислять сумму массивов строк? Или сумму списков неких Item? Никак. Это подходит только для целых чисел (и даже там есть неоднозначность Little-Big). Даже сложить два массива float — это уже не однозначное преобразование.

А конкатенация — актуальна для всего.
Отредактировано 05.12.2021 18:03 Shmj . Предыдущая версия .
Re[17]: Индексы и прочие новшества - умеют ли...
От: Muxa  
Дата: 05.12.21 18:41
Оценка:
M>>Что за бред ты несешь?
M>>Сложение векторов это операция, которую применяют миллионы раз в каждой компьютерной игре при расчете графики.
M>>Открой любую библиотеку линейной алгебры, там сложение векторов в каждой функции.

S>Это специализированные преобразования. Как вы будете вычислять сумму массивов строк?

Применить оператор "+" поэлементно.

S>Или сумму списков неких Item? Никак.

Применить оператор "+" поэлементно.

S>Это подходит только для целых чисел (и даже там есть неоднозначность Little-Big).


S>Даже сложить два массива float — это уже не однозначное преобразование.
надо коллегам в геймдеве рассказать, а то они не в курсе.

S>А конкатенация — актуальна для всего.

И как же нам скантатенировать два элемента struct { int x; void* y; }?
Re[17]: Индексы и прочие новшества - умеют ли...
От: samius Россия http://sams-tricks.blogspot.com
Дата: 05.12.21 18:50
Оценка: +2
Здравствуйте, Shmj, Вы писали:

S>А конкатенация — актуальна для всего.

Слишком сильное заявление. С моей колокольни она не нужна примерно для всего, за редким исключением. Например, подсунуть склеенный массив в какой-нибудь JSON форматтер. Т.е. там, где единицей обмена информации является именно массив. Но это единичные случаи, т.к. базой для ввода/вывода являются потоки, работа с которыми не требует конкатенации массивов, более того, она там избыточна. Даже обмен с неуправляемой памятью конкатенации не требует.
Re[18]: Индексы и прочие новшества - умеют ли...
От: Shmj Ниоткуда  
Дата: 05.12.21 19:06
Оценка:
Здравствуйте, Muxa, Вы писали:

S>>Это специализированные преобразования. Как вы будете вычислять сумму массивов строк?

M>Применить оператор "+" поэлементно.

А в случае с целыми числами — вы просто поэлементно складываете или же учитываете переполнение и переносите в новый разряд?

S>>Или сумму списков неких Item? Никак.

M>Применить оператор "+" поэлементно.

А если оператор не определен для Item?

S>>Это подходит только для целых чисел (и даже там есть неоднозначность Little-Big).

M>
S>>Даже сложить два массива float — это уже не однозначное преобразование.
M> надо коллегам в геймдеве рассказать, а то они не в курсе.

А причем тут геймдев?

S>>А конкатенация — актуальна для всего.

M>И как же нам скантатенировать два элемента struct { int x; void* y; }?

Конкатенация массивов/списков — просто создаете новый массив, который по длине равен двум — и копируете ссылки на элементы.
Re[18]: Индексы и прочие новшества - умеют ли...
От: Shmj Ниоткуда  
Дата: 05.12.21 19:08
Оценка:
Здравствуйте, samius, Вы писали:

S>>А конкатенация — актуальна для всего.

S>Слишком сильное заявление. С моей колокольни она не нужна примерно для всего, за редким исключением. Например, подсунуть склеенный массив в какой-нибудь JSON форматтер. Т.е. там, где единицей обмена информации является именно массив. Но это единичные случаи, т.к. базой для ввода/вывода являются потоки, работа с которыми не требует конкатенации массивов, более того, она там избыточна. Даже обмен с неуправляемой памятью конкатенации не требует.

Для чего вы вообще используете массивы/списки?

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

+ можно добавить — как для строк. Кто не хочет — можно не использовать.
Отредактировано 05.12.2021 19:15 Shmj . Предыдущая версия .
Re: Индексы и прочие новшества - умеют ли...
От: graniar  
Дата: 05.12.21 19:17
Оценка:
Здравствуйте, Shmj, Вы писали:

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


S>byte[] array1 = ...

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

S>?


#define array1 "Hello"
#define array2 "world
#define array3 array1 " " array2

:P
Re[19]: Индексы и прочие новшества - умеют ли...
От: Muxa  
Дата: 05.12.21 19:37
Оценка:
S>>>Это специализированные преобразования. Как вы будете вычислять сумму массивов строк?
M>>Применить оператор "+" поэлементно.
S>А в случае с целыми числами — вы просто поэлементно складываете или же учитываете переполнение и переносите в новый разряд?
В какой еще новый разряд?
math24.ru/сложение-и-вычитание-векторов.html

S>>>Или сумму списков неких Item? Никак.

M>>Применить оператор "+" поэлементно.
S>А если оператор не определен для Item?
Не скомпилируется пока не определишь.

S>>>Это подходит только для целых чисел (и даже там есть неоднозначность Little-Big).

M>>
S>>>Даже сложить два массива float — это уже не однозначное преобразование.
M>> надо коллегам в геймдеве рассказать, а то они не в курсе.
S>А причем тут геймдев?
Сложение векторов это одна из основных операций в компьютерной графике.

S>>>А конкатенация — актуальна для всего.

M>>И как же нам скантатенировать два элемента struct { int x; void* y; }?
S>Конкатенация массивов/списков — просто создаете новый массив, который по длине равен двум — и копируете ссылки на элементы.
Ну, если конкатенация актуальна для всего как сконкатенировать два объекта этой структуры?
Re[20]: Индексы и прочие новшества - умеют ли...
От: Shmj Ниоткуда  
Дата: 05.12.21 19:48
Оценка:
Здравствуйте, Muxa, Вы писали:

S>>А причем тут геймдев?

M>Сложение векторов это одна из основных операций в компьютерной графике.

И? C# — это что, язык исключительно для компьютерной графики? Это язык общего значения.

S>>>>А конкатенация — актуальна для всего.

M>>>И как же нам скантатенировать два элемента struct { int x; void* y; }?
S>>Конкатенация массивов/списков — просто создаете новый массив, который по длине равен двум — и копируете ссылки на элементы.
M>Ну, если конкатенация актуальна для всего как сконкатенировать два объекта этой структуры?

Мы о конкатенации СПИСКОВ!!! А элементы невозможно конкатенировать, за редким исключением.
Re[21]: Индексы и прочие новшества - умеют ли...
От: Muxa  
Дата: 05.12.21 19:52
Оценка:
S>>>А причем тут геймдев?
M>>Сложение векторов это одна из основных операций в компьютерной графике.
S>И? C# — это что, язык исключительно для компьютерной графики? Это язык общего значения.
Так и сложение векторов используется не только в графике.

S>>>>>А конкатенация — актуальна для всего.

M>>>>И как же нам скантатенировать два элемента struct { int x; void* y; }?
S>>>Конкатенация массивов/списков — просто создаете новый массив, который по длине равен двум — и копируете ссылки на элементы.
M>>Ну, если конкатенация актуальна для всего как сконкатенировать два объекта этой структуры?
S> Мы о конкатенации СПИСКОВ!!! А элементы невозможно конкатенировать, за редким исключением.
А, я просто думал что "конкатенация — актуальна для всего". Ошибался видимо.
Re[19]: Индексы и прочие новшества - умеют ли...
От: samius Россия http://sams-tricks.blogspot.com
Дата: 05.12.21 20:12
Оценка:
Здравствуйте, Shmj, Вы писали:

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


S>Для чего вы вообще используете массивы/списки?

Чаще всего для того, что бы пробежать по последовательности более одного раза внутри одного метода. Но даже если в своей двоичной сериализации данных, не помню, что бы мне нужна была конкатенация массивов. Может быть она кажется простым решением в некоторых случаях, но это шикарный способ заскочить в LOH лишний раз.
S>Вообще мешать не будет. Кроме как однозначная конкатенация — других разумных вариантов нет. Если поэлементное складывание — то как быть с переполнением, как складывать типы, отличные от целых чисел?
Мешать-то не будет. Для чего она нужна?
Ну да ладно, допустим, интероп. Но как часто вообще нужен интероп и тем более, конкатенация массивов для него? В моей практике не каждые 5 лет такое бывает.

S>+ можно добавить — как для строк. Кто не хочет — можно не использовать.

Ну да строки-то мы складываем каждый день не по разу, однако, чем дальше, тем реже. Благодаря интерполяции.
Re[22]: Индексы и прочие новшества - умеют ли...
От: Shmj Ниоткуда  
Дата: 05.12.21 20:16
Оценка:
Здравствуйте, Muxa, Вы писали:

S>>И? C# — это что, язык исключительно для компьютерной графики? Это язык общего значения.

M>Так и сложение векторов используется не только в графике.

Я ни разу не сталкивался — ни в какой области.

S>>>>>>А конкатенация — актуальна для всего.

M>>>>>И как же нам скантатенировать два элемента struct { int x; void* y; }?
S>>>>Конкатенация массивов/списков — просто создаете новый массив, который по длине равен двум — и копируете ссылки на элементы.
M>>>Ну, если конкатенация актуальна для всего как сконкатенировать два объекта этой структуры?
S>> Мы о конкатенации СПИСКОВ!!! А элементы невозможно конкатенировать, за редким исключением.
M>А, я просто думал что "конкатенация — актуальна для всего". Ошибался видимо.

Умейте читать в контексте — конкатенация списка актуальна для любого типа элемента списка. Не нужно реализовывать + для отдельных элементов.
Re[23]: Индексы и прочие новшества - умеют ли...
От: Muxa  
Дата: 05.12.21 20:59
Оценка:
S>Умейте читать в контексте — конкатенация списка актуальна для любого типа элемента списка.
Даже если список с циклом?

S> Не нужно реализовывать + для отдельных элементов.

Погоди, погоди, это что получается если мне нужно поэлементно применить некоторую операцию к элементам контейнера, то я должен реализовать эту операцию для этих элементов?
Прям вечер откровений какой-то.
Отредактировано 05.12.2021 21:00 Muxa . Предыдущая версия .
Re: Индексы и прочие новшества - умеют ли...
От: vaa https://www.youtube.com/playlist?list=PLtrvASfI1KW7VOYRKjglcagQzWLoxlncl
Дата: 06.12.21 02:15
Оценка: +1
Здравствуйте, Shmj, Вы писали:

S>Особо не смотрел.


using System;
using System.Linq;
using static ArrayFunctions;

var a = new[] { 1, 2, 3 }; 
var b = new[] { 4, 5, 6 };
var c = a.Concat(b).ToArray();
var d = a.Union(b).ToArray();
var e = a.Plus(b);
var j = plus(a,b);// <= забавно, функция занимает столько же символов сколько и метод.


Чем '+' семантически лучше метода?

public static class ArrayExt {
    public static T[] Plus<T>(this T[] array,T[] add) => array.Union(add).ToArray();
}

public static class ArrayFunctions {
    public static T[] plus<T>(T[] array,T[] add) => array.Plus(add); 
}
Re[2]: Индексы и прочие новшества - умеют ли...
От: Shmj Ниоткуда  
Дата: 06.12.21 03:01
Оценка:
Здравствуйте, vaa, Вы писали:

vaa>Чем '+' семантически лучше метода?


Нагляднее.
Re[3]: Индексы и прочие новшества - умеют ли...
От: vaa https://www.youtube.com/playlist?list=PLtrvASfI1KW7VOYRKjglcagQzWLoxlncl
Дата: 06.12.21 06:32
Оценка:
Здравствуйте, Shmj, Вы писали:

vaa>>Чем '+' семантически лучше метода?


S>Нагляднее.


Субъективно.

(+ a b)
(add a b)


let c = (+) a b;
let c =  a + b;
let c =  a |> ((+) b);



Вопросов масса. Тут даже нет у участников какой-то четкой позиции по поводу нужности.
что насчет удобства работы с кодом? будет ли код обобщеннее, легче рефакторится, чем код на функциях или методах?
Вдруг захочется пооптимизировать '+', не проще ли это будет с методом?

вот кстати еще один вариант (из пхп), и это не сложение:

$a + $b Объединение

так что, + это сложение или объединение массивов?
Re[4]: Индексы и прочие новшества - умеют ли...
От: Shmj Ниоткуда  
Дата: 06.12.21 12:01
Оценка:
Здравствуйте, vaa, Вы писали:

S>>Нагляднее.

vaa>Субъективно.

Ну уберите тогда операторы из языка — оставьте только функции. А вместо {} — пишите begin|end.

vaa>[/q]

vaa>так что, + это сложение или объединение массивов?

Только конкатенация как в python не вызывает проблем.
Re[5]: Индексы и прочие новшества - умеют ли...
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 06.12.21 12:31
Оценка: 3 (1)
Здравствуйте, Shmj, Вы писали:

S>Ну уберите тогда операторы из языка — оставьте только функции. А вместо {} — пишите begin|end.

У меня для вас хорошие новости — помимо по сю пору платного Дельфи, есть ещё и FreePascal. Там всё ровно так, как вы заказываете — и begin/end, и отсутствие перегрузки операторов.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[5]: Индексы и прочие новшества - умеют ли...
От: vaa https://www.youtube.com/playlist?list=PLtrvASfI1KW7VOYRKjglcagQzWLoxlncl
Дата: 07.12.21 02:36
Оценка:
Здравствуйте, Shmj, Вы писали:

S>Ну уберите тогда операторы из языка — оставьте только функции. А вместо {} — пишите begin|end.

Ну так это Виртом и его Oberon доказано уже, что чем проще ЯП тем он более надежный.
C++ почему ругают потому что там столько правил, что не нарушить хотя бы одно не может ни один джедай.
если же принять единственную возможную форму (Функция аргументы), то это освоит любой.
Где-то читал эссэ про лисп, там есть фраза "если бы скобки были единственной проблемой..."
Как-то так.
Эту же мысль можно и объединению массивов можно применить. Неужели это проблема которая не дает делать простые и надежные программы?
Re[6]: Индексы и прочие новшества - умеют ли...
От: Shmj Ниоткуда  
Дата: 07.12.21 03:33
Оценка:
Здравствуйте, vaa, Вы писали:

S>>Ну уберите тогда операторы из языка — оставьте только функции. А вместо {} — пишите begin|end.

vaa>Ну так это Виртом и его Oberon доказано уже, что чем проще ЯП тем он более надежный.

Тут не надежность а наглядность важна. К спец. символам мозг привыкает и как бы выхватывает из общего текста. Слова еще прочесть нужно — а спец. символ сразу распознается.
Re[7]: Индексы и прочие новшества - умеют ли...
От: vaa https://www.youtube.com/playlist?list=PLtrvASfI1KW7VOYRKjglcagQzWLoxlncl
Дата: 07.12.21 07:00
Оценка:
Здравствуйте, Shmj, Вы писали:

S>Тут не надежность а наглядность важна. К спец. символам мозг привыкает и как бы выхватывает из общего текста. Слова еще прочесть нужно — а спец. символ сразу распознается.


Гомоиконичность наглядее же, плюс ко всему функцию '+' можно компоузить, передавать и .т.д. первоклассная сущность, а операторы это "деревянные игрущки прибитые гвоздями к потолку"

(let ((f #'+))
   (funcall f 1 1))
;; => 2
Re[15]: Индексы и прочие новшества - умеют ли...
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 07.12.21 11:12
Оценка: 3 (1) +2 :)
Здравствуйте, Shmj, Вы писали:
S>Если число не вмещается в 8 байт, вестимо. Для этого ведь предлагают реализовать оператор + как сложение чисел?
Давайте всё же отложим в сторону чайную ложку, соду, зажигалку, и пакетик с порошком, похожим на муку.

Массив — это очень низкоуровневая конструкция. Она может использоваться для большого количества разных применений.
Использование его в качестве "целого числа большой разрядности" — изрядная экзотика. Очень странно, что именно она первой пришла вам в голову.
Гораздо более частым случаем является использование массива для воплощение алгебраической концепции вектора.
И сложение векторов в алгебре традиционно является поэлементной суммой. Применимо оно, естественно, только к векторам одинакового размера.
Никакого little-endian или big-endian там нет, как нет и "переноса переполнения".
Если в алгебре у нас встречается сумма разноразмерных векторов, то обычно подразумевается наличие операции повышения размерности — то есть двумерный вектор (4, 5) эквивалентен трёхмерному вектору (4, 5, 0) и четырёхмерному (4, 5, 0, 0).
Именно такое векторное сложение реализует предлагаемое выше по треду поэлементное сложение.

Мы можем использовать вектора-поверх-массивов и для других задач — например, i-й элемент массива соответствует количеству объектов i-го класса в нашей выборке (см. задачи классификации, ML и прочий data science).
В таком случае поэлементная сумма по-прежнему является корректным результатом для, к примеру, агрегации векторов, построенных по двум разным выборкам.

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

Опять-таки, встраивать такое поведение прямо в базовую конструкцию "массив однотипных элементов" — оверкилл.
Мы ожидаем подобного поведения от более высокоуровневых конструкций типа https://docs.microsoft.com/en-us/dotnet/api/system.numerics.vector3.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[16]: Индексы и прочие новшества - умеют ли...
От: vaa https://www.youtube.com/playlist?list=PLtrvASfI1KW7VOYRKjglcagQzWLoxlncl
Дата: 07.12.21 12:24
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Мы ожидаем подобного поведения от более высокоуровневых конструкций типа https://docs.microsoft.com/en-us/dotnet/api/system.numerics.vector3.


или как в ДИ особый синтаксис, впрочем в ди массивы более универсальны чем в шарпе:
    auto a = [1,2,3];
    auto b = [3,4,5];
    auto c = new int[3];
    c[] = a[] + b[]; // сложение => [4, 6, 8]
    auto d = a ~ b; // сцепление => [1, 2, 3, 3, 4, 5]
Re[7]: Индексы и прочие новшества - умеют ли...
От: karbofos42 Россия  
Дата: 07.12.21 14:29
Оценка:
Здравствуйте, Shmj, Вы писали:

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


S>>>Ну уберите тогда операторы из языка — оставьте только функции. А вместо {} — пишите begin|end.

vaa>>Ну так это Виртом и его Oberon доказано уже, что чем проще ЯП тем он более надежный.

S>Тут не надежность а наглядность важна. К спец. символам мозг привыкает и как бы выхватывает из общего текста. Слова еще прочесть нужно — а спец. символ сразу распознается.


Прикол в том, что кому нужна будет эта операция, всё равно будет использовать свои обёртки.
Потому что вот эти пересоздания массивов — такое себе решение.
Для всяких префиксов и прочей фигни я скорее всего напрямую в Stream буду данные пихать, а не пересобирать сотню массивов и копировать элементы туда-сюда.
Для строк StringBuilder не просто так придумали, хоть и есть оператор +.
Наглядность записи типа var e = a + b + c + d всё равно поделится на ноль тем фактом, то там будет создано 3 массива и куча лишних копирований элементов,
что нормальные разработчики это использовать не будут и будут на форумах писать, что в майкрософте наркоманы, добавляют в язык всякий хлам, а не какие-то нужные вещи.
Re[8]: Индексы и прочие новшества - умеют ли...
От: Shmj Ниоткуда  
Дата: 07.12.21 16:45
Оценка:
Здравствуйте, karbofos42, Вы писали:

K>Наглядность записи типа var e = a + b + c + d всё равно поделится на ноль тем фактом, то там будет создано 3 массива и куча лишних копирований элементов,


Вот, хотел привести пример строк. Тоже вроде как + на практике редко где применим, когда необходима именно работа со строками, однако он есть. И таки используете для второстепенных целей, когда нет требования к ресурсам (к примеру для быстрого тестового приложения — когда нужно быстро запустить и посмотреть как отработает). Добавить + в StringBuilder — было бы красивее, кста.

Для массивов и списков та же идея. Если хочешь экономии ресурсов — то не применяй.
Отредактировано 07.12.2021 16:47 Shmj . Предыдущая версия . Еще …
Отредактировано 07.12.2021 16:47 Shmj . Предыдущая версия .
Re[9]: Индексы и прочие новшества - умеют ли...
От: samius Россия http://sams-tricks.blogspot.com
Дата: 07.12.21 16:56
Оценка: +2
Здравствуйте, Shmj, Вы писали:

S>Добавить + в StringBuilder — было бы красивее, кста.

Применение + к StringBuilder-у отвратительно, т.к. оператор не должен изменять операнды. Но если (+) не будет изменять StringBuilder, то в чем тогда смысл?
Re[10]: Индексы и прочие новшества - умеют ли...
От: Shmj Ниоткуда  
Дата: 07.12.21 21:15
Оценка:
Здравствуйте, samius, Вы писали:

S>Применение + к StringBuilder-у отвратительно, т.к. оператор не должен изменять операнды. Но если (+) не будет изменять StringBuilder, то в чем тогда смысл?


Можно += перегрузить.
Re[11]: Индексы и прочие новшества - умеют ли...
От: samius Россия http://sams-tricks.blogspot.com
Дата: 08.12.21 04:49
Оценка: 18 (1)
Здравствуйте, Shmj, Вы писали:

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


S>>Применение + к StringBuilder-у отвратительно, т.к. оператор не должен изменять операнды. Но если (+) не будет изменять StringBuilder, то в чем тогда смысл?


S>Можно += перегрузить.


Составные операторы присваивания не могут быть перегружены явным образом. Однако при перегрузке бинарного оператора соответствующий составной оператор присваивания (если таковой имеется) также неявно перегружается. Например, += вычисляется с помощью +, который может быть перегружен.

https://docs.microsoft.com/ru-ru/dotnet/csharp/language-reference/operators/operator-overloading
Re[16]: Индексы и прочие новшества - умеют ли...
От: Shmj Ниоткуда  
Дата: 09.12.21 01:43
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Гораздо более частым случаем является использование массива для воплощение алгебраической концепции вектора.


Что насчет списков?
Re[17]: Индексы и прочие новшества - умеют ли...
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 09.12.21 02:41
Оценка:
Здравствуйте, Shmj, Вы писали:
S>Что насчет списков?
Списки достаточно плохо годятся для воплощения алгебраической концепции вектора.
Что конкретно вас интересует?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[18]: Индексы и прочие новшества - умеют ли...
От: Shmj Ниоткуда  
Дата: 09.12.21 03:51
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>>Что насчет списков?

S>Списки достаточно плохо годятся для воплощения алгебраической концепции вектора.
S>Что конкретно вас интересует?

Знак + для списков вестимо, об этом же говорим.
Re[19]: Индексы и прочие новшества - умеют ли...
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 09.12.21 06:32
Оценка:
Здравствуйте, Shmj, Вы писали:
S>Знак + для списков вестимо, об этом же говорим.
Для каких именно списков?
Тут возникает масса малоприятных нюансов.
Смотрите: оператор резолвится статически на основе формальных типов параметров. Нормального способа сделать оператор виртуальным не существует, по крайней мере в рамках привычного нам ООП с полиморфизмом по нулевому аргументу.

Это означает, что при наследовании типов у вас могут получаться совершенно контринтуитивные результаты.
Например, если у вас определён оператор + для аргументов List<T>, то к List<T> можно будет прибавлять экземпляры не только List<T>, но и его потомков.
Результат, правда, окажется всё того же типа List<T>. Ну, это вроде бы ладно — прибавили мы к List<System.Data.Services.ExpandSegment> какой-нибудь System.Data.Services.ExpandSegmentCollection, получили List<System.Data.Services.ExpandSegment>. Вроде норм. Но вот забавно — мы можем попробовать сложить два экземпляра System.Data.Services.ExpandSegmentCollection, но получим вовсе не System.Data.Services.ExpandSegmentCollection, а по-прежнему List<System.Data.Services.ExpandSegment>.

Исправить это не так-то легко. Если вы попробуете напилить непротиворечивую реализацию "оператора сложения для списков", вы поймёте причину.

Для класса string эти соображения не действуют, т.к. он sealed.
Но у нас нет sealed-класса для списков.

Даже для массивов у нас возникнут затруднения при описании оператора сложения.

В той реализации, которую я предлагал, b + d превращается в b.Concat(d).
Прикол в том, что это будет работать и для случаев
b = new Base[1];
d = new Derived[1];

Результатом у нас, очевидно, должен быть массив Base[2].
Попробуйте написать такое определение и реализацию метода Concat, чтобы (d + b) давало не ошибку компиляции, а по-прежнему Base[2].
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re: Индексы и прочие новшества - умеют ли...
От: Vladek Россия Github
Дата: 09.12.21 14:02
Оценка:
Здравствуйте, Shmj, Вы писали:

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


S>byte[] array1 = ...

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

S>?


Это будет уже другой тип данных. Надо смотреть в сторону ArrayBufferWriter<T> и других типов из пространства System.Buffers.
http://files.rsdn.org/43395/hr-kyle-theisen-04.png
Re[3]: Индексы и прочие новшества - умеют ли...
От: Ночной Смотрящий Россия  
Дата: 11.01.22 06:38
Оценка:
Здравствуйте, fk0, Вы писали:

fk0> Вот поэтому C# -- кривая паделка микрософта, а C++ -- язык будущего.

fk0>Куда в .NET не ткни -- прибито гвоздями и компиляторная магия.
fk0>Всё здорово и замечательно только в проектах уровня хелло-ворлд, как до дела
fk0>доходит, сразу проблемы.

Спасибо что пришел сюда рассказать нам об этом.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[8]: Индексы и прочие новшества - умеют ли...
От: Ночной Смотрящий Россия  
Дата: 11.01.22 06:41
Оценка:
Здравствуйте, karbofos42, Вы писали:

K>Наглядность записи типа var e = a + b + c + d всё равно поделится на ноль тем фактом, то там будет создано 3 массива


Не будет.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[19]: Индексы и прочие новшества - умеют ли...
От: Ночной Смотрящий Россия  
Дата: 11.01.22 08:54
Оценка:
Здравствуйте, Shmj, Вы писали:

S>Кроме как однозначная конкатенация — других разумных вариантов нет.


А ты уверен что она однозначная? Как, к примеру, ты будешь конкатенировать два Dictionary?
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[20]: Индексы и прочие новшества - умеют ли...
От: Shmj Ниоткуда  
Дата: 11.01.22 11:20
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>А ты уверен что она однозначная? Как, к примеру, ты будешь конкатенировать два Dictionary?


Однозначность только со списками. Со словарями — понятно что есть варианты — либо добавлять недостающие элементы, либо же выбрасывать исключение если два одинаковых ключа.
Re[21]: Индексы и прочие новшества - умеют ли...
От: Ночной Смотрящий Россия  
Дата: 11.01.22 13:06
Оценка:
Здравствуйте, Shmj, Вы писали:

НС>>А ты уверен что она однозначная? Как, к примеру, ты будешь конкатенировать два Dictionary?

S>Однозначность только со списками.

А словарь это тоже список.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[3]: Индексы и прочие новшества - умеют ли...
От: IT Россия linq2db.com
Дата: 11.01.22 14:52
Оценка:
Здравствуйте, Shmj, Вы писали:

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


Представляю каких уродцев можно налепить с такой фичей.
Для строк в .NET FW сразу с самого начала вместе к конкатенацией был предоставлен StringBuilder и всем любителям Питонов было объяснено, что конкатенацией сильно увлекаться не стоит, если надо добавлять префиксы/хидеры, то лучше пользоваться StringBuilder.

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


Ну это понятно.
//rsdn.org/forum/images/bis.gif Если нам не помогут, то мы тоже никого не пощадим.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.