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

[VTsalyuk]

Ну, transform КМК всяко лучше

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

for(i=0;...) 
  c[i] = a[i] + b[i];

Просто потому, что заложенный в transform цикл эффективнее организован.

Но на мой вкус лучше выписать этот цикл из transform явно. Вангую, что несколько тактов процессора на этом можно сэкономить.

[photon]

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

Тогда уж

Можно и так, но лично я считаю это несущественными рюшечками.

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

(правда я очень сомневаюсь в осмысленности transform в данном случае)

Во-первых, почему бы и нет, во-вторых, вопрос стоял: "Как осуществить их сложение с помощью std::transform()?" - я не знаю, как "осуществить сложение, используя transform", не используя transform.

warlock66613 в сообщении #1385743 писал(а):

Наверное, наоборот? Скопировать более короткий, а затем добавить длинный.

Я имею в виду, что-то типа такого:

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

    using T1 = int;
    using T2 = float;
    std::vector<T1> v1{ 1, 2, 3, 4, 5 };
    std::vector<T2> v2{ 1.f, 2.f, 4.f };
    std::vector<std::common_type<T1, T2>::type> result;

    if (v1.size() > v2.size())
    {
        std::vector<std::common_type<T1, T2>::type> temp_result(v1.cbegin(), v1.cend());
        std::transform(v2.cbegin(), v2.cend(), temp_result.cbegin(), temp_result.begin(), std::plus<>());
        std::swap(result, temp_result);
    }
    else
    {
        std::vector<std::common_type<T1, T2>::type> temp_result(v2.cbegin(), v2.cend());
        std::transform(v1.cbegin(), v1.cend(), temp_result.cbegin(), temp_result.begin(), std::plus<>());
        std::swap(result, temp_result);
    }

    for (auto const& item : result)
    {
        std::cout << item << std::endl;
    }

[Munin]

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

Просто потому, что заложенный в transform цикл эффективнее организован.

Это кто вам сказал?

С вероятностью 99 %, именно так он и реализован.

[mihaild]

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

С вероятностью 99 %, именно так он и реализован.

Нет, он же на итераторах, а не на индексах.

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

for (; __first1 != __last1; ++__first1, (void)++__first2, ++__result)
    *__result = __binary_op(*__first1, *__first2);

И бинарный код получается немного разный: цикл transform. Содержательная часть впрочем получается одинаковой.

[Munin]

Да, на условии for-а можно даже немного потерять.

[VTsalyuk]

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

Это кто вам сказал?

Никто. Я сам читал в одном из файлов STL. Имя его, правда, не помню.

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

-- 03.04.2019, 22:16 --

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

И Страуструп, и Мартынов рассказывают об итераторах на примере vector, и остается неясным, зачем это вообще было надо, пока не перешли к list и map. Вот на них надо было вводить итераторы, там они играют существенную роль и по сути отличаются от указателя. .

-- 03.04.2019, 22:20 --

mihaild
Уверен, что -- в случае vector -- transform на итераторах работает быстрее, чем цикл на индексах. Делал замеры быстродействия.

[mihaild]

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

Уверен, что -- в случае vector -- transform на итераторах работает быстрее, чем цикл на индексах

У меня не воспроизводится. Результаты замеров и код: https://github.com/mihaild/dxdy/blob/ma ... _benchmark

[Munin]

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

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

Ещё см. итераторы во вводе-выводе.

-- 04.04.2019 00:33:56 --

Полезное упражнение. Дан граф или дерево (это два разных упражнения). Написать DFS-итератор и BFS-итератор.

-- 04.04.2019 00:37:26 --

Ещё в GNU в 90-е был контейнер что-то вроде chunked array. Его тоже можно поупражняться делать (в том числе, разумный интерфейс, инварианты, гарантии сложности).

[photon]

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

Появилась новая версия Polynomial.zip

Пробежался по диагонали по вашему "анализу" найденного на gitHub. Чтиво оставило тягостное впечатление.
Во-первых, если, вам, например, не нравится, что авторы не реализовали корректное сравление чисел с плавающей точкой, - возьмите и реализуйте, либо выберите другой проект - благо их там полно. Во-вторых, если не поддерживается вашим допотопным компилятором, это не вина авторов - они используют более прогрессивные подходы - идите в ногу с ними или хотя бы не ставьте им это в вину. Это касается, в частности, формы записи циклов и использования auto-типа. В-третьих, ваши выводы об эффективности-неэффективности выглядят довольно наивными и не подкреплены проверками (например в случае функции Degree(), которая, скорее всего заинлайнится и на фоне остальных операций съест какие-то ничтожные доли времени).

Нет, не все там и на мой взгляд прекрасно. Например, если инициализировать полином пустым вектором, либо в процессе вызова Cutting() он станет нулевым, то Degree() будет возвращать -1, что как-то не очень хорошо. И code-style не везде выдержан, и, возможно, еще что-то - я внимательно не анализировал. Но это поправимые вещи - можно взять и исправить/расширить/дополнить, а не диванософски обплевать.
Претензия, что, дескать, шаблонные классы плохи тем, что может что-то вылезти неизвестно когда, лечится а) написанием качественного кода; б) тем, до чего вы пока что, видимо, еще не дошли - до написания тестов, покрывающих и разные типы и какие-то крайние возможные значения параметров. Так делают при реальной разработке, а рассуждения как правильнее делать на коленке, имхо, лишены большого смысла.

[Munin]

photon в сообщении #1385853 писал(а):

Degree() будет возвращать -1, что как-то не очень хорошо.

А сколько он должен возвращать для нулевого полинома? У математиков с этим нет единого соглашения, так что это design-level issue.

[photon]

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

так что это design-level issue.

Да, пожалуй, я соглашусь с этим - мой наезд на этот момент тоже не вполне оправдан, хотя поводы придраться все равно есть
Например

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

        T operator [] (int pos) const {
                if (pos > this->Degree()) {
                        return T(0);
                }
                else {
                        return coef[pos];
                }
        }

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

[VTsalyuk]

mihaild
Интересно! Попробую повторить на своем "допотопном" компиляторе. Но не сразу бегом... Дела, знаете ли.

Мои результаты замеров в документе CppTemplateA.pdf архива, пункт 4.4.

-- 04.04.2019, 08:54 --

photon
Я это (int degree) тоже критикую.

Как математику, мне нравится, что 0 имеет степень -1. Это лучше, чем степень 0. Как разработчик, я решил, что степень будет нулевой . И в том, и в другом случае приходится особо обрабатывать эту крайнюю ситуацию.

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

[photon]

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

Мои результаты замеров в документе CppTemplateA.pdf архива, пункт 4.4.

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

[VTsalyuk]

Понял. Компилятор я указывал. Уверен, что дебажная версия. Потому что ключи дефолтные. Почитаю и сообщу.

Как раз интереснее, как это воспроизведется другими, более совершенными, компиляторами.

[warlock66613]

photon в сообщении #1385860 писал(а):

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

А мы в любом случае можем вылезти за пределы вектора - не влево, так вправо. А operator[] стандартно никаких проверок не делает; если нужен вариант с проверками, лучше назвать его at(). Но, конечно, неявный кастинг из int в size_t тут совершенно не оправдан.