Christoph Hormann wrote:

> 
> Le Forgeron wrote:
 
> And the macro would just have to analyze the components of the vectors and
> place 'Vector.t' at the appropriate positions in the poly object.  I
> currently don't have the time to write it, but it's really quite easy
> (although it would take some time to parse for a 15th order poly).  


Please, do not waste your time at writing such kludging-macro, when the 
best solution would have been to change the syntax of the poly objects
so as to parse only the useful information. At worst, if backward 
compatibility is an issue, a new 'poly2' syntax would be able to provide 
the new one while the old 'poly' remained unchanged. (just like the new 
mesh2... same core object, different syntax!)

Post a reply to this message

On Wed, 11 Sep 2002 09:30:20 -0400, Christopher James Huff <chr### [at] maccom>
wrote:
> I find keywords much easier to read and write than numbers

POV's SDL doesn't help me to make decision. Patterns has names and internal
functions hasn't. Type of interpolation for splines has names and types for
interpolation for images hasn't. Methods usually hasn't names. Noise generator
types have no names.

> I feel that you should only use a number for a numeric value.

Then how to call two different algoithms for connections along torus fragments
to make it readable ?

> And I really hope you 
> meant "path_type INT".

Of course.

> "type" already exists, and spline names can be used for all splines 
> instead of just in the sphere_sweep shape, so you aren't adding a huge 
> number of one-use keywords.

I will reconsider this.

ABX

Post a reply to this message

Le Forgeron wrote:
> 
> [...]
> 
> Please, do not waste your time at writing such kludging-macro, when the
> best solution would have been to change the syntax of the poly objects
> so as to parse only the useful information. At worst, if backward
> compatibility is an issue, a new 'poly2' syntax would be able to provide
> the new one while the old 'poly' remained unchanged. (just like the new
> mesh2... same core object, different syntax!)

I disagree, the current syntax isn't exactly easy to use in hand written
code but wrapper macros can much improve that.  Adding more than 100 new
keywords is really not a good idea IMO, it would enormously blow up the
already large parser (the current parsing code for the poly object is
really compact).  Your suggestion would also introduce a disturbing double
meaning to the x, y and z identifiers.

A serious advantage would of course be the potential for signatures and
the shortest code contest.

If a new syntax is made for poly objects i would suggest using 'exponent
vectors':

poly2 { 
  <6, 0, 0>, 1,
  <0, 5, 0>, 1,
  <0, 0, 4>, 1,
  <0, 0, 0>, -10
}

poly2 { 
  <6, 0, 0>, 1,
  <0, 5, 0>, 1,
  <0, 0, 4>, 1,
  <0, 0, 0>, -10,
  <2, 1, 3>, -3
}

You could still declare symbols for the vectors but the parser would be
kept clean from unnecessary clutter.

Christoph

-- 
POV-Ray tutorials, IsoWood include,                 
TransSkin and more: http://www.tu-bs.de/~y0013390/  
Last updated 13 Aug. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

On Wed, 11 Sep 2002 17:01:24 +0200, Christoph Hormann <chr### [at] gmxde>
wrote:
> Your suggestion would also introduce a disturbing double
> meaning to the x, y and z identifiers.

You mean triple probably. Don't forget x, y and z in functions.

ABX

Post a reply to this message

In article <6uiunuc15f15ikpe3mdavli2tc3q5h8tg7@4ax.com>,
 ABX <abx### [at] abxartpl> wrote:

> > I find keywords much easier to read and write than numbers
> 
> POV's SDL doesn't help me to make decision. Patterns has names and internal
> functions hasn't.

Huh? The internal functions have names, they are just defined through 
the functions.inc file instead of being built-in. If you use the 
function ID numbers directly, you are doing it wrong, and your scene 
probably won't work in future versions.


> Type of interpolation for splines has names and types for
> interpolation for images hasn't.

And I can remember the keywords for spline types a lot easier than the 
numbers for image interpolation.


> Methods usually hasn't names.

Methods? POV doesn't have...oh, you mean like the media sampling methods?
That is one case where I might have used numbers. The only keywords I 
can think of are "random" or "monte_carlo" (which I'm not entirely sure 
is right), "even_spacing", and "supersampled", and none of them seem 
very appropriate. I would have used "sampling_method" instead of 
"method" though...or a completely different syntax, somethign like: 
sampling {type, PARAMS}


> Noise generator types have no names.

I don't like the way noise generators were done, either in syntax or in 
the way they were done internally. I think that feature was just a hack.
I would have used names such as perlin_noise, old_pov_noise, pov_noise, 
lewis_noise, etc, and a completely different syntax. There would be a 
global generator that could be set to any of these, but a noise 
generator could be defined in the file as a function, something like:

global_settings {
    noise_generator function {perlin_noise {}}
    noise_generator FUNCTION_IDENTIFIER
}
#declare myNoise = function {perlin_noise {range MIN, MAX ...}}

Patterns and other things that use noise would be able to use any 
function as the noise source.


> > I feel that you should only use a number for a numeric value.
> Then how to call two different algoithms for connections along torus fragments
> to make it readable ?

torus and torus2, torus1 and torus2, toroidal1 and 2, or something 
similar...it is done in other places: the spiral patterns, atan and 
atan2 functions, etc...
If keywords make sense, I think they should be used instead of numbers.

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

On Wed, 11 Sep 2002 11:33:53 -0400, Christopher James Huff <chr### [at] maccom>
wrote:
> > > I find keywords much easier to read and write than numbers
> > 
> > POV's SDL doesn't help me to make decision. Patterns has names and internal
> > functions hasn't.
>
> Huh? The internal functions have names, they are just defined through 
> the functions.inc file instead of being built-in. 

So what's the problem to define keywords for types this way ?

> Patterns and other things that use noise would be able to use any 
> function as the noise source.

Interesting idea. Are you reserving rights to make patch for it ? ;-)

> torus and torus2, torus1 and torus2, toroidal1 and 2, or something 
> similar...it is done in other places: the spiral patterns, atan and 
> atan2 functions, etc...
>
> If keywords make sense, I think they should be used instead of numbers.

If keyword make sense it can be always added as identifier during parsing.
Otherwise it seems overloading for parser. I can't say I fully understand how
parser works but I imagine with every new token it can slow down a little.
Further I imagine patches for 3.5 will introduce a lot of new tokens so
prasing can be overloaded. Tell me if it works differently.

On the other hand I wonder if some propability of occurences could be
introduced to parser. As source library from IRTC could be investigated for
probability of keywords. Most probable keywords could be compared with parsed
token first.

ABX

Post a reply to this message

In article <48punuklg3k2jl8trmqh5r6r3eokpq9del@4ax.com>,
 ABX <abx### [at] abxartpl> wrote:

> > Huh? The internal functions have names, they are just defined through 
> > the functions.inc file instead of being built-in. 
> So what's the problem to define keywords for types this way ?

Slower parsing, for one. ;-)
Requiring an external include file. Potential conflicts with future 
keywords if you use all lower-case, not fitting in with the rest of the 
language if you use upper-case. Providing an include file and using 
integer codes would be much better than nothing though.


> > Patterns and other things that use noise would be able to use any 
> > function as the noise source.
> Interesting idea. Are you reserving rights to make patch for it ? ;-)

Heh, implementing it in the current POV would take a huge amount of 
work. I'm mainly thinking of it as something to be considered for the 
4.0 rewrite.


> If keyword make sense it can be always added as identifier during parsing.
> Otherwise it seems overloading for parser. I can't say I fully understand how
> parser works but I imagine with every new token it can slow down a little.
> Further I imagine patches for 3.5 will introduce a lot of new tokens so
> prasing can be overloaded. Tell me if it works differently.

I doubt adding a token slows things down significantly, for more complex 
scenes it probably takes a smaller and smaller fraction of the total 
time, and for POV 4.0, the scene will probably be compiled into 
bytecodes for a virtual machine to run...more tokens would slow down 
compiling slightly, but compiling will be a small fraction of the total 
time used before the scene renders.


> On the other hand I wonder if some propability of occurences could be
> introduced to parser. As source library from IRTC could be investigated for
> probability of keywords. Most probable keywords could be compared with parsed
> token first.

Or the parser could do something similar on the fly: if a token is 
matched, move it to the front of the list. Tokens that occur more often 
will spend more time towards the front of the list. Not as efficient, 
but simpler and adapts to the scene...for example, a mesh file will have 
a very different occurance distribution from other scenes, mainly having 
"triangle" or "smooth_triangle", "{}" braces, ",", "<", and ">" 
characters, and numbers. After the first triangle, these will be at the 
top of the token list. I did something similar for Sapphire: when a 
symbol is resolved it moves to the front of the symbol table.

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

On Wed, 11 Sep 2002 15:32:30 -0400, Christopher James Huff <chr### [at] maccom>
wrote:
> > > Huh? The internal functions have names, they are just defined through 
> > > the functions.inc file instead of being built-in. 
> > So what's the problem to define keywords for types this way ?
>
> Slower parsing, for one. ;-)

But I can include only necessary files so can optimize parsing time.

> Requiring an external include file.

So many languages use header files with definitions so nothing new.

> > Interesting idea. Are you reserving rights to make patch for it ? ;-)
>
> Heh, implementing it in the current POV would take a huge amount of 
> work. I'm mainly thinking of it as something to be considered for the 
> 4.0 rewrite.

chicken ;-)

> I did something similar for Sapphire: when a 
> symbol is resolved it moves to the front of the symbol table.

Any reference ? You mean http://sapphire.sourceforge.net/ ? 

ABX

Post a reply to this message

> Or the parser could do something similar on the fly: if a token is 
> matched, move it to the front of the list. Tokens that occur more often 
> will spend more time towards the front of the list. Not as efficient, 
> but simpler and adapts to the scene...for example, a mesh file will have 
> a very different occurance distribution from other scenes, mainly having 
> "triangle" or "smooth_triangle", "{}" braces, ",", "<", and ">" 
> characters, and numbers. After the first triangle, these will be at the 
> top of the token list. I did something similar for Sapphire: when a 
> symbol is resolved it moves to the front of the symbol table.


	Do you mean that the current POV-Ray parser (which I never
really investigated) searches the full list of keywords to get the
proper token ? If so, what about hash tables as used when parsing
mesh triangles/textures ?
	Putting the last resolved symbol at the beginning of the
list assumes a high probability to find the same symbol again. I
agree this is good for such big objects as meshes (and usually
a very big scene is made of very big meshes...). But I don't think
it's better than using hash tables in general. [A perfect hash table
would be appropriate for build-in keywords which number is fixed].

	Forget all that if POV-Ray does it already  :-)

Post a reply to this message

On Tue, 10 Sep 2002 15:42:31 +0200, ABX <abx### [at] abxartpl> wrote:
> Any idea for nice name for interpolation without interpolation ?

Let's check voting. 'path_type' followed by parameter seems fine.
There are two votes for float parameter and two votes for keyword parameter.
Any help to fullfill democracy in this syntax designing ?

ABX

Post a reply to this message