English Amiga Board


Go Back   English Amiga Board > Coders > Coders. Language > Coders. C/C++

 
 
Thread Tools
Old 25 July 2018, 19:52   #21
deimos
Registered User

 
Join Date: Jul 2018
Location: Londonish / UK
Posts: 111
Interesting.

Could you unload the good and bad libraries so we can compare, or at least verify version numbers?
deimos is offline  
Old 25 July 2018, 20:07   #22
alkis
Registered User

 
Join Date: Dec 2010
Location: Athens/Greece
Age: 47
Posts: 449
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
alkis is offline  
Old 25 July 2018, 20:42   #23
deimos
Registered User

 
Join Date: Jul 2018
Location: Londonish / UK
Posts: 111
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.

Last edited by deimos; 25 July 2018 at 20:50.
deimos is offline  
Old 25 July 2018, 20:49   #24
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 45
Posts: 3,316
Quote:
Originally Posted by deimos View Post
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.


Quote:
Originally Posted by deimos View Post
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.


Quote:
Originally Posted by deimos View Post
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.
meynaf is offline  
Old 25 July 2018, 20:52   #25
Samurai_Crow
Total Chaos forever!

Samurai_Crow's Avatar
 
Join Date: Aug 2007
Location: Ft. Collins, CO USA
Age: 44
Posts: 1,131
Send a message via Yahoo to Samurai_Crow
Was the A3000 image using hardware FPU? That could affect things as well.
Samurai_Crow is offline  
Old 25 July 2018, 21:24   #26
deimos
Registered User

 
Join Date: Jul 2018
Location: Londonish / UK
Posts: 111
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.

Quote:
Originally Posted by meynaf View Post
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 is offline  
Old 25 July 2018, 21:24   #27
deimos
Registered User

 
Join Date: Jul 2018
Location: Londonish / UK
Posts: 111
Yes, this is one thing that would point to the problem being within the library.

Quote:
Originally Posted by Samurai_Crow View Post
Was the A3000 image using hardware FPU? That could affect things as well.
deimos is offline  
Old 25 July 2018, 21:37   #28
PeterK
Registered User
 
Join Date: Apr 2005
Location: Hangover
Posts: 2,406
Quote:
Originally Posted by deimos View Post
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().
PeterK is offline  
Old 25 July 2018, 21:40   #29
deimos
Registered User

 
Join Date: Jul 2018
Location: Londonish / UK
Posts: 111
So, how can we explain this:

Code:
#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.
deimos is offline  
Old 25 July 2018, 21:45   #30
PeterK
Registered User
 
Join Date: Apr 2005
Location: Hangover
Posts: 2,406
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..

Last edited by PeterK; 25 July 2018 at 21:52.
PeterK is offline  
Old 25 July 2018, 21:46   #31
deimos
Registered User

 
Join Date: Jul 2018
Location: Londonish / UK
Posts: 111
No, you must have posted it while I was typing. I will read it now.

Quote:
Originally Posted by PeterK View Post
Did you read my previous post already before creating your new test?
deimos is offline  
Old 25 July 2018, 21:54   #32
deimos
Registered User

 
Join Date: Jul 2018
Location: Londonish / UK
Posts: 111
Quote:
Originally Posted by PeterK View Post
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.
deimos is offline  
Old 25 July 2018, 21:58   #33
PeterK
Registered User
 
Join Date: Apr 2005
Location: Hangover
Posts: 2,406
Should be 0.000001 or not?
PeterK is offline  
Old 25 July 2018, 21:58   #34
deimos
Registered User

 
Join Date: Jul 2018
Location: Londonish / UK
Posts: 111
No, I think it's correct, we're printing the cos ( + 0.000001), then the sin ( + 0.000001)

Quote:
Originally Posted by deimos View Post
Isn't it?

I might need a coffee.

I have two different results, either one is wrong, or they're both wrong.
deimos is offline  
Old 25 July 2018, 22:00   #35
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 45
Posts: 3,316
Quote:
Originally Posted by deimos View Post
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).


Quote:
Originally Posted by deimos View Post
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.


Quote:
Originally Posted by deimos View Post
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).



Quote:
Originally Posted by deimos View Post
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.


Quote:
Originally Posted by PeterK View Post
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).
meynaf is offline  
Old 25 July 2018, 22:01   #36
deimos
Registered User

 
Join Date: Jul 2018
Location: Londonish / UK
Posts: 111
Quote:
Originally Posted by PeterK View Post
Should be 0.000001 or not?
When copying by hand there was a typo. Yes:

1.570796: 0.000001, 1.000001
deimos is offline  
Old 25 July 2018, 22:01   #37
PeterK
Registered User
 
Join Date: Apr 2005
Location: Hangover
Posts: 2,406
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 is offline  
Old 25 July 2018, 22:15   #38
PeterK
Registered User
 
Join Date: Apr 2005
Location: Hangover
Posts: 2,406
Quote:
Originally Posted by meynaf View Post
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.
PeterK is offline  
Old 25 July 2018, 22:16   #39
deimos
Registered User

 
Join Date: Jul 2018
Location: Londonish / UK
Posts: 111
Quote:
Originally Posted by meynaf View Post
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 is offline  
Old 25 July 2018, 22:27   #40
deimos
Registered User

 
Join Date: Jul 2018
Location: Londonish / UK
Posts: 111
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.
deimos is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
vbcc 0.9f released phx News 49 01 April 2018 12:33
vbcc V0.9e released phx News 17 31 October 2016 22:18
VBCC and #include majikeyric Coders. C/C++ 3 03 March 2016 16:07
vbcc 0.9d phx News 43 13 July 2015 20:41
VBCC 0.8j for Windows hitchhikr Coders. General 11 09 October 2008 01:58

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 08:48.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2018, vBulletin Solutions Inc.
Page generated in 0.09186 seconds with 14 queries