So what's wrong with version 1.2?

[Guest]

You'll have to change your avatar, John !

[lagroue]

You'll have to change your avatar, John ! , I said

[MtnViewJohn]

No, I'll just use the 'hue =+x' syntax.

But seriously Lagroue, what do you think about replacing the current color model with one based on hue targets? If you think it's a bad idea then I won't do it.

[lagroue]

You're very kind with somebody that doesn't even read carefully !

OK. Considering the new model granted, here's some remarks.
Let's start by reviewing our variable kinds :

Real numbers : x,y, rotation,skew
[0,1] : brightness,sat,alpha,size
"Quantics", with a real side, and a [0,1] side at the same time : hue

When newbies have more chance to give up, people could ask :

Feature forum : Could we please have a limit to x ? y ? rotation ? size ? Please this would be such a nice feature and I can't draw my butterfly without that.

Developpers forum : Why can't I set a limit to x ? y ? rotation ? size ? Why is this cfdg model inconsistant ?

Developpers forum : Since when +30 isn't 30 ("hue=+30" is not equivalent to "hue=30") ? And what if I want to set hue to -30 ?
(this one is very important : it means that a future cfdg grammar with support for expressions is jeopardized !)

And a last : why do I write "hue=+30" when I write "x 30" for exactly the same meaning ? Generally, what's this syntax where some patterns don't always have the same meaning ?

OK. I'll have a coffee. Hold on

[lagroue]

Black French coffee isn't the italian one, thus I can drink more. So.

BTW : what does chris say about that ?

[lagroue]

I've been rewriting this one many times - this should be the last version.



OK. Let's remove the "quantic" notion, keep the whole bunch of your features, but clean the syntax.

First idea : hue is an angle, like rotation. So hue will remain a real number, and behave exactly like rotation.

Second idea : current cfdg grammar/syntax is consistent. Let's not break it.

Third idea : variables are typed. A type determines the meaning of syntax patterns applied to it. (types would be [0,1], [0, +infinite], [-infinite, +infinite], [-infinite,+infinite]/360. I won't discuss all of them.)

Let's go :

A) [-infinite, +infinite] and [-infinite, +infinite]/360 numbers syntax, like before (idea 2)

Code: Select all

hue = 60	# set hue to 60 (idea 1)
hue 30		# add 30 to hue
hue +30		# add 30 to hue since 30 = +30
hue -30		# add -30 to hue (substract 30)

B) [0, +infinite] numbers syntax, like before (idea 2)

Code: Select all

s=1		# ?
s 1		# keeps size the same
s 2		# multiply size by 2
s 0.5	# divide size by 2

C) [0,1] numbers syntax, like before (idea 2)

Code: Select all

sat = 0.5	# set saturation to 0.5
sat 0.5		# move saturation 50% closer to 1
sat -0.5	# move saturation 50% closer to 0

D) [-infinite, +infinite] and [-infinite, +infinite]/360 limits syntax (consistent with A, idea 3)

Code: Select all

|hue = 60	# set hue limit to 60
|hue 30		# add 30 to hue limit
|hue -30	# substract 30 to hue limit

E) [0,1] limits syntax (consistent with C, idea 3)

Code: Select all

|sat = 0.75	# set saturation limit to 0.75
|sat 0.5	# move saturation limit 50% closer to 1
|sat -0.5	# move saturation limit 50% closer to 0

F) [0,1] limit usage

Code: Select all

sat 0.5|	# set saturation 50% CLOSER to limit
sat -0.5|	# set saturation 50% AWAY from limit (thus towards 0 or 1 depending on the relative positions of saturation and its limit)

G) [-infinite, +infinite]/360 limit usage

Code: Select all

hue 0.5|	# set hue 50% closer to limit, through the SMALLEST path, or counter-clock-wise if 180°
hue -0.5|	# se hue 50% closer to limit, through the LONGEST path, or clock-wise if 180°

Below are non prioritary features, but consistency implies those (and clean code makes it easy to implement ) :

Code: Select all

# other parameters
r = 30		# set angle to 30 degrees absolutely (0 is horizontal)
r 30		# add 30 degree to angle
|r = 60		# set angle limit to absolute 60 (0 is horizontal)
r 0.5|		# set angle 50% closer to limit, through the SMALLEST path, or counter-clock-wise if 180 °

# two-values parameters
|s 2		# multiply x and y size limits by 2
|s 3 2	# multiply size limit x by 3, and size limit y by 2
s 0.5|		# move both x and y size 50% closer to their limits
s -0.2|		# move both x and y size 20% away from their limit, thus closer to 0 (same as "s 0.8")
s 2 0.5|	# multiply x size by 2, and move y size 50% closer to its limit

# problems
s=2
|s=2
x=2
|x=2
x 0.5|

Limits are initialised at the same value as its "real-world" counterpart.

About the 0.5| syntax :
The aim is to tag the number to trigger the limit behavior, so that to allow bi-valued parameters like size or skew to be precisely tuned (even if it is only in the future) : "s 0.5| 2". Character-speaking, it could be 0.5|, |0.5, or >0.5, I don't care. Just : tag the number, not the parameter.

About the 0.5| closer/away meaning :
This is a proposition only. Sounded well in my mind, that's all. And the meaning stays the same, whether we're in [0,1], [0,360], or "real real" numbers like x and y, though I don't know how you'll implement an x limit, and your clock/anti-clock is seducing, too.

About the 0 and 1 limits, and the fact that today's syntax is a subset of the new syntax without losing its meaning (without breaking already produced cfdg files, yeah) :
"sat 0.5" moves saturation 50% closer to 1, so that it is possible to move saturation limit closer to 1, and with the same syntax "|sat 0.5", for consistency's sake. In some way, I was bound to keep today's cfdg files running.

Last argument in favor of the syntax : it it recursive

Code: Select all

|||sat 0.4
||sat 0.5|
|sat 0.1|
sat 0.5|

...But I don't know what that does

When you write the tutorial, you'll thank me
And you'll be able to incrementally add limit support to parameters, without breaking any previous code. "today, limits are only implemented for hue", "new in version 1.3 : limits extends to saturation, brightness and alpha", etc.

[lagroue]

BTW, hue will keep on going logarithmicly to its limit (won't it ?) thus a scale parameter both :
- would have been enough,
- is logically equivalent,
- is less readable.

So, hurray for limits.
But linear gradient from red to yellow are still out of reach (are they ?).

For [0,1] variable, limits are a real add-on.


I'd like to hear aaronstj's point of view, too !

[lagroue]

So that scale extends from x/y to other parameters, it would be not bad to introduce a scale syntax : *toto is in [0, +infinite], and is the scale of toto :

Code: Select all

x 2    # add 2 to x, in the x geometry given by x's scale, like today
*x 2    # multiply x scale by 2, like today's "size 2 1"

And we could imagine *r, *hue, etc. Woow, I've got a headache...

I wrote this post as another argument in favor of |limit syntax : A modifier character and a parameter name gives a "parameter-modifier parameter". | gives a limit, * gives a scale, *| is the scale of the limit...


About [0,+infinite] parameters : I forgot that they are allowed to be negative too, while keeping their multiplying behavior :

Code: Select all

s 0.5    # divide s by 2, already
s -1    # multiply s by -1, already
# I mean :-P
*x 0.5    # divide *x by 2
*x -1    # multiply *x by -1

(Today's flip actually is s -1 1, plus a optional rotation)

[MtnViewJohn]

I like your limit syntax much better than mine. Hue scaling would have given us the same capability but I can't imagine explaining convergent geometric series math to every new user on the forums.

On applying the limit syntax to the geometric constructs (size, location, rotation, etc):

Code: Select all

# other parameters
r = 30      # set angle to 30 degrees absolutely (0 is horizontal)
r 30      # add 30 degree to angle
|r = 60      # set angle limit to absolute 60 (0 is horizontal)
r 0.5|      # set angle 50% closer to limit, through the SMALLEST path, or counter-clock-wise if 180 °

# two-values parameters
|s 2      # multiply x and y size limits by 2
|s 3 2   # multiply size limit x by 3, and size limit y by 2
s 0.5|      # move both x and y size 50% closer to their limits
s -0.2|      # move both x and y size 20% away from their limit, thus closer to 0 (same as "s 0.8")
s 2 0.5|   # multiply x size by 2, and move y size 50% closer to its limit 

I'm afraid that isn't going to work. When the new transforms were added in version 1.1 we went from size and rotation variables to general affine transform matrices. It was the only way to implement them. Applying a limit means adjusting size/rotation/skew based on the current setting and the target or limit. But there is no way to extract a current size or rotation from the affine transform matrix now that we have angle-nonconserving transforms. We can do it with x and y, so we can add the limit syntax or the assignment syntax to x and y adjustments. But I kind of don't want to if we can't do it for the others.

What we could do is apply the scaling concept to size, rotation, skew, x, and y (but not flip). This modifies the adjustment before it gets multiplied into the transform matrix and is lost. But, '*x 2' is not the same as 'size 2 1' because it only changes the positions of shapes. It doesn't change their size. 'foo {*x 2}' would make all the sub-components of shape foo twice as far apart without increasing in size the actual squares, circles, and triangles that ultimately go together to make shape foo. Is this really a useful effect? I don't know.

But linear gradient from red to yellow are still out of reach (are they ?).

As you said earlier, scaling logarithmically in hue and space at the same time produces a linear gradient. But I am still a fan of providing hooks for limiting recursion depth, which could be used for linear hue gradients or linear rotation gradients.

[MtnViewJohn]

Hmmm,

Code: Select all

hue 0.5|   # set hue 50% closer to limit, through the SMALLEST path, or counter-clock-wise if 180°
hue -0.5|   # set hue 50% closer to limit, through the LONGEST path, or clock-wise if 180°

What happens when you do 'hue -0.5' and the hue moves from more than 180° from the target to less than 180° from the target? The next 'hue -0.5' would go in the opposite direction. Maybe it should be like this:

Code: Select all

hue 0.5|   # set hue 50% closer to limit,  counter-clock-wise
hue -0.5|   # set hue 50% closer to limit, clock-wise

[lagroue]

I understand and/or agree with your last messages, John.
Maybe we've come up with a solution, now !

[lagroue]

What we could do is apply the scaling concept to size, rotation, skew, x, and y (but not flip). This modifies the adjustment before it gets multiplied into the transform matrix and is lost. But, '*x 2' is not the same as 'size 2 1' because it only changes the positions of shapes. It doesn't change their size.

Oups, no, I don't agree (I still don't read well...)

Space is inflated by 2 in the x axis after a "size 2 1", right ?
This is the exact intended effect of "*x 2".

They both affect shape size and position. In other words, size is an emanation of position - after all, we only have a two-dimensional vector space.
SQUARE { *x 2 } should draw a rectangle, just like SQUARE { s 2 1 } does today.

Code: Select all

startshape scene
rule scene {
	toto { s 2 1 }
	toto { y 1 }
}
rule toto {
	SQUARE { }
	SQUARE { x 1 b 0.5 }
}

[Guest]

I still think a color map mode is a good idea.

[Guest]

D'oh. That was me. Forgot to log in.

[aaronstj]

Dammit. I have no idea why that last one is labeled guest.