C / C++ / MFC

When should printf round a floating number up for display?

30-Dec-12 5:34

I already answered this question here[^]. Please post in one forum only.

One of these days I'm going to think of a really clever signature.

Member 419459328-Dec-12 5:11

Re: When should printf round a floating number up for display?

28-Dec-12 5:11

Specifically this statement:

C++

printf("Chi square distribution for %s samples is %1.2f (%1.4f), and randomly\n",
   String_Value, chisq, chisq);

I re-implemented this program in MASM to speed it up and I get the following difference (note that I added the (%1.4f)) to display the pre-rounded number to see why I was getting differences:

C++

------------------------------------------------------------------ 17
Chi square distribution for 2048 samples is 6.13 (6.1250), and randomly
-------------------------------------------------------------- 17
Chi square distribution for 2048 samples is 6.12 (6.1250), and randomly

The question is, which one is correct according to the C spec? Should 6.1250 round up to 6.13 or should it take 6.1250+ to round up?

There are other questions such as the following:

C++

printf("of this %s %s file by %d (%2.2f) percent.\n\n", String_Value, samp,
   (short) (((100 * ((binary ? 1 : 8) - ent) / (binary ? 1.0 : 8.0)) + 0.5)),
            ((100 * ((binary ? 1 : 8) - ent) / (binary ? 1.0 : 8.0))));

The cast to a (short) seems to truncate a 5.7 to 5, I had to add the (.... + 0.5) just before the cast in order to get the rounded number. Again, I added the (%2.2f) to display the rounding differences.

Which is correct according to the C spec, rounding or truncation?

The program being re implemented is John Walker's ENT.

Dave.

Richard MacCutchan28-Dec-12 5:53

Re: When should printf round a floating number up for display?

28-Dec-12 5:53

I think the rules for rounding when a floating point's decimal part ends in 5 is, round up if the previous digit is even, and down if it's odd. So 6.125 rounds up to 6.13 but 6.115 would round down to 6.11; this is easy to check. In the second instance if you cast a float to an integer it discards the decimal part.

One of these days I'm going to think of a really clever signature.

Member 419459328-Dec-12 6:55

Re: When should printf round a floating number up for display?

28-Dec-12 6:55

Richard,

Very interesting. I pulled up my 8087 book "THE 8087 PRIMER", John F. Palmer and Steven P. Morse and looked up rounding. The nearest to what you described is the "round to nearest Even" mode, not the round to the nearest Odd as you described. Are you sure about this? Is it in some C spec?

If you are programming the FPU and want to cast a float to an integer, you just execute an FIST or FISTP, which will round to the specified rounding mode which is usually "round to nearest Even" unless you specifically set the mode to "round to 0" before you store the value.

Dave.

Richard MacCutchan28-Dec-12 7:01

Re: When should printf round a floating number up for display?

28-Dec-12 7:01

Well I did not have a reference to hand so it's just from what I recall during other development. However, you seem to have more up to date information than me.

One of these days I'm going to think of a really clever signature.

Member 419459328-Dec-12 7:08

Re: When should printf round a floating number up for display?

28-Dec-12 7:08

Richard,

I'm not trying to argue, just trying to find out what the spec says.

"THE 8087 PRIMER" is just a spec, from the Senior Staff Engineers at Intel Corp. explaining why they did what they did. How C uses the hardware should be specified somewhere.

Dave.

Richard MacCutchan28-Dec-12 7:18

Re: When should printf round a floating number up for display?

28-Dec-12 7:18

Member 4194593 wrote:
I'm not trying to argue

I did not mean to imply that you were; I am more than happy to have my assumptions corrected. As to what the C/C++ compiler should do in these cases, you could look at http://www.stroustrup.com/[^], or the Microsoft reference pages[^].

One of these days I'm going to think of a really clever signature.

Member 419459328-Dec-12 7:20

Re: When should printf round a floating number up for display?

28-Dec-12 7:20

Richard,

Thank you for the links. I'll report back with anything I find (if I can understand it).

Dave.

Member 419459328-Dec-12 8:20

Re: When should printf round a floating number up for display?

28-Dec-12 8:20

Richard,

I did find out that a float cast as a (short) is truncated, but not yet found out about rounding in printf.

Dave.

Member 419459328-Dec-12 8:58

Re: When should printf round a floating number up for display?

28-Dec-12 8:58

Richard,

I did find out only that the number will be rounded to the number of specified precision digits, but there is no mention of which rounding method is used! I did send feedback that I was dissatisfied with their answer.

Dave.

jschell28-Dec-12 9:45

jschell

28-Dec-12 9:45

Member 4194593 wrote:
The question is, which one is correct according to the C spec?

Depends on what you mean by "C spec".

Prior to C99 it was left up to the implementation how rounding occurred.

According to the following (but not verified by me) C99 specifies how rounding is done (search for C99)

http://linuxgazette.net/144/misc/lg/a_question_of_rounding_in_issue_143.html[^]

Re: When should printf round a floating number up for display?

Member 419459328-Dec-12 12:51

graphics.h multi-threading problem

28-Dec-12 12:51

jschell,

Thank you for the excellent link, at least it references a spec, namely IEEE.

Personally, I do not think it really makes any difference what the least significant digit is rounded to, but when you are converting a program and want to insure that the conversion is accurate, and the program has many options, the easiest approach is a batch file calling the two programs, supplying the different input files and options to be processed, and then using a file compare routine to compare the outputs for each test instance.

In the case of ENT compiled under Visual Studio 2008, I can see truncation, rounding to an even, and common rounding, all in one program. Makes it a bit difficult to "emulate" the original program.

I have examined all of the test output (the diffs) for all of the test instances, and all of my results match the ENT results except possibly for that last digit. At this point I am calling this a valid conversion, and a huge learning experience. At least my version is about 5 times as fast for huge files as ENT (16 GB - all DWORD values for a full 2^32 period) 6 min vs 28 min.

Dave.

yudhistira dewanata28-Dec-12 0:22

28-Dec-12 0:22

I'm not sure if i should put this question in this forum or the Graphics forum, as the description in graphics forum only says DirectX,OpenGL or GDI.

So I was trying this graphics.h library that can crate simple graphic for console app. Everything works just fine until I multithreaded? it.

Ok, here is the code:

#include<graphics.h>
void drawrect(int l,int t,int r,int d,int col){
  if(col==0)setcolor(RED);
  else setcolor(BLUE);
  rectangle(l,t,r,d);
}
void drawpiece(int l,int t,int r,int d,int col){
  for(int i=1;i<5;i++)
    drawrect(i*16+l,t,i*16+r,d,col);
}
DWORD WINAPI Thread2(void* lparam){
  int px2=161,py2=17;
  for(int i=0;i<10;i++,py2+=16,delay(100))
    drawpiece(px2,py2,px2+16,py2+14,1);
}
int main()
{   
    initwindow(600,600,"TEST");   
    CreateThread(0,0,&Thread2,NULL,0,0);
    int px1=17,py1=17;
    for(int i=0;i<10;i++,py1+=16,delay(100))
      drawpiece(px1,py1,px1+14,py1+14,0);    
    getch();
    return EXIT_SUCCESS;
}

What i'm trying to do is to make two set of blockline. where first set is red and second set is blue.
this code makes the color mixed up.
So that's it. Any help would be greatly appreciated.

Richard MacCutchan28-Dec-12 5:49

28-Dec-12 5:49

I have not checked your arithmetic, but it may be that the start points and limits of your rectangles are not correct.

One of these days I'm going to think of a really clever signature.

yudhistira dewanata28-Dec-12 16:23

28-Dec-12 16:23

I have checked the arithmetic and it works just fine if i don't multithread it.
This works just fine:

#include<graphics.h>
void drawrect(int l,int t,int r,int d,int col){
  if(col==0)setcolor(RED);
  else setcolor(BLUE);
  rectangle(l,t,r,d);
}
void drawpiece(int l,int t,int r,int d,int col){
  for(int i=1;i<5;i++)
    drawrect(i*16+l,t,i*16+r,d,col);
}
/*DWORD WINAPI Thread2(void* lparam){
  int px2=161,py2=17;
  for(int i=0;i<10;i++,py2+=16,delay(100))
    drawpiece(px2,py2,px2+16,py2+14,1);
}*/
int main()
{   
    initwindow(600,600,"TEST");   
 //   CreateThread(0,0,&Thread2,NULL,0,0);
    int px1=17,py1=17;
    for(int i=0;i<10;i++,py1+=16,delay(100))
      drawpiece(px1,py1,px1+14,py1+14,0);    

    int px2=161,py2=17;
    for(int i=0;i<10;i++,py2+=16,delay(100))
      drawpiece(px2,py2,px2+16,py2+14,1);

    getch();
    return EXIT_SUCCESS;
}

I'm really starting to think that this might be a problem from graphics.h

Richard MacCutchan28-Dec-12 23:07

28-Dec-12 23:07

It may well be a problem with the graphics library (not the header) which is rather old and was probably not designed with multi-threading in mind. I would suggest you switch to one of the more current graphics libraries available in the Windows API.

One of these days I'm going to think of a really clever signature.

yudhistira dewanata30-Dec-12 5:01

30-Dec-12 5:01

Yes that's what i thought. I've switched to SDL and it works.
Anyway, thanks for replying to my question. Really appreciate it.

Randor 29-Dec-12 8:25

Randor

29-Dec-12 8:25

Hi,

This is very basic computer science problem. Look at your code cafefully.

First read all about context switching[^] and once you completely understand look over your code again.

Now ask yourself what would happen if ThreadA context switches in the middle of drawrect() and ThreadB continues execution of drawrect().

Best Wishes,
-David Delaune

Richard MacCutchan29-Dec-12 21:28

29-Dec-12 21:28

David,
My reading of that is that it should, in theory, work. The variables used by each function are all stack variables and each thread has its own stack, so context switching should not affect it. I can only assume that there is some code in the actual library that is not thread safe.

One of these days I'm going to think of a really clever signature.

yudhistira dewanata30-Dec-12 5:30

30-Dec-12 5:30

David,
Thanks for the reply, I've read about context switching and now I have so many question going on my head.
First thing first, what actually happen when you multithread? Does the processor run two or more processes independently at the same time , or does it still need to switch between processes?
because if it does run the two separately then why would it need to switch context?

another one is if it does run the two separately, then i'm guessing the function drawrect() can't be used at the same time and thus needs to be switched between processes. by logic, will it work if i apply semaphores to it?

So there you go. Can you help me with this? or did i confuse you with my questions?