 |
 |
|
 |
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
OK, can someone tell me why this generates a parse error:
#declare Spline = spline {cubic_spline
-2/13, <-1,0,0>
-1/13, <0,0,0>
0, <1,0,0>
1/13, <5,0,0>
2/13, <8,0,0>
}
While this doesn't:
#declare Spline = spline {cubic_spline
-2/13, <-1,0,0>
(-1/13), <0,0,0>
0, <1,0,0>
1/13, <5,0,0>
2/13, <8,0,0>
}
The only difference between these two bits of code is the brackets
around -1/13.
I'm hopelessly confused as to why the brackets are necessary on that one
line, and that one line alone.
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
In article <3c4990b9$1@news.povray.org>,
"Andrew" <ast### [at] hotmail com> wrote:
> OK, can someone tell me why this generates a parse error:
>
> #declare Spline = spline {cubic_spline
> -2/13, <-1,0,0>
> -1/13, <0,0,0>
> 0, <1,0,0>
> 1/13, <5,0,0>
> 2/13, <8,0,0>
> }
You don't have commas separating the items. POV-Ray doesn't care about
spaces or separate lines, it sees:
-2/13, <-1,0,0>
-1/13, <0,0,0>
as:
-2/13, <-1,0,0> - 1/13, <0,0,0>
When you add in the parentheses, it sees:
-2/13, <-1,0,0> (-1/13), <0,0,0>
and can figure out that the "-1/13" is a separate value.
--
--
Christopher James Huff <chr### [at] mac com>
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Aha! Thank you. I thought it would be something really obvious, and I
had wondered why commas weren't necessary. I guess I shall simply use
commas at all times now.
> You don't have commas separating the items. POV-Ray doesn't care about
> spaces or separate lines, it sees:
> -2/13, <-1,0,0>
> -1/13, <0,0,0>
> as:
> -2/13, <-1,0,0> - 1/13, <0,0,0>
>
> When you add in the parentheses, it sees:
> -2/13, <-1,0,0> (-1/13), <0,0,0>
> and can figure out that the "-1/13" is a separate value.
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Why are those commas optional anyway?
- Slime
[ http://www.slimeland.com/ ]
[ http://www.slimeland.com/images/ ]
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
In article <3c49da50$1@news.povray.org>, "Slime" <noo### [at] hotmail com>
wrote:
> Why are those commas optional anyway?
Backwards compatibility. The same code is used to parse all commas, and
that code was written to support the old <xVal yVal zVal> vector syntax,
so it tries to accept blank spaces. Sometimes it accepts them when it
shouldn't, but it has no way to tell...
--
--
Christopher James Huff <chr### [at] mac com>
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Andrew <ast### [at] hotmail com> wrote:
: had wondered why commas weren't necessary.
The main reason is backwards compatibility, but there are other really good
reasons as well.
For example, suppose that you wanted to make the spline points inside a
loop. You could do something like this:
spline
{ cubic_spline
#declare Ind = 0;
#while(Ind < 10)
Ind, <Ind, Ind*Ind, 0>
#declare Ind = Ind+1;
#end
}
Now suppose that the commas were mandatory. That wouldn't work anymore.
It won't work either if you add a comma after the vector.
I'll let it as an exercise how complicated that would need to be done if
commas were mandatory.
--
#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 <3c49df0d@news.povray.org>, Warp <war### [at] tag povray org>
wrote:
> I'll let it as an exercise how complicated that would need to be done if
> commas were mandatory.
Not very. I always do it anyway, for possible forwards compatability in
case a future version makes them required.
spline {cubic_spline
#declare Ind = 0;
#while(Ind < 9)
Ind, <Ind, Ind*Ind, 0>
#declare Ind = Ind + 1;
#end
Ind, <Ind, Ind*Ind, 0>
}
--
--
Christopher James Huff <chr### [at] mac com>
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
"Warp" <war### [at] tag povray org> wrote:
> Now suppose that the commas were mandatory. That wouldn't work anymore.
> It won't work either if you add a comma after the vector.
> I'll let it as an exercise how complicated that would need to be done if
> commas were mandatory.
Only one line more, if the following parses ...
spline
{ cubic_spline
0, 0
#declare Ind = 1;
#while(Ind < 10)
,Ind, <Ind, Ind*Ind, 0>
#declare Ind = Ind+1;
#end
}
OK .. I(We all) know, what you mean, but probably this example was too simple
...
Question: How far back do we need Backward-compatibility ?
Commas are standard at least since 3.0, so I think somewhere should be a
hard-cut ...
_IF_ all the suggestions for the (somewhere in the far future) POV4 will
come true, we
will have a complete(?) different SDL, with hardly any way for
backward-compatibility ...
--
[Talking about cardriving]
"People are opstacles?
Oh...I always treat them as bonus points..." [Ian Burgmyer in p.o-t]
// Jan Walzer <jan### [at] lzer net>
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Christopher James Huff <chr### [at] mac com> wrote:
: Not very. I always do it anyway, for possible forwards compatability in
: case a future version makes them required.
If a future version makes commas mandatory, that would be a huge step
*backwards* in versatility.
(Unless a #-command can replace a comma.)
--
#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 <3c49ec58@news.povray.org>, Warp <war### [at] tag povray org>
wrote:
> If a future version makes commas mandatory, that would be a huge step
> *backwards* in versatility.
How?
--
--
Christopher James Huff <chr### [at] mac com>
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Christopher James Huff <chr### [at] mac com> wrote:
:> If a future version makes commas mandatory, that would be a huge step
:> *backwards* in versatility.
: How?
Because it would disallow making automatic generation of long lists of
items (number, vectors...) in such a simple and versatile way as currently.
Currently it's just enough to create the list of items in a loop, without
having to take into account that there should be one comma less than the
number of items.
(Note that the problem with the solution you suggested is that there might
be cases where the loop is not executed even once, that is, no items are
created at all.)
--
#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 <3c4a05f7@news.povray.org>, Warp <war### [at] tag povray org>
wrote:
> Because it would disallow making automatic generation of long lists of
> items (number, vectors...) in such a simple and versatile way as currently.
> Currently it's just enough to create the list of items in a loop, without
> having to take into account that there should be one comma less than the
> number of items.
> (Note that the problem with the solution you suggested is that there might
> be cases where the loop is not executed even once, that is, no items are
> created at all.)
In this case it's an extra line and some math in the loop. The cases you
mention aren't that common, and you can still put a comma on every line
but the last, it's just a little more complex. Not by very much,
either...just by one #if() statement in the mix.
--
--
Christopher James Huff <chr### [at] mac com>
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
On 2002-01-20 00:20, Christopher James Huff <chr### [at] mac com> wrote:
> In article <3c4a05f7@news.povray.org>, Warp <war### [at] tag povray org>
> wrote:
>
>> Because it would disallow making automatic generation of long lists of
>> items (number, vectors...) in such a simple and versatile way as currently.
>> Currently it's just enough to create the list of items in a loop, without
>> having to take into account that there should be one comma less than the
>> number of items.
>> (Note that the problem with the solution you suggested is that there might
>> be cases where the loop is not executed even once, that is, no items are
>> created at all.)
>
> In this case it's an extra line and some math in the loop. The cases you
> mention aren't that common, and you can still put a comma on every line
> but the last, it's just a little more complex.
You could also allow a superfluous comma after the last item, like many
other programming languages (e.g., C and perl) do.
hp
--
_ | Peter J. Holzer | Hört doch dieses törichtes Volk ohne
|_|_) | Sysadmin WSR | Verstand, die Augen haben und nicht sehen,
| | | hjp### [at] hjp at | die Ohren haben und nicht hören!
__/ | http://www.hjp.at/ | -- Jeremia 5:21
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
On Sat, 19 Jan 2002 19:20:27 -0500, Christopher James Huff <chr### [at] mac com>
wrote:
> just by one #if() statement in the mix.
parsing is slowest part of POV, such additional #if() could slow down simple
loops more then twice sometimes imo
ABX
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
On Sat, 19 Jan 2002 22:30:07 +0100, Jan Walzer wrote:
> Question: How far back do we need Backward-compatibility ?
> Commas are standard at least since 3.0, so I think somewhere should be a
> hard-cut ...
But why? The cases where it's still possible to leave them out are perfectly
unambiguous anyway, so why require them?
--
#macro R(P)z+_(P)_(P)_(P+1)_(P+1)+z#end#macro Q(C,T)bicubic_patch{type 1u_steps
6v_steps 6R(1)R(3)R(5)R(7)pigment{rgb z}}#end#macro _(Y)#local X=asc(substr(C,Y
,1))-65;<T+mod(X,4)div(X,4)9>-2#end#macro O(T)Q("ABEFUQWS",T)Q("WSXTLOJN",T)#
end O(0)O(3)Q("JNKLCGCD",0)light_source{x 1}// ron### [at] povray org
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
In article <0tin4usrh1hbhf2td9the8l6l19rctr2e0@4ax.com>,
W?odzimierz ABX Skiba <abx### [at] babilon org> wrote:
> parsing is slowest part of POV, such additional #if() could slow down simple
> loops more then twice sometimes imo
Only if you only loop once, for example when you have two items, you
might have an extra millisecond or so.
--
--
Christopher James Huff <chr### [at] mac com>
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|
 |