По-моему вопрос уже поднимался, но навскидку не нашел. В любом случае, хочется знать, нет ли в планах снабдить подсказом функции ReadXXX2 и ReadXXX3 по аналогии с ReadXXX([подсказ]) ? Сейчас приходится писать что-то вроде
Write('Введите начало и конец интервала: ');
var (a,b):=ReadReal2;
А ведь насколько элегантнее смотритсяь
var (a,b):=ReadReal2('Введите начало и конец интервала:');
Я обратил на это внимание сразу, как только появились эти функции. И судя по большому коммиту от Jun 17, 2017, это уже реализовано во внутренних билдах 1486+. Ждем-с апдейта.
@admin Небольшое замечание: в ReadArrXXX, ReadSeqXXX и ReadSeqXXXWhile строки передаются как const, а в ReadXXX и новых ReadXXX2 и ReadXXX3 – почему-то просто ReadInteger2(message: string). Непорядок-с 
И было бы все-таки правильнее в новых функциях назвать подсказки также prompt (как в оригинальных ReadXXX), а не просто message.
Спасибо. Исправили.
Убрали const в параметрах и переименовали message в prompt
step - слово распространённое. Всё легло.
Вернусь к теме матриц, aka двумерные массивы.
У нас уже есть замечательный набор функций и расширений, которые позволяют раскромсать существующую матрицу хоть на отдельные элементы (с индексами - ElementsWithIndexes), хоть на строки (Rows), хоть на столбцы (Cols). Мы можем заменить в матрице указанную строку (SetRow) или столбец (SetCol) содержимым одномерного массива. Можем переставить местами пару строк (SwapRows) или столбцов матрицы (SwapCols). Можем транспонировать матрицу (Transpose) и можем заменить в ней значение каждого элемента другим, к сожалению, никак не связанным с индексом строки и столбца значением (Transform).
А что не можем? Немногого, но это и есть та самая “ложка дегтя…”. Мы не можем преобразовать элементы массива по некоему произвольному правилу. Например, в зависимости от некоей F(i,j), где i,j - индексы этого элемента. Для одномерного массива у нас это есть: Transform((x,i)->F(x,i)). Для матриц нет. И компактно заменить его нечем.
Запланированы срезы для матриц, насколько я помню. Поэтому вопрос о вычеркивании строк/колонок из массива я не поднимаю - ключ к его разрешению лежит в срезах. Хотя и тут все не тривиально: если надо вычеркнуть строку из середины, результат даст объединение двух срезов, а у нас такой операции не перегружено, чтобы объединять две матрицы по строкам или колонкам.
Резюме: возможно ли сделать для матриц разновидность Transform((x,i,j)->F(x,i,j)) ?
Нет вроде.
Можно пользоваться
a := MatrGen(3,4,(i,j)->i<j?a[i,j]:0);
И правда, нет Transform((x,i)->F(x,i)). А казалось ведь, что есть… ну это, видимо навеяло двойственностью в Where/Select, когда можно писать Where(x->F(x)) и Where((x,i)->F(x,i)). Кстати, Intellisence не видит Transform.
Давайте все же отделим мух от котлет. Проблема не новую матрицу создать, проблема её модифицировать. И если для одномерных массивов вопрос обновления решается сакраментальным a:=F(a).ToArray, то для двумерных это не проходит. А возможность формировать двумерные массивы на базе одномерных, несмотря на неоднократные просьбы подумать, Вы отвергаете на некоем концептуальном уровне, несмотря, что она есть и в современном Фортране, и в современном Питоне… Как следствие - пишем-пишем красиво и функционально, а потом бац! - и съезжаем в ворох тривиальных циклов, потому что требуется обеспечить a[i,j]=F(a[i,j],i,j).
Рассыпать двумерный массив посредством ElementsWithIndexes, затем сформировать на базе этой россыпи с помощью MatrGen некий новый массив и присвоить потом старому этот новый - ну некрасиво это… И опять же, MatrGen не учитывает старые значения элементов.
Ну, сделать Transform с индексами - не проблема. Согласен.
@Admin, как Вы смотрите на то, чтобы написать и включить в состав дистрибутива некую библиотеку численных методов, которая при необходимости может подключаться по принципу той же GraphABC, т.е. по uses ? Понятно, что нельзя бесконечно расширять язык и посыпать его сахарной пудрой. Но в то же время, хочется иметь и набор каких-то библиотечных подпрограмм, и набор разных вещей, просто повышающих удобство работы, например, матричную алгебру, булеву алгебру, обработку строк и т.д. Это даже может быть и не одна библиотека.
Проблем тут несколько. Первая - авторские права. Алгоритмы численных методов и их программная реализация давно существуют и опубликованы. Я не видел, чтобы где-то был запрет на их использование, но считаю, что правильным будет упоминание об источнике в исходном тексте модуля. Вторая - степень строгости того или иного численного метода, Я думаю, быть может стоит объявить уровень библиотек “учебным”, т.е. не претендующим на безапелляционность в научном мире. Ведь, к примеру, не секрет, что датчик случайных чисел в PascalABC страдает тем же, чем страдает датчик в .NET - в нем просматривается определенная корелляция серий, а следовательно, все программы на его базе будут иметь те же недостатки. У него хорошее равномерное распределение (по моим оценкам - с точностью в сотые доли процента), а вот “случайность” не очень хороша. Слишком часто он выдает в коротких сериях последовательности чисел одного знака. На [-5;5] можно среди 30 чисел многократно получать последовательности, не содержащие, к примеру, нуля. Ну да бог с ним, чего я к ДСЧ прицепился…)) Научные программы обычно всегда снабжаются большим количеством оценки решений, что также требует серьезных математических изысков. Я не уверен, что с подобным подходом подобной библиотеке будет суждено увидеть свет. Третья - наполнение. Кому решать, что “достойно” включения в библиотеку и откуда брать исходники, если нет уверенности, что они качественные?
Смотрю хорошо, только кто будет этим заниматься и насколько сбалансированной будет такая библиотека?
Не будем ли мы изобретать велосипед, ведь наверняка есть подобные библиотеки? И надо будет просто делать их порт на PascalABC.NET.
И - кто будет этим заниматься?
Про портацию уже была мысль. Но как-то вот она заглохла. Видимо не нашлись нормальные исходники, Да и трудоемкость портации может оказаться очень и очень солидной. Заниматься этим должны несколько человек. Прежде всего должен быть “генератор идей”, который будет выдавать “а вот хорошо бы…”. Без этого библиотека превратится в помойку, куда напихают всего, что кажется полезным на данную минуту. Должна быть все же какая-то стратегия. А делать её можно постепенно, добавляя новые модули. Что-то могу я дать из своих наработок. Кроме того, я не вижу для себя особых проблем в переносе кода на Паскаль с других языков. Начиная с Алгол-60, на котором я когда-то немало писал)))
Как вариант - можно дать кому-то из студентов в качестве курсовика или диплома поучаствовать. Он же будет связующим звеном между Вами и остальными, кто захочет принять участие в работе над библиотекой.
А тогда идеология таких библиотек может не совпасть с мировоззрением разработчиков. Например, не понравятся лежащие в основе коды и т.п.
Вот, к примеру книга Форсайт Дж, Малькольм М. Машинные методы математических вычислений Прекрасная книга, с описанием и анализом применимости численных методов, отличная теория и фортрановский код. Вы бы хотели видеть эти программы (или часть из них) в подключаемой библиотеке на паскале? Кто же может дать ответ на подобный вопрос, кроме разработчика?
Вот еще один набор алгоритмов. Он в четырех сборниках, все алгоритмы со свидетельствами и контрольными примерами, тексты на Алгол-60. Могу перевести те, что окажутся интересными, в Паскаль. Список_алгоритмов.PDF (258,3 КБ) Но кто решит, что интересно, что нет?
К библиотекам я отношусь спокойно. Если будет библиотека с какими-то численными методами, которые реализует внешний квалифицированный разработчик - мы её внедрим. Очевидно, она будет неполна.
На мой взгляд, надо пользоваться стандартными библиотеками. Теми, что уже разработаны и апробированы сообществом. Переводить в Паскаль - это мне кажется странным. Если коды написаны на C# или даже на чём угодно - сделать обёртку на C# или PascalABC.NET - и пользоваться. А писать с нуля - ну, несовременно это как-то. Наверняка, Форсайта кто-то уже реализовал.
А это кто решает?
Безусловно, вопрос только кто. Большую часть программ из этого сборника я в паскаль уже давно перенес и пользуюсь. Но не все. Равно как и с упомянутыми алгольными алгоритмами из агеевских сборников - перетаскиваю по мере надобности. Это общая беда - найти библиотеку с программой, причем именно такой, как надо - зачастую быстрее написать.
К примеру есть свободная библиотека SciLab - я попытался её использовать, уж не помню, что-то надо было быстро написать, но не тут-то было! Там надо изучить особенности представления данных, интерфейс и т.д. Ну зачем рядовому пользователю изучать какие-то интерфейсы и прочую “фигню”, если ему надо найти экстремум функции? Не проще ли найти соответствующую функцию и просто подставить туда свои параметры? Вот такой, на мой взгляд, должна быть библиотека, чтобы и школьник мог легко ей воспользоваться. Этим почти все библиотеки грешат - сложностью интерфейса.
Вот SSPLIB - пакет научных программ на Фортране от IBM - думаете, там можно просто так взять и обратить матрицу? Ан нет, надо сначала выбрать программу для ввода данных, потом для компоновки матрицы, потом собственно обращения и еще для вывода результатов! И не только найти, но и разобраться в их интерфейсах!.
Может, лучше все же иметь возможность написать uses Matrix и в нужном месте указать a.Invert ?
Точно. Реализовали. На Фортране есть. И реализовали те, кто надо.
Занятно… там я ссылку привел на Форсайта, фортрановские тексты прямо в книге. Авторская реализация. ))) Или Форсайта на Фортране реализовали люди, более уважаемые, чем Форсайт? ))
Ну я не знаю, кто там более уважаемый, а кто менее. У меня есть код, и я совсем не уверен, что он реализован именно Форсайтом. Ссылка на Форсайта. Однако все это есть в специализированных пакетах типа LinPack
LINPACK is a software library for performing numerical linear algebra on digital computers. It was written in Fortran by Jack Dongarra, Jim Bunch, Cleve Moler, and Gilbert Stewart, and was intended for use on supercomputers in the 1970s and early 1980s. It has been largely superseded by LAPACK, which runs more efficiently on modern architectures. LINPACK makes use of the BLAS (Basic Linear Algebra Subprograms) libraries for performing basic vector and matrix operations.
Тут в авторах значится Молер (Моулер), один из соавторов Форсайта. Кто там более уважаемый и кем, Джек Донгарра или Форсайт, не мне решать. Я имел ввиду, что реализованы профессионально, используется в профессиональных целях, многократно верифицированы, стало быть изобретать велосипед, переписывая код, вряд ли нужно. Нужно ли эти библиотеки встраивать в Паскаль - решать разработчикам. Я лично не очень понимаю, зачем. Но если нужно, то почему бы и нет. В рамках курсовой работы.
Ну и еще, например, если говорить об обращении матрицы,то не может быть одинаковой процедуры обращения для всех матриц. В учебных целях, да, для малых размерностей, а вообще - нет. Более того, к примеру, для больших размерностей это и не нужно, нужно решать систему уравнений, а не матрицу обращать. Ну и так далее, если начать смотреть на какие-то процедуры, становится понятно, почему разные параметры, почему интерфейс сложный, ну и все остальные сложности.
Институт математики, механики и компьютерных наук ЮФУ, 2005–2021