Liebchen,
Any mistakes in here are presumably part of the problem.

clipka <ano### [at] anonymousorg> wrote:

> So, if I understand your earlier posts correctly, the following statement:
>
>     #if ( int(YVal*Mult) >= int(UArray [U].y*Mult) &
>           int(YVal*Mult) <= int(UArray [U].z*Mult) )
>
> fails to work correctly, because [something in there] has the wrong
> value and somehow 0 doesn't seem to compare equal to 0, right?
>
> Well, I don't see that. I do see the statement properly kicking in at
> YVal=0, U=0, UArray[U]=<0,0,1.047>.

Well, here's the rub.
I run a loop from 0 to 1.
My _Y function returns a multiple of that value.
     [The obvious, sane, "normal" mathematical result of this is 0*N = 0]
That value gets passed to one macro,
which needs the results of the second macro to continue.
The second macro takes what is presumably STILL zero, and looks, for all intents
and purposes, based on my debug output, to actually be zero, and compares that
value to a looped series of array elements - starting at ... zero.

So it LOOKS to me that I have YVal=0, U=0, UArray[U]=<0,0,1.047>, but the test
condition fails.  When I force those things to have those values -right after
the macro starts and just before the comparison by using #local YVal = 0; etc,
then the test succeeds.

I reiterate my response.   W    T    F.

So I'm still stuck with, or stuck thinking, that the problem is with one of
those three values not being what it appears (and perhaps erroneously
assuming/presuming that's a result of the diabolicalities of floating point
math[s]) [FPM]

The sizes of the arrays (spurious cruft) seem[ed] to me to be irrelevant, in the
immediate case since even if I used array [2], it should still function fine
with U=0, since the test that should trigger an exit from the macro is when U=0,
and so truly, even a single element array ought to work. And so I logically
looked to the arguments of the comparison (FPM) and the progenitors of those
arguments.

So it still appears to me, for all practical purposes, that my original concern
still stands.  Perhaps as a more educated, experienced, and professional
programmer, you have ideas about what the actual problem might be**, how it
arises, and how I can detect and avoid it in the future.

Or someone can jump in, confirm that they're seeing the same behaviour, and
discover what I broke and how, and explain how they went about discovering it.


> > All that other stuff that you're looking at is just spurious cruft thrown in to
> > see WTF was going on, and will hopefully be fixed.
>
> This would be a lot easier if the scene was something you could point at
> and say, "Any mistakes in here are presumably part of the problem".
> Spurious cruft just distracts any reader other than you[*] from what's
> really going on, especially if it contains errors in itself.
>
> [*Or maybe including you; maybe you've accidently fixed the original
> problem by now already, and are being distracted from this factoid by a
> similar - or even totally unrelated - symptom caused by the spurious
> cruft. Been there, done that.]


Any mistakes in here are presumably part of the problem.


** "You program worse than you did in 1980 on a TRS-80 or Commodore VIC-20,
Bill, and you should really endeavor to learn how to write code that doesn't
SUCK."

So noted.  But I still SUCK, and I'm still STUCK.

Post a reply to this message