Значит надо уметь их задавать

И никакого сожаления тут не нужно

Это тоже неудачная традиция. Ковектор тоже «элемент векторного пространства», но есть причины, по которым у ковекторов существует их (отдельное) название. Лучше было бы говорить «линейный объект», или что-то в этом духе. И по-моему очень уместно как раз использовать тут слово «тензор».

Собственно, это хорошо вскрывается, когда люди просят объяснить, что такое тензор. «Элемент тензорного произведения» дурацкий ответ, но в итоге он часто озвучивается, потому что математики не оперируют понятием «тензор», а оперируют понятием тензорного произведения. В то же время они оперируют понятием «вектор», но тщательно отделяют векторы от ковекторов и других тензоров, когда речь о геометрии. Благодаря этому не появляется выражений, не имеющих геометрического смысла (= не инвариантных относительно замен координат).

Люди не спрашивают, что такое вектор, потому что могут легко представить себе отрезок со стрелкой и естественные операции над отрезками со стрелками. Это и есть правильный ответ на вопрос «что такое вектор», и не нужно думать про вектор как про «элемент векторного пространства». В то же время про «тензор» иначе думать и не получится.

Тем не менее, ни вектор как «отрезок со стрелкой», ни тензор как «элемент тензорного произведения» или как «элемент векторного пространства связанного определенным образом с исходным» не есть последовательности чисел. ООП (CLOS уж точно) или система типов (в Common Lisp с этим не очень, как можно видеть по этой библиотеке в том числе) позволяют отделить геометрическую часть задачи от вычислительной, точно так же как «бизнес-логику» отделяют от ее алгоритмической имплементации, с теми же преимуществами. Поэтому и «к сожалению принято называть» — потому что эта терминология крепко препятствует такому разделению.

нет насчет того что он не есть последовательность числе спасибо конечно за объяснение

но он ей задается таки

и это то что интересует

тензоры например в программировании как то используются

хотя я не знаю где

и задаются думаю тоже как то

не удивлюсь если по разному в зависимости от usecase

тем не менее из всего этого текста так и не понятно
что плохого в существовании операции деления вектора на число

если она увеличивает точность

и точность важна

типа в математике это звучит довольно бессмысленно

а в библиотеке почему это плохо

Умножение быстрее, и скорость тоже важна. «Меньше функций» — тоже важно. Надо знать, когда лучше умножать на обратное, когда делить почленно (и на что! почему бы отдельно знаменатели вообще не хранить и не делить всегда в самом конце один раз если точность важна?). Чтобы знать, надо корректно описать предметную область в объектной модели. В корректном описании последовательности чисел можно делить (поэлементно) на числа, но векторы можно только умножать на числа, и введение отдельной операции для деления настолько же оправданно как, скажем, введение отдельной операции умножения на 1+ε.

ща но умножение быстрее не получится если надо умножить на обратное потому что обратное то откуда то тоже взяться должно
то есть это нечестно так говорить, где то деление должно случиться

меньше функций — нуу это если ты экспортишь интерфейс важно, а для внутренней фигни мне кажется скорость важнее

Одно деление медленнее одного умноженя?