Re: add/assign problem, part 2.

[David Mebane <david dot mebane at mse dot gatech dot edu>]

Thanks, both of you.

Regarding the point David made about my strange syntax, I also agree, and for me
it's just a matter of knowing I have to pass arrays by reference, but not
knowing about the better way to do this.  His point about std::vector is well
made and will be taken into account.

Andrew is also correct, however, in that this is not actually the issue in this
case.

Andrew, the output you're getting is not quite right -- the solver isn't going
through any iterations, because the variable _nres_ in LSMbdnew::iterate is zero
every time, since LSMbdnew::norm isn't working properly.  But I have tracked the
problem to the function bulkfunc::f.  If you notice, the function
bulkfunc::setparam doesn't actually set all the param's.  It misses one -- po2.
 When you get down into bulkfunc::f, then, you'll note that the second element
in the output array has a sqrt(po2) in the denominator.

Now, this obviously isn't any kind of compiler error (again, sorry), but so that
I can make it at least a little relevant to the list, does anyone know why the
value here was returned as zero (but obviously was something more along the
lines of nan)?  Is that a compiler issue?

Thanks,
-David


Quoting Andrew Haley <aph@gcc.gnu.org>:

> Andrew Haley writes:
>  > DCH writes:
>  >  >
>  >  > >  > I haven't actually compiled up your program, but immediately alarm
>  >  > >  > bells are ringing when I see things like
>  >  > >  >
>  >  > >  > a = *(vec + i)
>  >  > >
>  >  > >It's just a nonstandard way to write vec[i].  I mean, it's weird, but
>  >  > >it's not actually wrong.  :-)
>  >  >
>  >  > Sure.  The point I was making is that the variable i was being
>  >  > incremented up to a ceiling value
>  >  > which was determined by a function parameter, i.e. you're trusting
>  >  > whoever calls your function
>  >  > to get the value of this parameter correct.  Much safer to iterate
>  >  > with a vector:
>  >  >
>  >  > for (size_t i = 0, length = vec.size(); i < length; ++i) {
>  >  >          do something with vec[i];
>  >  > }
>  >
>  > Right, but that's a red herring here: the code in question doesn't
>  > seem to be getting that wrong.  I don't agree with your point in
>
> Ahem.  I don't diisagree.  :-)
>
>  > general, but it seems to be at best only tangentially related to the
>  > OP's problem.
>  >
>  > What we need from the OP is a description of the expected behaviour,
>  > and then we can discover whether this really is a compiler bug.
>  >
>  > Andrew.
>