POV-Ray : Newsgroups : povray.general : Spline problem Server Time
6 Aug 2024 19:25:30 EDT (-0400)
  Spline problem (Message 1 to 10 of 16)  
Goto Latest 10 Messages Next 6 Messages >>>
From: Andrew
Subject: Spline problem
Date: 19 Jan 2002 10:28:57
Message: <3c4990b9$1@news.povray.org>
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

From: Christopher James Huff
Subject: Re: Spline problem
Date: 19 Jan 2002 11:12:36
Message: <chrishuff-9C93D9.11132819012002@netplex.aussie.org>
In article <3c4990b9$1@news.povray.org>,
 "Andrew" <ast### [at] hotmailcom> 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] maccom>


Post a reply to this message

From: Andrew
Subject: Re: Spline problem
Date: 19 Jan 2002 11:15:06
Message: <3c499b8a@news.povray.org>
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

From: Slime
Subject: Re: Spline problem
Date: 19 Jan 2002 15:42:56
Message: <3c49da50$1@news.povray.org>
Why are those commas optional anyway?

- Slime
[ http://www.slimeland.com/ ]
[ http://www.slimeland.com/images/ ]


Post a reply to this message

From: Christopher James Huff
Subject: Re: Spline problem
Date: 19 Jan 2002 16:00:14
Message: <chrishuff-54F4FD.16010819012002@netplex.aussie.org>
In article <3c49da50$1@news.povray.org>, "Slime" <noo### [at] hotmailcom> 
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] maccom>


Post a reply to this message

From: Warp
Subject: Re: Spline problem
Date: 19 Jan 2002 16:03:10
Message: <3c49df0d@news.povray.org>
Andrew <ast### [at] hotmailcom> 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

From: Christopher James Huff
Subject: Re: Spline problem
Date: 19 Jan 2002 16:29:31
Message: <chrishuff-1EEB89.16302619012002@netplex.aussie.org>
In article <3c49df0d@news.povray.org>, Warp <war### [at] tagpovrayorg> 
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] maccom>


Post a reply to this message

From: Jan Walzer
Subject: Re: Spline problem
Date: 19 Jan 2002 16:29:55
Message: <3c49e553$1@news.povray.org>
"Warp" <war### [at] tagpovrayorg>  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] lzernet>


Post a reply to this message

From: Warp
Subject: Re: Spline problem
Date: 19 Jan 2002 16:59:53
Message: <3c49ec58@news.povray.org>
Christopher James Huff <chr### [at] maccom> 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

From: Christopher James Huff
Subject: Re: Spline problem
Date: 19 Jan 2002 17:44:12
Message: <chrishuff-4B8A52.17450919012002@netplex.aussie.org>
In article <3c49ec58@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   If a future version makes commas mandatory, that would be a huge step
> *backwards* in versatility.

How?

-- 
 -- 
Christopher James Huff <chr### [at] maccom>


Post a reply to this message

Goto Latest 10 Messages Next 6 Messages >>>

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.