Regarding ifstream...

[alvifarooq]

can anyone tell me if this will actually read off float values from a text file: (only posting bits of the code)

ifstream fin ("inputfile.txt");

//then we read from file and store in a float x...imagine that the file has only several numbers... 

fin >> x;

i've implemented it but i get glitches in the answers...like if i have 139.6 in the file i get a value of x = 138.99876 smth...i think it's something to do with the spaces...consider this format which i read...

in the file: 126.9 130.0 145.0 166.8

when i read it in i get 125.88888943673 129.99983783 etc etc...

Thanks,

Farooq

[CornedBee]

That's weird. Usually I write such things off to rounding errors, but 1.02 is quite a lot. Perhaps a poor standard library implementation? Perhaps it would be interesting to compare this to the input scanf would parse.

[alvifarooq]

well for some numbers it is exact...and for the others i get the long trails...i don't really understand why...is there a way that i can set an input precision or something...that round numbers to maximum of 3 decimal places...like 0.001 smth...

thanks...

Farooq

[Dave Evans]

i've implemented it but i get glitches in the answers...like if i have 139.6 in the file i get a value of x = 138.99876 smth...i think it's something to do with the spaces...consider this format which i read...

in the file: 126.9 130.0 145.0 166.8

when i read it in i get 125.88888943673 129.99983783 etc etc...

Thanks,

Farooq

If your compiler is giving these errors, ask for your money back. But first, run the following and see if you get more than 1 digit error in the 7th significant decimal digit for floats and in the 18th significant digit for doubles.

#include <iostream>
#include <fstream>
#include <iomanip>
using namespace std;

int main()

{
  float fx;
  double dx;
  int i;

  ifstream fin ("inputfile.txt");

        
  cout << fixed << setprecision(20);

  cout << "Floats:" << endl;
  for (i = 0; i < 4; i++) {
    fin >> fx;
    cout << "fx = " << fx << endl;
  }

  cout << endl << endl;

  cout << "Doubles:" << endl;
  for (i = 0; i < 4; i++) {
    fin >> dx;
    cout << "dx = " << dx << endl;
  }

  return 0;
}

Here's the text for inputfile.txt:

126.9 130.0 145.0 166.8
126.9 130.0 145.0 166.8

(Of course this is quick-and-dirty with no error checking, etc., but it should give you a clue as to whether your compiler's i/o works.)


The outputs should look something like:

Floats:
fx = 126.90000152587890625
fx = 130.00000000000000000
fx = 145.00000000000000000
fx = 166.80000305175781250


Doubles:
dx = 126.90000000000000568
dx = 130.00000000000000000
dx = 145.00000000000000000
dx = 166.80000000000001137

Regards,

Dave

[Dave Evans]

well for some numbers it is exact...and for the others i get the long trails...i don't really understand why...is there a way that i can set an input precision or something...that round numbers to maximum of 3 decimal places...like 0.001 smth...

thanks...

Farooq

130.0 is exactly representable as a binary floating point number.
So is 145.0.

126.9 is not. Neither is 166.8. Neither is 0.1. Etc.

As long as you are using built-in data types (float, double) you are stuck with this situation. You can apply a rounding algorithm to make the output look more presentable (or let cout<< do it for a given precision).

If you require exact calculations (for financial calculations, for example), I can think of a couple of possibilities:

1. Multiply all dollars-and-cents quantities by 100 (so all your calculations are in cents). If you have to multiply by a fraction (to add 8 percent sales tax, for example), be aware that you still may have some round-off errors.

2. Get a library/package that does decimal arithmetic for arbitrary precision numbers. You still may encounter roundoff errors for numbers not exactly representable as decimal fractions (1/3, for example).

Bottom line: all numbers in the computer are rational numbers with finite precision. Some quantities that you run across may not be exactly representable in whatever number system you are using (binary, decimal, etc.)

Regards,

Dave

[alvifarooq]

hi...
thanks a lot Dave...i'll try that...

see why i'm so intent on this is because i'm implementing the Astar search algorithm...now theoretically if i find the distance between two coordinates on the screen...even if i use sqrt or i don't use it (meaning just leave at the sum of the squares of the difference)...the answer should be the same...in the case where i have only 126.0 etc etc in the file the answers in both ways is the same...but if i have something like 126.7 etc etc...they turn out to be different...don't really know why that happens...

do i use some sort of flag for the ifstream precision...

Regards,

Farooq

[Hermitsky]

put what you get from the file into a string, then extract numbers from the sting ,store them into float variable.

#include<iostream>
#include<iomanip>
#include<fstream>
#include<string>
#include<sstream>
using namespace std;

int main()
{
fstream openf;
string filecontents;
char read;
float numbers;
openf.open("d:\\test.txt",fstream::in);
while(openf.get(read))filecontents+=read;
for(int num1=0,num2=0;num1<=filecontents.size();num1++)
{
if(filecontents.substr(num1,1)==" "||filecontents.substr(num1,1)=="\0")
  {
   istringstream istream(filecontents.substr(num2,num1-num2));
   istream>>numbers;
   cout<<numbers<<endl;;
   num2=num1+1;
  }
}

return 0;
}

[Dave Evans]

hi...
thanks a lot Dave...i'll try that...

see why i'm so intent on this is because i'm implementing the Astar search algorithm...now theoretically if i find the distance between two coordinates on the screen...even if i use sqrt or i don't use it (meaning just leave at the sum of the squares of the difference)...the answer should be the same...in the case where i have only 126.0 etc etc in the file the answers in both ways is the same...but if i have something like 126.7 etc etc...they turn out to be different...don't really know why that happens...

do i use some sort of flag for the ifstream precision...

Regards,

Farooq

You can give the input value as many or as few digits as you want (usually an ascii string from a file or from an input terminal). When the conversion is made to machine representation, a double for example. If it turns out that what you gave it is not exactly representable in the machine, the conversion routine will pick a value that is a "real close" approximation. For example, it doesn't matter whether you give it decimal values of 0.1, 0.10, 0.100, or 0.1000000000. The internal representation will be a real close approximation to 0.1 decimal.

When you want to print out the value, you can specify the number of digits you want after the decimal point, and the output routine will round off the internal representation to the number of digits you specify. It is not rare to see different conversion routines (from different compilers) give numbers that are a digit off in the 18th significant decimal digit for a double. It is also not completely preventable unless you know exactly what the answer should be. (In which case, the computer is giving you a verification of what you already knew, not telling you something that you didn't know.)

I once knew a grad student whose professor wouldn't accept his project since the instructor's favorite test case gave the answer as 4 (an exact value which just happened to be the output from a previous program written for the 36-bit IBM 7040). Well the same FORTRAN routine written by my buddy on the 32-bit IBM 360 gave 3.999999 as the answer. My buddy's solution (given here in pidgin-FORTRAN):

if (x .eq. 3.999999) then x = 4

(The professor, seeing the right answer, didn't actually see the need to look at the 50+pages of obscurely commented spaghetti-FORTRAN to see what actually happened here.)


Regards,

Dave