I
Ian Collins
But not all.pereges said:You can check that by inserting a small printf statement. TThe inner
if is satisfied in quite a few cases.
But not all.pereges said:You can check that by inserting a small printf statement. TThe inner
if is satisfied in quite a few cases.
But not all.
Richard Heathfield said:pereges said:
Debuggers are over-rated by some people, and can be a huge time sink if
used flailingly.
Can we test this code at all?
What input should be given?
What output should there be?
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);
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)
On May 9, 2:33 pm, pereges <[email protected]> wrote:
Didn't like this. I used reader(&obj); (reader takes **object).
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..
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 ?
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
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
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.
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.
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
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.
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.- 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.
I promised a reply to this, and here it is.
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:
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.
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;
Second fix to this file: in the raytrace() function, i is unused, so I
removed it.
Well, I had to dig through three layers of #include before finding an
include for math.h. Not funny. Still, it's there somewhere.
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.
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.