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..
Please explain?
Already did above...
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).
Your reversals are not equivalent.
Just like any complex statement, you have to ensure you do it correctly!
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 <=.
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.
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 addMOD to the mix, which treats the number as unsigned when doing the division.
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.
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.
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.
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.
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
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....
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?
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' ?
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.
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.
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
Comments
I don't think it matters.
Just like any complex statement, you have to ensure you do it correctly!
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
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?
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
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.
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
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.
-Phil
b * c / d , and
b / d * c
As math expressions, these two are equivalent. As procedural expressions, they are definitely not.
-Phil
I think it's important not to confuse a programming operator, which is procedural, with a math operator, which is a static entity
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....
For example Javascript: 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"
-Phil
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.
Heater,
Welcome to the discussion! Did you just wake up?
Yes, order matters, procedurally, even at the same precedence level.
-Phil
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' ?
Yes, precisely what Phil is getting at.
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
-Phil
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
Now get some sleep.
-Phil
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 ?
This isn't hard. Not really.
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
Sometimes a programmer will need to do it one way or the other to avoid overflow/underflow, resulting in an error