|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
> Am 14.09.2018 um 21:55 schrieb clipka:
>
> > Which is not surprising, since you have
> >
> > #for (U, 0, Usize)
> >
> > while the array is only Usize elements long, from 0 to Usize-1.
>
> Sorry, that's an imprecise observation; the array is Usize+1 elements
> long, so it has space for elements from 0 to Usize. But you're only
> initializing elements from 0 to UU, with UU = Usize-1, so element Usize
> remains uninitialized.
While that's the error that POV-Ray reports, it's only symptomatic of the
initial failure to catch Yvalue = 0, and return a valid array element
identifier.
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.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 14-9-2018 17:15, Bald Eagle wrote:
> Thomas de Groot <tho### [at] degrootorg> wrote:
>> On 14-9-2018 1:30, Bald Eagle wrote:
>>> I may need something ... stronger than coffee, gin, bourbon, and Stephen's
>>> proprietary family-secret Dried Frog Pills (TM) (R) (c)
>>>
>>
>> Be careful about those pills, especially in combination with fire water.
>> Stephen certainly warned you about it (or he should have). They got me
>> in the padded cell.
>>
>> --
>> Thomas
>
> Lightweight. :P
>
> Next thing, you'll be telling me that the hookah he and I have been building to
> smoke some imported dried Conraua goliath is ... "ill advised".
>
> Now, be a good lad and fetch me a Winchester bottle of ether.
>
>
I'll get you a Klein bottle of POV-Ray distillate instead.
--
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 15/09/2018 à 08:47, Thomas de Groot a écrit :
> On 14-9-2018 17:15, Bald Eagle wrote:
>> Thomas de Groot <tho### [at] degrootorg> wrote:
>>> On 14-9-2018 1:30, Bald Eagle wrote:
>>>> I may need something ... stronger than coffee, gin, bourbon, and
>>>> Stephen's
>>>> proprietary family-secret Dried Frog Pills (TM) (R) (c)
>>>>
>>>
>>> Be careful about those pills, especially in combination with fire water.
>>> Stephen certainly warned you about it (or he should have). They got me
>>> in the padded cell.
>>>
>>> --
>>> Thomas
>>
>> Lightweight. :P
>>
>> Next thing, you'll be telling me that the hookah he and I have been
>> building to
>> smoke some imported dried Conraua goliath is ... "ill advised".
>>
>> Now, be a good lad and fetch me a Winchester bottle of ether.
>>
>>
>
> I'll get you a Klein bottle of POV-Ray distillate instead.
>
Did you keep the box it came in ?
I might have an usage for such box, and recycling is such a trend now.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 15.09.2018 um 00:29 schrieb Bald Eagle:
> clipka <ano### [at] anonymousorg> wrote:
>> Am 14.09.2018 um 21:55 schrieb clipka:
>>
>>> Which is not surprising, since you have
>>>
>>> #for (U, 0, Usize)
>>>
>>> while the array is only Usize elements long, from 0 to Usize-1.
>>
>> Sorry, that's an imprecise observation; the array is Usize+1 elements
>> long, so it has space for elements from 0 to Usize. But you're only
>> initializing elements from 0 to UU, with UU = Usize-1, so element Usize
>> remains uninitialized.
>
> While that's the error that POV-Ray reports, it's only symptomatic of the
> initial failure to catch Yvalue = 0, and return a valid array element
> identifier.
(I presume you mean `YVal`)
Then what does this have to do with your latest statement that "The
offender is #declare _Y = function (Angle, _M) {min(max(0, Angle * _M),
_M)}"?
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>.
> 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.]
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
and to home in on the problem:
#for (U, 0, Usize)
no effect #local YVal=0;
code proceeds #local U=0;
no effect #local UArray[U]=<0,0,1.047>;
So I tried #local U = int (U); Nope.
So, #for (U, 0, .... doesn't actually start at 0??? :|
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 16.09.2018 um 00:50 schrieb Bald Eagle:
> and to home in on the problem:
>
> #for (U, 0, Usize)
>
> no effect #local YVal=0;
> code proceeds #local U=0;
> no effect #local UArray[U]=<0,0,1.047>;
Maybe I'm a bit daft here, but can you please elaborate on the above
notation? Does each line represent something you tried inserting...
somehwere? After the `#for()` statement?... with the left showing the
result and the right showing the statement you tried? Did you try each
of the lines individually, or did you add them one after the other in
the above order? Does "no effect" mean you didn't get the desired
effect, or does it mean the observed effect isn't there? Does "Code
proceeds" mean the code works, or does it mean the `#if` clause is skipped?
Hunting down obscure bugs is a matter of precision. This seems to be
something so strange that I need to understand /exactly/ what you're
doing and /exactly/ what your results are.
This is all the more important since I still don't seem to get the same
results; so either I didn't fully understand your description to allow
me to reproduce it - in which case precision is important so that I can
figure out what I'm still doing differently than you - or thre is
something fundamentally different between my environment and yours - in
which case precision is important because your description of the
scenario is all I have to go by to understand the root cause.
> So I tried #local U = int (U); Nope.
You tried that where? And what exactly does "Nope" mean?
> So, #for (U, 0, .... doesn't actually start at 0??? :|
I can pretty much rule that one out: The parser takes the literal `0`
and immediately assigns it to the local variable U, with no other fancy
operations involved. If there are any two statements by which you can
absolutely positively reliably get a clean genuine zero into some
variable, it is `#declare/local Foo=0;` and `#for (Foo,0,...)`.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
|
|