Spin2 Operator Syntax - Page 12 — Parallax Forums

# Spin2 Operator Syntax

• Posts: 2,996
jmg,
I don't think it matters.
• Posts: 18,069
jmg wrote: »
Cluso99 wrote: »
jmg wrote: »
Err, has everyone fully grasped this new !< !> syntax now imposes restrictions on the operator order ?
That restriction was not there on the old syntax.
If you say 'Hey, let's allow either order', in one case the opcode does not do what it literally says.
Which repeats the problem of backwards MIN, where what happens is not what the code says..
This is OK
Elev := 1000 #> Elev <# 2000
Which is equivalent to
Elev := 1000 FGE Elev FLE 2000
or, this can be re-ordered as
Elev := Elev FGE 1000 FLE 2000
all are bound 1000..Elev..2000 (which is another syntax candidate )

This is ok
x := x !< 5 !> 10
simple order swap gives
x := 5 !< x !> 10
but what does that now say ? 5 is NOT less Than X, which means 5 is >= X, and X=1 will output 1.
It is ok to re-code like this
x := 5 !> x !> 10
.. but here the operator flips when the order flips, which the old opcode did not require (nor does FGE).

Just like any complex statement, you have to ensure you do it correctly!
• Posts: 6,347
The !> does kind of lose its meaning when the limit is put on the left side instead of the right. Or what about "x := y !< z", where you really don't know the values of y and z. We're really talking about getting the maximum value of y and z, but I guess it's just too hard to use the symbol "max" for the operator. Another thing about !> is that it looks like a comparison operator. Seeing it for the first time I would assume it is equivalent to <=.
• Posts: 23,514
edited 2017-04-15 15:50
jmg,

I fail to see how simply renaming #> to be !< and <# to be !> changes how they can be used. In fact it doesn't. They mean exactly the same thing as before.

-Phil

• Posts: 4,217
The point was to find something that was more intuitive and indicative and memorable. Maybe it is not possible with operands.
• Posts: 10,255
After watching this discussion, it's obvious MIN and MAX as implemented here differ from more typical implementations.

We need to pick something useful, and there are a couple options on the table I'm fine with, and then go.

People will need to know what they do, and frankly, given that difference, triggering them to seek what they do is actually a good thing.

There will be a quick, RTFM on this feature no matter what, given where we are now. So why avoid it?

• Posts: 23,514
edited 2017-04-15 18:07
BTW, x := 5 !> x !> 10 does not work. It peaks out at 5 even when x is, say 9, just as x := 5 <# x <# 10 does in Spin1.

And, back to REM vs. MOD, in Spin1 the // operator is a remainder; it's not the modulus. If MOD in Spin2 behaves the same way, we need a different mnemonic for it. Anyway, I don't know why we can't just keep //. But if we wanted to, we could add MOD to the mix, which treats the number as unsigned when doing the division.

-Phil
• Posts: 15,154
edited 2017-04-16 01:01
They mean exactly the same thing as before.
Ah, maybe you have historic hindsight to know they mean the same, but they do not say the same.
BTW, x := 5 !> x !> 10 does not work. It peaks out at 5 even when x is, say 9, just as x := 5 <# x <# 10 does in Spin1.
Here you underline the problem.
You know how the old opcode works, so you are not reading what the symbols say, but are skipping ahead to what you know they will do.

Sadly, very few new P2 users will know anything about the old opcodes/symbols, so they will read the literal NOT and GREATER.

x := 5 NOT GREATER than x NOT GREATER than 10 , bounds x within 5..10, and operand order matters.

• Posts: 15,154
T Chap wrote: »
The point was to find something that was more intuitive and indicative and memorable. Maybe it is not possible with operands.
Not with cryptic glyphs, so they are best avoided. Mostly, they have been fixed.

• Posts: 23,514
jmg,

I think it's important not to confuse a programming operator, which is procedural, with a math operator, which is a static entity. But anyone who does even a minimal amount of programming understands this. And they will understand that x := y !< 0 !> 10 is the correct expression.

And, BTW, !> and !< are not cryptic glyphs. The say what they mean and mean what they say.

-Phil
• Posts: 15,154
edited 2017-04-16 01:11
jmg,

I think it's important not to confuse a programming operator, which is procedural, with a math operator, which is a static entity. But anyone who does even a minimal amount of programming understands this. And they will understand that x := y !< 0 !> 10 is the correct expression.

And, BTW, !> and !< are not cryptic glyphs. The say what they mean and mean what they say.
Again, you manage to reinforce my point.
If you have to say "it's important not to confuse a programming operator, which is procedural, with a math operator" that shows the problem.

Why should such confusion even be possible, when most languages try to avoid ambiguity, rather than create it ?

Any Language manual that has to start out by saying "it's important not to confuse a programming operator, which is procedural, with a math operator", is rather an admission of failure in language design.
I have already shown they do not actually mean what they say.

• Posts: 23,514
edited 2017-04-16 01:17
jmg wrote:
Why should such confusion even be possible, when most languages try to avoid ambiguity, rather than create it ?
It's not the least bit ambiguous. Who -- besides you -- says it's confusing? Once again, when you're in a hole, it's best to stop digging.

-Phil
• Posts: 21,230
Phil,
...programming operator, which is procedural, with a math operator, which is a static entity.
I have done a ton of programming since 1974 and I have no idea what you are talking about.

• Posts: 23,514
BTW, here's an example of the difference between between math expressions and procedural expressions that even the beginning programmer learns from the get-go:

b * c / d , and
b / d * c

As math expressions, these two are equivalent. As procedural expressions, they are definitely not.

-Phil
• Posts: 15,154
It's not the least bit ambiguous.
If that were really true, you would have no need to qualify like this ? QED.
I think it's important not to confuse a programming operator, which is procedural, with a math operator, which is a static entity
Who -- besides you -- says it's confusing?
Spin's cryptic operators have a long history of proven confusion, which is why this thread exists, (to try to fix that), and why it is up to page 12....

• Posts: 21,230
Phil,
As math expressions, these two are equivalent. As procedural expressions, they are definitely not.
On which planet is "b * c / d" not the same as "b / d * c" ?

For example Javascript:
```> b=1
1
> c=2
2
> d=3
3
> b * c / d
0.6666666666666666
> b / d * c
0.6666666666666666
>
```
Now, admittedly things might not be so equal in computer world with different numbers.

And it will go horribly wrong when working in only integers.

I don't understand what you mean with the difference between "math expressions" and "procedural expressions"

• Posts: 23,514
jmg wrote:
If that were really true, you would have no need to qualify like this ? QED.
I think it's important not to confuse a programming operator, which is procedural, with a math operator, which is a static entity
Your "QED" has no merit. What I'm averring is just programming 101. If I'm wrong, how would you explain x := x + 1?

-Phil
• Posts: 10,255
edited 2017-04-16 02:05
Put comparisons in there, and expressions become more than just math.

That is why all the odd forms exist. Capture comparison as value, assignment, non assignment, etc...

It's not used much, but it is possible to make most of a program as expressions.

• Posts: 23,514
edited 2017-04-16 02:12
heater wrote:
On which planet is "b * c / d" not the same as "b / d * c" ?
Um ... in SpinWorld, perhaps?

Heater,

Welcome to the discussion! Did you just wake up?

Yes, order matters, procedurally, even at the same precedence level.

-Phil
• Posts: 15,154
If I'm wrong, how would you explain x := x + 1?
I'm confused by this ? There is no cryptic spin operator here, and so most languages I know would increment x by one.
Smarter ones would code that to an INC opcode, if x is locally accessible.

I've no idea how you imagine writing "x := x + 1" makes you 'right' ?

• Posts: 10,255
And it will go horribly wrong when working in only integers.

Yes, precisely what Phil is getting at.

• Posts: 23,514
jmg wrote:
I've no idea how you imagine writing "x := x + 1" makes you 'right' ?
It's very simple: again, there's a difference between math equations/expressions and procedural assignments/expressions. Obviously x = x + 1 makes no sense mathematically. But it's totally comprehensible procedurally.

So, procedurally, x := x !< 0 !> 10, evaluated left-to-right, makes perfect sense. It doesn't have to make sense as a mathematical equation. But that's one of the first things taught to beginning programmers.

-Phil
• Posts: 15,154
Obviously x = x + 1 makes no sense mathematically.
Really ? Strange my calculator has no problems at all, with what you claim makes no sense mathematically ?

• Posts: 23,514
jmg wrote:
Really ? Strange my calculator has no problems at all, with what you claim makes no sense mathematically ?
Of course not. Your calculator is a procedural device, not a mathematical one. Give it up, jmg. I'm growing weary or your stubborn intransigence.

-Phil
• Posts: 21,230
edited 2017-04-16 02:30
Phil,
Welcome to the discussion! Did you just wake up?
Thanks. No, I was trying to get to sleep after a long day but what you said bugged me.
Yes, order matters, procedurally, even at the same precedence level.
Yes of course. In the perfect world of mathematics "b * c / d" is the same as "b / d * c".

That might not be true in the clunky world of the computers numerical representations.

What I was asking is what on earth is the difference between the "math expressions" and "procedural expressions" that you talk about.

I realize now it just your way of saying that computers screw up

• Posts: 23,514
edited 2017-04-16 02:33
heater wrote:
I realize now it just your way of saying that computers screw up
Yes!! And that's the first lesson beginning programmers need to learn!

Now get some sleep.

-Phil
• Posts: 15,154
jmg wrote:
Really ? Strange my calculator has no problems at all, with what you claim makes no sense mathematically ?
Of course not. Your calculator is a procedural device, not a mathematical one.
Yet google finds zero hits on your claim "calculator is a procedural device" ?

It does find this :
"A calculator is a device that performs arithmetic operations on numbers"

It does get hard to extract meaning from some of your posts ?

• Posts: 10,255
Calculators have a process jmg. A procedure is a process, in the general sense.

This isn't hard. Not really.
• Posts: 23,514
jmg,

There are four very pregnant does just outside my living room window. This means that the urban deer population in my little burg is about to explode once again. As much as the fawns are sooo cute, they grow up into voracious garden munchers, which creates some friction between the local gardeners and the deer lovers, who sometimes feed them.

Somehow, that conflict of opinion trumps any trivial angels-dancing-on-the-head-of-a-pin thing we're discussing here, so I'm going to sign off.

G'night!
-Phil
• Posts: 18,069
BTW, here's an example of the difference between between math expressions and procedural expressions that even the beginning programmer learns from the get-go:

b * c / d , and
b / d * c

As math expressions, these two are equivalent. As procedural expressions, they are definitely not.

-Phil
Agreed

Sometimes a programmer will need to do it one way or the other to avoid overflow/underflow, resulting in an error