problem with output of the program on different OS

P

pereges

But not all.

Yes, but this is what we want.
That particular function is meant to determine the closest
polygon(triangle in this case) in a mesh that the ray hits. In some
cases the ray won't hit any triangle in the mesh which means that
res.hit will remain false.
 
P

pereges

One thing I thought of doing is to get rid of static variables all
together. With dynamic variables, you can free the memory as and when
you want.
 
R

Richard

Richard Heathfield said:
pereges said:


Debuggers are over-rated by some people, and can be a huge time sink if
used flailingly.

What total and utter nonsense. When one needs a debugger they are
exceptionally useful. This constant downer you put on debuggers is more
down to your own incompetence at using one. I have never, ever had a
case where using one has cost me time or effort. At the very worst case
it can run in the bg and not actually track anything BUT still be able
to give an IMMEDIATE stack trace in the case of an exception of some
kind.
 
P

pereges

Can we test this code at all?

What input should be given?

What output should there be?

The program can compile and run. Just make one change in test.c:

object o, *obj; // line 27 in the code

obj = &o;

i = reader(o);
.....
.....


The input to the program is the sphere.zeus file. However, that is
taken care of. The program also asks user to enter certain things :

"Enter the frequency"

Enter 40e+7 for eg. (Any number of the order 10^7 will do)

"Enter the amplitude of electrical field"

Enter 10e-4 for eg. (Any number of the order 10e-4 will do)

"Enter the number of rays"

Enter 1000 for eg. (Any number > 1000 will work, however the program
will be very slow for huge values like 1,000,000. On my pc, it gives
an error message "malloc has failed!: Insufficient memory"
for value 10,000,000)
 
B

Bart

On May 9, 5:33 pm, Bart <[email protected]> wrote:
The program can compile and run. Just make one change in test.c:

object o, *obj; // line 27 in the code

obj = &o;

i = reader(o);

Didn't like this. I used reader(&obj); (reader takes **object).
The input to the program is the sphere.zeus file. However, that is
taken care of. The program also asks user to enter certain things :

"Enter the frequency"

Enter 40e+7 for eg. (Any number of the order 10^7 will do)

"Enter the amplitude of electrical field"

Enter 10e-4 for eg. (Any number of the order 10e-4 will do)

"Enter the number of rays"

Enter 1000 for eg.  (Any number > 1000 will work, however the program
will be very slow for huge values like 1,000,000. On my pc, it gives
an error message "malloc has failed!: Insufficient memory"
for value 10,000,000)

OK, but what should the output be?

With inputs of 40000000, 0.0001 and 1100, I got:

Es: 2.979907e-012 Ei: inf RCS: 0.000000e+000

But then, I'm running on Windows and you say the problem is with
Linux..
 
P

pereges

On May 9, 2:33 pm, pereges <[email protected]> wrote:
Didn't like this. I used reader(&obj); (reader takes **object).


I'm sorry, you are correct.

OK, but what should the output be?

With inputs of 40000000, 0.0001 and 1100, I got:

Es: 2.979907e-012 Ei: inf RCS: 0.000000e+000

But then, I'm running on Windows and you say the problem is with
Linux..


I will have to check up some scientific literature to determine what
the *exact* and expected output should be. But I can definetely tell
something is wrong because I'm getting the following output on windows
for the same input that you have taken:

Es: 4.431255e-10 Ei: 1.226668e-04 RCS: 4.539517e+01

There is definetely something wrong and its quite likely that these
are all garbage values
 
B

Ben Bacarisse

pereges said:
Can you please tell me about a good debugger ? Is there some
preliminary stuff I should read about debugging in C prior to using a
debugger ?

The fantastic tool "valgrind" reports that the printf on line 45 is
done using uninitialised values. That does seem to be the case.

The E_scattered member of radar has only its imaginary part set in the
initialise function. The value is then updated using both parts.

Valgrind reports other problems, but start with that one.

A few remarks...

You are happy to use C99features but you don't use C99's complex
numbers.

You should re-think when you pass pointers and when you pass
structures by copying. For example, reader is passed an object ** but
it always uses only *obj as a value (it never assigns to *obj which is
why one might sometimes use a double pointer). In other cases, the
whole object structure is copied where I'd expect to see a const
object * parameter for reasons of speed.
 
B

Bart

I'm sorry, you are correct.





I will have to check up some scientific literature to determine what
the *exact*  and expected output should be. But I can definetely tell
something is wrong because I'm getting the following output on windows
for the same input that you have taken:

Es: 4.431255e-10 Ei: 1.226668e-04 RCS: 4.539517e+01

There is definetely something wrong and its quite likely that these
are all garbage values

Yes, you do have a problem. With lccwin, it gave the results I posted.
On gcc, it gave INF,INF and IND. With DMC it crashed, possibily with
pointer dereferencing (but could not pinpoint where; with debug on it
was somewhere in the runtime).

For ease of testing, I combined all modules into a single module, and
hard-coded those 3 inputs. Next (although I don't have time now) would
be output statements to pinpoint that crash, which hopefully is not
unconnected with the main problem.

It doesn't matter now what the exact results should be; get them
consistent first.
 
B

Bart

I'm sorry, you are correct.





I will have to check up some scientific literature to determine what
the *exact*  and expected output should be. But I can definetely tell
something is wrong because I'm getting the following output on windows
for the same input that you have taken:

Es: 4.431255e-10 Ei: 1.226668e-04 RCS: 4.539517e+01

There is definetely something wrong and its quite likely that these
are all garbage values

Something went amiss with my last post -- it'll turn up half-finished
soon.

Anyway in find_closest_intersection(), index is not set and makes
res.tindex have funny values in raytrace(), causing array bounds
overflow. But setting this to 0 just gave more errors a bit later on.
Whether this is relevant to your main problem, I don't know, but it
should be fixed.

Hope this helps.
 
P

pereges

Anyway in find_closest_intersection(), index is not set and makes
res.tindex have funny values in raytrace(), causing array bounds
overflow. But setting this to 0 just gave more errors a bit later on.
Whether this is relevant to your main problem, I don't know, but it
should be fixed.


Well, index is set to i.


if(res->t < closestdistance)
{

closestdistance = res->t;
uresult = res->u;
vresult = res->v;
index = i;
}
 
P

pereges

Anyway in find_closest_intersection(), index is not set and makes
res.tindex have funny values in raytrace(), causing array bounds
overflow. But setting this to 0 just gave more errors a bit later on.
Whether this is relevant to your main problem, I don't know, but it
should be fixed.


btw i just checked up and all the res.tindex values are in between 0
to 1199 which is valid as there are 1200 triangles in the mesh which
you can verify in the sphere.zeus fiel or simply printing the value
o.ntri (number of triangles). The number of vertices is 601
 
B

Bart

I'm sorry, you are correct.





I will have to check up some scientific literature to determine what
the *exact*  and expected output should be. But I can definetely tell
something is wrong because I'm getting the following output on windows
for the same input that you have taken:

Es: 4.431255e-10 Ei: 1.226668e-04 RCS: 4.539517e+01

There is definetely something wrong and its quite likely that these
are all garbage values

[replying to this message as google not showing your other post]

You're right; find_closest...() was a red herring, I was using a too-
small number of rays.

The crash with DMC was the free(&obj)in main() (&obj doesn't point to
allocated storage).

The discrepancies, well look at these two lines in initialize_radar():

real(radar->E_incident) = 0;
imag(radar->E_scattered) = 0;

Initialise also the other halves of .E_incident and .E_scattered.

Now lccwin, gcc and dmc all give the same results.

Whether they are right or not, I've no idea.
 
P

pereges

On May 9, 3:11 pm, pereges <[email protected]> wrote:
Initialise also the other halves of .E_incident and .E_scattered.

Now lccwin, gcc and dmc all give the same results.

Whether they are right or not, I've no idea.

Thank you very much for pointing out this major flaw.

The output that I'm getting is the same as before(don't know why).
keep in mind that the output i posted earlier was for 1100 rays since
you had taken the same input.

Here's my input:

frequency: 40e+7
amplitude of electrical field: 10e-4
numberofrays: 1000

Output:
Es: 7.085529e-11 Ei: 7.957116e-05 RCS: 1.118991e+01

Can you please check the values.
 
B

Bart

Thank you very much for pointing out this major flaw.

The output that I'm getting is the same as before(don't know why).
keep in mind that the output i posted earlier was for 1100 rays since
you had taken the same input.

Here's my input:

frequency: 40e+7
amplitude of electrical field: 10e-4
numberofrays: 1000

Output:
Es: 7.085529e-11 Ei: 7.957116e-05 RCS: 1.118991e+01

Can you  please check the values.

This is what I get, taken directly off the screen. Run with the exact
same values:

Enter the frequency of the electromagnetic rays to be fired
40e7
Enter the amplitude of electric field
10e-4
Enter the number of electromagnetic rays to be fired
1000
Es: 7.391785e-011 Ei: 1.112194e-004 RCS: 8.351773e+000

(Note the first two figures are 400,000,000 and 0.001, not 40,000,000
and 0.0001 as I'd used earlier.)

Your original problem was I think inconsistency across OSs, possibly
now it's just logical error. And I don't think many here know whether
these numbers are good or not!
 
P

pereges

This is what I get, taken directly off the screen. Run with the exact
same values:

Enter the frequency of the electromagnetic rays to be fired
40e7
Enter the amplitude of electric field
10e-4
Enter the number of electromagnetic rays to be fired
1000
Es: 7.391785e-011 Ei: 1.112194e-004 RCS: 8.351773e+000

(Note the first two figures are 400,000,000 and 0.001, not 40,000,000
and 0.0001 as I'd used earlier.)

Your original problem was I think inconsistency across OSs, possibly
now it's just logical error. And I don't think many here know whether
these numbers are good or not!

Strange. The values that you are getting are very different from the
ones that Im getting. Another problem I noticed is that I'm getting
the same value I was getting previously (on windows, compiling with
pellesC) even though you had pointed out a major flaw.
 
B

Bart

Strange. The values that you are getting are very different from the
ones that Im getting. Another problem I noticed is that I'm getting
the same value I was getting previously (on windows, compiling with
pellesC) even though you had pointed out a major flaw.- Hide quoted text -

Out of 4 Windows C compilers:

lccwin32, gcc, dmc all give: 7.39, 1.11, 8.35 (ignoring exponents)

Pelles C gives: 7.08, 7.95, 1.11 same as you.

Time to suspect Pelles C I think! What are the results on linux?

If you can get at least one more compiler that gives my figures, it's
then easy to print out radar.E_scattered say and see where they
diverge.

But it's also possible there's a bug in Pelles C.
 
P

pereges

Out of 4 Windows C compilers:

lccwin32, gcc, dmc all give: 7.39, 1.11, 8.35 (ignoring exponents)

Pelles C gives: 7.08, 7.95, 1.11 same as you.

Time to suspect Pelles C I think! What are the results on linux?


Well I can't access the linux machine right now but I will post the
details as soon as i can.

If you can get at least one more compiler that gives my figures, it's
then easy to print out radar.E_scattered say and see where they
diverge.

But it's also possible there's a bug in Pelles C.

god i never thought about that possibility.

I haven't tried out the program with Turbo C ( or TC++) compiler but I
believe it will be difficult to execute the program because dos has
severe memory limitations ?
 
P

pereges

I promised a reply to this, and here it is.

Thank you very much for the help. It has given me a lot of insight on
C programming in general.
Okay, so let's look at the code. You should of course read other people's
replies too, because I'm bound to miss something.

I indented the code to my own taste. It had tabs in, and they had to go,
because Usenet hates tabs. Line numbers refer to /my/ version of the code,
which was the result of indenting the original with these settings:

I understand. What text editors do you personally prefer while working
on linux ? What about vi ?On windows machine, I use Qeditor

The first problem I found was that the project wouldn't compile. That
probably means that you are using C99isms - not wrong, but inconvenient
for those few remaining millions that don't have a C99 compiler. To get
your code to compile, I must either disable C90 conformance in my compiler
or hack the code. Since I don't plan on disabling conformance,
code-hackery happened at this end.

Rule 1 is of course to fix the first diagnostic message first. Now, in this
case, the first few messages were:

raytrace.c: In function `find_closest_intersection':
raytrace.c:29: warning: `index' might be used uninitialized in this
function
raytrace.c: In function `raytrace':
raytrace.c:67: warning: unused variable `i'

The first of these looks dire, but it may well be that obj->ntri is always
greater than 0.

Yes obj->ntri >= 0


At this stage, however, I don't know that. And it would
not hurt to initialise index to -1 at this stage. If it remains -1 after
the loop, the original program was clearly assuming that the loop was
always setting this value, and therefore was broken, so I'm going to
assert that it's not -1... in fact, I'm going to assert that it's
non-negative (because it's set to i, which runs from 0 upwards). This
involves adding <assert.h> to the include list, and changing

int index, i;

to

int index = -1, i;

and adding

assert(index >= 0);

just after the for-loop and just before res->t = closestdistance;

I think this is not the problem. It is possible that index will be -1
for many rays and its perfectly normal. The index value is just there
to indicate which triangle the ray has hit. It is possible that the
ray does not hit any triangle. I have a member in the intersectresult
data structure called 'hit'. If the ray does not hit any triangle,
then hit will remain FALSE. index will probably contain some garbage
value. But that's irrelevant since in the raytrace function we are
looking for only those cases where res.hit == TRUE.
Second fix to this file: in the raytrace() function, i is unused, so I
removed it.

Do you think its dangerous to have such declarations in bigger
projects ?


Well, I had to dig through three layers of #include before finding an
include for math.h. Not funny. Still, it's there somewhere.

My idea was to have such declarations at one place. Hence, I included
it in common.h.


The other stuff? Well, not your fault - you're using valid C99 syntax - but
my compiler doesn't support it so I'm going to rewrite it into a syntax
that is supported by your compiler and mine. I will take the opportunity
to point out some assumptions that your code is making by asserting that
they are true. I've also re-written your malloc in canonical style:

*pointinarray = malloc(*numpoints * sizeof **pointinarray);

In general, for any object pointer p, you can point it at the memory for N
objects of that type by calling malloc like this:

p = malloc(N * sizeof *p);

Note the leading * on the rightmost p.

Plugging in: for N, you want *numpoints, right? So:

p = malloc(*numpoints * sizeof *p);

For p, you want *pointinarray. Watch carefully, counting stars:

*pointinarray = malloc(*numpoints * sizeof **pointinarray);

And that's it. This form survives a type change without modification
(except, of course, a type change to void *).

I am very suspicious about these lines:

for(yi = 0; yi <= numpointsy; ++yi)
{
for(xi = 0; xi <= numpointsx; ++xi)

How SURE are you that those <= are correct? It's very likely that they
should be < rather than <= but you as the code's author will be able to
work out whether this is an error far more quickly than I can.

My revision of your gen_grid_points function (which requires you to add an
include for the <assert.h> header) looks like this:

int gen_grid_points(vector ** pointinarray,
unsigned long int *numpoints,
double xmax,
double xmin,
double ymax,
double ymin,
double zdist)
{
unsigned long int numpointsx;
unsigned long int numpointsy;
unsigned long int i = 0;
double xlength = xmax - xmin;
double ylength = ymax - ymin;
double xsize;
double ysize;
unsigned long int xi, yi;

assert(pointinarray != NULL);

assert(numpoints != NULL);
assert(*numpoints >= 0);

assert(xmax >= xmin);
assert(ymax >= ymin);

numpointsx = sqrt(*numpoints);
numpointsy = sqrt(*numpoints);

assert(numpointsx > 1);
assert(numpointsy > 1);

xsize = xlength / (numpointsx - 1);
ysize = ylength / (numpointsy - 1);

*numpoints = (numpointsx + 1) * (numpointsy + 1);

*pointinarray = malloc(*numpoints * sizeof **pointinarray);

if(*pointinarray == NULL)
{
perror("malloc has failed");
return FAILURE;
}

/* Generating the points on the grid, points to be used as ray origin */
for(yi = 0; yi <= numpointsy; ++yi)
{
for(xi = 0; xi <= numpointsx; ++xi)
{
(*pointinarray + i)->x = xmin + xi * xsize;
(*pointinarray + i)->y = ymin + yi * ysize;
(*pointinarray + i)->z = zdist;
++i;
}
}

return SUCCESS;

}

I recommend that you plug this version in, and re-test. Do any of the
assertions fail? If so, that may well be your problem.

Yes, there is some problem while compiling radar.c.

The problem is with the assert(*numpoints >= 0) statement on line
number 32 of radar.c as reported by pellesC compiler:

Building radar.obj.
C:\Documents and Settings\abc\Desktop\raytrace\raytrace\radar.c(32):
warning #2130: Result of unsigned comparison is constant.
C:\Documents and Settings\abc\Desktop\raytrace\raytrace\radar.c(32):
fatal error: Internal error: 'Access violation' at 0x004083f3.


I tried to comment that line and then compiled and executed the code.
I get the same output as before for the following input:

frequency: 40e+7
amplitude: 10e-4
numberofrays: 1000

The output is:
Es: 7.085529e-11 Ei: 7.957116e-05 RCS: 1.118991e+01

BartC has obtained similar results using the PellesC compiler but he
is getting different result when using dmc, lccwin, gcc on
windows( all the three results using dmc, lccwin, gcc are same though
for the above input). Can you please tell me what result you have
obtained on your linux machine ? Are the results consistent everytime
the program is executed ?
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,904
Latest member
HealthyVisionsCBDPrice

Latest Threads

Top