Am 15.09.2018 um 22:48 schrieb Bald Eagle:
> Liebchen,
> Any mistakes in here are presumably part of the problem.

By "in here", do you mean the scene you posted earlier, or this post I'm
replying to? In the former case I think that's not true, and in the
latter case it doesn't help much because it's not a complete scene, just
a vague description.

> 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.

Let's be more precise: You run a `#for` loop - the one with the variable
named `Theta` - from 0 to (at most) 1 in steps of 0.001.

> My _Y function returns a multiple of that value.
>      [The obvious, sane, "normal" mathematical result of this is 0*N = 0]

More precisely, it returns a multiple of that value, unless the result
would be less than 0 in which case it returns 0, or unless the result
would be larger than the multiplication factor in which case it returns
the multiplication factor.

> That value gets passed to one macro,

That's the macro `PatchUV` we are talking about here and the factor is
`Usize`, which should be an integer as it is the result of a
`round()+1`. Apparently its value is 7.

> which needs the results of the second macro to continue.

That's the `ThisPatch` macro, right?
From what I can see, the parameters of `PatchUV` are passed as-is to
`ThisPatch`.

> 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.

The loop your're talking about here is the `#for (U, 0, ...)` loop in
`ThisPatch`, right? And the array in question is `UArray`, and the
element in question is `UArray[U]`. With U=0 it starts at `UArray[0]`
which, according to my observation, seems to have the value
<0,0,1.047something>.

> So it LOOKS to me that I have YVal=0, U=0, UArray[U]=<0,0,1.047>,

Conformed, except that the z component of UArray[U] has more decimals.
`1.0471975511965976` (and then zeros) is what I get when debugging it at
high precision.

> but the test condition fails.

And that one I can absolutely positively *NOT* confirm. Are you just
inferring that from other symptoms, or have you actually double-checked
it, and placed e.g. a `#debug "Inside!\n"` smack inside the `#if`, so
that it reads

    #for (U, 0, Usize)
        #debug concat ("Testing Y = ", Scalar (YVal, 3, 0), " vs ",
Vector (UArray [U], 20, 0), " \n")
        #if ( int(YVal*Mult) >= int(UArray [U].y*Mult) & int(YVal*Mult)
<= int(UArray [U].z*Mult) )
        #debug "Inside!\n"
        ...

Because I did, and saw the debug statement get hit nice and square for
U=0 (and only U=0), as I would totally expect from the code.

Try this please. If you also do get an "Inside!" for U=0, then you've
been hunting a ghost. If you do /not/ get an "Inside!" for U=0, then
we're instead hunting a rare gremlin native to your type of machine.


(Well, to be honest I actually tested with "Got Here!\n" instad of
"Inside!\n", but I /think/ that shouldn't make much of a difference...)


> 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.

I totally agree, this is so WTF that my current hypothesis is still that
you're not seeing what you think you're seeing.


> 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]

There /is/ still room for the diabolic floating point math hypothesis:
If you're running on Linux, then you're probably running a version
compiled with -ffast-math, which extends the nine levels of floating
point hell by a tenth level, which may have /some/ impact at /some/
point. That tenth level is a domain of sloppines for the sake of speed,
a kind of "sod all safety and environmental protection regulations, we
got a deadline to meet" mode.

Also, floating-point math has two values for zero, which may play a
role: The regular "positive" zero (the one you get when you specify `0`
as the start value in a `#for` loop, for instance), and the special
"negative" zero (the one you get as a result of... well, some special
cases of some particular mathematical operations). Normally they should
compare equal, but in -ffast-math mode I wouldn't trust that assumption.

And still, before I follow that train of thought, I want to make
absolutely, perfectly sure that what you think you're seeing is indeed
happening, and we're totally not just hunting some ghost. Because a walk
on the tenth level of floating point hell - and possibly even remotely,
because I may be unable to reproduce it here - probably wouldn't be a
walk in the park, and before I embark on such a time- and
energy-consuming journey I want to be totally sure that it's not just a
fever dream.


> 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.

Nope, not yet. Just wild speculations at this point.

Post a reply to this message