Is there any way to tell a identifier which evaluates to a vector from an
identifier which evaluates to a real? Essentially, I want a way to determine
the type of an identifier. I want to create a macro like this

#macro StringOut(IDENTIFIER)
#if (IDENTIFIER is_vector)
    {do some vector related things here}
#else
    #if (IDENTIFIER is_real)
        {do some real related things here}
    #end
#end
#end

Post a reply to this message

In article <39ce6e42@news.povray.org> , "Neil Freebairn" 
<nei### [at] lineonenet> wrote:

> Is there any way to tell a identifier which evaluates to a vector from an
> identifier which evaluates to a real? Essentially, I want a way to determine
> the type of an identifier. I want to create a macro like this

Please do not use excessive cross-posting. See the "Cross-Posting Guidelines
for news.povray.org" in povray.announce.frequently-asked-questions.

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.


     Thorsten


____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

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

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