> Is it possible to do a Bitwise AND in SDL?

Yes, but not directly. Also note, that, as Warp pointed out, pov numbers
are floating point, so you might lose some bits if you use too many.

Untested suggestion:

// to extract bit K of N:

#macro Bit(K,N)
   ((floor(N/pow(2,K))) mod 2)
#end

// bitwise operations with K bits

#macro Not(N,K)
   pow(2,K)-1-N
#end

#macro Nand(N,M,K)
   #local I=0;
   #local R=0;
   #while (I<K)
     #local R = R+(1-Bit(I,N)*Bit(I,M))*pow(2,I);
     #local I = I+1;
   #end
   (R)
#end

#macro And(N,M,K)
   Not(Nand(N,M,K),K)
#end

#macro Or(N,M,K)
   Nand(Not(N,K),Not(M,K),K)
#end

#macro Xor(N,M,K)
   And(Or(N,M,K),Nand(N,M,K),K)
#end


-- 
merge{#local i=-11;#while(i<11)#local
i=i+.1;sphere{<i*(i*i*(.05-i*i*(4e-7*i*i+3e-4))-3)10*sin(i)30>.5}#end
pigment{rgbt 1}interior{media{emission x}}hollow}//  Mark Weyer

Post a reply to this message

Christopher James Huff <cja### [at] earthlinknet> wrote:
> The equality operator expects numeric values, which strings aren't.

  I really hope this is enhanced in some future version.
  I see no reason for not supporting comparison operators on strings.

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

>   I really hope this is enhanced in some future version.
>   I see no reason for not supporting comparison operators on strings.


I'd like to see better support for different data types in general. By this
I mean, I'd like to be able to replace

#debug concat("X was ", str(X,0,0), ", velocity was <", str(vel.x,0,0), ",",
str(vel.y,0,0), ",", str(vel.z,0,0), ">.")

with

#debug "X was " + x + ", velocity was " + vel + "."

Strings can be a real nuisance to work with in POV-Ray SDL.

 - Slime
 [ http://www.slimeland.com/ ]

Post a reply to this message

*lol*

I only had four values, with some duplicates in functionality so I just
'unrolled' it into a big bunch of #IF statements

        == John ==

"Darren New" <dne### [at] sanrrcom> wrote in message
news:40718102$1@news.povray.org...
> Well, *that* should parse fast! ;-)

Post a reply to this message

Slime <fak### [at] emailaddress> wrote:
> #debug "X was " + x + ", velocity was " + vel + "."

  The problem with that is that POV-Ray can't know how many decimals you
want to print with those.

  A safe option is to internally use the "%g" printf() option which will
print only as many decimals as necessary (ie. it will not print trailing
zeroes after the decimal points), but it still can print something you
don't want to. Also, I think there's some odd limit to the maximum
amount of decimals "%g" will print which was quite low (6 or something
like that) and you might want more in many cases. "%g" will also print
in "scientific" format (ie. if the decimal place is too far from the
significant numbers it will use the 'e' notation (eg. "1.4531e-9")),
and in some cases you might not want that.

  The question is, thus, if you want to print something different from
the default "%g" format (which POV-Ray should use when nothing else
is specified, like in your example above), how do you tell it?

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

>   The question is, thus, if you want to print something different from
> the default "%g" format (which POV-Ray should use when nothing else
> is specified, like in your example above), how do you tell it?

In that case, one could explicitly use the str() function instead of relying
on automatic type conversion:

#debug "X was " + str(x, 5, 5) + "."

But being able to skip that step is convenient when you're only interested
in a ballpark figure for debugging purposes.

 - Slime
 [ http://www.slimeland.com/ ]

Post a reply to this message

In article <407078ac@news.povray.org>, fak### [at] emailaddress says...
> > But.... Some mathematical operations require such operations.... Or at
> > least they can use them, so it is odd that such a thing is not actually
> > supported. Any method used to simulate this, where the result needs to be
> > used as a real numeric value would take extra steps to 'build' the value
> > from the array, string or whatever. This is imho quite silly.
> 
> True. But it would be possible. POV-Ray SDL is just a simple scripting
> language provided for convenience; if you really need the speed that bit
> operations can give you, then you're *probably* using the wrong language for
> the job. You should consider writing a program in a different language which
> outputs a POV-Ray SDL file which can be #included from your main one, to
> provide the necessary data or objects.
> 

Which works fine, unless their was a real reason why it needed values 
only computed on the fly in the SDL. Animations being one example. Having 
to export a new SDL for every frame is kind of annoying if the only 
reason for doing it is because there are no bitwise operators. Still. Its 
one of those things I can see as an issue, not something bugging me 
personally.

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

Post a reply to this message

In article <cjameshuff-1E239E.20195404042004@news.povray.org>, 
cja### [at] earthlinknet says...
> In article <MPG.1ada23538462981989a0c@news.povray.org>,
>  Patrick Elliott <sha### [at] hotmailcom> wrote:
> 
> > But.... Some mathematical operations require such operations.... Or at 
> > least they can use them, so it is odd that such a thing is not actually 
> > supported. Any method used to simulate this, where the result needs to be 
> > used as a real numeric value would take extra steps to 'build' the value 
> > from the array, string or whatever. This is imho quite silly.
> 
> It is not silly. The scene language is a high level language, and has no 
> concept of bits, or even integers. Its numeric values are double 
> precision floats. Performing bitwise operations on these is generally a 
> bad idea, and is rarely useful. These operations are rarely used, and 
> nearly useless for POV-Ray scripts.
> 
Well, true. The fact that they are floats makes it a bit more 
interesting. I was thinking more in terms of integer values. Their are 
likely some tricks you can do with simple bitwise operations for color or 
even heightfield, etc. that could be theoretically faster in some cases. 
I don't have any specific application in mind that I am thinking of at 
the moment though.

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

Post a reply to this message

> Having
> to export a new SDL for every frame is kind of annoying

True. What I tend to do to save space is to just comma-separated data which
can be #read by an SDL script. Sometimes I'll output something like

[frame number], [data],[data],[data],...
[frame number], [data],[data],[data],...
...

and occasionally I'll do something more sophisticated, with keyframes:

[time value], [data],[data],[data],...
[time value], [data],[data],[data],...
...

Either way, I have the SDL script #read in the necessary data for a certain
frame, do interpolation in the case of keyframes, and then use the data
however it wants.

The idea, of course, is to balance your need of low-level features with your
desire to avoid extra complication.

 - Slime
 [ http://www.slimeland.com/ ]

Post a reply to this message

In article <MPG.1adcd012e074ae8989a14@news.povray.org>,
 Patrick Elliott <sha### [at] hotmailcom> wrote:

> Well, true. The fact that they are floats makes it a bit more 
> interesting. I was thinking more in terms of integer values. Their are 
> likely some tricks you can do with simple bitwise operations for color or 
> even heightfield, etc. that could be theoretically faster in some cases. 
> I don't have any specific application in mind that I am thinking of at 
> the moment though.

For parse-time operations, the difference in execution time between a 
bit shift and multiplication or division by a power of 2 would be 
unmeasurable, any differences that exist would be dwarfed by the 
overhead of parsing the code. For the VM or even native code, the speed 
difference is very minor, if the operation isn't changed by the 
compiler. You use the operation that best suits what you are doing. For 
POV scenes, bitwise operators aren't very useful, and can be implemented 
using strings or arrays well enough that a built-in version is 
unnecessary.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message