VBCC - What's going on here?

[deimos]

Interesting.

Could you unload the good and bad libraries so we can compare, or at least verify version numbers?

[alkis]

Three libs are the same.
Only one is different
The bad one is mathieeedoubbas.library mathieeedoubbas 37.1 (21.1.91)
Good one mathieeedoubbas.library mathieeedoubbas 38.2 (24.1.92)

Bad one size: 5244 bytes
Good one size: 5240 bytes

[deimos]

So, looking at the version numbers, we can jump wildly to the conclusion that this library was broken in 2.04 and fixed by the time 2.1 was released. The library was available with 1.3 (I haven't verified this, I'm just going by what I see online) but we don't know if that version was broken. We don't know whether the version shipped with 2.05 was broken or not.

Still, doesn't explain how the library can return the right result some of the time (it's only broken for that specific input and when called by itself, it works fine when called as part of the varargs of the last printf), which makes me very suspicious that something else is actually going on, bearing in mind how central and crucial this library would have been to many applications.

[meynaf]

Originally Posted by deimos

We don't know whether the version shipped with 2.05 was broken or not.

2.05 is shipped with 37.1 so it's the broken version.

Originally Posted by deimos

Still, doesn't explain how the library can return the right result some of the time, which makes me very suspicious that something else is actually going on,

Pseudo random bugs can exist. It could access some uninitialised memory, things like that.

Originally Posted by deimos

bearing in mind how central and crucial this library would have been to many applications.

Not that much ! Floats are quite rarely used, at least for what typically runs on machines with v37. If it's a corner case (which i suspect) then the bug might have gone inconspicuous for a long time.

[Samurai_Crow]

Was the A3000 image using hardware FPU? That could affect things as well.

[deimos]

I get that bugs can appear to be random, but I don't agree that floats are rarely used, or that this is a corner case. You might argue that there weren't commercial applications using floats (I disagree), but don't forget the thousands of bedroom coders.

cos(M_PI / 2)

The cosine of 90 degrees.

And no one noticed, all the way through 2.04 and 2.05? No one got their hot new graphics computer and their brand new c compiler and tried to draw a circle?

If this was 25 years ago I would dissassemble the different versions of the libraries to look for the difference, but frankly, today, I wouldn't know how.

Originally Posted by meynaf

2.05 is shipped with 37.1 so it's the broken version.



Pseudo random bugs can exist. It could access some uninitialised memory, things like that.



Not that much ! Floats are quite rarely used, at least for what typically runs on machines with v37. If it's a corner case (which i suspect) then the bug might have gone inconspicuous for a long time.

[deimos]

Yes, this is one thing that would point to the problem being within the library.

Originally Posted by Samurai_Crow

Was the A3000 image using hardware FPU? That could affect things as well.

[PeterK]

Originally Posted by deimos

Still, doesn't explain how the library can return the right result some of the time (it's only broken for that specific input and when called by itself, it works fine when called as part of the varargs of the last printf), which makes me very suspicious that something else is actually going on, bearing in mind how central and crucial this library would have been to many applications.

There is probably no different result from the Sin() function, because Sin() is part of mathieeedoubtrans.library. It's more likely caused by a problem with Fix() or other basic functions in mathieeedoubbas.library, which are used by the printf() function of the compiler. So it may depend on the output format of printf() what you get for the result. For example: the Fix() function needs a "round to zero" mode in order to produce correct results with printf(). In case that mathieeedoubas.library uses a different rounding mode for Fix() you may just get random results or trash for the output of printf().

[deimos]

So, how can we explain this:

#include <math.h>
#include <stdio.h>

double xsin(double a) {
    double x = sin(a);
//    x += 0.000001;
    return x;
}

double xcos(double a) {
    double x = cos(a);
//    x += 0.000001;
    return x;
}

int main(int argc, char const *argv[]) {
    double a = M_PI / 2;
    double x = xcos(a);
    double y = xsin(a);
    printf("%f: %f, %f\n", a, x, y);
    return 0;
}

Run this how it is, I get:

1.570796: 0.000000, 0.000000

i.e. incorrect.

Un-comment the two lines that are commented and run it again, I get:

1.570796: 0.000000, 1.000001

i.e. correct.

[PeterK]

Did you read my previous post already before creating your new test?

The xcos() result is also not correct in the second case. It still looks like a printf() problem with Fix() or maybe other string formating functions..

[deimos]

No, you must have posted it while I was typing. I will read it now.

Originally Posted by PeterK

Did you read my previous post already before creating your new test?

[deimos]

Originally Posted by PeterK

The xcos() result is also not correct in the second case.

Isn't it?

I might need a coffee.

I have two different results, either one is wrong, or they're both wrong.

[PeterK]

Should be 0.000001 or not?

[deimos]

No, I think it's correct, we're printing the cos ( + 0.000001), then the sin ( + 0.000001)

Originally Posted by deimos

Isn't it?

I might need a coffee.

I have two different results, either one is wrong, or they're both wrong.

[meynaf]

Originally Posted by deimos

I get that bugs can appear to be random, but I don't agree that floats are rarely used, or that this is a corner case. You might argue that there weren't commercial applications using floats (I disagree), but don't forget the thousands of bedroom coders.

Floats ARE rarely used. I disassembled megabytes of various code and hardly found any.
We're not in the PC world (where floats are indeed scattered all over the place, especially at wrong places).

Originally Posted by deimos

cos(M_PI / 2)

The cosine of 90 degrees.

Not exactly. There is no way to represent PI/2, it has to be an approximation. Who knows what lurks then.

Originally Posted by deimos

And no one noticed, all the way through 2.04 and 2.05?

Right, no one noticed. Or someone did, and it got fixed in v38.
Many games just don't use the OS. Same for demos. Very few utilities will use floats. Drawing some sine is best done with tables. So it's not surprising at all.
Besides, we have 3 versions of math libraries (ffp, single, double).

Originally Posted by deimos

No one got their hot new graphics computer and their brand new c compiler and tried to draw a circle?

There are other, much better ways to draw a circle.

Originally Posted by PeterK

There is probably no different result from the Sin() function, because Sin() is part of mathieeedoubtrans.library. It's more likely caused by a problem with Fix() or other basic functions in mathieeedoubbas.library, which are used by the printf() function of the compiler. So it may depend on the output format of printf() what you get for the result. For example: the Fix() function needs a "round to zero" mode in order to produce correct results with printf(). In case that mathieeedoubas.library uses a different rounding mode for Fix() you may just get random results or trash for the output of printf().

As Sin() requires a lot of computations, it's not weird to think they might be done with calls to mathieeedoubbas.library (which IS opened when mathieeedoubtrans.library is used).

[deimos]

Originally Posted by PeterK

Should be 0.000001 or not?

When copying by hand there was a typo. Yes:

1.570796: 0.000001, 1.000001

[PeterK]

I would expect 1.570796: 0.000001, 1.000001 or do I need a beer?

Ok, ok, a typo can happen. But I will get my beer anyway ...

[PeterK]

Originally Posted by meynaf

As Sin() requires a lot of computations, it's not weird to think they might be done with calls to mathieeedoubbas.library (which IS opened when mathieeedoubtrans.library is used).

Okay, that's indeed possible. But I know these strange printf() outputs already from my mathlibs where they always happened when Fix() was done with the wrong rounding mode. Printf() seems to use Fix() to format the output string. But of course, other functions in mathieeedoubas.library may be involved, too. Sometimes I had exactly the same hex return values from some trigonometric or logarithmic functions and only the rounding mode of mathieeedoubbas.library was responsible for a different printf() output.

[deimos]

Originally Posted by meynaf

Many games just don't use the OS. Same for demos. Very few utilities will use floats.

Yes, but that's not how people started. In this case I hit the problem while trying to write code to generate a lookup table. So I get all that. I just don't think it's correct to say that it was never apparent because people weren't writing C code that used floating point. I know I was - I wrote just as much OS friendly C code as I did hardware hitting 68K code. I think something has changed. Maybe the problem was always there, but it's only showing up now. I don't know, I can't make a case because I'm only seeing it for certain, specific inputs.

I just don't like not understanding. I won't feel comfortable coding in this environment until I do.

[deimos]

I don't think we can blame printf, changing that line to:

printf("%f: %f, %f | %f\n", a, x, y, (x - y) * 123.0);

gives:

1.570796: 0.000000, 0.000000 | 0.000000

suggesting that both x and y are really 0.0.