Sayonji Aug 12 2012 at 12:47

Динамические мат. функции в C++

5 min

15K

C++*Haskell*

From sandbox

+44

Comments 34

vScherba Aug 12 2012 at 13:57

ЗдОрово. А еще можно переписать без лямбд, тогда код будет работать на компиляторах без поддержки C++11. Вот на примере оператора сложения:

func_t operator+ (const func_t &arg, const func_t &arg2)
{
    struct _sum
    {
        _sum(const func_t &arg, const func_t &arg2)
            : _arg(arg), _arg2(arg2){}

        double operator()(double x)
        {
            return (*_arg.f)(x) + (*_arg2.f)(x);
        }

        const func_t& _arg;
        const func_t& _arg2;
    };

    realfunc realf = _sum(arg, arg2);
    return func_t(realf);
}

Хотя, коряво все это выглядит без лямбд.

dima_mendeleev Aug 12 2012 at 14:22

Долой переменные!
Виват Функциональное!
Виват Бесточечное!

*(еще вот такое есть — похоже на ваше)

vScherba Aug 12 2012 at 14:38

А статический список, если я правильно понял, используется только для вечного хранения realfunc объектов, он всегда растет при конструировании func_t и очищается только по завершении программы? Я бы посмотрел в сторону shared_ptr и хранил бы его вместо realfunc *f, если нет циклических ссылок. Список был бы не нужен.

GooRoo Aug 12 2012 at 14:40

(highfive)

vScherba Aug 12 2012 at 14:41

shared_ptr<realfunc> f;

Угловые скобки съелись.

Sayonji Aug 12 2012 at 15:09

Да, это тот факт, с которым я смирился перед тем, как начать писать. Можно, конечно, создавать внешние классы для «цепочек» составления функций. Т.е., я решаю в программе какую-то задачу в созданном специально под эту задачу объекте, а потом удаляю его.
Выглядело бы это примерно так:

func_chain T1();
T1::func_t f = ...
...

Но всё равно со статической коллекцией, пусть не одной.

К сожалению, я не имею ни малейшего представления о shared_ptr.

GooRoo Aug 12 2012 at 15:10

Самое время заиметь.

GooRoo Aug 12 2012 at 14:39

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

Я правильно понял, что Вы создаёте статическое хранилище функций, которое заполняете в рантайме? о_О Причём, коллекция только заполняется — из неё ничего не удаляется.

Значит, если я создам в своей программе 500 функций, то там будет как минимум 500 объектов (на самом деле больше, т.к. при композиции создаются дополнительные объекты func_t), причём удалятся они только при завершении работы программы.

Как минимум, неплохо бы заменить std::vector<> на std::list<>, а в класс добавить счётчик ссылок, чтобы ненужные функции оттуда удалялись, когда они становятся ненужными.

А вообще, не могли бы Вы ещё раз объяснить (желательно на примере кода) вот этот абзац, ибо мне кажется, я чего-то не уловил:

Скажем, мы хотим, чтобы некая процедура принимала пару функций A и B и возвращала новое выражение, например, 5A + B. Наша процедура создаст лямбду 5A, затем создаст 5A + B, используя 5А и В. Полученное процедура вернет и завершится, в этот момент лямбда 5А пропадет из области видимости и возвращенное выражение попросту не будет работать.

GooRoo Aug 12 2012 at 14:44

Оу, у Вас и так list<>. Это я провтычил, но ничего от этого не меняется.

vScherba Aug 12 2012 at 14:49

Мне кажется, если поверхностно смотреть, то не нужен list вообще, если вставить shared_ptr на место

realfunc *f; //указатель на элемент коллекции

в class func_t.

Может, я чего-то не учел.

GooRoo Aug 12 2012 at 14:51

В целом да, должно работать.

Sayonji Aug 12 2012 at 14:57

#include <iostream>
#include <xstddef>
#include <functional>

using namespace std;

typedef tr1::function<double(double)> realfunc;

realfunc go(realfunc &A, realfunc &B)
{
	realfunc A5 = [&](double x) {
		return A(x) * 5;
	};
	realfunc A5pB = [&](double x) {
		return A5(x) + B(x);
	};
	return A5pB;
}

int main()
{
	realfunc A = [&](double x) {
		return x;
	};
	realfunc B = [&](double x) {
		return x;
	};
	realfunc A5pB = go(A, B);
	cout << A5pB(3) << endl;
	getchar();
}

Вот тут рантайм. А если go() возвращает A5, то всё в порядке.

=(

GooRoo Aug 12 2012 at 15:08

#include <cstddef>
#include <functional>
#include <iostream>

using namespace std;

typedef function<double(double)> realfunc;

realfunc go(realfunc A, realfunc B)
{
	return [=](double x) {
		return A(x) * 5 + B(x);
	};
}

int main()
{
	realfunc A = [](double x) {
		return x;
	};
	realfunc B = [](double x) {
		return x;
	};
	auto A5pB = go(A, B);
	cout << A5pB(3) << endl;

	return EXIT_SUCCESS;
}

Sayonji Aug 12 2012 at 15:13

Ну так вы в фукнции go() создаете единственный объект и его же копию возвращаете. В моем примере проблема была в потере А5.

GooRoo Aug 12 2012 at 15:14

Сделайте лямбду [=] вместо [&] и всё будет работать.

Sayonji Aug 12 2012 at 15:24

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

GooRoo Aug 12 2012 at 15:27

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

vScherba Aug 12 2012 at 15:35

Попробуйте оба варианта в релизе с максимальной настройкой оптимизации компилятора, сделайте замеры производительности на хорошо нагруженном примере и сравните. Если [=] окажется не менее производительным, чем [&], выбрасывайте список, код упростится.

megalol Aug 12 2012 at 19:12

Размер функции не зависит от размера ее кода, только от того, что она захватывает. И проще сделать так, чтобы гигантская функция захватывала по ссылке нужные данные (и shared_ptr лучше static), а не ее саму захватывать по ссылке.
Зато в случае захвата = будет рядом храниться все что надо и это будет быстрее. Память дешевая, дорого обходятся кэш-промахи и локальность данных важнее.
А лучший подход — boost phoenix, если динамичность не нужна

alexeibs Aug 12 2012 at 14:41

Вот если бы оно умело какие-нибудь простейшие преобразования типа a — a = 0, a + 0 = a, a * (b + c) = a * c + b * c. Коли речь зашла о производных, то было бы полезно выводить производные элементарных функций, а не пытаться их аппроксимировать, да еще и не очень точно.

Sayonji Aug 12 2012 at 15:03

Ну, преобразование «а — а => 0» работало бы только если это было бы одно и то же «а». Если это были бы разные экземпляры одной и той же мат. функции, выяснить такое мне не представляется возможным. Как и проверить, является ли произвольная функция нулем, чтобы сократить ее при сложении.

encyclopedist Aug 12 2012 at 15:11

Это крайне похоже на Expression Templates, которые используются давно (лет 15) и замечательно обходятся без лямбд.

startupper Aug 12 2012 at 20:56

Название статьи прочитал как «Динамический мат». Задумался

-3

lisyarus Aug 12 2012 at 22:56

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

Sayonji Aug 13 2012 at 01:40

В констукторе копирования я как раз просто копирую указатель, не трогая список.

lisyarus Aug 13 2012 at 02:11

И правда, извиняюсь, перепутал с конструктором от realf.

kosmonaFFFt Aug 13 2012 at 07:26

[quote]
Скажем, мы хотим, чтобы некая процедура принимала пару функций A и B и возвращала новое выражение, например, 5A + B. Наша процедура создаст лямбду 5A, затем создаст 5A + B, используя 5А и В. Полученное процедура вернет и завершится, в этот момент лямбда 5А пропадет из области видимости, и возвращенное выражение попросту не будет работать.
[/quote]

Можно создать лямбду 5A внутри результирующей 5A + B, тогда этой проблемы не будет.

Sayonji Aug 13 2012 at 07:53

Я даю пользователю класса свободу действий. Пусть делает как хочет, и будет работать.

loz Aug 13 2012 at 11:20

Да просто скажите прямо — в плюсах не работают замыкания.

GooRoo Aug 13 2012 at 14:44

По ссылке не работают конечно. И это хорошо.

Sayonji Aug 13 2012 at 15:41

Всё работает так, как и должно работать.

loz Aug 13 2012 at 11:24

Математические функции еще отличаются чистотой, а переменные — иммутабельностью. Короче говоря берите любой функциональный язык и наслаждайтесь.

Dubor Aug 13 2012 at 17:01

>Ну да, как это использовать.
>Например вот так:
>func_t f1 = cos(5 * func_t() + 8);
>это создаст, как видно, функцию
>f1(x) = cos(5x + 8)

Для тренировки полезно: пока все это заработает, надо достаточно много тонких моментов вспомнить. Только в реальных проектах этим лучше не пользоваться. Лучше:


double f1 (double x) { return cos(5*x + 8); }

Sayonji Aug 13 2012 at 21:14

Ну так это не динамически же.

Show the best of all time