Fuer Integer Under/Overflow-Detection nutzen ich die SafeInt Library (https://safeint.codeplex.com/) von Microsoft - nur zu Floats habe ich leider bisher nichts gefunden

Ich habe mir mal ein Testprogramm geschrieben um die verschiedenen Problemfälle aufzuzeigen - bisher erkenne ich einen Over/Underflow und den Rest nach der Operation - bin mir aber nicht sicher ob das so richtig ist (meine Platformen sind alle IEE754 Konform)

Hat jemand Erfahrungen mit solchen Tests?

#include <limits>
#include <cassert>

static bool is_subnormal_bits(const double& p_value)
{
  const unsigned int* const p = reinterpret_cast<const unsigned int*>(&p_value);
  return (p[1] & 0x7FF00000) == 0  && (p[0] || p[1] & 0x000FFFFF);
}

static bool is_pinf(const double& p_value)
{
  return p_value > 0.0 && p_value/p_value != p_value/p_value;
}

static bool is_ninf(const double& p_value)
{
  return p_value < 0.0 && p_value/p_value != p_value/p_value;
}

static bool is_nan(const double& p_value)
{
  return p_value != p_value;
}

int main(int argc, char** argv)
{
  double max = std::numeric_limits<double>::max(); // groesster double Wert
  double min_before_0 = std::numeric_limits<double>::min(); // kleinster Wert vor 0.0
  double lowest = -max; // kleinster double Wert
  double null = argc - argc; // sonst kommt der Kompiler und mault wegen divison durch 0.0
  assert(null == 0.0);

  //NaN
  double nan = sqrt(-1.0);
  assert(is_nan(nan));

  //+/- Infinite
  double pinf = 1.0/null;
  double ninf = log(null);
  assert(is_pinf(pinf));
  assert(is_ninf(ninf));

  //Subnormal
  double subnormal = min_before_0 / 2.0;
  assert(is_subnormal_bits(subnormal));

  //Overflows

  //TEST 1
  {
    double a = max;
    double b = 100.0; // ein bisschen ueber max
    double r = a + b;
    assert(r == a); // Ergebnis entspricht immer noch a und b > 0.0
  }

  //TEST 2
  {
    double a = max;
    double b = max; // max ueber max
    double r = a + b;
    assert(is_pinf(r)); // +INFINITY
  }

  //FRAGE: Ab welchem Wert von b geht das Ergebnis auf +INIFINTY?

  //TEST 3
  {
    double a = max;
    double b = 2.0; // max ueber max
    double r = a * b;
    assert(is_pinf(r)); // +INFINITY
  }

  // Underflows

  //TEST 4
  {
    double a = lowest;
    double b = 100.0;
    double r = a - b;
    assert(r == a); // Ergebnis entspricht immer noch a und b > 0.0
  }

  //TEST 5
  {
    double a = lowest;
    double b = max;
    double r = a - b;
    assert(is_ninf(r)); // -INFINITY
  }

  //TEST 6
  {
    double a = (lowest + 1.0);
    double b = 2.0;
    double r = a - b;
    assert(r == a); // Ergebnis entspricht immer noch a
  }

  //FRAGE: Ab welchem Wert von b geht das Ergebnis auf -INIFINTY?

  return 0;
}

bin mir aber einfach nicht sicher ob das alles so richtig ist - oder ob es Lücken gibt die ich nicht sehe, es viel performanter geht, man vor der Operation prüfen sollte/muss/kann

#include <limits> 
#include <cassert> 

static bool is_subnormal_bits(const double& p_value) 
{ 
  const unsigned int* const p = reinterpret_cast<const unsigned int*>(&p_value); 
  return (p[1] & 0x7FF00000) == 0  && (p[0] || p[1] & 0x000FFFFF); 
} 

static bool is_inf(const double& p_value) 
{ 
  return p_value/p_value != p_value/p_value; 
} 

static bool is_pinf(const double& p_value) 
{ 
  return p_value > 0.0 && is_inf(p_value); 
} 

static bool is_ninf(const double& p_value) 
{ 
  return p_value < 0.0 && is_inf(p_value); 
} 

static bool is_nan(const double& p_value) 
{ 
  return p_value != p_value; 
} 

struct result_t
{
  enum enum_t
  {
    FP_OK,
    FP_UNDERFLOW,
    FP_OVERFLOW,
    FP_NAN,
    FP_SUBNORMAL
  };
};

static result_t::enum_t check_result(const double& p_a, const double& p_b, const double& p_result, const double& p_no_change_value)
{
  if(is_nan(p_result))
  {
    return result_t::FP_NAN;
  }

  if(is_subnormal_bits(p_result))
  {
    return result_t::FP_SUBNORMAL;
  }

  if(p_b == p_no_change_value) return result_t::FP_OK;

  const bool equal = p_a == p_result;
  const bool inf = is_inf(p_result);
  if(equal || inf)
  {
    return (p_b < 0.0) ? result_t::FP_UNDERFLOW : result_t::FP_OVERFLOW;
  }

  return result_t::FP_OK;
}

static double checked_fp_add(const double& p_a, const double& p_b, result_t::enum_t& p_status)
{
  const double result = p_a + p_b;
  p_status = check_result(p_a, p_b, result, 0.0);
  return result;
}

static double checked_fp_mul(const double& p_a, const double& p_b, result_t::enum_t& p_status)
{
  const double result = p_a * p_b;
  p_status = check_result(p_a, p_b, result, 1.0);
  return result;
}

int main(int argc, char** argv) 
{ 
  double max = std::numeric_limits<double>::max(); // groesster double Wert 
  double min_before_0 = std::numeric_limits<double>::min(); // kleinster Wert vor 0.0 
  double lowest = -max; // kleinster double Wert 
  double null = argc - argc; // sonst kommt der Kompiler und mault wegen divison durch 0.0 
  assert(null == 0.0); 

  //NaN 
  double nan = sqrt(-1.0); 
  assert(is_nan(nan)); 

  //+/- Infinite 
  double pinf = 1.0/null; 
  double ninf = log(null); 
  assert(is_pinf(pinf)); 
  assert(is_ninf(ninf)); 

  //Subnormal 
  double subnormal = min_before_0 / 2.0; 
  assert(is_subnormal_bits(subnormal)); 

  //Overflows 
  result_t::enum_t result = result_t::FP_OK;

  //TEST 1 
  double r = checked_fp_add(max, 100.0, result);
  assert(result == result_t::FP_OVERFLOW);

  //TEST 2 
  r = checked_fp_add(max, max, result);
  assert(result == result_t::FP_OVERFLOW);

  //FRAGE: Ab welchem Wert von b geht das Ergebnis auf +INIFINTY? 

  //TEST 3 
  r = checked_fp_add(max, 2.0, result);
  assert(result == result_t::FP_OVERFLOW);

  //TEST 4 
  r = checked_fp_add(lowest, -100.0, result);
  assert(result == result_t::FP_UNDERFLOW);

  //TEST 5 
  r = checked_fp_add(lowest, -max, result);
  assert(result == result_t::FP_UNDERFLOW);

  //TEST 6 
  r = checked_fp_add(lowest + 1.0, -2.0, result);
  assert(result == result_t::FP_UNDERFLOW);

  //FRAGE: Ab welchem Wert von b geht das Ergebnis auf -INIFINTY? 

  //TEST 7
  r = checked_fp_mul(min_before_0, 1.0 / 2.0, result);
  assert(result == result_t::FP_SUBNORMAL);

  //TEST 8
  r = checked_fp_mul(max, -2.0, result);
  assert(result == result_t::FP_UNDERFLOW);

  //TEST 9
  r = checked_fp_mul(nan, 1.0, result);
  assert(result == result_t::FP_NAN);

  return 0; 
}

z.B. hatte ich schon mit dem SQL-Server Problem mit Subnormalen und NaNs bei INSERTs - wie es mit INFNITY aussieht habe ich noch nicht getestet

(Abschnitt: Floating-Point Exceptions as C++ Exceptions)

warum nutzt Du nicht die Floating Point Exceptions?

Würde ich (möglicherweise) noch als Erweiterung in meine Library reinbauen - falls schon aktiv gesetzt

Probleme:

Ist das Platform-Unabhängig? (IEE754 ist aber schon meine mindest Anforderung)
hat ARM und andere Platformen was vergleichbares?

Weil ich damit als Library/Dll Fremd-Applikationen in ihrem Floating-Point Verhalten beeinflusse - falls ich die Exceptions scharf schalten würde
und es in der Applikation Code gibt der z.B. FP-Exceptions auf C++ Exceptions mappt - aber bisher immer inaktiv war usw. habe ich dann plötzlich mit meiner Lib das Programmverhalten geändert - böse böse

Oder kann man diese (möglicherweise) applikationsweiten Auswirkungen von FP-Exceptions - heute/anders besser kontrollieren?

n4296.pdf schrieb:

If a program attempts to access the stored value of an object through a glvalue of other than one of the following types the behavior is undefined:
[…]

und listet nur Dinge auf, die nichts mit deinen reinterpret_cast s zu tun haben. Das heißt: Dein Code ruft undefiniertes Verhalten hervor. Das würde ich vermeiden.

Dazu verlässt Du Dich darauf, dass

• double ein 64bit IEEE754 float ist
• der Code auf einer little-endian Maschine läuft
• int 32bit breit ist

Ich würde stattdessen mit static_assert sicherstellen, dass std::numeric_limits<double>::is_iec559 true ist und statt zwei unsigned int s einfach einen std::uint64_t benutzen — zumindest dann, wenn Du Bitfrickelei bei double s machen willst.

Und

p_value/p_value != p_value/p_value

kannst Du natürlich mit

is_nan(p_value/p_value)

abkürzen.

Ich frage mich auch, welche Motivation Du hattest, static zu verwenden. Wenn ich nicht möchte, dass etwas außerhalb der Übersetzungseinheit nicht über seinen Namen erreichbar ist, verwende ich dazu in C++ anonyme Namensräume statt static , weil ich es IMHO die Motivation besser ausdrückt.

double ein 64bit IEEE754 float ist
der Code auf einer little-endian Maschine läuft
int 32bit breit ist

Das ist mir klar, meine Vorgabe und auch so geprüft - nur eben nicht in diesem Beispiel

und listet nur Dinge auf, die nichts mit deinen reinterpret_casts zu tun haben.

ist das ein ganzer Satz - ich habe keine Ahnung was du mir sagen möchtest - was meinst du, float<->int cast aliasing Probleme? das macht der std::uint64_t aber auch nicht besser - und mit 2x uint32 bleibt der Code gleich - ist aber geschmackssache

Ich frage mich auch, welche Motivation Du hattest, static zu verwenden.

nur aus Gewohnheit - der VS2010 Kompiler generiert trotz anonymen Namensraum die Funktionen als externals - stört mich irgendwie

Die Kernfrage ist aber nicht ob mein Code schön ist oder besser aufgebaut werden kann sondern nur ob ich so meine OVERFLOW/UNDERFLOW Tests machen kann

und listet nur Dinge auf, die nichts mit deinen reinterpret_casts zu tun haben.

ist das ein ganzer Satz - ich habe keine Ahnung was du mir sagen möchtest - was meinst du, float<->int cast aliasing Probleme? das macht der std::uint64_t aber auch nicht besser - und mit 2x uint32 bleibt der Code gleich - ist aber geschmackssache

Du hast nur die zweite Hälfte des Satzes zitiert. Ja. Ich rede vom Aliasing. Ich habe auch nicht behauptet, dass uint64_t das Aliasing-Problem löst. Das war eher ein Tipp bzgl Endianness, weil Du dann die Endian-spezifischen Indizes [0] und [1] nicht mehr brauchst.

Gast3 schrieb:

Die Kernfrage ist aber nicht ob mein Code schön ist oder besser aufgebaut werden kann sondern nur ob ich so meine OVERFLOW/UNDERFLOW Tests machen kann.

Du kannst von mir aus natürlich auch sonst was machen, wie z.B. undefiniertes Verhalten hervorrufen. Aber tatsächlich tun würde ich das an Deiner Stelle nicht.

Bzgl Underflow: 0.0 oder -0.0 kann auch das Ergebnis eines Underflows sein. Das fängst Du so aber nicht ab.

Das war eher ein Tipp bzgl Endianness, weil Du dann die Endian-spezifischen Indizes [0] und [1] nicht mehr brauchst.

Du kannst von mir aus natürlich auch sonst was machen, wie z.B. undefiniertes Verhalten hervorrufen.

ok dann nutze ich ein uint64 für die Endianess-Vereinfachung und mach ein memcpy gegen das Aliasing Problem

die meisten (alle?) Kompiler optimieren das memcpy wenn sie kein Aliasing-Problem sehen auf einen einfachen Cast

oder hast du einen bessern Tip (Unions sind da ja auch nichts wert)

Bzgl Underflow: 0.0 oder -0.0 kann auch das Ergebnis eines Underflows sein. Das fängst Du so aber nicht ab.

kannst du mal ein Beispiel zeigen wo genau die beiden Werte ein Underflow sind?

die meisten (alle?) Kompiler optimieren das memcpy wenn sie kein Aliasing-Problem sehen auf einen einfachen Cast

Hmm, dieser Satz irritiert mich gerade etwas. Verwechselst Du Aliasing vielleicht mit Alignment? Die Fehlerquelle bei der Verletzung der Aliasing-Regel ist doch, dass der Compiler Code nach der as-if-Regel umsortieren und dabei annehmen darf, dass Du die Aliasing-Regeln nicht verletzt. Tust Du es doch, macht das Programm nicht unbedingt mehr das, was es soll.

Ich hoffe doch mal, dass memcpy von 4 oder 8 Bytes (wobei die Größe zur Übersetzungszeit bekannt ist) irgendwie effizient übersetzt wird. Geprüft habe ich das aber nicht.

Gast3 schrieb:

oder hast du einen bessern Tip (Unions sind da ja auch nichts wert)

Der GCC garantiert übrigens explizit, dass "type punning" per union s OK ist. Es ist quasi ein zusätzliches GCC Feature. Aber aus Gründen der Portabilität würde ich darauf verzichten. Nee, ich habe da jetzt auch keinen besseren Tipp als memcpy parat.

Gast3 schrieb:

Bzgl Underflow: 0.0 oder -0.0 kann auch das Ergebnis eines Underflows sein. Das fängst Du so aber nicht ab.

kannst du mal ein Beispiel zeigen wo genau die beiden Werte ein Underflow sind?

Klar. Das geht ganz einfach:

#include <iostream>
#include <cmath>

double naive_hypot(double x, double y) {
	return std::sqrt(x*x + y*y);
}

int main() {
	double x = 3e-200;
	double y = 4e-200;
	double z = naive_hypot(x,y);
	std::cout << z << std::endl;
}

In naive_hypot wird x*x und y*y in diesem Beispiel gleich 0.0 wegen Underflow sein. Die Ausgabe des Programms ist also 0 statt 5e-200. Ein Underflow kann Dir also bei zwei Zahlen s und t mit s!=0 und t!=0 für s*t eine 0 geben. Dem Ergebnis allein siehst Du das jetzt nicht an. Eine Multiplikation von zwei Zahlen kann ja wirklich 0 sein, sollte es nur nicht, falls beide Argumente ungleich 0 sind.

Hmm, dieser Satz irritiert mich gerade etwas. Verwechselst Du Aliasing vielleicht mit Alignment?

Ich hoffe doch mal, dass memcpy von 4 oder 8 Bytes (wobei die Größe zur Übersetzungszeit bekannt ist) irgendwie effizient übersetzt wird

ja verwechselt und ja memcpy wird optimiert (von VStudio, GCC, Clang, ARM, weitere?)

Klar. Das geht ganz einfach

wenn man so wie ich auf Einzeloperationen testet muss man den Algorithmus eben auch so schreiben - oder gibt es eine andere Möglichkeit

double checked_fp_naive_hypot(double x, double y) {
  result_t::enum_t result = result_t::FP_OK;
  double x2 = checked_fp_mul(x,x, result); //==> FP_OVERFLOW
  double y2 = checked_fp_mul(y,y, result); //==> FP_OVERFLOW
  double x2_add_y2 = checked_fp_add(x,y, result);
  double sqrt_result = std::sqrt(x2_add_y2);
  return sqrt_result;
}

wenn ich einen checked_double-Typ mit Operatoren fuer + - * / oder sowas haette
dann wuerde dein x*x oder y*y schon eine Exception/oder anderes werfen