"Kenneth" <kdw### [at] gmailcom> wrote:

>
> *If* that is the case, then the select() result can have only two states or
> outcomes-- true or false (or 1 and zero). Which would then pick either argument
> B or C, but never D(??) So, I am wondering if your f-boom macro will ever
> actually be chosen by this select() set-up.
>

Hmm. I think I muddied my question and my logic, sorry. I kind of mixed up what
happens in a 4-argument 'select' use.

But it would seem that only two of the three B-C-D select() results could be
chosen by your function, but not all three.

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:

> > #include "functions.inc"
> > #declare FnChkVals = function (x) {
> >      select(((x<0.0) | (x>1.0)),
> >          0,
> >          0,
> >          f_boom(x,2,3,4,5,6)
> >      )
> > }


Kenneth, I use select all the time.

This is how it works:

select (N, -1, 0, 1)

When your comparison function gets evaluated, it returns a Boolean state (in
POV-Ray it's a 0 or a 1).

So what he's doing, is checking if x is less than 0 or greater than 1.
If it is, then the Boolean result is true, which in POV-Ray is 1.
If it's not, then the result is false, or zero.
The negative option in the select statement never gets used - it's just there to
force the select function to have a zero option that's separate from the 1
option, since a 3-term select statement is divided into 2 results:  negative or
>= 0.

I hope that helps.

Post a reply to this message

On 2/16/23 19:56, Bald Eagle wrote:
> since a 3-term select statement is divided into 2 results:  negative or
 > ????.

Bill W (BE) explained well.

However, I'm going to re-state things because what showed up where I 
have ???? characters above looks different on the web than what I see in 
Thunderbird(a).

There are two forms of select(). The is a four term/argument version and 
a three term version. The four term allows 'actions' for negative, zero 
and positive input values. The three term one allows actions for 
negative and (zero or positive) values.

I used the 4 term because I think it reads a little cleaner when setting 
up a boolean test in the first term which can only return a zero or one 
- the negative action is never used as Bill W said.

Aside: You can use the 3 term select depending upon a boolean result in 
the first term test by doing something like:

select(1-(2*((x<0.0) | (x>1.0))), 0, 1)

I think this form less clear and, FWIW, it's slower than the four term 
version.

Bill P.

(a) The leading '>' character got picked up as being an indication of 
text from a previous post and is displaying as a vertical bar '|' in 
Thunderbird.

Post a reply to this message

On 2/16/23 18:45, Kenneth wrote:
> Yes. Functions as used in height_fields never see called x,y values
> outside the [0-1] range.

Perhaps worth saying a little more than the above. Whether creating a 
height_field or internal image_map from a function in POV-Ray, any 
'function return' values outside the [0-1] get 'wrapped' to a ramp wave 
as is the default with the majority of inbuilt patterns.

So, function return values of:
-0.1 --> 0.9
-0.5 --> 0.5
-0.9 --> 0.1.
1.1 --> 0.1
1.5 --> 0.5
1.9 --> 0.9

In other words, there is a jump or discontinuity when returning values 
go negative or larger than 1. Further, there is no ability to to invoke 
wave(a) modifiers as is true with the pattern mechanism.

Function based image_maps and height_fields all end up in a [0-1] 
vertical/value range - even if your function itself returns values 
outside that range.

Bill P.

(a) - The povr fork offers some wave modification capability via new 
inbuilt functions like f_sine_wave().

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:
>
> I'm going to re-state things because what showed up where I
> have ???? characters above looks different on the web than what I see in
> Thunderbird(a).

No problem at my end; I see the correct syntax in the web portal.

Sorry for my longer-than-usual-delay in responding; I had to think hard about
this 'negative option being ignored' thing, and the difference between a 3-part
vs. 4-part select(). I was still thinking about it when I feel asleep last
night! William P's function construct makes better sense to me now; I finally
had the 'flashing insight'.

docs for the 4-part select:
When used with four parameters, if A < 0 it will return B. If A = 0 it will
return C. Else it will return D (A > 0).

I had to work out my own rather pedantic 'truth table' of sorts, as I see it --
hopefully corrected this time--

-------
Given  ((x<0.0) | (x>1.0))  as the first argument 'A':
The boolean results in parentheses are only ever 0 or 1 (true or false).

if x is indeed less than 0.0 OR greater than 1.0, that produces boolean TRUE (or
1) in the parentheses. Compared against select's 'zero by definition' for A,  1
is 'greater than zero'.  So according to the rules, the outcome of select() will
be argument D-- the f_boom macro. Effectively, it doesn't matter if x exceeds
either limit; the result will be TRUE in either case.

If x is exactly 0.0  *or inside the given range*, the boolean operation in
parentheses produces FALSE (or 0). But, for select's argument A
comparison, 'zero equals zero' -- and argument C is chosen, which is 0.0 in
William P's code and 0.3 in mine.
-------

So far, argument B is never chosen; C and D take care of every possible outcome
of    ((x<0.0) | (x>1.0))

HOWEVER, I see now that a simpler 3-part select() would not work when using
argument A as written-- because of the 3-part rules: Argument B is only chosen
when argument A is *less than* 0, which never occurs with  ((x<0.0) | (x>1.0))

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
>
> The boolean results in parentheses are only ever 0 or 1 (true or false).

The boolean results in parentheses are only ever 0 or 1 (false or true).

Oops.  ;-)

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:
>...
> I used the 4 term because I think it reads a little cleaner when setting
> up a boolean test in the first term which can only return a zero or one
> - the negative action is never used as Bill W said.

I agree..


> Aside: You can use the 3 term select depending upon a boolean result in
> the first term test by doing something like:
>
> select(1-(2*((x<0.0) | (x>1.0))), 0, 1)
>...

How about just this:

select(
    -((x < 0.0) | (1.0 < x)),
    0,
    1
)

- or this:

select(
    -((0.0 <= x) & (x <= 1.0)),
    1,
    0
)


--
Tor Olav
http://subcube.com
https://github.com/t-o-k

Post a reply to this message

On 2/17/23 20:49, Tor Olav Kristensen wrote:
>> Aside: You can use the 3 term select depending upon a boolean result in
>> the first term test by doing something like:
>>
>> select(1-(2*((x<0.0) | (x>1.0))), 0, 1)
>> ...
> How about just this:
> 
> select(
>      -((x < 0.0) | (1.0 < x)),
>      0,
>      1
> )
> 
> - or this:
> 
> select(
>      -((0.0 <= x) & (x <= 1.0)),
>      1,
>      0
> )

:-)

Very likely OK in practice, and cleaner in form than my three term select.

What spooks me some is that -0 and +0 are real things in the IEEE 
floating point standard and as supported by C++. If a C++ coder has 
thought to test for -0 < 0, they can.

Bill P.

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:

> What spooks me some is that -0 and +0 are real things in the IEEE
> floating point standard and as supported by C++. If a C++ coder has
> thought to test for -0 < 0, they can.

Which raises the question about how the IEEE 754 gets implemented in POV-Ray's
source code, and if a user can test for -0 through SDL.

I actually just watched:


https://www.youtube.com/watch?v=p8u_k2LIZyo

yesterday (it was in the sidebar when watching yesbird's animation), and they
went over some interesting points, and was also wondering if we could implement
something like this in POV-Ray SDL, and source, and if you'd find it useful or
are already using it in povr.

- BW

Post a reply to this message

On 2/18/23 08:33, Bald Eagle wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
> 
>> What spooks me some is that -0 and +0 are real things in the IEEE
>> floating point standard and as supported by C++. If a C++ coder has
>> thought to test for -0 < 0, they can.
> 
> Which raises the question about how the IEEE 754 gets implemented in POV-Ray's
> source code, and if a user can test for -0 through SDL.

So tempted to answer I don't know(a)... ;-)

For the floating point standard we mostly get what the C++ compilers 
give us depending upon options used while compiling. Excepting where in 
the POV-Ray source there might be hard coded behavior which is not 
strictly compliant or in days gone by was intended to handle things is 
some more compliant manner(b).

As for testing for -0 via SDL, I cannot think of any direct method...

On my development compiles using g++ 11.3 and the -ffast_math flag, I 
can code:

#declare negZero = -0.0;
#declare posZero = +0.0;
#declare hmmZero = 0.0/-1.0;

#debug concat("-0.0 shows up as : ",str(-0.0,0,-1)," \n")
#debug concat("+0.0 shows up as : ",str(+0.0,0,-1)," \n")

#debug concat("Var negZero shows up as : ",str(negZero,0,-1)," \n")
#debug concat("Var posZero shows up as : ",str(posZero,0,-1)," \n")
#debug concat("Var hmmZero shows up as : ",str(hmmZero,0,-1)," \n")

#error "\nStopping at end of parsing\n"

and see as a result:

-0.0 shows up as : -0.000000
+0.0 shows up as : 0.000000
Var negZero shows up as : -0.000000
Var posZero shows up as : 0.000000
Var hmmZero shows up as : -0.000000

So maybe build up strings and do a string compare?

Aside: The C++ value comparison operators mirrored in SDL will - by 
default - ignore the sign of zero.

> 
> I actually just watched:
> 
> Fast Inverse Square Root — A Quake III Algorithm
> https://www.youtube.com/watch?v=p8u_k2LIZyo
> 
> yesterday (it was in the sidebar when watching yesbird's animation), and they
> went over some interesting points, and was also wondering if we could implement
> something like this in POV-Ray SDL, and source, and if you'd find it useful or
> are already using it in povr.
> 
Cool old stuff!

As for fast, clever algorithms... I've tried some tricks in povr and 
looked over quite a few, though not the particular one in the video. 
Most come with somewhat noisy behavior compared to standards compliant 
code. The noise is difficult to swallow given the end benefit(c) - 
floor() and ceil() fast equivalents, for example.

Bill P.

(a) I don't know it all - about anything. Where I do know a little, 
there's almost never a simple, complete answer.

(b) The radiosity code to this day has some complicated configurations 
related to the floating point math, for example. Unsure what all of this 
used or needed these days.

(c) The povr fork, while coding up new functions, did implement single 
and floating point flavors / options for many functions. Anywhere the 
single floating point code was significantly faster on my i3 hardware - 
at the expense of accuracy. Often single float accuracy in functions is 
OK depending on - stuff.

Measuring and tuning for performance is REALLY difficult these days 
given the hardware realities. For core functionality, the tuning job is 
best left to the compiler folks as a near hard rule.

Post a reply to this message