Problem to compile C code having Double floating variables.

[wahid]

Hello

I have a problem to compile my C program with VC6++. In my C program, most
of variables are double floating type. With Borland Turbo C++ (Version 3),
I use HUGE model size of code generation. By using this setting, the compiler
gives correct output of double floating variables in text file.

But when I compile the same C code with the VC6++, the compiler gives unpredictable
and inconsistent result of double floating. Can anyone tell me what’s wrong
with the setting of VC6++ compiler, or do I need to modify my C code? - Please
tell me.

Thanks

Wahid Daud

[ralph]

"wahid" <abd_wahid_daud@hotmail.com> wrote:
>
>Hello
>
>I have a problem to compile my C program with VC6++. In my C program, most
>of variables are double floating type. With Borland Turbo C++ (Version 3),
>I use HUGE model size of code generation. By using this setting, the compiler
>gives correct output of double floating variables in text file.
>
>But when I compile the same C code with the VC6++, the compiler gives unpredictable
>and inconsistent result of double floating. Can anyone tell me what’s wrong
>with the setting of VC6++ compiler, or do I need to modify my C code? -
Please
>tell me.
>
>Thanks
>
>Wahid Daud
>

Are you talking about "double" or "long double"?

Long Doubles are mapped to 'double' in VC++ (6/7) and therefore only the
'syntax' is supported. There are alternative math libraries available that
provide "huge" and long double classes. They are very accurate in terms of
the integer portion but will vary when compared in terms of their fractional
portion.

If you are just using "doubles" then check how you are writing and reading
the values. Format specifications can also vary. (How do you know the Borland
correct?)

Ultimately the "correctness" of an extremly small or large number is a product
of the CPU and its math coprocessor.

[wahid]

Hi Ralph,

Thanks for your reply. This is how I have declared my variables to double
in my C code.

#include<stdio.h>
#include<conio.h>
#include<math.h>
#include<string.h>
#include<stdlib.h>
#include<malloc.h>
#include"declare.h"

#define ROW 20
#define COL 80

int font;
Double max_chrlen, max_chrlen1, max_chrlen2, max_chrlen3, max_chrlen4;
double chrlenx1[COL], chrlenx2[COL], chrlenx3[COL], chrlenx4[COL], chrlenx5[COL];
double hf1, hf2, hf3, hf4, hf5, hf6, max_hf;
double nf1, nf2, nf3, nf4, nf5, nf6, max_nf;
double h1, h2, h3, h4, h5, h6, h7, Eh;
char strx1[ROW][COL], strx2[ROW][COL], strx3[ROW][COL], strx4[ROW][COL];
char *sp, *px1, fmt[30];


- This is my output compiled with Borland Turboc C++(version 3).

[ I ] W= 212.000, w1= 80.000
[ p ] W= 344.000, w1= 276.000
[ o ] W= 327.000, w1= 276.000
[ h ] W= 338.000, w1= 254.000


- This is my output compiled with VC6++.

[ I ] W= -185119262698635660000000000000000000000000000000000000000000000,
w1=-92559631349317831000000000000000000000000000000000000000000000
[ p ] W= -185119262698635660000000000000000000000000000000000000000000000,
w1=-92559631349317831000000000000000000000000000000000000000000000
[ o ] W= -185119262698635660000000000000000000000000000000000000000000000,
w1=-92559631349317831000000000000000000000000000000000000000000000
[ h ] W= -185119262698635660000000000000000000000000000000000000000000000,
w1=-92559631349317831000000000000000000000000000000000000000000000

You can see the output compiled with VC6++ has given suspicious result. In
this program, I used fprintf function to format the output. Do I need to
change variables declaration from double to float?

Thanks
Wahid Daud



"ralph" <nt_consulting32@hotmail.com> wrote:
>
>"wahid" <abd_wahid_daud@hotmail.com> wrote:
>>
>>Hello
>>
>>I have a problem to compile my C program with VC6++. In my C program, most
>>of variables are double floating type. With Borland Turbo C++ (Version
3),
>>I use HUGE model size of code generation. By using this setting, the compiler
>>gives correct output of double floating variables in text file.
>>
>>But when I compile the same C code with the VC6++, the compiler gives unpredictable
>>and inconsistent result of double floating. Can anyone tell me what’s wrong
>>with the setting of VC6++ compiler, or do I need to modify my C code? -
>Please
>>tell me.
>>
>>Thanks
>>
>>Wahid Daud
>>
>
>Are you talking about "double" or "long double"?
>
>Long Doubles are mapped to 'double' in VC++ (6/7) and therefore only the
>'syntax' is supported. There are alternative math libraries available that
>provide "huge" and long double classes. They are very accurate in terms
of
>the integer portion but will vary when compared in terms of their fractional
>portion.
>
>If you are just using "doubles" then check how you are writing and reading
>the values. Format specifications can also vary. (How do you know the Borland
>correct?)
>
>Ultimately the "correctness" of an extremly small or large number is a product
>of the CPU and its math coprocessor.

[ralph]

"wahid" <abd_wahid_daud@hotmail.com> wrote:
>
>Hi Ralph,
>
>Thanks for your reply. This is how I have declared my variables to double
>in my C code.
>
>#include<stdio.h>
>#include<conio.h>
>#include<math.h>
>#include<string.h>
>#include<stdlib.h>
>#include<malloc.h>
>#include"declare.h"
>
>#define ROW 20
>#define COL 80
>
>int font;
>Double max_chrlen, max_chrlen1, max_chrlen2, max_chrlen3, max_chrlen4;
>double chrlenx1[COL], chrlenx2[COL], chrlenx3[COL], chrlenx4[COL], chrlenx5[COL];
>double hf1, hf2, hf3, hf4, hf5, hf6, max_hf;
>double nf1, nf2, nf3, nf4, nf5, nf6, max_nf;
>double h1, h2, h3, h4, h5, h6, h7, Eh;
>char strx1[ROW][COL], strx2[ROW][COL], strx3[ROW][COL], strx4[ROW][COL];
>char *sp, *px1, fmt[30];
>
>
>- This is my output compiled with Borland Turboc C++(version 3).
>
>[ I ] W= 212.000, w1= 80.000
>[ p ] W= 344.000, w1= 276.000
>[ o ] W= 327.000, w1= 276.000
>[ h ] W= 338.000, w1= 254.000
>
>
>- This is my output compiled with VC6++.
>
>[ I ] W= -185119262698635660000000000000000000000000000000000000000000000,
>w1=-92559631349317831000000000000000000000000000000000000000000000
>[ p ] W= -185119262698635660000000000000000000000000000000000000000000000,
>w1=-92559631349317831000000000000000000000000000000000000000000000
>[ o ] W= -185119262698635660000000000000000000000000000000000000000000000,
>w1=-92559631349317831000000000000000000000000000000000000000000000
>[ h ] W= -185119262698635660000000000000000000000000000000000000000000000,
>w1=-92559631349317831000000000000000000000000000000000000000000000
>
>You can see the output compiled with VC6++ has given suspicious result.
In
>this program, I used fprintf function to format the output. Do I need to
>change variables declaration from double to float?
>
>Thanks
>Wahid Daud
>

That is some strange output.
Using fprintf() to display doubles you should use '%f' (You can also use
%g,%G,%e,%E, to get scientific formatting 'dddEnnn'). But you shouldn't have
to redefine to a float (4-byte).

I wouldn't think TC would be any different when it came to something as basic
as printf/fprintf. It is interesting that the numbers are identical, they
are extremely large, and appear to break down into multiple 4-byte addresses.
First reaction is that your type format is correct but whatever you are passing
is delivering addresses not floating point values. (What is actually 2 address
values are being interpreted as a double.)

Just for kicks you might change your format to %x or %P and see if the values
match your current stack or data storage.

In your original post you mentioned "HUGE model" which I took as some kind
of HUGE number class or library, but did you really mean "model" like in
small, medium, and large? In VC6 there are no separate memory models any
more - it is all 32-bit flat addresses. So, is it possible that in your port
you are using some kind of macros or special casting? We use to do some strange
things back in the days of segmented memory. Have you cranked up the Warning
level and really examined eveything it is reporting?

Sorry that is about all the help I can give. VC6 works with doubles. It has
to be something in your ported code.

-ralph

[Abd Wahid Daud]

"ralph" <nt_consulting32@hotmail.com> wrote:
>
>"wahid" <abd_wahid_daud@hotmail.com> wrote:
>>
>>Hi Ralph,
>>
>>Thanks for your reply. This is how I have declared my variables to double
>>in my C code.
>>
>>#include<stdio.h>
>>#include<conio.h>
>>#include<math.h>
>>#include<string.h>
>>#include<stdlib.h>
>>#include<malloc.h>
>>#include"declare.h"
>>
>>#define ROW 20
>>#define COL 80
>>
>>int font;
>>Double max_chrlen, max_chrlen1, max_chrlen2, max_chrlen3, max_chrlen4;
>>double chrlenx1[COL], chrlenx2[COL], chrlenx3[COL], chrlenx4[COL], chrlenx5[COL];
>>double hf1, hf2, hf3, hf4, hf5, hf6, max_hf;
>>double nf1, nf2, nf3, nf4, nf5, nf6, max_nf;
>>double h1, h2, h3, h4, h5, h6, h7, Eh;
>>char strx1[ROW][COL], strx2[ROW][COL], strx3[ROW][COL], strx4[ROW][COL];
>>char *sp, *px1, fmt[30];
>>
>>
>>- This is my output compiled with Borland Turboc C++(version 3).
>>
>>[ I ] W= 212.000, w1= 80.000
>>[ p ] W= 344.000, w1= 276.000
>>[ o ] W= 327.000, w1= 276.000
>>[ h ] W= 338.000, w1= 254.000
>>
>>
>>- This is my output compiled with VC6++.
>>
>>[ I ] W= -185119262698635660000000000000000000000000000000000000000000000,
>>w1=-92559631349317831000000000000000000000000000000000000000000000
>>[ p ] W= -185119262698635660000000000000000000000000000000000000000000000,
>>w1=-92559631349317831000000000000000000000000000000000000000000000
>>[ o ] W= -185119262698635660000000000000000000000000000000000000000000000,
>>w1=-92559631349317831000000000000000000000000000000000000000000000
>>[ h ] W= -185119262698635660000000000000000000000000000000000000000000000,
>>w1=-92559631349317831000000000000000000000000000000000000000000000
>>
>>You can see the output compiled with VC6++ has given suspicious result.
>In
>>this program, I used fprintf function to format the output. Do I need to
>>change variables declaration from double to float?
>>
>>Thanks
>>Wahid Daud
>>
>
>That is some strange output.
>Using fprintf() to display doubles you should use '%f' (You can also use
>%g,%G,%e,%E, to get scientific formatting 'dddEnnn'). But you shouldn't
have
>to redefine to a float (4-byte).
>
>I wouldn't think TC would be any different when it came to something as
basic
>as printf/fprintf. It is interesting that the numbers are identical, they
>are extremely large, and appear to break down into multiple 4-byte addresses.
>First reaction is that your type format is correct but whatever you are
passing
>is delivering addresses not floating point values. (What is actually 2 address
>values are being interpreted as a double.)
>
>Just for kicks you might change your format to %x or %P and see if the values
>match your current stack or data storage.
>
>In your original post you mentioned "HUGE model" which I took as some kind
>of HUGE number class or library, but did you really mean "model" like in
>small, medium, and large? In VC6 there are no separate memory models any
>more - it is all 32-bit flat addresses. So, is it possible that in your
port
>you are using some kind of macros or special casting? We use to do some
strange
>things back in the days of segmented memory. Have you cranked up the Warning
>level and really examined eveything it is reporting?
>
>Sorry that is about all the help I can give. VC6 works with doubles. It
has
>to be something in your ported code.
>
>-ralph
>

Hello,

Q1: In your original post you mentioned "HUGE model" which I took as some
kind of HUGE number class or library, but did you really mean "model" like
in small, medium, and large?
Answer:
Exactly, in my program I used Huge model. I have tried using other available
memory model size such as Medium and Large in Borland Turbo C, but this would
give the same result as VC6.

Q2: So, is it possible that in your port you are using some kind of macros
or special casting?
Answer:
I’m not using any macros in my program. I’m not so sure about ‘special casting’,
but I hope it is not in my program, because I have no idea how write or to
use it.

Q3: Have you cranked up the Warning level and really examined everything
it is reporting?
Answer:
VC6 has given no error and warning.

Wahid Daud

[ralph]

"Abd Wahid Daud" <abd_wahid_daud@hotmail.com> wrote:
>
> ... snipped
>
>Hello,
>
>Q1: In your original post you mentioned "HUGE model" which I took as some
>kind of HUGE number class or library, but did you really mean "model" like
>in small, medium, and large?
>Answer:
>Exactly, in my program I used Huge model. I have tried using other available
>memory model size such as Medium and Large in Borland Turbo C, but this
would
>give the same result as VC6.
>

That is an interesting clue - and this is likely where the problem lies.

A 'C' program using the standard libraries and native types (fprintf, double,
etc.) will not differ appreciably between memory models, 16-bit/32-bit, Unix/Windows,
VC/Borland/gcc/cc/Metaware, etc. - especially with 'doubles' in the range
you showed on your previous post. That means that even in 16-bit a particular
routine should compile and run the same independent of any "memory model".

My seqmented architecture knowledge is a little shaky - it has been awhile,
but the only real difference between the models was the number of allowed
data and text(code) segments and whether pointers are interpreted as 'near'
(within a segment) or 'far' (in another seqment). The 'huge' model (afaik)
only added the ability to create data structures larger than 64k (They could
cross seqmented boundries).

Only the size of an application and the size of data structures and stacks
would be effected by a "memory model". It would have no effect on precision
or scale of a numeric type and I can't imagine how it would affect fprintf().
(I can see one array laying across a boundry but "all of them"?) In any case
that would be a mute problem when recompiled in 32-bit space.

The fact that your routine won't compile/run in any other memory model leads
me to believe there is definately something wrong with the logic of your
original TC code. You were just "lucky" when HUGE worked and the others didn't.
Isolate one or more of your routines and massage them until you can get it
to run in all models equally and you will have solved your problem.

Or, of course, the better option is to forget the past and just modify your
ported code.

-ralph

[Danny Kalev]

ralph wrote:
>
> "Abd Wahid Daud" <abd_wahid_daud@hotmail.com> wrote:
> >
> > ... snipped
> >
> >Hello,
> >
> >Q1: In your original post you mentioned "HUGE model" which I took as some
> >kind of HUGE number class or library, but did you really mean "model" like
> >in small, medium, and large?
> >Answer:
> >Exactly, in my program I used Huge model. I have tried using other available
> >memory model size such as Medium and Large in Borland Turbo C, but this
> would
> >give the same result as VC6.
> >
>
> That is an interesting clue - and this is likely where the problem lies.
>
> A 'C' program using the standard libraries and native types (fprintf, double,
> etc.) will not differ appreciably between memory models, 16-bit/32-bit, Unix/Windows,
> VC/Borland/gcc/cc/Metaware, etc. - especially with 'doubles' in the range
> you showed on your previous post. That means that even in 16-bit a particular
> routine should compile and run the same independent of any "memory model".
>
> My seqmented architecture knowledge is a little shaky - it has been awhile,
> but the only real difference between the models was the number of allowed
> data and text(code) segments and whether pointers are interpreted as 'near'
> (within a segment) or 'far' (in another seqment). The 'huge' model (afaik)
> only added the ability to create data structures larger than 64k (They could
> cross seqmented boundries).
>
> Only the size of an application and the size of data structures and stacks
> would be effected by a "memory model". It would have no effect on precision
> or scale of a numeric type and I can't imagine how it would affect fprintf().
> (I can see one array laying across a boundry but "all of them"?) In any case
> that would be a mute problem when recompiled in 32-bit space.
>
> The fact that your routine won't compile/run in any other memory model leads
> me to believe there is definately something wrong with the logic of your
> original TC code. You were just "lucky" when HUGE worked and the others didn't.
> Isolate one or more of your routines and massage them until you can get it
> to run in all models equally and you will have solved your problem.
>
> Or, of course, the better option is to forget the past and just modify your
> ported code.

Looks like we've been shooting in the dark. Can't you (the original
poster, that is) post some excerpts of your original code? I'm talking
about the definitions of the routines. Also, I suggest that you look for
macro wizardry behind your back. It may well be the case that the
innocent looking fptintf() routines are in fact macros in disguise that
do much more than you think they do. This is a common trick/hack legacy
C code. Finally, check for hardware specific hacks such as XORing CPU
registers, register variables and so on.

Danny