Программирование для математиков: класс Polynomial

[tolstopuz]

mihaild в сообщении #1335406 писал(а):

И скажем unique_ptr не CopyAssignable, но класть их в контейнер вполне можно.

Да, действительно, все меняется, теперь vector в зависимости от операций требует разного.

[slavav]

VTsalyuk, если вы разместите ваши материалы на GitHub, у участников дискуссии появится возможность посылать вам pull requests. Это будет более продуктивно, чем обсуждение на форуме. Обещаю своё участие.

[rockclimber]

slavav в сообщении #1335446 писал(а):

VTsalyuk, если вы разместите ваши материалы на GitHub, у участников дискуссии появится возможность посылать вам pull requests.

К сожалению, в предыдущем своем топике ТС признался, что не знает, что такое github. Так что ему как минимум надо объяснить, что такое контроль версий вообще, что такое git и github в частности, потом уже будут pull request'ы и все остальное.
Еще, имхо, для такого рода библиотек хорошо бы тесты писать.

[VTsalyuk]

rockclimber в сообщении #1335364 писал(а):

Цитата из PDF файла:

Цитата:

А зачем изучать С++? Конечно, ради объектно-ориентированного программирования. Но ООП, с моей точки зрения, это не проектирование интерфейса пользователя вышиванием по канве, а разработка, и затем использование, классов объектов.

Фраза построена таким образом, как будто вы где-то встретили утверждение "ООП - это проектирование интерфейса пользователя вышиванием по канве", и теперь его опровергаете. Просто интересно, где можно было найти такой бред и как можно было воспринимать его всерьез.

-- 29.08.2018, 21:21 --

Кхм. После такого

Цитата:

Иногда случается, что попытка вычисления достаточно сложных выражений с многочленами вызывает ошибки на стадии компиляции. Диагностика этих ошибок иногда, хм, непонятная. Например инструкции
double A[3] = {1, 1, 2};
double B[2] = {-1, 1};
Polynomial Z(0.0);
Z += Polynomial(2, A) * Polynomial(1, B);
вызывают ошибку
Error! E189: overloaded function cannot be selected for arguments used in call
По видимому, проблема в том, что компилятор не справляется с сохранением и дальнейшим использованием промежуточных результатов вычисления.

Я могу только сказать: "Садись, два."
Не суметь скопировать в гугл текст ошибки и понять по поисковой выдаче, что делать дальше, - это отдельный талант. Я уже не говорю о том, чтобы использовать перегрузку функций, не зная, что это и зачем это.

По поводу вышивания по канве. Вы, наверное, таких не знаете, а я встречал, с позволения сказать, преподавателей, которые всю премудрость ООП сводят к визуальному проектированию интерфейса в VC++ или в Delphi. C использованием готовых компонентов.

Я более-менее умею читать по английски, и что написано, понимаю. Я не понимаю, почему это было написано. Компилятор не смог построить ссылку на продукцию конструктора для передачи функции в качестве параметра. Хотя я тут же показал, что с другими объектами (именованными) эта задача компилятору посильна. Да и странно бы было, если бы не так

Зачем перегрузка оператор-функций? -- Для приятности пользователю.

[Munin]

VTsalyuk в сообщении #1336425 писал(а):

Компилятор не смог построить ссылку на продукцию конструктора для передачи функции в качестве параметра. Хотя я тут же показал, что с другими объектами (именованными) эта задача компилятору посильна.

Не "не смог", а "не захотел". Потому что правилами языка это явно запрещено. Осталось догадаться, а почему так.

[VTsalyuk]

Xaositect в сообщении #1335381 писал(а):

Что сразу бросается в глаза:

• Нет единого стиля оформления кода: в большинстве мест отступ в два пробела, но в паре мест используется один пробел, в большинстве мест закрывающая фигурная скобка идет на отдельной строке, но иногда впихнута в последнюю, в половине файлов используется очень странный стиль, где функции начинаются с отступом в один пробел.
• Проект слишком маленький, чтобы делать его некроссплатформенным. У меня с первого раза не скомпилировалось (conio.h и несответствие регистра в названии файла Polynomial.hpp в архиве)
• В паре мест стоит точка с запятой после тела функции - будет синтаксическая ошибка на старых компиляторах.
• Операторы присваивания (=,+=,-=,*=) должны возвращать не void, а Polynomial& (ссылку на полученный после присваивания объект).
• Вместо конструктора из FILE* и метода Display нужны операторы для работы с потоками ввода-вывода.
• Дизайн деления с остатком ужасен (как минимум, нет потокобезопасности)
• Не используются даже базовые средства C++. std::vector здесь будет очень кстати, или хотя бы уж new вместо malloc.
• В C++ заголовки называются не stdio.h, а cstdio.
• Почему это вообще не шаблонный класс?

Тут есть несколько интересных предложений.

По стилю. Спасибо, посмотрю.

Кроссплатформенность? Увы, я не знаю других платформ и не могу тестировать. Что касается универсальности текста для разных компиляторов, то, боюсь, это невозможно. Из двух текстов
for(unsigned i =...)
{...
}
for(unsigned i =...)
{...
}
и
for(unsigned i =...)
{...
}
for(i =...)
{...
}
один компилятор любит только первый, а другой -- только второй.

Следующие два предложения приняты. Спасибо.

"конструктора из FILE* и метода Display" -- по учебникам, это потокоориентированный ввод/вывод. Если Вы имеете в виду символику >> и <<, то она слишком sophisticated для фундаментального представления. При переходе к профессиональной работе в программировании (и даже раньше) читатель легко перейдет к этому стилю. Задачи научить всем вкусным плюшкам языка я не ставил -- для этого существуют учебники.

Особенно мне понравилось напихать в контейнер мономы и назвать это полиномом. Давно о таком думал, даже предложил одному студенту реализовать. К сожалению, тот соскочил. Не знаю только, чем это лучше. Зато точно вижу недостаток: такой подход требует от читателя бОльших знаний. Это же касается создания шаблонов.

Дизайн деления с остатком. Подскажите, пожалуйста, что такое "потокобезопасность". Потеря информации в ситуациях типа P / Q + R / S? Что такое pair, почитаю... А он позволит написать P + R / S?

А не сводится ли new Polynomial компилятором к (Polynomial *)malloc? На мой взгляд, второй вариант дает лучшее фундаментальное представление о том, что делается в программе. Читатель легко перейдет самостоятельно к более лаконичному варианту, когда поймет более подробный. Выбор осознанный.

Заголовок stdio.h в файле .cpp мой компилятор скушал не поперхнувшись.

-- 03.09.2018, 19:07 --

Munin
спасибо! Немного изменю тон в своих комментариях.

[Munin]

В общем, выглядит ситуация так, будто человек, знакомый с Си с 1990 года, а с C++ с 1992 года - сейчас вышел из анабиоза и решил "показать класс". Например, он считает malloc более понятным (не говоря уже о том, что не догадывается, что new вызывает конструктор, а malloc - нет).

[VTsalyuk]

Munin
Примерно так. Но не "показать класс", а помочь учащемуся.

new double -- о каком конструкторе идет речь? В других случаях, если действительно надо -- будет new с конструктором. Читал об этом в учебнике Мартынова.

Хм! Откуда у меня взялся (Polynomial *)malloc? Не исправляю в своем посте на new double, чтобы Ваша реплика не повисла.

Насчет того, что malloc более понятен, я не считаю, я знаю. new легче запомнить и писать, а понять труднее.

[Munin]

VTsalyuk в сообщении #1336466 писал(а):

Но не "показать класс", а помочь учащемуся.

Медвежья услуга получается. Лучше оставьте такую помощь людям, которые (1) умеют программировать, (2) умеют программировать на C++, и (3) умеют программировать на современном C++. Ну и вдобавок, умеют учить программировать, знают, с какого конца за это браться.

VTsalyuk в сообщении #1336466 писал(а):

new double -- о каком конструкторе идет речь?

О вот таком вот:

VTsalyuk в сообщении #1336448 писал(а):

А не сводится ли new Polynomial компилятором к (Polynomial *)malloc?

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

[worm2]

Можно понять, почему был выбран язык C++ : хотелось использовать его средства перегрузки операторов.
Но тут даже простое использование уже готовой библиотеки с перегрузкой операторов (не заглядывая в её исходный код) может быть сложным и изобиловать подводными камнями.
Реализация же такой библиотеки требует глубокого знания языка. Это далеко за пределами возможностей математиков, только знакомящихся с программированием. Всё равно, как объяснять школьникам про комплексные числа и, войдя в раж, дойти до абстрактной алгебры и условий Коши–Римана.
Надо проще. Например, на Си, без указателей (хотя вру, без указателей вряд ли получится), с простыми функциями и неперегружаемыми операторами. Уныло, зато понятно.

[Munin]

VTsalyuk в сообщении #1336466 писал(а):

Хм! Откуда у меня взялся (Polynomial *)malloc? Не исправляю в своем посте на new double, чтобы Ваша реплика не повисла.

Ок. Незнание разницы между этими двумя вещами, и как они должны компилироваться:

VTsalyuk в сообщении #1336448 писал(а):

Используется синтаксис C++

for(unsigned i =...)
{...
}
for(unsigned i =...)
{...
} 

и


Используется синтаксис C++

for(unsigned i =...)
{...
}
for(i =...)
{...
}

- тоже проблема.

-- 03.09.2018 19:38:52 --

worm2 в сообщении #1336469 писал(а):

Надо проще. Например, на Си, без указателей, с простыми функциями и неперегружаемыми операторами. Уныло, зато понятно.

Вообще же для такой задачи, видимо, стоило бы выбрать другой язык. Более user-friendly. Какой-нибудь Python, Haskell, Mathematica...

[VTsalyuk]

worm2 в сообщении #1336469 писал(а):

Надо проще. Например, на Си, без указателей (хотя вру, без указателей вряд ли получится), с простыми функциями и неперегружаемыми операторами. Уныло, зато понятно.

Я такое делал на Pascal. Но с указателями. Иначе действительно совсем уж уныло.

-- 03.09.2018, 19:46 --

Munin в сообщении #1336467 писал(а):

VTsalyuk в сообщении #1336466 писал(а):

Но не "показать класс", а помочь учащемуся.

Медвежья услуга получается. Лучше оставьте такую помощь людям, которые (1) умеют программировать, (2) умеют программировать на C++, и (3) умеют программировать на современном C++. Ну и вдобавок, умеют учить программировать, знают, с какого конца за это браться.

Замечательно! С удовольствием почитаю учебный проект "Как нам реорганизовать Polynomial". Спорить не буду. Это будет урок номер 2. Кто возьмется? Давайте выкладывать в этой же теме.

-- 03.09.2018, 19:57 --

Munin в сообщении #1336471 писал(а):

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

Давайте попробую. В обоих примерах переменная i не была объявлена вне операторов цикла. В первом случае компилятор считает цикл for блоком, внутри которого переменная i объявлена, а при выходе из него исчезает, и поэтому требует повторного объявления в следующем цикле (Watcom С/C++ compiler). Во втором -- компилятор считает переменную объявленной для всего тела функции и поэтому возражает против ее повторного объявления (VC++ v.6). Выходит, это какой-то из компиляторов не знает, как они должны компилироваться?

[arseniiv]

Да, известно, что некоторые компиляторы плевали на стандарт языка, к тому времени уже опубликованный. Вы бы ещё подревнее компилятор выбрали.

[VTsalyuk]

Значит, мой разбор ситуации правильный. Хорошо! А Вы читали стандарт? Какой из компиляторов прав? Ссылку можно?

[arseniiv]

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