What Do 1.#Inf00, -1.#Ind00 and -1.#Ind Mean

C : My 'Poisson calculator' gives me #1.INF00. Why does this happen?

You declared a variable named FactoAct of type float. Since it is an extern variable with no initialisation, it has a value of 0.

Later you define a function Facto_Act(float Act) with an implicit return type of "int".

Your division xxx / FactoAct divides xxx by the variable FactoAct, which is zero. That's where your INF result comes from.

When you had the function at the top, when the compiler saw xxx / FactoAct, FactoAct was not the result of a call to the function, it was the function itself. You can't divide a number by a function. It doesn't make sense. The only thing you can do with a function is take its address, or call it.

You probably want FactoAct (x) or something like that.

PS. Don't use float instead of double, unless you have a reason that you can put into clear words why in your specific case float is better than double.

Cosine of a number with no math.h. Unknown error 1.#INF00

Incorrect term calculation.

Term variables are not re-initialize each loop, which appears to be OP's algorithm's need.

[Edit] Code

double MyCosine(double Angle, int Terms) {
  int cont1, cont2, cont3;
  double r1, r2, r3;
  // r1 = Angle;
  int i, n = Terms;
  double result = 0.0;
  for (i = 0; i <= n; i++) {
    r1 = 1.0;
    for (cont1 = 0; cont1 < 2 * i; cont1++) {
      // r1 = r1 * r1;
      r1 = r1 * Angle;
    }
    r2 = 1.0;
    for (cont2 = 1; cont2 <= 2 * i; cont2++) {
      r2 = r2 * cont2;
    }
    r3 = 1;
    // for (cont3 = 1; cont3 < i; cont3++) {
    for (cont3 = 0; cont3 < i; cont3++) {
      // r3 = (-1) * (-1);
      r3 = r3 * (-1);
    }
    result = result + (r1 / r2) * r3;
  }
  printf("%e %e\n", result, cos(Angle));
  return result;
}

A re-write would not need to re-initialize the term and then the nested for loops could be eliminated. Other simplification exists.

what is meant by 'Most C system provide for logically infinite floating values'?

There are no numbers in a computer. We build computers out of physical parts, and we use physical properties to store and manipulate data.

In various places, a computer has electric charges, electric voltages, magnetic fields, or other physical things that we use to represent data. In doing this, we pick some physical state and call it “0” and some other state and call it “1”. These are merely convenient names. Mathematical numbers like 0 and 1 are abstract entities—they are concepts with no physical existence. The numbers 0 and 1 do not exist in computers.

We bundle these physical states, often in groups of eight, 32, or 64, and then label them in various ways. For example, with the eight bits in the states labeled 00100010, we might call that “34”. It is still not a number. We are merely using a binary notation for the number 34, and that binary notation further designates the state of the pieces of the machine.

The pieces of the machine in the state 00100010 are not inherently the actual number 34 any more than they are a banana or the concept of red.

We design parts of the machine so they can manipulate these states. Somewhere in the machine is an adder that takes as input physical states representing one number and physical states representing another number and creates as output physical states representing the number that is the sum of the two input numbers.

Computers contain many parts like these that create the effect of adding numbers, multiplying numbers, subtracting numbers, and so on. These are just effects created in a machine.

With floating-point numbers, we designate certain of the bit patterns to represent infinity, and we design the floating-point arithmetic unit to behave correspondingly. When we give the floating-point arithmetic adder one input that represents infinity and another input that represents a finite number, it produces an output that represents infinity, because we designed the floating-point arithmetic unit to do that. Similarly, when we give the floating-point divider one input that represents the number one and another input that represents the number zero, it produces as output the bit pattern that represents infinity, again because we designed it to do that.

When you print a floating-point object that as the bit pattern representing infinity using printf("%f", x);, the C implementation prints a string representing infinity. Microsoft’s chosen string for that is “1.#INF00”, which is rather ugly. Some other implementations use “inf”, which is only slightly better.

When you attempt to print a floating-point object using printf("%d", x);, the behavior is not defined by the C standard, because the %d conversion expects to receive an int object, but the x you are passing is a double object. Passing the wrong type of argument can screw up the argument-passing mechanism in a variety of ways, so you will not always get answers that make sense without knowing how the internals of the software work.

Infinity in MSVC++

Use numeric_limits:

#include <limits>

float maxFloat = std::numeric_limits<float>::infinity();

Does epsilon really guarantees anything in floating-point computations?

"you must use an epsilon when dealing with floats" is a knee-jerk reaction of programmers with a superficial understanding of floating-point computations, for comparisons in general (not only to zero).

This is usually unhelpful because it doesn't tell you how to minimize the propagation of rounding errors, it doesn't tell you how to avoid cancellation or absorption problems, and even when your problem is indeed related to the comparison of two floats, it doesn't tell you what value of epsilon is right for what you are doing.

If you have not read What Every Computer Scientist Should Know About Floating-Point Arithmetic, it's a good starting point. Further than that, if you are interested in the precision of the result of the division in your example, you have to estimate how imprecise b-c was made by previous rounding errors, because indeed if b-c is small, a small absolute error corresponds to a large absolute error on the result. If your concern is only that the division should not overflow, then your test (on the result) is right. There is no reason to test for a null divisor with floating-point numbers, you just test for overflow of the result, which captures both the cases where the divisor is null and where the divisor is so small as to make the result not representable with any precision.

Regarding the propagation of rounding errors, there exists specialized analyzers that can help you estimate it, because it is a tedious thing to do by hand.

Recovering context after handling exception only works with VS /RTCs (run time checks) enabled

Finally got the answer to my own question. I had been using a line GetThreadContext(GetCurrentThread(),&myContext) to capture the current context, which had my desired values for floating point registers after calling _clearfp and _controlfp. However I failed to notice in the help for GetThreadContext: If you call GetThreadContext for the current thread, the function returns successfully; however, the context returned is not valid.

Turns out the right way to get the current thread context is RtlCaptureContext. I'll edit my original code to reflect.

Static field initialization order

When the code is converted to a console application and use g++, it prints out the correct value (g++4.8.2, OS X):

#include <iostream>

using namespace std;

template <typename T>
struct constant_test {

    static const T PI;
    static const T FULL_CIRCLE;
    static const T HALF_CIRCLE;
    static const T DEG_TO_RAD;

};

template <typename T> const T constant_test<T>::PI = 3.141592653589f;
template <typename T> const T constant_test<T>::FULL_CIRCLE = 360.0f;
template <typename T> const T constant_test<T>::HALF_CIRCLE = constant_test<T>::FULL_CIRCLE / 2;
template <typename T> const T constant_test<T>::DEG_TO_RAD = constant_test<T>::PI / constant_test<T>::HALF_CIRCLE;

int main()
{
    // uncomment to make it work
    //float test_ref = constant_test<float>::HALF_CIRCLE;
    cout << "Value: " << constant_test<float>::DEG_TO_RAD << endl; // correct result

    char buf[128];
    sprintf(buf, "Value: %f", constant_test<float>::DEG_TO_RAD );
    cout << buf << endl; // again correct
    
    return 0;
}

Output:

Value: 0.0174533
Value: 0.017453

The static constants are initialized in order, see https://stackoverflow.com/a/10011133/3093378, so you should have constant_test<T>::DEG_TO_RAD initialized when you display it (and it looks it is, from the code above).

---

Related Topics