Spin2 Operator Syntax

191012141518

Comments

  • jmg,
    I don't think it matters.
  • 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..
    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 <=.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 22,756
    edited 2017-04-15 - 15:50:46
    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

  • The point was to find something that was more intuitive and indicative and memorable. Maybe it is not possible with operands.
  • 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?

  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 22,756
    edited 2017-04-15 - 18:07:32
    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
  • jmgjmg Posts: 14,494
    edited 2017-04-16 - 01:01:08
    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.

  • jmgjmg Posts: 14,494
    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.

  • 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
  • jmgjmg Posts: 14,494
    edited 2017-04-16 - 01:11:58
    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.


  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 22,756
    edited 2017-04-16 - 01:17:47
    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
  • 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.

  • 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
  • jmgjmg Posts: 14,494
    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....


  • 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"







  • 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
  • potatoheadpotatohead Posts: 10,117
    edited 2017-04-16 - 02:05:46
    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.

  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 22,756
    edited 2017-04-16 - 02:12:13
    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
  • jmgjmg Posts: 14,494
    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' ?

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

    Yes, precisely what Phil is getting at.

  • 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
  • jmgjmg Posts: 14,494
    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 ?

  • 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
  • Heater.Heater. Posts: 21,233
    edited 2017-04-16 - 02:30:34
    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 :)





  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 22,756
    edited 2017-04-16 - 02:33:48
    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
  • jmgjmg Posts: 14,494
    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 ?

  • Calculators have a process jmg. A procedure is a process, in the general sense.

    This isn't hard. Not really. :D
  • 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
  • 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 ;)

Sign In or Register to comment.