Re: std::complex - C/C++

Доброго времени суток всем.

Может кто мне объяснит какие такие соображения преследовали авторы стандартной библиотеки изобретая сабж? А именно, интерисует чего ради они не сподобились реализовать функций доступа к реальной и мнимой части комплексного числа? Почему для того чтобы изменить мнимую составляющую я должен писать конструкции типа:

std::complex<double> z(1.0,2.0);
z = std::complex<double>(z.real(), 1.0);

Честно говоря попахивает идиотизмом, но может я чего-то недопонимаю?

Почему у типа int нет доступа к пятой цифре числа? Почему надо извращаться, чтобы у int поменять только пятую цифру??

MAS>Доброго времени суток всем.

MAS>Может кто мне объяснит какие такие соображения преследовали авторы стандартной библиотеки изобретая сабж? А именно, интерисует чего ради они не сподобились реализовать функций доступа к реальной и мнимой части комплексного числа? Почему для того чтобы изменить мнимую составляющую я должен писать конструкции типа:
MAS>

MAS>std::complex<double> z(1.0,2.0);
MAS>z = std::complex<double>(z.real(), 1.0);
MAS>

MAS>Честно говоря попахивает идиотизмом, но может я чего-то недопонимаю?

Здравствуйте, Аноним, Вы писали:

А>Почему у типа int нет доступа к пятой цифре числа? Почему надо извращаться, чтобы у int поменять только пятую цифру??

MAS>>Доброго времени суток всем.

MAS>>Может кто мне объяснит какие такие соображения преследовали авторы стандартной библиотеки изобретая сабж? А именно, интерисует чего ради они не сподобились реализовать функций доступа к реальной и мнимой части комплексного числа? Почему для того чтобы изменить мнимую составляющую я должен писать конструкции типа:
MAS>>

MAS>>std::complex<double> z(1.0,2.0);
MAS>>z = std::complex<double>(z.real(), 1.0);
MAS>>

MAS>>Честно говоря попахивает идиотизмом, но может я чего-то недопонимаю?

Помоему ваша ирония здесь абсолютно не уместна.

Вы вообще когда нибудь работали с комплексной математикой? С цифровой обработкой сигналов например? Что-то мне подсказывает, что врядли.

Здравствуйте, m.a.smirnoff, Вы писали:

MAS>Помоему ваша ирония здесь абсолютно не уместна.

Вы вообще когда нибудь работали с комплексной математикой? С цифровой обработкой сигналов например? Что-то мне подсказывает, что врядли.

Другая аналогия: почему нет методов для модификации отдельно мантиссы и порядка у вещественных чисел?

Там, где нужно потрошить числа — используется наиболее удобное их представление. И иногда изобретается своё собственное.
Ты же не выкатываешь претензии, почему std::complex внутри представлен исключительно как (re,im), хотя иногда бывает удобнее иметь дело с (abs,arg)?

... << RSDN@Home 1.2.0 alpha rev. 655>>

Здравствуйте, Кодт, Вы писали:

К>Другая аналогия: почему нет методов для модификации отдельно мантиссы и порядка у вещественных чисел?
Потому как доступ к ним достаточно затруднен и легко получить кучу проблем с неправильными значениями.

К>Там, где нужно потрошить числа — используется наиболее удобное их представление. И иногда изобретается своё собственное.
К>Ты же не выкатываешь претензии, почему std::complex внутри представлен исключительно как (re,im), хотя иногда бывает удобнее иметь дело с (abs,arg)?
Дело-то как раз в том, что std::complex задумывалось именно как "абстрактное" комплексное число. Но на практике это не работает — в std::complex всегда хранят комплексоное число в виде пары Декартовых координат. И часто требуется нормальный доступ к его компонентам.

В общем, типичный случай overengineering'а.

Здравствуйте, m.a.smirnoff, Вы писали:

MAS>Доброго времени суток всем.

MAS>Может кто мне объяснит какие такие соображения преследовали авторы стандартной библиотеки изобретая сабж? А именно, интерисует чего ради они не сподобились реализовать функций доступа к реальной и мнимой части комплексного числа? Почему для того чтобы изменить мнимую составляющую я должен писать конструкции типа:
MAS>

MAS>std::complex<double> z(1.0,2.0);
MAS>z = std::complex<double>(z.real(), 1.0);
MAS>

MAS>Честно говоря попахивает идиотизмом, но может я чего-то недопонимаю?

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Кодт, Вы писали:

К>Здравствуйте, m.a.smirnoff, Вы писали:

MAS>>Помоему ваша ирония здесь абсолютно не уместна.

Вы вообще когда нибудь работали с комплексной математикой? С цифровой обработкой сигналов например? Что-то мне подсказывает, что врядли.

К>Другая аналогия: почему нет методов для модификации отдельно мантиссы и порядка у вещественных чисел?

К>Там, где нужно потрошить числа — используется наиболее удобное их представление. И иногда изобретается своё собственное.
К>Ты же не выкатываешь претензии, почему std::complex внутри представлен исключительно как (re,im), хотя иногда бывает удобнее иметь дело с (abs,arg)?

А вообще, чем-нибудь регламентируется внутреннее представление этого типа? Насколько я знаю, нет. В какой-то реализации STL оно может действительно оказаться внутри представленным как (abs, arg), а, впринципе, может инкапсулировать и оба представления.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, rg45, Вы писали:

R>А вообще, чем-нибудь регламентируется внутреннее представление этого типа? Насколько я знаю, нет. В какой-то реализации STL оно может действительно оказаться внутри представленным как (abs, arg), а, впринципе, может инкапсулировать и оба представления.

Я тоже думал, что — а если на какой-то платформе комплексные числа вообще аппаратно реализованы... — но в стандарте пишут, что std::complex хранит декартово представление. А полярное представление — внешними функциями.

2.6.2.2 Class template complex
The class complex describes an object that can store the Cartesian components, real() and imag(), of a complex number.

Хотя... Это complex<T> декартов. А вот специализации — complex<float>, complex<double>, complex<long double> — могут быть какими угодно! В том числе, фасадами для аппаратных типов.

... << RSDN@Home 1.2.0 alpha rev. 655>>

Здравствуйте, Кодт, Вы писали:

К>Я тоже думал, что — а если на какой-то платформе комплексные числа вообще аппаратно реализованы... — но в стандарте пишут, что std::complex хранит декартово представление. А полярное представление — внешними функциями.
Комплексные числа на многих платформах аппаратно и реализованы. Причем ВЕЗДЕ они представлены как пара декартовых чисел. Где-то даже я видел реализацию с помощью SSE.

Здравствуйте, Кодт, Вы писали:

К>Здравствуйте, rg45, Вы писали:

R>>А вообще, чем-нибудь регламентируется внутреннее представление этого типа? Насколько я знаю, нет. В какой-то реализации STL оно может действительно оказаться внутри представленным как (abs, arg), а, впринципе, может инкапсулировать и оба представления.

К>Я тоже думал, что — а если на какой-то платформе комплексные числа вообще аппаратно реализованы... — но в стандарте пишут, что std::complex хранит декартово представление. А полярное представление — внешними функциями.
К>

К>2.6.2.2 Class template complex
К>The class complex describes an object that can store the Cartesian components, real() and imag(), of a complex number.

К>Хотя... Это complex<T> декартов. А вот специализации — complex<float>, complex<double>, complex<long double> — могут быть какими угодно! В том числе, фасадами для аппаратных типов.

Мне кажется, тут возникают определенные неоднозначности в трактовке: во-первых, describes, а не implements или contains, а во-вторых, can store, а не should store.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, rg45, Вы писали:

R>Здравствуйте, m.a.smirnoff, Вы писали:

MAS>>Доброго времени суток всем.

MAS>>Может кто мне объяснит какие такие соображения преследовали авторы стандартной библиотеки изобретая сабж? А именно, интерисует чего ради они не сподобились реализовать функций доступа к реальной и мнимой части комплексного числа? Почему для того чтобы изменить мнимую составляющую я должен писать конструкции типа:
MAS>>

MAS>>std::complex<double> z(1.0,2.0);
MAS>>z = std::complex<double>(z.real(), 1.0);
MAS>>

MAS>>Честно говоря попахивает идиотизмом, но может я чего-то недопонимаю?

R>В данном случае, налицо принцип необходимого и достаточного интерфейса: с помощью данного набора функций вы можете сделать с объектом что угодно, а удобства создавайте себе сами, с помощью внешних функций.

Прошу прощения, что через ваше сообщение отвечу не только вам но и другим участником дискусси.
1. Ответ лично вам. При чем здесь "принцип необходимого и достаточного интерфейса" и уж тем более "удобства". Это соверщенно естественная потребность, с точки зрения математики, непосредственный доступ к обеим составляющим комплексного числа. О какой эффективности рассчетов может идти речь,например, в случае фильтрации комплексного сигнала, если для доступа к составляющим каждого отсчета нужно будет совершать описанные мной манипуляции.
2. Ответ по поводу представления. По стандарту в классе complex хранится именно классическое Декартово представление комплексного числа, что косвенно подтверждается интерфейсными функциями imag и real. А для получения абсолютного значения и угла (для полярных координат) в std есть соответствующие функции.
3. Казалось бы, что мешало, завести две перегруженные функции типа

template<class T> T real(const complex<T>&);
template<class T> T imag(const complex<T>&);

4. По поводу ссылки http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1806.html#387. Судя по дате предложения (8 Nov 2002) оно должно было бы попасть в стандарт 2003 года, однако ж ... Вот я и не пойму, в чем собственно проблема.
5. Я сам раньше не пользовался этим классом, ибо небыло необходимости, однако тут потребовалось использовать одну библиотеку в которой в качестве комплексных чисел используется именно std::complex, а тут такя бяка

MAS>std::complex<double> z(1.0,2.0);
MAS>z = std::complex<double>(z.real(), 1.0);
MAS>

MAS>Честно говоря попахивает идиотизмом, но может я чего-то недопонимаю?

Добавлю свои 5 копеек:
Судя по всему, разработчикам STL знакома эта проблема, поэтому они оставили маленькую лазейку для тех, кому "ну очень надо": я посмотрел реализации в DinkumSTL for VC7.1 и в STLPort 4.6.2 — в обоих реализациях внутреннее представление имеет спецификатор доступа "public".

Так что такой код проходит:

complex<double> c;

//DinkumSTL
c._Val[0] = 0;
c._Val[1] = 1;

//STLPort
c._M_re = 0;
c._M_im = 1;

Чтобы минимизировать зависимость кода от деталей реализации, можно соорудить что-то типа вот этого:

template <class T>
inline void set_im(complex<T>& c, T t)
{
#if defined STLPORT
   c._M_im = t;
#else if defined DINKUMSTL71
   c._Val[1] = t;
#endif
}

Здравствуйте, Bell, Вы писали:

B>Чтобы минимизировать зависимость кода от деталей реализации, можно соорудить что-то типа вот этого:
B>

B>template <class T>
B>inline void set_im(complex<T>& c, T t)
B>{
B>#if defined STLPORT
B>   c._M_im = t;
B>#else if defined DINKUMSTL71
B>   c._Val[1] = t;
B>#endif
B>}
B>

~ :) fgrep -C 2 _M_real /usr/include/c++/4.2/complex | head -n 5

    private:
      _Tp _M_real;
      _Tp _M_imag;
    };

Проще, наверное, так:

template <class T>
inline void set_im(std::complex<T>& c, T t)
{
#if SENSIBLE_STL
    reinterpret_cast<T (&)[2]>(c)[1] = t;
#else
    c = std::complex<T>(c.real(), t);
#endif
}

Или const_cast использовать. Хак, а что поделаешь?..

Здравствуйте, Bell, Вы писали:

B>Здравствуйте, m.a.smirnoff, Вы писали:

MAS>>Доброго времени суток всем.

B>Чтобы минимизировать зависимость кода от деталей реализации, можно соорудить что-то типа вот этого:
B>

B>template <class T>
B>inline void set_im(complex<T>& c, T t)
B>{
B>#if defined STLPORT
B>   c._M_im = t;
B>#else if defined DINKUMSTL71
B>   c._Val[1] = t;
B>#endif
B>}
B>

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, m.a.smirnoff, Вы писали:

MAS>Может кто мне объяснит какие такие соображения преследовали авторы стандартной библиотеки изобретая сабж? А именно, интерисует чего ради они не сподобились реализовать функций доступа к реальной и мнимой части комплексного числа?

А вдруг на платформе есть аппаратная реализация комплексных чисел?
Если делать так, как в стандарте сейчас, то можно написать соответсвующую специализацию, а если так, как хочешь ты, то фиг там напишешь, а не специализацию...

Хотя что таки мешает заиметь функции для установки той и другой части я всё равно не очень понимаю...

Хотя, стоит, ИМХО, попробовать во что таки компилируется

template<typename T> set_imag( std::complex<T>& dst,  T imag )
{
    dst = std::complex( dst.real(), imag );
}

Очень может быть, что оно хорошо компилируется и real часть не переписывает лишний раз...

Здравствуйте, Erop, Вы писали:

E>А вдруг на платформе есть аппаратная реализация комплексных чисел?
E>Если делать так, как в стандарте сейчас, то можно написать соответсвующую специализацию, а если так, как хочешь ты, то фиг там напишешь, а не специализацию...

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

E>Хотя, стоит, ИМХО, попробовать во что таки компилируется

E>template<typename T> set_imag( std::complex<T>& dst,  T imag )
E>{
E>    dst = std::complex( dst.real(), imag );
E>}

E>Очень может быть, что оно хорошо компилируется и real часть не переписывает лишний раз...

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

Здравствуйте, Erop, Вы писали:

E>Хотя что таки мешает заиметь функции для установки той и другой части я всё равно не очень понимаю...

E>Хотя, стоит, ИМХО, попробовать во что таки компилируется

E>template<typename T> set_imag( std::complex<T>& dst,  T imag )
E>{
E>    dst = std::complex( dst.real(), imag );
E>}

E>Очень может быть, что оно хорошо компилируется и real часть не переписывает лишний раз...

Единственное сомнение терзает: в каком пространстве имен определить эту функцию? Хочется ведь, чтоб при вызове из разных пространств имен компилятор мог ее находить по параметру типа std::complex. Но для этого мы должны определить ее в одном пространстве имен с std::complex, то бишь в std. Запрещено стандартом. Можно, конечно, повсеместно использовать директивы using, но это уже не так элегантно.

Здравствуйте, m.a.smirnoff, Вы писали:

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

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

E>>Хотя, стоит, ИМХО, попробовать во что таки компилируется

E>>template<typename T> set_imag( std::complex<T>& dst,  T imag )
E>>{
E>>    dst = std::complex( dst.real(), imag );
E>>}

E>>Очень может быть, что оно хорошо компилируется и real часть не переписывает лишний раз...

MAS>Что-то мне подсказывает что врядли, однако лезть в получивший ся бинарь счас не очень хочется. Может когда времени будет побольше посмотрю, что из этого безобразия получается.

Ну в целом можешь подумать во что это таки скомпилируется...

ИМХО во что-то типа такого:

[псевдокод]
загрузить в регистр 1 из dst.re
загрузить в регистр 2 из imag
записать из регистра 1 в dst.re
записать из регистра 2 в dst.im
[/псевдокод]

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

Здравствуйте, Erop, Вы писали:

E>AFAIK сейчас таких реализаций, которые несовместимы с представлением как пара double не бывает. Но никто не мешает им быть...
E>Ну а про фиг там или не фиг, так это я про то, что на платформе комплексное число может быть представлено как-то так, что поля "вещественная часть" может и не быть в явном виде.
E>Вдруг, например, порядки будут храниться в такой реализиции отдельно, а мантисы отдельно?

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

E>>>Хотя, стоит, ИМХО, попробовать во что таки компилируется

E>>>template<typename T> set_imag( std::complex<T>& dst,  T imag )
E>>>{
E>>>    dst = std::complex( dst.real(), imag );
E>>>}

E>>>Очень может быть, что оно хорошо компилируется и real часть не переписывает лишний раз...

MAS>>Что-то мне подсказывает что врядли, однако лезть в получивший ся бинарь счас не очень хочется. Может когда времени будет побольше посмотрю, что из этого безобразия получается.

E>Ну в целом можешь подумать во что это таки скомпилируется...

E>ИМХО во что-то типа такого:
E>

[псевдокод]
E>загрузить в регистр 1 из dst.re
E>загрузить в регистр 2 из imag
E>записать из регистра 1 в dst.re
E>записать из регистра 2 в dst.im
E>[/псевдокод]

E>Казалось бы, не такая уж нереальная задачка для оптимизатора выбросить выделенные строки...

Это все гадание на кофейной гуще, и очень сильно зависит от оптимизатора и целевой платформы. Чего бы мне как раз не хотелось.

	От:	m.a.smirnoff
	Дата:	06.11.07 21:11
	Оценка:

	От:	Аноним
	Дата:	06.11.07 21:32
	Оценка:	1 (1) +1 -1

	От:	m.a.smirnoff
	Дата:	06.11.07 21:49
	Оценка:

	От:	Roman Odaisky
	Дата:	07.11.07 08:49
	Оценка:	-1

	От:	Кодт
	Дата:	07.11.07 09:29
	Оценка: