Any idea for nice name for interpolation without interpolation ?
In my rewrtitten sphere_sweep module I have added additional types for
interpolations. One of them is something like "no interpolation" - it makes
set of spheres without connections - then in fact it works for spheres just
like mesh for triangles - have own internal bounding hierarchy, shares data
between instances and reserves memory only for center, radius and pointer to
texture. My problem is that I don't know how to call this kind of
interpolation. I don't like the
  no_interpolation
  interpolation off
  spline off
and have no language experience to choose anything better than
  no_spline
So any help with this language problem? Note it should look readable when more
than one interpolation type is specified:
  sphere_sweep{
    // make rounded cylinder ...
    linear_spline
    sphere{x 1 pigment{rgb 1}
    sphere{y 0.1 pigment{red 0.1}}
    // ... and one additional separated sphere
    no_spline
    sphere{z 0.2 texture{My_Favourite}}
  }

ABX

Post a reply to this message

ABX wrote:
> 
> Any idea for nice name for interpolation without interpolation ?
> In my rewrtitten sphere_sweep module I have added additional types for
> interpolations. One of them is something like "no interpolation" - it makes
> set of spheres without connections - then in fact it works for spheres just
> like mesh for triangles - have own internal bounding hierarchy, shares data
> between instances and reserves memory only for center, radius and pointer to
> texture. My problem is that I don't know how to call this kind of
> interpolation. I don't like the
>   no_interpolation
>   interpolation off
>   spline off
> and have no language experience to choose anything better than
>   no_spline
> [...]

I think it should have 'connection' somewhere.  This clearly shows there
is no connection at all between the spheres and not just no interpolation
(which could mean anything).

How about:

connection off | linear_spline | cubic_spline | ...

BTW this sounds like a very interesting feature after all.  I'm just
rendering a 6000 spheres mechanical simulation and it's taking ages (not
for the simulation but for the render).

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 Tue, 10 Sep 2002 16:05:56 +0200, Christoph Hormann <chr### [at] gmxde>
wrote:
> connection off | linear_spline | cubic_spline | ...

You mean like you wrote or :

  connection TYPE_OF_CONNECTION
  TYPE_OF_CONNECTION: off | linear_spline | cubic_spline

what about replacing 'connection' with 'sweep_type' ?

ABX

Post a reply to this message

ABX wrote:
> 
> You mean like you wrote or :
> 
>   connection TYPE_OF_CONNECTION
>   TYPE_OF_CONNECTION: off | linear_spline | cubic_spline
> 
> what about replacing 'connection' with 'sweep_type' ?
> 

I find connection very intuitive.  sweep_type seems rather meaningless to
me.  Especially 'sweep_type off'.

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

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

> Any idea for nice name for interpolation without interpolation ?

In the case of sphere_sweeps, don't you define a path it shall sweep on?  So
maybe call it "path" or "path_type".

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

On Tue, 10 Sep 2002 17:21:01 +0200, "Thorsten Froehlich" <tho### [at] trfde>
wrote:
> In the case of sphere_sweeps, don't you define a path it shall sweep on?  So
> maybe call it "path" or "path_type".

Yes, 'path' sounds nice. So one vote for 'connection' and one for 'path'. Any
other vote? My heart is now for 'path_type FLOAT' becouse it is made with
short words and I don't like that I have to reserve new token for every new
type of interpolation. There are also subtypes for interpolations when I can't
choose nice names. For example there are two toroidal connection types: one by
Ron Parker and one by Slime (IIRC). Making type float is better IMO. What do
you think?

ABX

Post a reply to this message

ABX wrote:

> On Tue, 10 Sep 2002 17:21:01 +0200, "Thorsten Froehlich" <tho### [at] trfde>
> wrote:
> 
>>In the case of sphere_sweeps, don't you define a path it shall sweep on?  So
>>maybe call it "path" or "path_type".
>>
> 
> Yes, 'path' sounds nice. So one vote for 'connection' and one for 'path'. Any
> other vote? My heart is now for 'path_type FLOAT' becouse it is made with
> short words and I don't like that I have to reserve new token for every new
> type of interpolation. There are also subtypes for interpolations when I can't
> choose nice names. For example there are two toroidal connection types: one by
> Ron Parker and one by Slime (IIRC). Making type float is better IMO. What do
> you think?
> 
> ABX
> 

My vote, if you care, would go for 'path' but no float, a keyword for 
each type/kind. (do you really remember by looking at the SDL that there
is various projection for image (using map_type) and which number
correspond to what kind ?
I do not. If you do (without looking at the help file or code),
please fill the following form to describ map_type in image_map:

  default value:
  0 :
  1 :
  2 :
  3 :
  4 :
  5 :
  6 :

I will check it later against the documentation!!

Post a reply to this message

On Wed, 11 Sep 2002 12:13:45 +0200, Le Forgeron <jgr### [at] freefr> wrote:
> My vote, if you care

I care, just don't be angry if I choose otherwise :-)

> would go for 'path' but no float, a keyword for 
> each type/kind. (do you really remember by looking at the SDL that there
> is various projection for image (using map_type) and which number
> correspond to what kind ?
> I do not.

I do not either but I don't like so many keywords used so rarely. Apropriate
include file with identifiers assigned to floats could be enough. There are
two include files with identifiers assigned this way: "functions.inc" and
"const.inc" ?

One of my teachers at technical university learned me that I shoudn't remember
every equation, piece of kowledge, keyword. I should know how to find it if I
need it.

ABX

Post a reply to this message

ABX wrote:
> 
> Yes, 'path' sounds nice. So one vote for 'connection' and one for 'path'. Any
> other vote? My heart is now for 'path_type FLOAT' becouse it is made with
> short words and I don't like that I have to reserve new token for every new
> type of interpolation. There are also subtypes for interpolations when I can't
> choose nice names. For example there are two toroidal connection types: one by
> Ron Parker and one by Slime (IIRC). Making type float is better IMO. What do
> you think?

'path_type FLOAT' seems fine, i agree using a float to specify the type is
a good idea, like with image_map map_type.  

If you don't want to introduce a new keyword at all you could use 'method'
like in media but it would be quite difficult to understand.

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

ABX wrote:

> On Wed, 11 Sep 2002 12:13:45 +0200, Le Forgeron <jgr### [at] freefr> wrote:
> 
>>My vote, if you care
>>
> 
> I care, just don't be angry if I choose otherwise :-)
> 


No problem, it's your patch...


> 
>>would go for 'path' but no float, a keyword for 
>>each type/kind. (do you really remember by looking at the SDL that there
>>is various projection for image (using map_type) and which number
>>correspond to what kind ?
>>I do not.
>>
> 
> I do not either but I don't like so many keywords used so rarely. Apropriate
> include file with identifiers assigned to floats could be enough. There are
> two include files with identifiers assigned this way: "functions.inc" and
> "const.inc" ?
> 
> One of my teachers at technical university learned me that I shoudn't remember
> every equation, piece of kowledge, keyword. I should know how to find it if I
> need it.
> 


That's ok for technical inclined people, not for user-friendliness.
Let's me have a last 'extrem' example with POV.

You know there is a poly object... From your teacher point of view, it 
is fine as it is. The order of the poly comes first, then the user must 
provide the right number of float value. It's all in the doc, so no 
problem (even if since the extension, the doc does not give the order 
for more than 7th order while the root solver can handle up to 15th!).

But from a user-friendliness aspect, when Joe user (with a degree in 
math, a.k.a not a mathemacaly ignorant) wants to have a poly equation to 
be rendered, he has to carrefully spot the place for all values, and 
simple things like x^6+y^5+z^4-10=0 turn into a nightmare of values.

If keyword, instead of positional syntax, had been used, it would be
far more easier to use the poly object, and p.b.i might be full of them.
Instead of a long collection of values (with a lot of zero), using 
keyword would have make it easier (*):

   poly { x6 1 y5 1 z4 1 const -10 }

If later the user wants to add a x^2yz^3 term, it's also far easier than
retrieving the correct position in the list:

   poly { x6 1 y5 1 z4 1 const -10 x2yz3 -3 }

As a bad thing is always worth something, I believe iso-surface wouldn't 
have been there so early if poly would have been easier in syntax, and 
their success might have been reduced...



*: Using the classical 'keyword value' paradigm, instead of the 
expectable (but more programmer-hostile) 'value [keyword]' which would
allow "poly { 1 x6 +1 y5 +1 z4 -10 }" (using the unary + for once !!!)

P.S: I removed the order of the poly in the example, but I'm not sure 
that's a good idea, even if the order could be computed at the end of 
the parsing of the poly. Anyway, It's only for the illustration, there 
is no real patch here.

P.S.2: the number of keywords needed for the 15th order poly is between 
800 and 900...(exact number is in the source code formulae) which also 
means good luck to try a 15 th order poly in pov now (that's only about 
800 zero to type and some rigthly placed other values!!!) [I do not want 
to debug your formulae!]

P.S.3: You might ask what the relation with your question... my answer 
is 'Think about user-friendliness, dismiss if you want, but think about it'.

Post a reply to this message

Le Forgeron wrote:
> 
> [...]
> 
> If keyword, instead of positional syntax, had been used, it would be
> far more easier to use the poly object, and p.b.i might be full of them.
> Instead of a long collection of values (with a lot of zero), using
> keyword would have make it easier (*):
> 
>    poly { x6 1 y5 1 z4 1 const -10 }
> 
> If later the user wants to add a x^2yz^3 term, it's also far easier than
> retrieving the correct position in the list:
> 
>    poly { x6 1 y5 1 z4 1 const -10 x2yz3 -3 }
> 

It is fairly possible to program this with macros, think of something
like:

Poly4(1*X6, 1*Y5, 1*Z4, -10*Const)
Poly5(1*X6, 1*Y5, 1*Z4, -10*Const, -3*X2YZ3)

X6, Y5, Z4 and all the others would be (4D) vectors:

#declare X6=<6, 0, 0, 1>;
#declare Y5=<0, 5, 0, 1>;
#declare Z4=<0, 0, 4, 1>;
#declare X2YZ3=<2, 1, 3, 1>;
#declare Const=<0, 0, 0, 1>;

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

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

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

> Yes, 'path' sounds nice. So one vote for 'connection' and one for 'path'. Any
> other vote? My heart is now for 'path_type FLOAT' becouse it is made with
> short words and I don't like that I have to reserve new token for every new
> type of interpolation. There are also subtypes for interpolations when I can't
> choose nice names. For example there are two toroidal connection types: one by
> Ron Parker and one by Slime (IIRC). Making type float is better IMO. What do
> you think?

I find keywords much easier to read and write than numbers, I feel that 
you should only use a number for a numeric value. And I really hope you 
meant "path_type INT". (there's no difference as far as POV is 
concerned, but for documentation you would want to say it is an integer 
value)

I would do something like:
type multisphere
type catmull_rom
type cubic
type linear
...

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

-- 
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 13:51:11 +0200, Le Forgeron <jgr### [at] freefr> wrote:
> That's ok for technical inclined people, not for user-friendliness.

I don't like user-friendliness at some places. While I agree that making tools
user-friendly increases market but at the same time it increases "stupidity"
when it is applied in wrong place - where some level of intelligence is
expected from user and additional tools like declarations and macros are
served.

> But from a user-friendliness aspect, when Joe user (with a degree in 
> math, a.k.a not a mathemacaly ignorant) wants to have a poly equation to 
> be rendered, he has to carrefully spot the place for all values, and 
> simple things like x^6+y^5+z^4-10=0 turn into a nightmare of values.

If HF_Sphere macro can create complicated smooth mesh from pattern why another
macro can't create poly object definition from apropriate input data ?

> As a bad thing is always worth something, I believe iso-surface wouldn't 
> have been there so early if poly would have been easier in syntax, and 
> their success might have been reduced...

:-)

> P.S.3: You might ask what the relation with your question... my answer 
> is 'Think about user-friendliness, dismiss if you want, but think about it'.

I think I think :-)

ABX

Post a reply to this message

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

ABX wrote:
> 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

float !

Post a reply to this message

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

We will forget it then ;-)

    Thorsten

Post a reply to this message

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

keyword!

    Thorsten

Post a reply to this message

On Thu, 12 Sep 2002 15:30:10 +0200, "Thorsten Froehlich" <tho### [at] trfde>
wrote:
> keyword!
>
>    Thorsten

Are you representing general stategy of the team with this vote ? I'm just not
sure how many votes I should count ;-)

Serously if this is suggestion from the team I would like to follow it. So ?

ABX

Post a reply to this message

Thorsten Froehlich wrote:
> 
> > > Any help to fullfill democracy in this syntax designing ?
> >
> > float !
> 
> keyword!

float!

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

Christoph Hormann wrote:
> 
> Thorsten Froehlich wrote:
> >
> > > > Any help to fullfill democracy in this syntax designing ?
> > >
> > > float !
> >
> > keyword!
> 
> float!

Keyword!

-- 
Ken Tyler

Post a reply to this message

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

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

Keyword.

-- 
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 <ne7vnuc47tqp5jpdqfn51nttlis14agp54@4ax.com>,
 ABX <abx### [at] abxartpl> wrote:

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

Still, including one file is probably more overhead than adding all the 
keywords contained in a couple files.


> > Requiring an external include file.
> So many languages use header files with definitions so nothing new.

So does POV, functions.inc. It is annoying though, confusing to newbies, 
and slower than a built-in keyword.


> > 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 will be looking at it...I'm just busy with school and lots of other 
personal projects. (the CSDL/Sapphire language, Lumini raytracer, 3D 
math and color-image libraries, a VR engine, a few others...)


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

No, I was talking about my CSDL project:
http://home.earthlink.net/~cjameshuff/csdl/csdl.html

It's a language I created, I'm using it to control the raytracer and VR 
engine. That's an old version though...I'll release a new one fairly 
soon.

The acronym seemed clumsy and a bit inappropriate, since the language is 
useful for more than simulations. I like sapphires, and it fit in with 
the Perl, Ruby, ... sequence. I didn't know there was a window manager 
with that name...

-- 
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 <3D8### [at] freefr>,
 Nicolas Calimet <pov### [at] freefr> wrote:

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

No, I don't mean this. I was talking about a hypothetical way of doing 
it, not a way to modify the current POV-Ray code.


> 	Putting the last resolved symbol at the beginning of the
> list assumes a high probability to find the same symbol again.

Not really...if it isn't used again, it quickly moves back "behind" the 
more often used keywords. The more often resolved ones spend more time 
at the front of the list, where they are hit more quickly. It is kind of 
like using the front of the list as a cache, it is extremely simple and 
much faster overall than just going through the list.


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

For the POV-Ray parser, it is probably the fastest way. Sapphire 
identifiers are pointers to strings: all identifiers with the same 
string point to the same memory location, so comparison is fast, and 
symbols are stored in a linked list, so it is extremely fast to remove 
an element and push it on at the front of the list.
It would be possible to use a hash table, and it might be faster, but it 
would use more memory and the number of symbols in a table is usualy too 
small to get a real benefit. For POV, the requirements are different, 
and a hash table is probably the best way.

I might eventually use a hash table for the compiler part of Sapphire, 
it currently does a string comparison against every built-in token until 
it finds a match. Compile times are already fast enough that I don't 
even notice the delay, though.

-- 
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 <tf51ouso920fksq7c8h0o92mot1iqg842h@4ax.com> , ABX 
<abx### [at] abxartpl>  wrote:

> Are you representing general stategy of the team with this vote ? I'm just not
> sure how many votes I should count ;-)

No, just my opinion!  Which means it will count something like 20% if there
would be vote in the team assuming the average "voter" participation ;-)

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

In article <chr### [at] netplexaussieorg> , 
Christopher James Huff <chr### [at] maccom>  wrote:

> So does POV, functions.inc. It is annoying though, confusing to newbies,
> and slower than a built-in keyword.

It isn't slower as far as the implementation is concerned.  And parsing
slowdowns do not really matter for functions.inc in a non-trivial scene.  It
does keep out a hundred or so keywords however, which is a great benefit for
everybody who does not happen to be using one of those functions in a
particular scene.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

On Thu, 12 Sep 2002 13:22:59 +0200, ABX <abx### [at] abxartpl> wrote:
> Any help to fullfill democracy in this syntax designing ?

keyword:
  Thorsten Froehlich, Christopher James Huff, Ken Tyler, J�r�me Grimbert

float:
  Philippe Debar, Christoph Hormann, Wlodzimierz Skiba

Thanks. I'll try to make something in the middle. I'll use integers to
recognize tokens ;-)

ABX

Post a reply to this message

In article <3d810f73@news.povray.org>,
 "Thorsten Froehlich" <tho### [at] trfde> wrote:

> > So does POV, functions.inc. It is annoying though, confusing to newbies,
> > and slower than a built-in keyword.
> It isn't slower as far as the implementation is concerned.  And parsing
> slowdowns do not really matter for functions.inc in a non-trivial scene.  It
> does keep out a hundred or so keywords however, which is a great benefit for
> everybody who does not happen to be using one of those functions in a
> particular scene.

A user-defined identifier is just as fast to identify and resolve as 
identifying a token? I'm doubtful about that...I wouldn't be surprised 
if the difference is too small to be important, though. It's somewhat 
annoying when you forget to include functions.inc (there have been 
several users with that problem), but it is useable and better than 
integer codes.

-- 
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 <t584ouk300oi4mdttqhkj4le7hfu1dth6q@4ax.com>,
 ABX <abx### [at] abxartpl> wrote:

> Thanks. I'll try to make something in the middle. I'll use integers to
> recognize tokens ;-)

What do you mean? I've run that through my head several times, and can't 
see what you could be planning.

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

"ABX" <abx### [at] abxartpl> a écrit dans le message de news:
t584ouk300oi4mdttqhkj4le7hfu1dth6q@4ax.com...
> On Thu, 12 Sep 2002 13:22:59 +0200, ABX <abx### [at] abxartpl> wrote:
> > Any help to fullfill democracy in this syntax designing ?
>
> keyword:
>   Thorsten Froehlich, Christopher James Huff, Ken Tyler, Jérôme Grimbert

Don't rule out the possibility that Ken Tyler put "keyword" just for the
sake of symmetry in the thread ;-) Float, keyword, float, keyword... Putting
"float" would have ruined the whole thing.

G.


--
**********************
http://www.oyonale.com
**********************
- Graphic experiments
- POV-Ray and Poser computer images
- Posters

Post a reply to this message

Gilles Tran wrote:
> 
> "ABX" <abx### [at] abxartpl> a écrit dans le message de news:
> t584ouk300oi4mdttqhkj4le7hfu1dth6q@4ax.com...
> > On Thu, 12 Sep 2002 13:22:59 +0200, ABX <abx### [at] abxartpl> wrote:
> > > Any help to fullfill democracy in this syntax designing ?
> >
> > keyword:
> >   Thorsten Froehlich, Christopher James Huff, Ken Tyler, Jérôme Grimbert
> 
> Don't rule out the possibility that Ken Tyler put "keyword" just for the
> sake of symmetry in the thread ;-)

Would I do that?

-- 
Ken Tyler

Post a reply to this message

"Ken" <tyl### [at] pacbellnet> a écrit dans le message de news:
3D829CE1.156832C4@pacbell.net...

> Would I do that?

Without any doubt.

A further enticement was the lack of identation in your answer, coming after
perfectly indented >> ones. The addition of a uppercase "K" was a nice touch
of originality too.
Now you may actually prefer the "keyword" solution but this would be getting
annoyingly on-topic.

G.

--
**********************
http://www.oyonale.com
**********************
- Graphic experiments
- POV-Ray and Poser computer images
- Posters

Post a reply to this message

Gilles Tran wrote:
> 
> "Ken" <tyl### [at] pacbellnet> a écrit dans le message de news:
> 3D829CE1.156832C4@pacbell.net...
> 
> > Would I do that?
> 
> Without any doubt.

Ouch! I'm wounded.
 
> A further enticement was the lack of identation in your answer, coming after
> perfectly indented >> ones. The addition of a uppercase "K" was a nice touch
> of originality too.

The wolf gives a sheepish grin.

> Now you may actually prefer the "keyword" solution but this would be getting
> annoyingly on-topic.

It is easier to search the docs for a partially remembered keyword than it is
to find a single float variable. In my advanced state of decay I need every
edge I can get to keep up with you younger folks.

-- 
Ken Tyler

Post a reply to this message

On Fri, 13 Sep 2002 15:11:55 -0400, Christopher James Huff <chr### [at] maccom>
wrote:
> What do you mean?

I will use keywords.

ABX

Post a reply to this message

ABX <abx### [at] abxartpl> wrote:

> Any idea for nice name for interpolation without interpolation ?
> In my rewrtitten sphere_sweep module I have added additional types for
> interpolations. One of them is something like "no interpolation" - it makes
> set of spheres without connections - then in fact it works for spheres just

What do you mean by "set of spheres", the ones that control the shape of
the sweep or the sweep itself, with fewer spheres than infinity? :) That
would be important, because with "no interpolation" I would associate no
interpolation of the control spheres, which would result in no sweep at
all (or, if you want to make them visible, the control spheres
themselves).

I guess what you mean is throw away most of the spheres of the sweep,
something like the famous "merry.pov" picture, if you happen to know
this one? Then you have the same interpolation as with the sphere_sweep
as it is now: linear, cubic and b-spline, just the result will look
different. If you want to have this, I would find it more intuitive to
have a whole new keyword for this.

You may need to have additional keywords, anyways, since how do you
specify how many spheres you want in the sweep, or how closely they
should be packed?

One last thought: This would be not a "real" sphere sweep at all after
the definition by J.J. van Wijk, but that's a question left to the
philosophers, I guess. ;)

Jochen Lippert

-- 
No smilies were harmed in the making of this message ;)

Post a reply to this message