In povray.text.scene-files Thorsten Froehlich <thorsten@trf.de> wrote:
: Regarding your question, there is no function to determine the type.
: However, as the result of any function in POV-Ray is deterministic, you
: should always know which variable type a variable is.  For a printing macro,
: you would then just pass that information along with the variable.

  I don't think it would be a bad idea to be able to get the variable type
from a variable instance (doesn't it carry it along anyways?).
  I don't even think that making a set of functions returing a bool value for
this would be hard. For example:
  isvector()
  isreal()
  isstring()
  ...

  For exampe isvector() would return true if the parameter is a vector, else
false.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

In article <39cf0b83@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   I don't even think that making a set of functions returing a bool value 
> for this would be hard. For example:
...snip...
>   For exampe isvector() would return true if the parameter is a vector, 
> else false.

I have no idea how to code that, but it should be quite possible. 
However, I think the first thing that would happen is that someone would 
write a macro to put all those functions into one which returns a 
different number or character for each type. Just one function should 
work fine...
type_of(IDENTIFIER)
returns:
    1-float
    2-2D vector
    3-3D vector
    4-color
etc...

Then variables for each type could be put in a standard include...
// types.inc

#declare FLOAT = 1;
#declare VECTOR_2D = 2;
#declare VECTOR_3D = 3;
#declare COLOR = 4;

so you could just use this:

#if(type_of(MyIdentifier) = COLOR)

instead of:

#if(is_color(MyIdentifier))

Not only would it take less keywords, but it would be more flexible and 
nearly as easy to use.(easier in some situations)

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

Chris Huff <chr### [at] maccom> wrote:
: Not only would it take less keywords, but it would be more flexible and 
: nearly as easy to use.(easier in some situations)

  If you want to use less keywords you'll have to remember the numbers. If
you want the numbers declared as easy-to-remember identifiers, then you
actually have one keyword more than in the one-function-per-type case. :)

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

> >   I don't even think that making a set of functions returing a bool
value
> > for this would be hard. For example:
> ...snip...
> >   For exampe isvector() would return true if the parameter is a vector,
> > else false.
>
> I have no idea how to code that, but it should be quite possible.
> However, I think the first thing that would happen is that someone would
> write a macro to put all those functions into one which returns a
> different number or character for each type. Just one function should
> work fine...
> type_of(IDENTIFIER)
> returns:
>     1-float
>     2-2D vector
>     3-3D vector
>     4-color
> etc...
>
> Then variables for each type could be put in a standard include...
> // types.inc
>
> #declare FLOAT = 1;
> #declare VECTOR_2D = 2;
> #declare VECTOR_3D = 3;
> #declare COLOR = 4;
>
> so you could just use this:
>
> #if(type_of(MyIdentifier) = COLOR)
>
> instead of:
>
> #if(is_color(MyIdentifier))
>
> Not only would it take less keywords, but it would be more flexible and
> nearly as easy to use.(easier in some situations)

Does it make sense for CODING, to distinguish between COLOR and
3/4/5-D -Vector ???
I often address my Color-Items in the Vector (r,g,b) with x,y and z ...
Aren't RGB-Color Vectors handled the same way like XYZ-Vectors are ???

So I think it would be better to have one function  for giving back the type
as
    - Vector
    - Integer  (Is there a difference between Float and Integer in POV ???)
    - Float
    - String

And another Function giving the Size of a Vector ... (for XYZ I get 3 and
for RGBFT I get 5)

I think for the correct use of them you have to take care yourself, i.e.
dont mischange RGBFT and RGBTF ...

But (maybe for Effects) there is the possibility in POV to assign a RGBFT to
a RGBTF or a RGB to a XYZ .... So where should the function know from what
it is ??? Maybe it gives you back the type from the time when you last used
it, ... or when you declared it, but this would need to give the type when
declaring them ...

--
Jan Walzer ...

Post a reply to this message

In article <39d35f5f@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   If you want to use less keywords you'll have to remember the numbers. If
> you want the numbers declared as easy-to-remember identifiers, then you
> actually have one keyword more than in the one-function-per-type case. :)

But you can choose to only declare the type identifiers you use, and you 
can change them if you run into conflicts. So you only have one 
identifier that must always be there.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

Jan Walzer <j.w### [at] itcampusde> wrote:
:     - Integer  (Is there a difference between Float and Integer in POV ???)
:     - Float

  Nope, they are both implemented in the same way, ie. using floats.
  However, the integer type may still be meaningful (ie. if the number is
not fractional). The problem is that in that case the integer can change to
a float after any operation (or vice-versa).
  I don't know if there's any real need for distinguishing between
fractional and non-fractional floats.

: And another Function giving the Size of a Vector ... (for XYZ I get 3 and
: for RGBFT I get 5)

  Don't forget that 2D vectors also exist.

  And by the way, there IS a difference between a color and a vector.
Consider this:

#declare Vector = <.1, .2, .3, .4>;
#declare Color1 = rgbf <.1, .2, .3, .4>;
#declare Color2 = rgbt <.1, .2, .3, .4>;

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

In article <39d44752@news.povray.org>, "Jan Walzer" 
<j.w### [at] itcampusde> wrote:

> Does it make sense for CODING, to distinguish between COLOR and
> 3/4/5-D -Vector ???
> I often address my Color-Items in the Vector (r,g,b) with x,y and z ...
> Aren't RGB-Color Vectors handled the same way like XYZ-Vectors are ???

The only thing that would really make sense would be 3D vectors and 5D 
colors, I think...it may be that everything is stored internally as 
5-component vectors, but I do not think so.(I know the expression parser 
uses these 5D vectors in some areas, but I really don't understand it 
well enough.)


>     - Integer  (Is there a difference between Float and Integer in POV 
>     ???)

Nope, no difference.


> I think for the correct use of them you have to take care yourself, i.e.
> dont mischange RGBFT and RGBTF ...
> 
> But (maybe for Effects) there is the possibility in POV to assign a 
> RGBFT to a RGBTF or a RGB to a XYZ .... So where should the function 
> know from what it is ??? Maybe it gives you back the type from the 
> time when you last used it, ... or when you declared it, but this 
> would need to give the type when declaring them ...

Colors are RGBFT, no matter what syntax created them. The "xtra" 
components are set to 0.

My revised list:
object
scalar(float)
vector
color
transform
spline
function
macro
texture
normal
finish
material
etc...

A separate function could be useful for differentiating between types of 
objects, but it would probably be better to have it a separate function. 
I'm not sure if it would be better for it to return a string 
representing the type or a number...strings would probably be best.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

Chris Huff wrote in message ...
>it may be that everything is stored internally as
>5-component vectors, but I do not think so.(I know the expression parser
>uses these 5D vectors in some areas, but I really don't understand it
>well enough.)

All colors are stored as 5D vectors.  I think that the parameters for a
julia_fractal are stored as 4D vectors, but I'm not absolutely sure on this.
3D and 2D vectors are both stored as 3D.


Mark

Post a reply to this message

That's exactly what I was looking for. Very elegant, many thanks.

I also agree with other contributors that a more generic solution would be
very useful.

Neil

Ron Parker <ron### [at] povrayorg> wrote in message
news:slr### [at] fwicom...
> On Sun, 24 Sep 2000 22:08:05 +0100, Neil Freebairn wrote:
> >Is there any way to tell a identifier which evaluates to a vector from an
> >identifier which evaluates to a real?
>
> (reply confined to advanced-users, which is the most appropriate of the
> crossposted groups.)
>
> If what you're going to get is guaranteed to be either a scalar or a 3-d
> vector, you can do something like this:
>
> #macro scalar_or_vector( A )
>
>   #declare C = rgbft 0 + A;
>
>   #if ( C.filter = C.red )
>     #debug "scalar\n"
>   #else
>     #debug "vector\n"
>   #end
>
> #end
>
>
> --
> Ron Parker   http://www2.fwi.com/~parkerr/traces.html
> My opinions.  Mine.  Not anyone else's.
> Proudly not helping RIAA and SDMI steal my rights --
>   http://www.eff.org/Misc/EFF/Newsletters/EFFector/HTML/effect13.08.html

Post a reply to this message

On Mon, 9 Oct 2000 17:27:07 +0100, Neil Freebairn wrote:
>That's exactly what I was looking for. Very elegant, many thanks.
>

Looking at it now, I see that there will be a couple of problems.  First,
it can't properly deal with vectors with an X value of zero.  If you fix that
by testing the green or blue values as well, it still can't properly deal
with zero vectors.  To fix it, make another local that's equal to
rgbft 0 + (1 + A) ,
then compare that vector's red and filter components as well.  Only if both
comparisons are equal is it a scalar (because 1+A is either a vector or a 
scalar, whichever A was, and either A or 1+A is going to have a nonzero X
component.)

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.
Proudly not helping RIAA and SDMI steal my rights -- 
  http://www.eff.org/Misc/EFF/Newsletters/EFFector/HTML/effect13.08.html

Post a reply to this message