Haha. Testing wrote a bug like "I didn't get a validation message when I clicked "Remove selected". So I asked them "Did you select anything?" They said no, but it's still a bug
So I disabled the button until an element is selected with a comment \\ Can't click me now!
So they wrote a NEW bug about how they are unable to click on the button
And for the first time ever, I was allowed to mark the bug "As Designed"
This is really unhealthy interaction between me and the test team :-/
Anyone have a suggestion for how I could tell them that I think their bugs are silly? I'm not the best wordsmith in the world.
Anyway, I don't want requirements like that. Disabling the button was a design decision. The button says "Remove Selected". Why on earth would you want to click it without selecting anything?
And so rather than throwing my hands up in the air and asking why someone would do something like that, I took the option away from them.
But testing not only wants to be able to click that button, they want a message explaining why clicking it doesn't work
If my bug gets rejected again, I'll do it their way, but I won't be happy about it :-/
Not because I hate the extra work, but because I think it degrades the product
I think that close votes should be "refreshed" after a question is edited, similar to how up and down votes are "unlocked" after a post is edited. More specifically, I want the option to reassign my close vote once each time the post is edited.
Consider the following scenarios:
A question is T...
The effect of the first one could be complaints in chat like "Why did you close my code trolling question as Too Broad if you really meant [some other reason]."
I'm against all the "notify me when a post I downvoted is updated" requests, but I had an idea that might be useful while unobtrusive.
How about quietly showing how many revisions/edits were made between your downvote and now? It could also "clear" when you recheck the post, so they don't stay m...
Personally I think that would help only a small minority of users, at the expense of fetching the revision history for every question everyone's downvoted on every profile load. But, I'm no mod/dev :D
(and check when you visited it last so it knows to clear the flags)
I thought favorites was a simple boolean changed/notchanged. It doesn't have to say "3 revisions", "50% edited", whatever. Also, I imagine most people DV more than favorite.
@MartinBüttner I thought about this while waiting for some friends to arrive at a bar, and I had come to a similar idea. I was going to propose that it should be able to test primality and (to avoid people claiming the tool factor as a programming language) perform addition.
@githubphagocyte I don't know. Perhaps I should have offered to move the discussion to a chatroom so we can talk about the difference between "retract" and "reassign"
@MartinBüttner To be fair, if you squashed all of those other questions together, mine is a duplicate. But as it stands, the pieces are scattered. Mine is the only whole question with all the pieces I wanted to be present.
@PeterTaylor Something like that sounds like a good test. Although I'd probably allow for any calculation to be a test, because a language might just have boolean output.
I think it would be difficult to think of any new question that wasn't made up largely of things that have been asked before. Otherwise you'd have to avoid every topic ever asked about.
@PeterTaylor The real issue mentioned by Doorknob remains though. You could still create a language that is cat for every invalid program and still have your 0/1 byte quine.
@MartinBüttner Maybe we need to add a "standard loophole" for quines and say that unless the question explicitly says otherwise it should be a true quine (i.e. one which actually composes a string). A fairly simple test would eliminate most cheats: if I can remove a character and it still "quines" then I repeat; if I get down to the empty program, it's disqualified.
I can't think of any case which the primality test test doesn't discriminate other than factor
A bit of an unusual one, but hey, why not? :)
The objective: Write a functioning IRCd in your language of choice that provides barebones functionality, in as few characters as possible. As long as it fulfills the criteria below, it does not have to fully comply with the IRC RFCs (this would make...
I don't know any of the background but I'm guessing that "barebones functionality, to keep the challenge short and fun" is a little optimistic about how short it will be
I find it fascinating that my most recent KoTH has given me twice the reputation my other one gave me (at the same question-oldness), simply because I provided 4 of my own bots, which have subsequently been upvoted
My previous answer was criticised for not drawing a line in a sand, so following some discussion on chat I propose a line.
Executive Summary
A purported programming language should be accepted as such if and only if it is capable of addition of natural numbers and primality testing of natural n...
@MartinBüttner just spent a good hour or so thinking my program was broken because I was replacing the top-left / with a D rather than a C, causing the 1 line to be 1 frame behind, breaking all my comparisons - new method seems to be working though
Sounds like you were leaning away from accepting non-implemented languages anyway, but I thought that might be a reasonably large factor to help decide
@PeterTaylor I don't have any knowledge of them, but I'm guessing they would give an advantage most question posters wouldn't have in mind
@PeterTaylor I had a vague impression of them being equivalent to massively parallel, since unlike a monte carlo approach they would sample the entire space. I don't have the background to guess how accurate that impression is though.
I think that since the question is about defining what a PL is, having an implementation or not is borderline off-topic, so I've added a link in the Observations sections to a more relevant meta question.
@PeterTaylor I think it's quite relevant here. This is not an academic/philosophic discussion about what is a programming language in general. We're trying to define rules for what makes a valid programming language in the context of PPCG answers.
I can see the issue spinning off a separate argument about non-free implementations etc. If you feel strongly about it, you can post your own answer, but I think it would be better as a separate question with links either way as "Related question".
Free and free is nice but I think as long as a reasonable number of people are able to test I wouldn't insist on it for all questions. I might insist on it for my own question, but most strongly for a KotH where I have to be able to run everything...
Yes. I am not impressed with the person who answered the stock trading KotH in Fortran for flavour reasons and then kept it in Fortran even after he had to wrap it in Python in order to meet the output spec.
@PeterTaylor I'm trying to implement this tiling right now. I think decomposition is easiest, because that's also how the tiling is defined (that picture there is a single decomposition step of an upwards-pointing pentagram). Now I wonder how I can best implement the decomposition. I can't just do it tile-by-tile because the connections between neighbours need to be patched up as well.
@MartinBüttner, the way I handled that for the Labyrinth tiling was to have maps both ways between a tile and its vertices and then to use the vertices to find the neighbours. Provided you're careful about how you do the subdivision you can ensure that each vertex is only calculated once and so you don't risk rounding errors breaking the identification.
@PeterTaylor well yes, I'll basically do that, but I've got limited screen space so I'll just start with a tile filling all of it and then subdivide
@PeterTaylor Well keeping track of the neighbours isn't really a problem I think. It's more like, having the full grid, what's the cleanest way to implement the subdivision, since I can't just map big tiles 1:n to new tiles. I'll be missing some tiles that arise between previously adjacent tiles, as well as their new adjacency information.
I wanted on-demand expansion to avoid the risk of a glider hitting the edge of the world and dying before I detected it. But given how few tilings seem to have easy-to-find gliders, I can understand if that's not something you're worried about.
Oh, so your concern is failing to identify all of the faces?
Well, look at that picture I sent you. Say I subdivide the large pentagrams again (leaving the small ones intact). Looking at the middle and the lower left one. Each gets replaced by 6 pentagrams one size smaller, and 5 pentagrams two sizes smaller, as well as 5 rhombs. But there will also appear an octagon and two rhombs between them which I can't assign to either one.
Currently my data structure doesn't even have a concept of edges or vertices.
It's just tiles and their neighbours.
Then I can just associate some geometry with each tile and render them all. But the GoL code doesn't need to know about edges and vertices. It only cares about neighbours.
It doesn't seem like there are any tiles that can't be assigned to a single parent tile. So it's just a question of finding the neighbours in the new tiles of two different parents.
Not yet. I just want to get the tiling at all for starters. If I want to expand, I can always do 4 more iterations, and transfer the old state to the new grid.
As long as I stick to this 5-fold symmetric version, doing 4 iterations contains a minified copy of the original tiling
Not sure how it would help. I'm not concerned with accurately placing/plotting the tiles. I've got enough precision for errors not to be noticeable. Currently, I'm only talking about the abstract adjacency graph for this.
Can the adjacency calculation be included in the iteration at each step?
I mean expand the subdivision step to update adjacencies as it goes
I've got my traveling salesman approach to the single curve image question running in the background. It looks OK from a distance but looking closer there are still a lot of crossed lines :(
@githubphagocyte I think I've been unclear. The point of the subdivision is to create both the adjacency graph and tile types/positions. The latter is rather trivial. So I'm only worried about the former.
Updating the adjacency graph within one decomposed tile is not a problem. The only tricky part is to update edges that get split up into multiple edges.
But I think by keeping track of edges as well, it shouldn't be too hard.
The update rules for the 5 prototiles (disregarding adjacency) are:
Could you just keep track of vertices, and point to them so that any shape that shares a vertex points to the same one? Then neighbours in terms of vertices would be straightforward
Large Pentagram -> 6 large pentagrams, 5 small pentagrams, 5 rhombs, 20 triangles Small Pentagram -> large pentagram Rhomb -> octagon and 2 rhombs Octagon -> 2 small pentagrams, 1 rhomb and 8 triangles Triangle -> 2 triangles
@githubphagocyte I'd still need to assign new vertices to the right subcomponent of the decomposed adjacent tiles
actually I think I need to refine those update rules a bit more
I think I need a check that when decomposing a large pentagram I only add small pentagrams on sides where it's not touching a small pentagram already
I'm trying to get the idea straight in my head. For each new shape you create, you define it in terms of vertices, and you don't store any of those vertices with the shape, but just pointers into a list of vertices, adding new vertices to the list if they aren't already there to point to. So then each shape is a list of pointers (as many pointers as it has vertices). And it's neighbours are those that share a pointer in common.
You would get a lot of duplication, but if you're doing it in terms of a vertex list you can just discard shapes which have all vertices in common with another
Didn't you have an intermediate image before? With the concave octagons empty? Or did I imagine that?
in the latter picture, wherever you have 6 blue pentagrams group them back together into a large one. and then ditch all the blue remaining ones completely
@githubphagocyte What confuses me about using the odd iterations only is that the first of those doesn't generate octagons. But apparently later ones do.
So I'd rather break it down into two, where each one captures all the possibilities.