On Sat, 22 Feb 2003 07:16:15 -0500, Warp quoth:

> Christopher James Huff <cja### [at] earthlinknet> wrote:
>> I see a bunch of categories that it doesn't fit in, and one that it
>> does. strlen() isn't a float function, it is a string function.
>> Categorizing by purpose makes much more sense.
> 
>   strlen() is a float function.
> 
>   There's a good and logical reason for calling it a float function (and
> you should know it without me telling it).
>   The reason for calling it a float function according to its return
>   value
> type is that it can be used anywhere a float is expected. In the same
> way a vector function can be used anywhere a vector is expected.

>   So naming and categorizing functions by their return value is not only
> logical but it's actualy a categorization by purpose: Float functions
> are those which can be used anywhere a float value is expected.

Is there any reason why it can't go in both places?  It's a float
function because it returns a float, and a string function because it
operates on strings.

And before you object, "trace" would be a vector function because it
returns a vector, and an object function because it operates on objects.

-- 
Mark

Post a reply to this message

Will W <wil### [at] nospamwizzardsnet> wrote:
> Organizing functions by return type is, for me, an intriguing idea.

  There's a very good reason for this in programming, as I explained
previously.
  In the same way as a variable has a type (eg. a variable of integer type),
a function has a type as well. The type of the function is determined by
its return value. Also constant literals have a type as well.
  The type of something determines where it can be used. For example, if
an integer is expected in a particular place, then any item of integer
type can be used there (ie. an integer literal, an integer variable, an
integer function or an expression which result is an integer).

  The purpose of a function (eg. to manipulate strings or whatever) is
a higher-level concept which has nothing to do with its type. The parameters
the function takes have nothing to do with its type (they don't affect in
any way *where* you can use the function).

  Organizing functions by their type is the easiest and most unambiguous
way of doing it. There are some functions which are very hard to classify
by their higher-level concept (because it's not unambiguous or it's a very
unique function).

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

Mark Wagner <mar### [at] gtenet> wrote:
> Is there any reason why it can't go in both places?

  There could be a "see also" subsection in the string functions section
where it's mentioned.

> And before you object, "trace" would be a vector function because it
> returns a vector, and an object function because it operates on objects.

  There are no "object functions" in POV-Ray.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

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

> > And before you object, "trace" would be a vector function because it
> > returns a vector, and an object function because it operates on objects.
> 
>   There are no "object functions" in POV-Ray.

trace(), min_extent(), max_extent(), inside()...I think that's it.

-- 
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

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

> Will W <wil### [at] nospamwizzardsnet> wrote:
> > Organizing functions by return type is, for me, an intriguing idea.
> 
>   There's a very good reason for this in programming, as I explained
> previously.

This isn't programming, it's documentation. The first thing most people 
will look for when looking for a string length function is a group of 
functions for manipulating strings.


>   The type of something determines where it can be used. For example, if
> an integer is expected in a particular place, then any item of integer
> type can be used there (ie. an integer literal, an integer variable, an
> integer function or an expression which result is an integer).

The purpose determines where it is useful. strlen() is only useful when 
handling strings, it is useless for math stuff.


>   The purpose of a function (eg. to manipulate strings or whatever) is
> a higher-level concept which has nothing to do with its type. The parameters
> the function takes have nothing to do with its type (they don't affect in
> any way *where* you can use the function).

Higher-level means closer to human thinking. The documentation is meant 
to teach humans.

-- 
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

In article <3e58628d@news.povray.org>,
 "Will W" <wil### [at] NOSPAMwizzardsnet> wrote:

> An added section of cross references for those who come to POV from a
> programming background could be very helpful. If there was a section
> entitled "Especially for Programmers New To POV" I would have read that
> before any other part of the manual, and I think that would be true for any
> other programmer, too. That would be a good place to say that in the SDL
> philosophy functions are organized by their return type, describe how POV
> macros differ from keyboard macros and subroutine calls, and so on. Such
> material should not replace what has been written, but should be added as an
> appendix.

It would be nice if it could be done without making the reader jump all 
over the documentation, but without much duplication. Here's one 
possible layout:

numeric functions
    scalar functions (float and integer)
        trig sub group...trig functions should be together, not mixed 
with functions like pow() and int().
    vector functions
string functions
object functions
array functions
other functions

And a separate section listing them by return type, with links to the 
main documentation.

-- 
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

Christopher James Huff wrote:
> In article <3e5601e0@news.povray.org>, Warp <war### [at] tagpovrayorg> 
> wrote:
> 
> 
>>  Functions are categorized based on what they return.
> 
> 
> And I personally have never liked this method.
> 
Now I agree!
Some time ago I was searching for the dot_product(..) syntax
but wasn't able to find it in the "vector functions" category... ;-)

Sebastian H.

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message
news:3e58e425@news.povray.org...
> Will W <wil### [at] nospamwizzardsnet> wrote:
> > Organizing functions by return type is, for me, an intriguing idea.
>
>   There's a very good reason for this in programming, as I explained
> previously.

Yes, I see that. You are preaching to the choir.

I do not see any compelling reason for changing the way the POV and its
documentation are organized. As I have said elsewhere, I do think a brief
appendix for experienced programmers who are new to POV could be very useful
in cutting down aggravation and stupid sounding questions. But that would be
an added feature, not a change in what has already been done. It would be
something nice to have, but not strictly necessary.


--
Will Woodhull
Thornhenge, SW Oregon, USA
willl.at.thornhenge.net

Post a reply to this message

Christopher James Huff <cja### [at] earthlinknet> wrote:
> other functions

  I'm still not comfortable with that.
  How do you classify a function as "other"? How do I know from a given
function if it's an "other" function?

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

Christopher James Huff <cja### [at] earthlinknet> wrote:
>>   There are no "object functions" in POV-Ray.

> trace(), min_extent(), max_extent(), inside()...I think that's it.

  Those are vector functions (because they can be used where a vector is
expected). They are not object functions because they can't be used
where an object is expected (there are no such functions in POV-Ray).

  You can call them "functions for getting information about an object",
but don't mix up type terminology with this. That would only cause
confusion.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message