WALTER bug (not a bug)

LarrySeyer · 03-06-2021, 08:30 AM

Does anyone know how to make the following WALTER code work correctly?

w<1200 (THIS WORKS!)

set something 1200

w<something (THIS DOES NOT WORK!!!)

Help!

LarrySeyer · 03-13-2021, 10:11 AM

Specifically, this works:

Code:

set mm_fader_mode h<520 [1] [0]

But this does NOT work:

Code:

set switch_point 520
set mm_fader_mode h<switch_point [1] [0]

White Tie · 03-13-2021, 11:12 AM

Code:

set something 1200

makes a coordinate list called 'something', containing the value 1200 . If you want to compare to that number, you need to specify a coordinate within the list.

Code:

w<something{0}

LarrySeyer · 03-13-2021, 03:00 PM

Set something [0 1200]

Is this what you mean?

L

White Tie · 03-13-2021, 03:34 PM

No; from the SDK:

Code:

scalar_value

    You can use a scalar_value as an expression in the following ways:
        Specifying the scalar name/value directly -- in this case, all values in the coordinate_list get this value. For example:

           set foo 1.0
             and
           set foo [1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0]
        ...or
           set foo h
             and
           set foo [h h h h h h h h]

...so what 'set something 1200' actually makes is 'set something [1200 ...]'.

To get your 1200 back, it lives at something{0}.
w<something won't work, because it should be w<something{0}

LarrySeyer · 03-13-2021, 04:32 PM

Understood.

Thank you!

L

DrTT · 05-13-2022, 07:24 AM

Dear all,

sorry to revive this thread, but LarrySeyer has been bitten by the same thing as I have.

In my opinion WALTER is a nice little UI definition language, but I think WALTER has a severe conceptual inconsistency here.

Being in the process of setting up a complex theme with WALTER I have the following mental model:

All variables in WALTER are eight-tuples (typically used for widget layouts).
When defining a "scalar" variable, it is elevated to an eight tuple with identical component values. E.g. set x 1 sets x to [1 1 1 1 1 1 1 1].
Normally scalar literals also behave like tuples. Hence you can do component-wise arithmetic with them so * 2 [1 2 3 4 5 6 7 8] produces [2 4 6 8 10 12 14 16] because the literal 2 is expanded to a tuple of twos.
This also means that scalar arithmetic works fine, because all operations work on the (identical) components of an eight-tuple. The only drawback is that the operations are done eight times instead of once, but this seems to be no performance issue...
To project out a really scalar value from such a variable, one can apply the "{}"-notation, e.g. xxx{0} yields the first tuple value.

Unfortunately there are places where this logic does not work any longer (which is mentioned in the documentation where it says that for some contexts "val1/val2 can be constant or scalar value variables" which means they must be scalars). Those contexts are:

comparisons: those fail for non-scalar values. I can understand that a total order comparison function is not possible for arbitrary tuples, but they should at least be okay for tuples with all components identical. In my opinion [1 1 1 1 1 1 1 1]<[2 2 2 2 2 2 2 2] is valid, but in WALTER it is not. So the code
Code:
```
set panelWidth w
set xxx panelWidth<100 [1] [0]
set yyy w<100 [1] [0]
```
leads to different values for xxx and yyy when w is 85. And this is absolutely counter-intuitive! (By the way: one has to know that w is a scalar by definition and hence it is different from your own variables...)
This logic also makes it difficult to define boolean variables like
Code:
```
set panelIsSmall w<100 1 0
set xxx ?panelIsSmall{0} [2] [5]
```
where you have to add some crazy projection when applying the variable to make it work.
compound operators like +:val1:val2. I can live with that in principle but it is not clear why they could not be fully identical to + * val1 argument1 * val2 argument2 for val1 and val2 being tuples.

So my feature request would be as follows:

For comparison operators do a componentwise comparison of the tuple elements and combine the results with an AND. So [1 2 5 4 7 8 12 3]<[2 6 9 5 12 14 13 7] is true and [1 2 5 4 7 8 12 3]<[2 6 4 5 12 14 13 7] is false. There should be no real problem with that since mathematics considers such a relation an "ordered vector space" with well-defined semantics.
Extend the compound operators to tuple values.

In my opinion this does not break any existing WALTER scripts: they then just do unnecessary extra work for the projection. It impedes performance somewhat because some operators (comparisons, compound operators) become a little bit more expensive, but this should be tolerable.

What do you think about that?

Best regards,
DrTT

White Tie · 05-13-2022, 07:56 AM

I don't follow most of that, but I would suggest that resurrecting an old bug report (that has been marked as not a bug!) to add a feature request makes it rather unlikely to go anywhere.

DrTT · 05-13-2022, 12:42 PM

Hello White Tie,

thanks for your hint! I shall start another thread and try to make my point there.

Best regards
DrTT

Justin · 05-14-2022, 05:00 PM

Quote:

Originally Posted by DrTT

Dear all,

sorry to revive this thread, but LarrySeyer has been bitten by the same thing as I have.

In my opinion WALTER is a nice little UI definition language, but I think WALTER has a severe conceptual inconsistency here.

Being in the process of setting up a complex theme with WALTER I have the following mental model:

All variables in WALTER are eight-tuples (typically used for widget layouts).
When defining a "scalar" variable, it is elevated to an eight tuple with identical component values. E.g. set x 1 sets x to [1 1 1 1 1 1 1 1].
Normally scalar literals also behave like tuples. Hence you can do component-wise arithmetic with them so * 2 [1 2 3 4 5 6 7 8] produces [2 4 6 8 10 12 14 16] because the literal 2 is expanded to a tuple of twos.
This also means that scalar arithmetic works fine, because all operations work on the (identical) components of an eight-tuple. The only drawback is that the operations are done eight times instead of once, but this seems to be no performance issue...
To project out a really scalar value from such a variable, one can apply the "{}"-notation, e.g. xxx{0} yields the first tuple value.

Unfortunately there are places where this logic does not work any longer (which is mentioned in the documentation where it says that for some contexts "val1/val2 can be constant or scalar value variables" which means they must be scalars). Those contexts are:

comparisons: those fail for non-scalar values. I can understand that a total order comparison function is not possible for arbitrary tuples, but they should at least be okay for tuples with all components identical. In my opinion [1 1 1 1 1 1 1 1]<[2 2 2 2 2 2 2 2] is valid, but in WALTER it is not. So the code
Code:
```
set panelWidth w
set xxx panelWidth<100 [1] [0]
set yyy w<100 [1] [0]
```
leads to different values for xxx and yyy when w is 85. And this is absolutely counter-intuitive! (By the way: one has to know that w is a scalar by definition and hence it is different from your own variables...)
This logic also makes it difficult to define boolean variables like
Code:
```
set panelIsSmall w<100 1 0
set xxx ?panelIsSmall{0} [2] [5]
```
where you have to add some crazy projection when applying the variable to make it work.
compound operators like +:val1:val2. I can live with that in principle but it is not clear why they could not be fully identical to + * val1 argument1 * val2 argument2 for val1 and val2 being tuples.

So my feature request would be as follows:

For comparison operators do a componentwise comparison of the tuple elements and combine the results with an AND. So [1 2 5 4 7 8 12 3]<[2 6 9 5 12 14 13 7] is true and [1 2 5 4 7 8 12 3]<[2 6 4 5 12 14 13 7] is false. There should be no real problem with that since mathematics considers such a relation an "ordered vector space" with well-defined semantics.
Extend the compound operators to tuple values.

In my opinion this does not break any existing WALTER scripts: they then just do unnecessary extra work for the projection. It impedes performance somewhat because some operators (comparisons, compound operators) become a little bit more expensive, but this should be tolerable.

What do you think about that?

Best regards,
DrTT

I agree that the current behavior of "scalar<vector" being interpreted as "scalar<0" is not useful and unxpected! We will change it so that it is interpreted as 'scalar<vector{0}'