Страница 1 из 3

Математика, но не простая...

СообщениеДобавлено: 13.03.2014 15:51:06
Vadim
Нашёл более-менее понятный и простой класс "Матрица", который сейчас немного дорабатываю, для того, чтобы сделать его основным типом данных для всяких сложных математических операций, как это сделано в программах типа Scilab или Maxima.
В эти выходные доделаю перегрузку операций - выложу исходник на всеобщее обозрение.

Re: Математика, но не простая...

СообщениеДобавлено: 13.03.2014 21:28:09
hinst
нельзя просто так взять и сделать математическую библиотеку на FPC

Re: Математика, но не простая...

СообщениеДобавлено: 14.03.2014 04:33:23
Vadim
hinst
А кто сказал, что это делается "просто так"? Покажи мне пальцем этого негодяя. :-)

Re: Математика, но не простая...

СообщениеДобавлено: 16.03.2014 18:18:30
Vadim
Вот, прошу любоваться. :-)
Вопрос знатокам: в исходном модуле индексы ряды и колонки начинаются с 1, а не с 0. Так и оставить или сделать всё таки начало с 0?
И вообще, высказывайте замечания.

Вопрос разработчикам FreePascal - операцию "^" никак нельзя перегрузить?

Re: Математика, но не простая...

СообщениеДобавлено: 16.03.2014 20:18:34
hinst
во-первых, в Паскале для возведения в степень придумали оператор **, типа умножить умножить, вот его можно перегрузить
а во-вторых: посмотрю - скажу

Добавлено спустя 39 минут 22 секунды:
а, всё, уже увидел, так и сделано
В целом сказать особенно нечего, как лучше делать индексы - не знаю... не принципиально, наверное
Вот если бы сделать как-нибудь автоматическое освобождение экземпляров когда они пропадают из видимости
А так: Create вызвано, Free не вызвано, это просто какая-то утечка памяти получаются

Re: Математика, но не простая...

СообщениеДобавлено: 17.03.2014 05:50:44
SSerge
Индексы принято начинать с нуля. Во всех выживших распространенных языках программирования. Паскаль со своими надуманными дидактическими целями здесь стоит особняком. Во всяком случае фиксированный индекс массива, начинающийся не с нуля - прямой источник ошибок при переносе не-паскалевского кода и наоборот.

Re: Математика, но не простая...

СообщениеДобавлено: 17.03.2014 06:53:47
Vadim
SSerge
Ок, понятно.

Re: Математика, но не простая...

СообщениеДобавлено: 17.03.2014 14:03:45
hinst
в R-project индексы с 1

Re: Математика, но не простая...

СообщениеДобавлено: 17.03.2014 15:13:57
Дож
Кажется, что если переделать class на object, то проблема автоматического удаления будет решена.

Нумеровать лучше с 0 с точки зрения скорости (нет лишнего вычитания единицы).

Re: Математика, но не простая...

СообщениеДобавлено: 17.03.2014 15:24:08
hinst
Дож писал(а):Кажется, что если переделать class на object, то проблема автоматического удаления будет решена.

Это подходит при условии, что при разрушении никаких дополнительных действий делать не надо и внутри object'а нет полей-экземпляров class'ов и никаких указателей, под которые выделяется память и которую нужно освобождать.
В общем это такое полу-решение, но на самом деле не решение, мне оно не нравится, потому что у меня как-то обычно получается, что внутри класса обязательно ещё всякие классы, получается что и их тогда надо переделывать на object'ы, и какие-то действия при разрушении приходится делать, а если делаешь динамические массивы внутри класса, то и они должны быть тогда только из простых типов либо из object'ов
При присваивании object'ов будет их копирование. Однако, если внутри будет динамический массив, то он весь копироваться не будет

Re: Математика, но не простая...

СообщениеДобавлено: 17.03.2014 15:27:32
Дож
Это подходит при условии, что при разрушении никаких дополнительных действий делать не надо и внутри object'а нет полей-экземпляров class'ов и никаких указателей, под которые выделяется память и которую нужно освобождать.


В данном конкретном случае это так.

При присваивании object'ов будет их копирование. Однако, если внутри будет динамический массив, то он весь копироваться не будет


Это если не перегружать оператор присваивания, то, да.

Re: Математика, но не простая...

СообщениеДобавлено: 20.03.2014 06:49:45
xdsl
SSerge писал(а):Индексы принято начинать с нуля. Во всех выживших распространенных языках программирования. Паскаль со своими надуманными дидактическими целями здесь стоит особняком.

1. Никаким не особняком. В синтаксисе паскаля четко сказано, что в квадратных скобках при определении массива стоит любой порядковый тип (типичный пример: array[char]of byte). Тип поддиазона - тоже порядковый, так что если кто определяет array[1..10] of byte, тот ничего не нарушает. Хочешь, с единицы индексируй, хочешь - с буквы "z" или c -86754, выбор программиста.
2. В модуле вообще используется двумерный динамический массив, с индексированием от нуля, так что суть претензий к языку программирования не понятна.
3. В математике переборные индексы принято начинать с единицы, поэтому логика в построении класса есть. Так что и здесь непонятна суть претензий.

Re: Математика, но не простая...

СообщениеДобавлено: 20.03.2014 08:55:07
SSerge
xdsl
1. Речь идет не о языке как таковом. Хотя, что вы считаете достоинством языка, на самом деле совершенно надуманный ход извращенной мысли г-на Вирта и в ряде случаев напрямую провоцирует ошибки программирования при попытке перевести программы с/на паскаль. Вы еще забыли упомянуть перечислимые типы (которыми емнип тоже можно индексировать), кои были введены исключительно для того, чтобы омериканоязычный программер мог не шевеля извилинами вывести ейное символьное наименование оператором writeln, и это типа невиданный прогресс. То, что при этом epic fail при любых других языках - кого волновало. Еще раз подчеркиваю - исходный паскаль - язык учебный и теоретизированный, в исходном виде - далёкий от практики программирования. Если бугурт продолжается, давайте приведем следующий пример: есть стандартная библиотека строковых функций языка Си. В ней принято, чтобы строка-результат или строка, по которой ведется обработка, всегда была первым элементом списка аргументов функции. Если не очень понятно -

Код: Выделить всё
const char * strstr ( const char * исходная_строка, const char * шаблон_поиска );


Как вы думаете, есть ли у вас шансы ошибиться, переводя текст программы, использующий эти вызовы, наpascal, в котором и это:

Код: Выделить всё
function Pos( const substr: shortstring;  const s: shortstring)):SizeInt;


и это

Код: Выделить всё
function strpos( str: PChar;  substr: PChar):PChar;


и даже внутри самого паскаля.
Сами не заметите, как при очередном вызове случайно переставите аргументы. И это не единственное.

Хотите вы или нет, эталон все таки Си/С++

2. см. п.1; причем здесь внутренняя реализация
3. Не надо делать индексацию, как в математике. Базовый класс, должен иметь индексы, отсчитывающиеся от нуля. Точка. Так работает процессор, так принято в ассемблере, так принято во всех языках программирования, кроме бейсика и фортрана. Если нужна математическая адресация - есть смысл создать класс-надстройку, в котором индексация будет от единицы. Это, imho, должно решить проблемы индейцев.

Да, я не люблю синтаксис языка паскаль.
У меня есть основания его не любить.
И да, в свое время я много чего накодил на турбе. И вот сейчас я смотрю на этот код, и иногда, когда возникает необходимость, с нехорошими словами, запускаю его под эмулятором доса. Потому что, сцуко, я слишком хорошо знал Borland Pascal и внутреннюю организацию его менеджера памяти, библиотек и прочего. Вот и напрограммил. Я де-факто не могу взять этот код и просто откомпилировать современными средствами - его придется писать заново. Даже для freePascal. И у вас будет то же. Позже. Поэтому настоятельно рекомендую писать как можно проще и не привязываться к фишкам, ставящим в тупик при необходимости перевести ваш код на другой язык программирования.

Re: Математика, но не простая...

СообщениеДобавлено: 20.03.2014 09:51:22
Дож
Код: Выделить всё
Хотите вы или нет, эталон все таки Си/С++

Вы хотите, чтобы паскаль имел такие же синтаксим и семантику, как и у С++?

Re: Математика, но не простая...

СообщениеДобавлено: 20.03.2014 10:19:27
SSerge
Дож писал(а):Вы хотите, чтобы паскаль имел такие же синтаксим и семантику, как и у С++?


Нет. Я пытаюсь показать, что уже в имеющихся функциях RTL есть бардак и нелогичность в порядке аргументов функций.
Ну и товарищ настоятельно доказывает, чтобы индексация у класса работы с матрицами могла быть с произвольного индекса, как типо все привыкли в паскале. Я же считаю, что это зло. И если это зло должно существовать, то - только в реализации класса, порожденного от базового. А базовый должен в интерфейсных функциях и [] индексировать от нуля. И с точки зрения скорости, и с точки зрения теоретики.