Why does it run differently?

Hey everyone. I'm a Computers Engineering student on my first semester and I'm scratching my head over an issue I'm having.

On the current C exercises I have, two of them are compiling differently than they should, although the code seems right. And when I say differently than they should, when I compile them on the Uni's UNIX server over the net using GCC, they run perfectly. When I do the compiling using MinGW and GCC locally at home in Windows, they're faulty.

Here is one of those programs in question:

Code:

---

#include <stdio.h>

main()
{
        float vathmoi[10], avg, max;
        int i, num, sum, count;

        sum = 0;

        for (i=0;i<=9;i++)
        {
                do
                {
                        printf("Enter student's grade: ", i + 1);
                        scanf("%f", &vathmoi[i]);
                        printf("%d %f\n", (int)(vathmoi[i] * 10), (vathmoi[i] * 10));
                }
                while ((int)(vathmoi[i] * 10) != (vathmoi[i] * 10) | vathmoi[i] < 0 | vathmoi[i] > 10);
                sum = sum + vathmoi[i];
        }
        avg = sum / 10.0;

        count = 0;
        max = 0;

        for (i=0;i<=9;i++)
        {
                if (vathmoi[i] >= avg) count++;
                if (vathmoi[i] > max) max = vathmoi[i];
        }
        printf("\n\n%d students are over the average.", count);
        printf("\nMax Grade: %.1f. Students: ", max);

        for (i=0;i<=9;i++)
        {
                if (vathmoi[i] == max) printf("%d ", i + 1);
        }
        printf("\n");
}

---

So, simple program, asks for 10 students' grades, and only sets them into the array if they're valid, that is, if they're between 0 and 10 and have only one digit past the decimal point. Since we're still on pretty basic stuff, the "only one digit" is determined via the multiplication by 10 and comparing the integer of that with the float. So for example, 4.6 * 10 = 46.00000 and the integer is 46, so accepted, while 4.65 * 10 = 46.50000 and the integer is 46, so denied.

And this works perfectly if I use the uni's GCC compiler via an SSH shell. However, if I use C-Free or Code::Blocks or any other C Editor with the MinGW GCC compiler, the small debug part that prints (int)(vathmoi * 10) and (vathmoi * 10) shows that something is completely wrong!

For example, if I give 4.6 as input for a grade, it says that (int)(vathmoi * 10) is 45 because (vathmoi * 10) is 45.999999!

Can someone explain why this happens? Is there some basic explanation on why I can't get the program to work right on my computer, while running it over the net on the UNIX server works fine?

Floating point behavior can differ between different operating systems and architectures. Floats are not infinitely precise. I don't see any real problem here.

Yes, well, I understand that (to a point, that is). It's not so much of a problem, as much as it makes the whole process of debugging tedious, since I can't properly test whether my projects actually work by just compiling them on Windows. To get them to work properly, I have to transfer the file via SSH to the uni's server, compile it there and run it there, instead of just clicking Build > Run on the IDE.

And besides boredom or tediousness or whatever, why would 4.6 be stored as 4.599999 instead of 4.600000? I mean okay, precision is not infinite, so 10.0 / 3 may equal 3.333333 and then 3.333333 * 3 = 9.999999, so okay, some precision lost there, however, why would it lose precision when just storing the number?

This means that the program in its current form can only be run and have correct function in my uni's server, as on my computer anything but .0 or .5 is considered an invalid student's grade by the program.

Is there anyway I can fix it or does that fall into more advanced waters that I don't want to swim in right now, being in the first semester and all?

--------------------------------------------------

Different Result Part. 2:

Here's another program that compiles differently and could only be tested properly on my uni's server. This program asks the user to enter a string, inverts it, and sees if the original and the inverted string are equal. So mayyam is a string that gets a happy response, hello is not.

Code:

---

#include <stdio.h>
#include <string.h>

main()
{
        char line[200];
        int i;

        gets(line);
        char linet[strlen(line)];
        char linet2[strlen(line)];

        strcpy(linet, line);

        for (i=0;i<strlen(linet);i++)
        {
                linet2[strlen(linet)-1-i] = linet[i];
        }
        if (strcmp(linet, linet2) == 0) printf("Einai\n");
}

---

Now the problem. If compiled on my computer, "mayyam" doesn't work, "mmayyamm" doesn't either, but "mayyyam" for some weird reason, does work. On the uni's server, all those 3 above work. Any explanation for this? What is it I don't know/understand/do correctly?

Read your grades in a different manner, one which doesn't involve messy floating point and the inaccuracies which result.

Say
int intPart, decimal;
scanf( "%d.%d", &intPart, &decimal );

I thought of that, but wouldn't that make my life much harder while trying to get averages and maximum grade and so on?

Funny thing is, we've been advised to use that certain comparison with the * 10 part and int by the post-graduate students that check and grade our projects. And why wouldn't they? If all work's done on the Uni's server, no such "inaccuracies" or problems occur. It's magic! *Sigh*

Quote:

---

Originally Posted by Leftos

why would 4.6 be stored as 4.599999 instead of 4.600000?

---

You've hit the answer right on the head - every number can't be stored, at it's exact value. Doesn't matter WHAT you do with that number thereafter, it will be output in the future as that approximation, not the exact value.

You can "normalize" the fp numbers before you make comparisons or output them. Google and read up to see if that's something you want to do. I've only used it a couple of times in my programs (but I just program for a hobby).

Quote:

---

Originally Posted by Leftos

I thought of that, but wouldn't that make my life much harder while trying to get averages and maximum grade and so on?

---

Yeah, somewhat, but it's manageable. It sounds like the people who wrote this assignment don't really understand floating point inaccuracy either, and they are expecting you to do the impossible (i.e., reproduce some precise result which is not precisely reproducible by definition!)

If you need N digits of precision, then multiply all values by 10^N, do your math in integer space, then divide by 10^N at the end.

Just remember than when you multiply two such "scaled" values the scale factor is squared and has to be divided out. This is basically a form of fixed-point arithmetic.

Ironically your instructors may not understand why you are doing this and dock you points for actually doing things the right way. Wouldn't be the first time.

For your string example, you don't have a '\0' at the end of your linet and linet2 (and you didn't allocate enough space for it anyway); so strcmp is going to keep examining and not necessarily see identical things off the ends of your array. printf linet and linet2 and see. (This shouldn't ever work, so you got lucky on your university machine.)

As to the first example, floating point is floating point. It's possible that your university machine uses larger memory sizes for float, so maybe their float is your double. (I haven't checked whether 4.6 in double gives the right answer and not in float.) (I would kind-of expect both to be using IEEE standard floating point, but who knows. I would almost guarantee neither is going to use binary-coded decimal.)

Thanks for all the answers, first of all. It would seem as if the university machine is magically configured to solve all these little problems. Floating point values are stored accurately and calculated accurately as well, strings do not require "null" at the end (\0) to work, and it's all fine and well.

@tabstop: I'll try printf, then increase space by +1 and strcat \0 onto both, see what happens.

Quote:

---

Originally Posted by Leftos

Thanks for all the answers, first of all. It would seem as if the university machine is magically configured to solve all these little problems. Floating point values are stored accurately and calculated accurately as well, strings do not require "null" at the end (\0) to work, and it's all fine and well.

---

More likely, the C library on the test machine is rounding float values before printing them, thus hiding the inaccuracy.

Quote:

---

Originally Posted by Leftos

Code:

---

        gets(line);

---

---

No one is going to complain about gets in that code?
Then I'm going to be the first one.
gets is incredibly dangerous, don't use it! Use fgets instead.

Right, to explain "why can't it be stored exactly", you have to understand that a floating point number is stored as binary. If we take 0.7 [1] for example:
Each bit to the right of the decimal point is worth half as much as the previous one.
So, we start "storing the largest portion of 0.7 that we can":
decimal = binary
0.5 = 0.1 // Still got 0.2 left to store
0.5 + 0.125 = 0.101 // 0.075 left
0.5 + 0.125 + 0.0625 = 0.1011 // 0.0125 left
0.5 + 0.125 + 0.0625 + 0.0078125 = 0.1011001 // 0.04685 left.
0.5 + 0.125 + 0.0625 + 0.0078125 + 0.0039075 = 0.10110011 // 0.0007775 left.

We can continue this forever, it will never be "zero left".

So when we convert the number back to decimal, we will only get 0.69999999.

These numbers are not particularly rare either, so it's very likely that the conversion from decimal to binary, without even a simple calculation, will convert it to a "ends with a number of nines" situation [or ends with 0.000001].

The RIGHT solution is to never trust floating point numbers to be precise. In the case of your check for "is there only one decimal place", you could "fudge it" by doing something like this:

Code:

---

  float f;
  ...
  if ((int)(f * 10 + 0.1) - (f * 10 + 0.1) < 0.1) ....

---

Oh, and don't use "|" when you actually mean "||" in your while-statement. It may not do what you want.


[1] I picked this number as a "well-known NOT working number".

> It would seem as if the university machine is magically configured to solve all these little problems.
Depending on your point of view, you either got lucky or unlucky.
Personally, I think you're lucky to have the illusion of floating point infallibility so soundly smashed so early in your programming career.

And no it hasn't solved all of them, you've just found one test case where it seems to work. There will be plenty of other cases where your local machine will seem to be correct and where both are "incorrect".

As soon as you attempt to parse say 4.6 as a float (or a double), you're going to have to take into account the approximate nature of floating point. Simply citing "this machine produces the expected answer" is not a substitute for being right. We see it all too often, the "expected answer" is produced despite all the attempts of the author to screw up.

Here is a nice long read.
What Every Computer Scientist Should Know About Floating-Point Arithmetic

Once again, thanks for all the helpful answers.

See, each project we have includes 4-6 exercises that must be completed in code. However, each project corresponds to a particular chapter(s) in Herbert Schildt's Teach Yourself C. So when I tried to calculate a power using math.h and the pow function, I was reprimanded, because, well, "you haven't been taught math.h yet." I've been programming on Visual Basic 6 for the past 5 years on my spare time, and I know there's hardly ever only one way to do something, and you can always come up with a more efficient idea.

But since I haven't been taught math.h, I "should have" calculated the power of a certain number using loops.

So yes, the post-graduate students that check our exercises actually told us to check the number that way, but I don't know the reason. If it doesn't work unless you have some particular edited C libraries, why would we be doing so? I'd love to test the method provided by matsp, I despise however the time it'll take me to explain to the post-graduate student something "I'm not supposed to know or care about yet", something "that's too advanced for me at this level."

Same goes with Elysia's complaint. Of course I have wondered why every C compiler I've used complains about "gets" being very dangerous, and of course I'd love to use fgets, however we've only been taught scanf and gets, Chapter 2 and Chapter 5, while fgets is on Chapter 9, thus, no can't do mister.

If I use it, my program may work more correctly, and I'll be teaching myself something new, however that's not the way things work for university projects.

We haven't discussed the approximate nature of floating point numbers, because it's too advanced right now. We haven't discussed the dangers of gets in depth, because it's too advanced right now.

Thank god we're past Hello World.

There is of course a method in the madness in teaching you to use loops to calculate x raised to y - at least for those not used to programming. The point isn't to ACTUALLY calculate x to the power of y, but to learn how to use loops - and pow() doesn't teach you that. In some sense, it is technically "cheating" to not use loops if the purpose of the exercise is to use loops. [I'm not suggesting you did it for the purpose of cheating - I'm sure you know how to. If, however, a person wants to avoid using loops to solve the problem because he/she is unable to use loops, then that's cheating, right?].

The same obviously applies for some other things.

At the same time, "teaching good practices", such as "use -Wall" to produce as much warnings as possible [I'd go as far as to suggest -Wall -Werror for projects that are "school-work size"].

Along with that, using fgets() is in itself not particularly advanced if you just teach people that "This is how you do this, ignore what it means for now":

Code:

---

fgets(str, sizeof(str), stdin)

---

. It is "good practice".

--
Mats

I understand, and yes, the pow thing was part of the project that referred to the chapter on loops, so it was part of the practice. However we had to use about 6 to 8 more loops in the same project, so it wasn't clear to me that we had to do something so trivial using a loop until a friend told me.

And although I see quite clearly why fgets is a much more safe apporach and good practice, we haven't been taught it yet, so I'm not going to risk a point off my project just for being more correct.

Quote:

---

Originally Posted by Leftos

And although I see quite clearly why fgets is a much more safe apporach and good practice, we haven't been taught it yet, so I'm not going to risk a point off my project just for being more correct.

---

Neither did I mean that you should, but rather suggesting that the teacher(s)/helper(s) should be able to "hide" the fact that you haven't got to fgets() in the book, and explain that "gets() is no good, use this for of fgets() instead" - without actually explaining all the ins and outs of how it works and why it's so much better. Get to WHY it's better when you get to that part of the book [and explaining how and why this is important, somewhere in the education too!].

--
Mats

It would seem to me that you're on the wrong course then. Since you already know some stuff, and have the sense to go digging for information yourself, you're already a step above the noobs who have to be spoon-fed all the way.

> Herbert Schildt's Teach Yourself C
Well if this is the reference text, then everybody is on the wrong course.
Schildt is famous for many many low-quality publications.

Quote:

---

Originally Posted by Leftos

Same goes with Elysia's complaint. Of course I have wondered why every C compiler I've used complains about "gets" being very dangerous, and of course I'd love to use fgets, however we've only been taught scanf and gets, Chapter 2 and Chapter 5, while fgets is on Chapter 9, thus, no can't do mister.

---

Now THAT is madness. Gets is very dangerous because it can very easily create buffer overruns. Gets should never, ever be used. It should not even be teached!
It never fails to amaze me how teacher and books learn people to use gets or other unsafe functions.
As matsp mentioned there, fgets(buffer, size, stdin) is the same as doing gets(buffer) and it much, much safer. Gets is just a dumb version of fgets, basically.
Complain at those who teach you if you want, but please, use fgets or at the very least learn how to use it. In a real application you should NEVER use gets.
And btw, even for school projects, it can be dangerous as soon as you run the application. It can even crash. Doesn't look good, does it?

I fully understand the risk of gets and the usefullness of fgets. And from what I've learned today, come the day I start programming in C for anything besides uni's projects, I'll use fgets. But for now, I don't want my grade lowered just because I'm using something I've not been taught.

Complain at your teacher, though. Always a good thing. Tell them not to teach dangerous stuff.

Quote:

---

Originally Posted by Leftos

I fully understand the risk of gets and the usefullness of fgets. And from what I've learned today, come the day I start programming in C for anything besides uni's projects, I'll use fgets. But for now, I don't want my grade lowered just because I'm using something I've not been taught.

---

For some reason computer science is fraught with bad instructors. Some of the absolute worst designed code I've ever seen was written by CS Ph. D's. These people are well versed in arcane topics and understand computer science and mathematics really well, but they have very little engineering skill. I don't mean to make a blanket statement. I have also seen some incredibly good code.

In my experience it is impossible to change these people's opinions no matter how wrong they are. Especially in the lower-numbered classes, the instructors sometimes don't even use the languages they are teaching. The best you can do is give them what they expect while keeping in mind that you are actually using bad techniques. Write a version for yourself that does it right. I wish it wasn't this way, but it's how it is. For now.

Here's something I don't understand. Well, another thing. Given the input is 7.6...

Code:

---

float a;
scanf("%f", &a);
printf("%f", a * 10);

---

...gives 75.999999, while...

Code:

---

float a;
scanf("%f", &a);
a = a * 10;
printf("%f", a);

---

...gives 76.000000. Why is that?

A better all-around check:

Code:

---

        float a, b;
        int inta;
        scanf("%f", &a);
        b = a * 10;
        inta = (int)(a * 10);
        printf("%f %f %f %d", a, a * 10, b, inta);

---

Output: 7.600000 75.999999 76.000000 75

Quote:

---

Originally Posted by Leftos

Here's something I don't understand. Well, another thing. Given the input is 7.6...

Code:

---

float a;
scanf("%f", &a);
printf("%f", a * 10);

---

...gives 75.999999, while...

Code:

---

 
float a;
scanf("%f", &a);
a = a * 10;
printf("%f", a);

---

...gives 76.000000. Why is that?

---

because the calculation is done a little bit differently - or the conversion from float to double is done differently [all floating point parameters to printf are double] , perhaps. You probably will find other cases where there are differences.

Actually, I reproduced the results you got on my machine, and there is a difference between the two code-sets is:

Code:

---

        fmulp        %st, %st(1)
        fstps        -4(%ebp)
        flds        -4(%ebp)
        fstpl        4(%esp)

---

This stores the value back in a, and then loads it and stores it as a double on the stack for printf. In the "just multiply a by ten", the red code is not present, meaning the more precise double value is stored onto the stack. Note that the precision of (x87) floating point calculations is decided at the store stage, not during the actual calculation.

I do apologize if you don't fancy reading assembler code and understanding what it means - but there's no way to explain the behaviour in any other way.

--
Mats

Don't worry. I'm glad you're still answering to my issues and explaining so well.

So the correct way to do floating point calculations would be outside functions such as printf. Here is the loop that made the program work on my computer too.

Code:

---

                do
                {
                        printf("Dwse vathmo %dou ma8hth: ", i + 1);
                        scanf("%f", &vathmoi[i]);
                        vathmoi10 = vathmoi[i] * 10;
                }
                while ((int)(vathmoi10) != vathmoi10 | vathmoi[i] < 0 | vathmoi[i] > 10);

---

Thanks for all the help and info anyway, it's been very helpful. A little testing always helps and in this case taught me something.

I'm still wondering, though, about why the other exercise with the inverted string doesn't work on my computer but works on the server.

Quote:

---

Originally Posted by Leftos

Don't worry. I'm glad you're still answering to my issues and explaining so well.

So the correct way to do floating point calculations would be outside functions such as printf. Here is the loop that made the program work on my computer too.

Code:

---

                do
                {
                        printf("Dwse vathmo %dou ma8hth: ", i + 1);
                        scanf("%f", &vathmoi[i]);
                        vathmoi10 = vathmoi[i] * 10;
                }
                while ((int)(vathmoi10) != vathmoi10 | vathmoi[i] < 0 | vathmoi[i] > 10);

---

Thanks for all the help and info anyway, it's been very helpful. A little testing always helps and in this case taught me something.

I'm still wondering, though, about why the other exercise with the inverted string doesn't work on my computer but works on the server.

---

The red code above is broken in two senses:
1. It's comparing an integer with a float, which is likely to fail under some circumstances [you just don't KNOW what those circumstances may be] due to floating point not being precise.

Code:

---

fabs((int)(vathmoi10) - vathmoi10) > 0.01

---

would be a better solution.
2. You are using bitwise or rather than logical or, which isn't quite the same thing - it sort of works OK for this case, but it's the wrong thing to do here. Use || instead of | and all will be fine.


As someone else suggested:

Code:

---

        char linet[strlen(line)];
        char linet2[strlen(line)];

---

should probably be

Code:

---

        char linet[strlen(line)+1];
        char linet2[strlen(line)+1];

---

Although both are a bit dubious as they are extensions to gcc, so won't work on other compilers. Perhaps this is the best solution:

Code:

---

        char linet[200];
        char linet2[200];

---

You also should set the end-marker of linet2 to zero - currently you just leave it to whatever it happens to be. Since different machines have different "stuff" sitting around in stack-based locations, what actually ends up at the end of the string is completely random, and on one machine it may be zero, on another some other value, so you get "random failyures" - it may even be different for different length strings.

--
Mats

I made it work. Thanks. I declared linet and line2 as 200 in size (can't declare after gets, obviously, and we haven't practiced subroutines yet), and made sure to add '\0' to linet2 on position strlen(linet). Now any string works.

Thanks everyone, you've been really helpful!