The scene below results in "Expected 'function identifier', } found 
instead".

Are the three bitwise_.. functions not usable in functions? Bug? Me?

Ingo

---%<---%<---%<---

#version 3.7;
global_settings{ assumed_gamma 1.0 }
#default{ finish{ ambient 0.1 diffuse 0.9 }} 

plane{ 
  <0,1,0>, 0 
  texture{ 
    pigment{ 
      function{bitwise_xor(x, y, z)}
    }
  }
}

light_source{< 3000,3000,-3000> rgb 1}

camera {
  angle 75
  location <0.0 , 3.0 ,-3.0>
  right x*image_width/image_height
  look_at  <0.0 , 1.0 , 0.0>
}

---%<---%<---%<---

-- 
https://ingoogni.nl

Post a reply to this message

Yikes.

I've tried all manner of things to correct the syntax or find a workaround, but
I can't even get the parser to recognize the expressions

#declare F1 = function {bitwise_and (x, y, z)}
#declare F2 = function {bitwise_or (x, y, z)}
#declare F3 = function {bitwise_xor (x, y, z)}

SO, I'm thinking that the problem is that somehow those built-in function
identifiers never got put in a list to get passed to the (separate) function
parser.   Oof.

Which means that until that gets fixed, you're going to have to roll your own
user-defined functions in SDL.  :(  I recall doing this somewhere, when I didn't
know that our bitwise operators were spelled-out function identifiers and not
the usual symbols.
I can go hunt that down if you need me to...


https://stackoverflow.com/questions/7199625/mathematical-equation-for-and-bitwise-operation

(a & b)
can be done with:

(((a/1 % 2) * (b/1 % 2)) * 1) +
(((a/2 % 2) * (b/2 % 2)) * 2) +
(((a/4 % 2) * (b/4 % 2)) * 4) +
....
(((a/n % 2) * (b/n % 2)) * n)
Where n is 2 to the number of bits that A and B are composed minus one. This
assumes integer division (remainder is discarded).

Post a reply to this message

in news:web.62c97261fd43e9001f9dae3025979125@news.povray.org Bald Eagle 
wrote:

> Yikes.

Yes.

I'll make a bugreport of it.
Doing my own in SDL is not important now, was just fiddling around.

Thanks.

-- 
https://ingoogni.nl

Post a reply to this message

>       function{bitwise_xor(x, y, z)}

I don't think this a bug so much as unsupported. Just FYI, it should probably be
a feature request rather than a bug report.

Also, the documentation says that these functions treat the inputs as integers.
Is that what you are expecting?

Post a reply to this message

"jceddy" <jce### [at] gmailcom> wrote:
> >       function{bitwise_xor(x, y, z)}
>
> I don't think this a bug so much as unsupported. Just FYI, it should probably be
> a feature request rather than a bug report.
>
> Also, the documentation says that these functions treat the inputs as integers.
> Is that what you are expecting?

Bald Eagle is exactly right as to why this isn't working, BTW.
For function{} there is a separate function parser that is pretty restrictive,
and it will not support calling things like bitwise_xor(), trace(), etc. It only
supports numerical values, operators, variables/parameters, and references to
other defined function names. So for this to work, someone would need to define
a "built-in" f_bitwise_xor function (for example), that you could then call in
function blocks.

You would indeed need to "roll your own" using only operators and simple
variables.

Post a reply to this message

in news:web.62c9a94afd43e900864166f75d51d79c@news.povray.org jceddy wrote:

> I don't think this a bug so much as unsupported.

Yes, you may be right. They are mentioned in the numeric expression 
section but not in the functions section. :(

-- 
https://ingoogni.nl

Post a reply to this message