#121

True, but it would be completely predictable. I’m not sure that @DIR 45; @STEP ever will be due to the cheapo sin() implementation plus rounding errors.

Okay, I stay with @X @X; @Y @Y then - don’t know much about mathematic completenesses but it seems at least pretty predictable. Maybe I am just feeling uncomfortable with things not being where they seem to be…

edit: Plus, you have a logical selection for variables in X and Y.

I don’t understand this?

#122

Yeah, if you align yourself with the center of the cell you’ll get predictable results.

As to X and Y variables being a logical selection, @MOVE takes two offsets, an X offset and a Y offset. It would be easier to think about

@MOVE X Y

than

@MOVE A B
#123

Blockquote

As to X and Y variables being a logical selection, @MOVE takes two offsets, an X offset and a Y offset. It would be easier to think about

@MOVE X Y
than

@MOVE A B

Hm, I am afraid I can’t even formulate a meaningful question to follow you…nevermind…

:jack_o_lantern:

EDIT: something has happened to the automatic quotation function of the forum - or ist just me?
EDIT2: Obviously it is just me, hm…does not work anymore here.

#124

Not just you, I’ve been having trouble using it all morning.

#125

Okay, I try it anyway: Why is selecting X as variable more logical than A?

#126

If you’re on a graph or any 2D Cartesian space, the 2 axes are traditionally referred to as the X-axis and the Y-axis.

1 Like
#127

Yes. I don’t get the connection to the suggestion I made, resp. the aim to calculate direction changes with @MOVE in distinction to using @DIR + @STEP. Why does it make a difference how the variable is called? Also nobody spoke of A’s and B’s here. What did I miss?

:exploding_head:

#128

If I wrote a script that said

@MOVE FOO BAR

It wouldn’t be as obvious when reading the script as

@MOVE X Y

I guess, to be clearer, it wouldn’t be as obvious when manipulating those variables, i.e.: FOO/BAR and X/Y.

It doesn’t make a difference in execution. It makes a difference to anyone trying to read and understand the code, though.

I was just mentioning that it is fortuitous that of the few general-purpose variables that are available on the teletype, two of them are X and Y. That is all.

Edit: stated differently, it is fortuitous that there are variables with names that happen to be descriptive within the context of manipulating the turtle’s X and Y position.

Edit2: I find it ironic that there is confusion about clarity :laughing:

#129

I find it ironic that there is confusion about clarity :laughing:

Maybe the irony is that there is confusion about confusion - my original confusion was if you have a script that makes the turtle run around diagonally in its corral like this (faster trigger in 1, slower trigger in 2):

1
@STEP; CV 1 N @

2
@DIR ADD MUL RAND 3 90 45

or:

1
@STEP; CV 1 N @; @DIR O

How would you do this with @MOVE X B ?

#130

Sounds like you want something akin to this:

I: X 1; Y 1
1: @MOVE X Y; CV 1 N @
2: Z RAND 3
   IF EQ Z 0: X 1; Y 1
   IF EQ Z 1: X -1; Y 1
   IF EQ Z 2: X -1; Y -1
   IF EQ Z 3: X 1; Y -1

Which rotates to a random 45-degree-from-cardinal offset. It would be trivial to limit this to eliminate 180 degree turns.

My observation was that:

The script that I wrote above is more predictable.

The script that you wrote above does not guarantee that the cell will change each time script 1 is called unless you ensure that @SPEED is about 141 and you `@X @X; @Y @Y’ after every step.

Therefore, the script that I wrote above is also less complex than yours. If you truly intend to move 1 cell at a time in a 45 degree offset to a cardinal direction, I think it is the better script.

Yes, it’s longer and more explicit, but I never understood you to be someone who appreciates terse complexity. Perhaps I was mistaken?

Also, can you see how the script is easier to understand than if I had used the general-purpose variables B and T instead of X and Y?

Wouldn’t that be poetic justice?

#131

Hm, maybe it is about how we are approaching this. I see the turtle as a…err…turtle that is walking around in a corral. So setting a direction and stepping forward feels more consistent to my perception of what is happening than changing coordinates of a point in a grid. That feels like a chopped process of going one step diagonally by going one step left and then one step forward. And how about using all 8 directions or changing speed. I think the If-Then construction is too static or robotic - cold mathematics. To me the beauty of @SPEED @DIR @STEP is its true-to-life way. But I also think of little electrons running back and forth through wires and squeezing themselves through resistors…

I played around with it a lot today and with @X @X; @Y @Y after every step it moves pretty regularly, even with @SPEED 100 which makes it compatible to all 8 directions. With higher speed settings I still got consistent patterns over the whole grid. That’s where I came from when the position rounding OP came to my mind.

I also ran into another problem and did not find a solution / OP for it: When you run different trigger outputs from one script how can you mute single outputs? Also I did run the turtle from the M script and wanted to periodically start and stop movement but M.ACT always started again very off beat. How about TR.MUTE to mute / unmute a trigger while the script keeps going?

1 Like
#133

Well, that heartens me to read, as it was the original intent of the design (that was shamelessly stolen from a 30-year-old recollection of Logo). The cardinal directions were added later to introduce some certainty.

If it is true that you value both the directional aspect of @STEP et al, then I think you make a good case for injecting some certainty into that mode.

Instead of forcing users to realign after every step to produce that certainty, perhaps forced alignment does merit an operator. Instead of making shorthand for the alignment operation, perhaps it should be a mode that can be enabled to do the alignment after every step.

Names, maybe:

  • @ALIGN 1
  • @CENTER 1
  • @QUANT 1 // for “Quantize step”

Or something of that ilk?

:+1: for the suggestion and making your case @Leverkusen

Implementation guts, reader beware.

Aligned mode could use @SPEED differently

  • Currently, the user would need to do the trigonometry ahead of time to calculate the speed required to move at least (X, Y) cells, or it could be an experimental/experiential parameter.
  • If we said that @SPEED now represented the minimum number of cells in the primary axis, then it could be more easily visualized,
    • e.g.: “I want to move 2.00 cells diagonally”
    • This works because you make the 45 degree “tiebreaker” mean both axes. (edit: or either axis, doesn’t matter)

:arrow_double_down: see this edit, @tehn, we both realized the shortcomings.

1 Like
(Teletype) 2.2 Release
(Teletype) 2.1 Release
#134

@RECENTER perhaps?

curious secondary outcomes: with speed less than 50 in any direction, the turtle will never move. less than 70 or so diagonal and it’ll never move that way.

but the point is taken, i do think the single-step in any of the 8 adjacent directions with speed/direction is a very fundamental use case, so some sort of modal toggle would make sense. maybe @QUANT does make the most sense then? constant quantizing to center?

1 Like
#135

Instead of forcing users to realign after every step to produce that certainty, perhaps forced alignment does merit an operator. Instead of making shorthand for the alignment operation, perhaps it should be a mode that can be enabled to do the alignment after every step.

Names, maybe:

@ALIGN 1
@CENTER 1
@QUANT 1 // for “Quantize step”
Or something of that ilk?

:+1: for the suggestion and making your case @Leverkusen

I am happy that I could convince you - I think it really gains function and easy-to-use-ness with this mode. :slightly_smiling_face:

How about @QPOS ? Reads a bit strange but might distinguish the OP better from the usual note quantization functions (and is short)?

#136

@ indicates a turtle function already, so I don’t see @QUANT as confusing.

Side note, this build has been shipping with an updated 0 character. It must not be too offensive, as I’ve yet to hear a complaint. What do you who have tested think of it?

#137

Just some quick tips as you’re getting ready to open up your PR. You’ve probably done all of these already, but they might be useful to others too.

Make sure you’ve:

  • Checked that the docs build
  • Got clang-format sorted, or got an alternative ready
  • Filtered all the zip files out of your branch. (I’d advise in future not going down that route.)
  • Merged or rebased against master@monome/teletype (as your PR must cleanly merge, and the easiest way to guarantee that is to do it yourself first)

Will you need someone else to tag the release and upload the zip file after the PR is merged?

#138

Still a no-go on this. I’ve reinstalled everything pandoc-related from the ground up short of building it from source, so maybe it’s my TeX install.

This works, but touches a bunch of files that I never have, making me think that it’s my LLVM / Clang version. I’ll install these from source. Should I aim for a particular version or shoot the moon?

Done and done. I’ll double-check that there are no remnants.

Absolutely. (Also, thanks for the proper syntax of branch@user/repo, never knew how to notate that.)

#139

There is a trick you can do, it’s possible to split the Tex generation with Pandoc, from the PDF generation with XeLaTeX.

So…

cd docs
../utils/docs.py teletype.tex    # will generate the Latex (internally uses Pandoc)
xelatex teletype.tex             # will generate the PDF (plus large quantities of Latex barf in your filesystem)

(please don’t accidentally commit the Latex barf)

Not actually sure that is the proper way… but it works.

#140

Sorry, forgot to answer this. I’ve got:

# OSX
$  clang-format --version
clang-format version 5.0.0 (tags/google/stable/2017-06-22)

# Arch Linux
$  clang-format --version
clang-format version 5.0.0 (tags/RELEASE_500/final)
1 Like
#141

Got the code formatting working, still working on making the documentation build properly.

In preparation for tomorrow’s release, I have opened the pull request. Note that this only represents a departure from RC2 in terms of formatting and other changes that do not affect functionality.

I plan to fix my documentation build problems and then prepare the release zip file tomorrow.

8 Likes