Wenn my_float vom Typ double ist, funktioniert der Code. Falls my_float vom Typ float ist, geht Zeile (*) nicht mehr, weil 2.0 anscheinend ein double ist und der op/ dann nicht mehr definiert ist.

Wie kann ich Zeile (*) schreiben oder wie kann ich das Problem umgehen, so dass der Code in beiden Fällen funktioniert?

my_float om = 0.1, k = 1.0, draft = 5.0, h = 1000.0, xmin=200.0;
  std::complex<my_float> waveVecx(1.0, 10.0);
  std::complex<my_float> waveVecy(1.0, 10.0);
  std::complex<my_float> CI(0.0,1.0);

  std::complex<my_float> vyWave = om * waveVecy / CI / k * cosh( k * (draft/2.0f-h)) / sinh(k * h) * exp(xmin*waveVecx);

Problematisch sind hier anscheinend die drei Funktionen cosh, sinh und exp

Grüssli

std::complex<my_float> vyWave = om * waveVecy / CI / k * my_float(cosh( k * (draft/2.0f-h)) / sinh(k * h)) * exp(xmin*waveVecx);

scheint zu gehen. Auch wenn das leider nicht zu einer erhöhten Lesbarkeit des Codes führt, wenn sowas häufiger auftaucht.

Der Code kompiliert bei mir einwandfrei. Sollte auch keine Probleme machen in C++, da es für cosh , sinh und exp Überladungen für float und double gibt. Einziges Problem könnte die Initialisierung deiner Variablen darstellen, aber das resultiert höchstens in einer Warnung.

Grüssli

Huch, das überrascht mich.

#include <complex>
#include <iostream>

typedef float my_float;

int main()
{
  my_float om = 0.1, k = 1.0, draft = 5.0, h = 1000.0, xmin=200.0;
  std::complex<my_float> waveVecx(1.0, 10.0);
  std::complex<my_float> waveVecy(1.0, 10.0);
  std::complex<my_float> CI(0.0,1.0);

  std::complex<my_float> vyWave = om * waveVecy / CI / k * cosh( k * (draft/2.0f-h))  / sinh(k * h) * exp(xmin*waveVecx);

  return 0;
}

führt zu

xxxxxx@yyyyyy:test g++ complex.cpp -ocomplex
complex.cpp:16:2: warning: no newline at end of file
complex.cpp: In function ‘int main()’:
complex.cpp:13: error: no match for ‘operator*’ in ‘std::operator/ [with _Tp = float](((const std::complex<float>&)((const std::complex<float>*)(& std::operator/ [with _Tp = float](((const std::complex<float>&)((const std::complex<float>*)(& std::operator* [with _Tp = my_float](((const my_float&)((const my_float*)(& om))), ((const std::complex<float>&)((const std::complex<float>*)(& waveVecy))))))), ((const std::complex<float>&)((const std::complex<float>*)(& CI))))))), ((const float&)((const float*)(& k)))) * cosh(((double)(((draft / 2.0e+0f) - h) * k)))’

Edit: In Bearbeitung ... zu viele Posts zu schnell hintereinander ...

Grüssli

Anscheinend weiss der GCC Kompiler nichts besseres zu tun, als vor dem Übergeben an sinh und cosh das Ergebnis der Operation in double zu konvertieren. Keine Ahnung wie der auf diese bescheuerte Idee kommt. Wenn man die Berechnung von cosh und sinh aus der Zeile rausnimmt und vorher ausrechnet, dann geht es wunderbar:

float r0 = sinh(k * h);
float r1 = cosh(k * (draft / 2.0f - h));

std::complex<my_float> vyWave = om * waveVecy / CI / k * r1 / r0 * exp(xmin*waveVecx);

Spricht auf der anderen Seite dafür, dass man Zwischenergebnisse verwenden sollte

Grüssli

Anscheinend weiss der GCC Kompiler nichts besseres zu tun, als vor dem Übergeben an sinh und cosh das Ergebnis der Operation in double zu konvertieren.

Das liegt wohl daran, dass sinh und cosh mit
`

double sinh(double);

double cosh(double);

`
zufällig aus der C-Library sichtbar sind. Ich sehe hier kein <cmath> und auch keine std::-Qualifizierung bzw using-Deklarationen. Richtig müsste es doch so aussehen, nicht?

#include <complex>
#include <cmath>      // <--- !!!
#include <iostream>

typedef float my_float;

int main()
{
  using std::cosh;  // <--- !!!
  using std::sinh;  // <--- !!!
  using std::exp;   // <--- !!!
  my_float om = 0.1, k = 1.0, draft = 5.0, h = 1000.0, xmin=200.0;
  std::complex<my_float> waveVecx(1.0, 10.0);
  std::complex<my_float> waveVecy(1.0, 10.0);
  std::complex<my_float> CI(0.0,1.0);

  std::complex<my_float> vyWave = om * waveVecy / CI / k *
    cosh( k * (draft/2.0f-h))  / sinh(k * h) * exp(xmin*waveVecx);

  return 0;
}

kk

Wobei ich mich trotzdem frage, wieso der Fall mit den Zwischenergebnissen dann funktioniert? Führt er dann zweimal eine implizite Konvertierung durch? Einmal nach double, was ja kein Problem ist, und einmal nach float, was ich zumindest für warnungsberechtigt halten würde

Grüssli

ps:

@Dravere: So längliche Formeln finde ich nicht schön, Zwischenergebnisse aber (oft) noch unschöner. In so einer Formel ist jede größe physikalisch, sowohl links als auch rechts. Wenn man jetzt formal unphysikalische Zwischenergebnisse einführt, stört das den Lesefluss auch ganz erheblich.