[running Windows 10]

(This might be old news?)
I was playing with splines recently, and came across a strange quirk when using
negative 'index' or parameter values for some of the points: Apparently, a comma
separator is needed after those points (otherwise a fatal error when the spline
is parsed), whereas positive-parameter points need no commas. This occurs in
both v3.7.0 and 3.8 beta 1. (As far as I know, there is no caveat or restriction
about creating points with negative index values.) The type of spline used--
linear, cubic etc-- has no effect on this behavior.

The documentation at "3.3.1.11 Spline" is somewhat unclear as to a *requirement*
for commas between separate points:

"The first item gives the type of interpolation [linear, cubic, etc]...
Following this are a number of float values each followed by a position vector,
all separated by commas." But the spline example there uses no comma separators,
and my own experience is that that are usually not needed.

With negative-index points, there appears to be a pattern(?) to the behavior.
Some examples:

This spline has only ONE negative-index point-- and parses OK as-is; no commas
between the points are needed:
#declare MY_SP_1 =
spline{
     natural_spline
    -0.3, < .3, .6, .5 >
     0, < -.52, -.36, -.59>
     0.5, < -1.0, .27, .68>,
     1.0, < .6, -.95, -.15>
     2.0, < -.75, -.52, -1.5>
     2.7, <.3,.5,2>
 }

This has TWO negative index points-- a comma is required after
the FIRST point only:
#declare MY_SP_2 =
spline{
     linear_spline
    -0.45, <.1,.3,-.1>,
    -0.3, < .3, .6, .5 >
     0, < -.52, -.36, -.59>
     0.5, < -1.0, .27, .68>
     1.0, < .6, -.95, -.15>
     2.0, < -.75, -.52, -1.5>
     2.7, <.3,.5,2>
 }

This one has TWO negative index points at the beginning (as above), plus
another one later-- a comma is required  after the FIRST point and another
*before* the later negative-index.
#declare MY_SP_3 =
spline{
     cubic_spline
   -0.45, <.1,.3,-.1>,
   -0.3, < .3, .6, .5 >
    0, < -.52, -.36, -.59>
    0.5, < -1.0, .27, .68>, // comma needed here, preceding the next
                            // negative index
   -1.0, < .6, -.95, -.15>
    2.0, < -.75, -.52, -1.5>
    2.7, <.3,.5,2>
 }


This one has THREE negative index points-- commas are required after the FIRST
and SECOND points:
#declare MY_SP_4 =
spline{
     cubic_spline
    -0.6, <.2,.1,.3>,
    -0.45, <.1,.3,-.1>,
    -0.3, < .3, .6, .5 >
     0, < -.52, -.36, -.59>
     0.5, < -1.0, .27, .68>
     1.0, < .6, -.95, -.15>
     2.0, < -.75, -.52, -1.5>
     2.7, <.3,.5,2>
 }

Post a reply to this message

Because the parser has no idea if you're making another point, or subtracting a
"vector-elevated" scalar value from the preceding vector.

<1, 1, 1> - 0.25 = <1, 1, 1> - <0.25, 0.25, 0.25> = <0.75, 0.75 0.75>

- BW

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Because the parser has no idea if you're making another point, or subtracting a
> "vector-elevated" scalar value from the preceding vector.
>
> <1, 1, 1> - 0.25 = <1, 1, 1> - <0.25, 0.25, 0.25> = <0.75, 0.75 0.75>
>
> - BW

Hmmm, that does make sense once it's dissected. But should the parser be 'fixed'
somehow, to eliminate this (seemingly) strange behavior? (i.e., unexpected
behavior from a typical user's standpoint?) One problem is with the rather
generic and misleading parse-error statement when the commas are left out:

"Parse error: No matching } , < found instead." Huh??

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
>
> But should the parser be 'fixed'
> somehow, to eliminate this (seemingly) strange behavior?

The easier solution would be to re-word the spline documentation, to make it
more consistent: The example there should have commas after each spline point
(whether or not they are actually needed); or, a caveat should be added about
negative-index points. Something like:
"While there is no restriction on using negative-parameter values for spline
points, be aware that the parser will have trouble distinguishing one such point
from another"-- using your dissected example to show why. :-)

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
One problem is with the rather
> generic and misleading parse-error statement when the commas are left out:
>
> "Parse error: No matching } , < found instead." Huh??

It's not misleading at all.
You're just not following through with my explanation and seeing what the
inevitable result is once the parser does the subtraction.

It's now expecting a new scalar value along the spline, and instead, you're
providing it with a vector value.

- BW

Post a reply to this message

hi,

"Kenneth" <kdw### [at] gmailcom> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
> > But should the parser be 'fixed'
> > somehow, to eliminate this (seemingly) strange behavior?
>
> The easier solution would be ...

(in my opinion) for users to not take advantage of a "lax" parser.  if you have
a list, then well, comma-separate the items (you're not a lawyer, are you ?
</grin>).  where you '#declare', even if the statement parses without the
semicolon, be consistent and write one anyway.  "help" the parser rather than
making it work harder ;-).

($0.02 and all that)


regards, jr.

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:

> (in my opinion) for users to not take advantage of a "lax" parser.  if you have
> a list, then well, comma-separate the items (you're not a lawyer, are you ?
> </grin>).  where you '#declare', even if the statement parses without the
> semicolon, be consistent and write one anyway.  "help" the parser rather than
> making it work harder ;-).

Betterer practice I think would be to just dump it all into a mixed array, (or
array of arrays), and then use a loop to define the spline.

Single-use containers are wasteful and annoying.

Best would be if we could use arrays as actual matrices - because I'm sure some
interesting things could be done with neat matrix magic tricks.

- BW

Post a reply to this message

On 28.04.2025 19:17, jr wrote:

> (in my opinion) for users to not take advantage of a "lax" parser.  if you have
> a list, then well, comma-separate the items

I can only add to this that following strict pattern definitely 
simplifies things for *my* built-in parser ;-)

OT: it reminds me how I wrote a PPM and PGM image format module in 
Python. Since PNM specs are rather fluid, everybody seem to follow their 
own header scheme, so I gave up thinking normally and started mangling 
're' regexp pattern until it started to consider anything but image data 
as image header ;-)

-- 
Ilyich the Toad
https://dnyarri.github.io/

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
> One problem is with the rather
> > generic and misleading parse-error statement when the commas are left out:
> >
> > "Parse error: No matching } , < found instead." Huh??
>
> It's not misleading at all.
> You're just not following through with my explanation and seeing what the
> inevitable result is once the parser does the subtraction.
>
> It's now expecting a new scalar value along the spline, and instead, you're
> providing it with a vector value.
>

Yes, I see that-- and the message does make sense...but only *after* the
parser's particular behavior with the negative-index points has been explained
;-) Prior to that, it's a mystery message. And the spline docs are completely
silent about what to expect, unfortunately.

But I agree with several others here, that it's simply better practice to use
commas after every entry-- and to ignore the docs' comma-less example.

Post a reply to this message