Duodyadic tiles challenge: codegolf.stackexchange.com/questions/48009/…

[Enter PhiNotPi]

You can see why I needed help formatting things in chat

Pastebin of my large first message because it may be easier to read there.

I'm envisioning duodyadic tiles as a physical object. In the case of a physical object, you can rotate and connect them in many ways.

If you want it to be usable then it would be handy to have subroutines. And if rather than being macros they execute "instantaneously" (i.e. one tick at the calling level corresponds to however long it takes to propagate through the subroutine) they could be quite powerful.

@PhiNotPi Like allowing my 01CIci tiles to be rotated in any direction? I think that would be great, representing it intuitively is the problem.

@Calvin'sHobbies Yeah, there might be enough ASCII characters to do that, but it would be painful to understand.

This reminds me of a circuit-building kid I had in elementary school: there were various circuit elements (wires, lights, batteries, switches, resistors, etc.) that could snap to a grid.

@PhiNotPi I'm pretty sure I know what you're talking about and I have one in my basement right now.

Also, on topic, rather than have -1 as a tile, I'd argue - would suffice as -1/negation.

Found it: snapcircuits.net

@PeterTaylor I like that idea, but how to represent it? There could be multiple grids in a file separated by empty lines, the top one being the main program and the others subroutines. I guess we'd need special tiles to denote input and output in subroutines?

@PhiNotPi Hey, I have that too!

(or had... it's probably lost somewhere by now)

There's a 99% chance mine is buried in my closet somewhere.

Huh. I suppose I shouldn't be surprised people commenting on a primarily computer science forum played with electronics as youngsters. @Calvin'sHobbies is it feasible to reserve two or three values (F,f,etc) as functions that could be defined as separate blocks?

@PhiNotPi For the rotation thing we could use ^v<> to specify input and output (ans maybe space for neither). Then the behavior of each tile would be dependent on how the arrows are arranged around it.

e.g.

 v
>+>
 v

would move things down and right, but

 ^
<+<
 ^

would move them up and left (though then everything is 3x3...)

How about allowing the two-input/two-output "normal" tiles to operate in the opposite direction simultaneously? For example, the AND gate would have B=R=T&L but also T=L=B&R?

Basically doing two actions in parallel.

@PhiNotPi I'm concerned about how practical/usable that is.

Since the data going in the opposite "unwanted" direction won't go to the circuit output, it works.

@BrainSteel Yes, though I think if there were functions, they would be automatically numbered so there could be arbitrarily many. e.g. "the F tile calls the function number L if R is non-zero and the output goes to both V" (just an impromptu example)

The idea is that you would reduce the number of distinct characters needed if some characters functioned as more than one rotation.

@cirpis Yeah, that's way simpler

The arrows would make each gate be 2x2, not 3x3.

So it could work.

@PhiNotPi I suppose that could work. It just seems kind of confusing. Would the tiles always do I/O down-right or up-left (unlike my proposed tiles))

I'm thinking arrows is probably the way to go if we prefer ease-of-use over compactness.

Also the arrows shouldnt be obligatory, if there are no arrows around a block then it assumes its preset i/o directions

Would that mean that some tiles could lie off of the 2x2 grid pattern?

Ok, though your idea is curious. The issue I see with the arrows is that any possible number of inputs/outputs would need to be handled. It might not be that bad, just something to consider.

@cirpis Actually, if we do use the arrows, I'd prefer that there are no preset directions. This seems to make things more symmetrical.

well, more inputs/outputs would allow one block to have multiple functionality

Lr7J sort of work for two-input, two-output blocks since they're sort of bended at a right-ish angle

For example, if X is any tile, then the old duodyadic circuits would now be:

  I I I
  v v v
I>X>X>X>i
  v v v
I>X>X>X>i
  v v v
  i i i

Instead of

XXX
XXX

That's quite readable, but not so compact. It depends, I believe, on the fundamental goal of the language.

@Calvin'sHobbies much like apl has the same character represent different functions depending on wheter the function is called as a monadic and diadic. This way we could have "-" with only one input represent negation, while "-" with two would be standard substraction

I dont think the arrows should be obligatory though

Just to emphasize, I'm not bent on keeping the tiles "doudyadic" (two outputs, two functions). I'm fine with having multiple inputs/outputs going in any directions.

If arrows weren't needed, then it would be possible to stuff extra things in-between the tiles on the grid.

Like XYX instead of X>X, where Y could be negation or something useful.

On the other hand, syntactic errors/ambiguity could occur if combinations like Xv appear.

@PhiNotPi I think that should be evaluated as neither input nor output, just a blank there.

such a construction could serve to direct i/o flows

though v< could be problematic to deal with

I think we would need corner pieces.

X>X
Y>v
XYX

For example, if we wanted to give Y a second output and send it through somewhere, like the other Y.

What if you define an arrow ^v>< to be a block that, upon receiving input from any direction, sends it in the arrow pointed to by the arrow? That would allow constructions like >v to move data right once, and then downward.

@PhiNotPi So one v could contain more than one input?

I think I mentioned in the Nineteenth Byte, but if you really wanted to this could be our second ever language design competition, preferably with a few restrictions :P

@PhiNotPi I'd prefer to keep the syntax well structured One option I thought would be cool is to make it kinda like piet. Each tile would be an intuitive 8x8 pixel image that could be rotated in 4 ways. (These could map to ASCII chars for a cryptic text version if necessary.)

@BrainSteel That runs into problems, since the arrows would be used to determine which cells give output.

@Calvin'sHobbies This is a feasible option. But that would be pretty horrid to read without the appropriate editor

@PhiNotPi Ah, yeah. However organization is covered, it's probably going to have to be very specific.

We would need to write a special editor for a piet-type version.

I know I know :P

Though we could just forget about compactness and use tiles like this:

+---+
| V |
|>&>|
| V |
+---+
| V |
|<!<|
| V |
+---+

Where the arrows denote I/O

Maybe use dot-matrix characters as some of the symbols?

Anyway, I'm really liking the idea of handling each tile based on its inputs/outputs. How we represent them can be dealt with later.

How about we discuss ideas for what types of tiles are definitely necessary?

Not sure about "definitely" but an "if" tile might be nice, i.e. if Input 1 is 0 it does this else if it's 1 it does that.

Isn't that a bit backwards?

Bitwise operations, like AND, OR, NOT, NOR, NAND, XOR, and XNOR, although a few might not need a unique tile and could be created just as combinations of the others.

@BrainSteel How so?

Ok, sure. I think we should consider all of them as functions with 4 potential inputs that are unordered, and 4 potential outputs that have some sort of symmetry.

@Sp3000 Haha, nothing serious, but most languages I'm familiar with require the if be a 1 to do the first thing, else do the second thing. You had an if (thing == 0) {} else{} thing going on.

Well I hadn't thought of what the this/that were, but I was thinking something like 3-input A, B, X. Return A if X is 1, else return B.

Like: Q outputs 0 to all of its outputs, and ends the program if any input is ever non-zero. (The exact number of inputs/outputs depends on the arrows.)

Tiles such as wire-crossings would be helpful.

@Calvin'sHobbies Like a "halting symbol" of sorts?

Right, because there's no other "natural" end to one of these programs as far as I can tell.

well this is a pretty busy chatroom

Except what would bitwise not do with multiple inputs?

My point is that I don't think the program should error or anything if things like that happen.

Heh. "This reminds me of a circuit-building kid I had in elementary school" ... "I'm pretty sure I know what you're talking about and I have one in my basement right now."

@MartinBüttner we're waning

I should have noticed that...

@Calvin'sHobbies just wondering, did you see Sp3000's suggestion to make this a language-design challenge?

I mentioned it again in here already :P

yeah that's what I meant

Oh, right

but I don't see any message acknowledging yours :P

I did, I'm just not sure how to go about it.

My suggestion in the 19th byte was that you do this actually much more simply than the pattern matching challenge. Just require the language to be Turing complete (can be shown by implementing something simple like Rule 110) and support at least integer types... and maybe some specification which constrains languages to this type of 2D logic based thing... and that's pretty much it.

I mean it'd be hard to keep it broad enough and narrow enough

Oh, I didn't see the 19th byte comment

We would want a definition that excludes Marbelous- or ><>-like languages.

You keep it narrow by saying that the language must be grid based where each cell represents a "function" (in some sense), which takes and passes data from and to its 4 orthogonal neighbours in some participant-defined way. It must also support input and output. Languages may support any data types but must at least support 32 bit integers.

@PhiNotPi hm yeah, Marbelous is indeed fairly similar

Perhaps a definition like.... A program consists of a grid of tiles. Each tile has a constant type (identical types = identical function) and a variable state (a number). Each tick of time, the state of each tile is simultaneously updated, aka assigned a new state, with the new state being a function of the tile's type and the previous states of the four adjacent tiles.

I think it might be possible, however, to re-implement Marbelous so that it is very similar to this definition of tiles.

If you make a language design challenge, isn't anyone who writes up an existing language automatically disqualified? Sure, you might get things like Marbelous, but is that a massive issue?

Are these kinds of tiles relevant in setting the rules of a challenge?

@Calvin'sHobbies Yes, reusing newlines makes it almost free to define subroutines. For the subroutine I/O, I was thinking that a subroutine may only have one tile touching each edge, and then we can infer the I/O without special tiles.

@PeterTaylor That sounds really elegant. Quite expensive for golfing purposes though (but then again, requiring rectangular code is usually a bit wasteful anyway).

Requiring routing is going to make it expensive.

If golfing is the goal then the values that are passed around should be variable-length arrays of big integers, and we probably need some input from APL/J/K programmers on what the operators should be.

Yeah that's true. I think design goals would help.

Maybe we might have a tile that takes input from the diagonals - i.e. rotates input by 45 degrees unmodified. Could be used for a bunch of things.

I don't know if this is possible or not, but maybe the tiles can auto-detect where the inputs are coming from and output through the other sides?

(possible as in whether there might sometimes be problems with too many inputs, although I suppose that could be debugged)

That's quite a nice idea, but I can imagine situations in which it's ambiguous.

Yeah, that's what I was worried about

Obvious inputs and outputs are obvious, and then tiles which have either all their inputs or all their outputs accounted for allow propagation of information, but if you have loops...

Maybe we could have something that acts like a diode?

So a backflow of information would be prevented?