Author Topic: Simon blogs (Read 132244 times)

Simon · « **on:** October 18, 2015, 06:05:44 AM »

Hi,

some loose rambling.

Basic tenet in open source: People are interested in how other people solve problems. You share source code obviously, but you also love to talk about what it does, and are honest about its shortcomings. You can show proudness of your project, provided you're not hiding the problems.

I'm sure the IRC regulars have grown used to "Lix does it like this, the reasons for it are A, B, C, and the source is ugly." The ugly parts ("// 9 indentation levels is way too much") come to mind much more frequently than the nice parts. Good parts don't come to mind all the time; they're simple and to-the-point.

You value public bug reports, and you value source patches even higher. Likewise, users are happy to make bug reports. (Treat users as co-developers.)

Level design shares some qualities with such development, but is different.

People don't play a pack several times. Given the abundance of great and intriguing levels today, people play your pack once if you're lucky, and zero times if you're not. Useful software is run again and again, individual levels are not.

As a pack developer, you want your users to play thoroughly tested levels. There are several approaches. You can make a closed beta. You can release on Lemmini first, where you have fewer users. Or, what I'd do -- release normally, be honest that it's not playtested, and have good faith that people won't play all at once.

I believe I'm unconventional: I cherry-pick single levels. I wait until other people praise certain levels, or, as with Icho's pack, entire level packs. Only then I invest a serious amount of time. As a result, my level diet consists of heavily playtested levels. Maybe others are like me; probably many are to a lesser extent.

Even if you choose "release publicly, and hope that some will wait anyway", you probably don't want unspoilered solutions in public posts. Most authors like feedback in a spoiler tag, or as a replay file. This way, the solutions are public, but you have to explicitly want to see them. This is exactly what spoiler tags are designed for: They don't put the solution out of reach, but only out of accidental reach.

I don't care if people post unspoilered solutions publicly for my little handful of levels. With time limits and hidden traps, I'm happy that most contemporary level designers share my views. But I won't shape discussion culture for level designers. If many like the spoiler-tagging and don't want solutions bantered in logged IRC, then following suit is the way to go.

Bonus rambling, apropos diet: The guinea pig diet consists of eating lots and lots of cucumber. A guinea pig would do the same, and they are extremely cute and obviously extremely smart, because they eat cucumber, which is tasty. Aim for at least half a cucumber per day, maybe even one per day. And cut way back on sugar drinks. Magic will happen!

<SimonN> I have bought 2 cucumbers earlier today, 1 is already eaten. Love love love
<geoo> me too :D :D :D

-- Simon

Simon · « **Reply #1 on:** January 04, 2016, 01:04:44 PM »

More loose rambling. Some of these ideas, I've presented them on IRC over the past months.

namida was sad on how bugs crept up in NL1. But finding many more bugs was expected: 2015 has been a super-active year for NL level development. 2015 was also a comparatively busy year for NL playing; I played at Ichotolot's without making my own levels. And more users find more bugs (obligatory link to Cathedral and the Bazaar).

namida likes NX as the abbreviation for NeoLemmix, presumably like Fx for Firefox, or because the X is cool. NX feels unnatural when you use PascalCase for the long name. The obvious abbreviation is exactly the capitalized letters.

If you get feedback, react to it in some way. Maybe you don't want to fix issues right away, then at least list them publicly. You won't get school grades for your hobby project, so don't try to hide flaws from other people. Icho is in his 5th or 6th iteration of backroute-fixing his large NL pack. This is splendid support. namida improved on tracking NL issues by encouraging separate topics for each, even though he'd like to fix only serious bugs right now. Also great.

Porting Lix's C++ code to D, I've noticed bugs in the physics from mere reading of code. Every program is full of bugs, this is also normal. You write software, you have bugs. (You make levels, you have backroutes.) I won't replicate C++ physics exactly, only wherever they feel important and easy-to-describe. geoo proposed to reorder some physics code anyway in the most recent C++ release 2015-09-02, and there are bugs to be fixed.

Example of why replicating physics would suck: The tumbler and flingploder are horrible to replicate exactly. The tumbler (= lix that is flung) had a bug in C++ where some terrain checks were off by 1 pixel, it got stuck inside 1-pixel-high horizontal lines. This is fixed, I hope, in D. Since the flingploder produces tumblers, it can't be ported accurately, unless I wanted to keep the other bug in. And the old exploder masks aren't symmetric. And the fling speed computation is crazily complicated. Yuck yuck yuck.

On the other hand, walker, faller, and ascender physics are ported with 100 % accuracy. They are much more a part of how the game feels. Also, sometimes we run into things we'd rather preserve as they are, come hell or high water:

// Horrible function. Copied out of C++ Lix almost unaltered. // The problem is that this function's semantics have already been // debugged to no end, C++ Lix had lots of bugs with tumblers over // the years. We'd have to be really smart to make this simpler. final Collision collision() { ...

This got way too technical and low-level again. Rambling is best at high level.

The more features your game has, the harder and longer any porting attempt will be, and the more features can come out wrong/buggy/strange.

When you rewrite, which is crazy from the get-go, continue to support the old version until the new one is done. Seen from the outside, NL does this well. Lix, seen from inside, not so much I believe >_> But other people could tell better. I've had 2 large releases in the middle of 2015, while the D port has been underway since 2015-02. I haven't included Raymanni's sets.

Over the past 4 months, I lost 9 kilograms with the guinea pig diet! (= 20 pounds in archaic units) Happy happy happy.

-- Simon

Simon · « **Reply #2 on:** January 17, 2016, 01:06:50 PM »

I was fun-browsing Wikipedia about the Euler-Mascheroni constant, read one of the linked papers, and found a lovely qoute inside: How Euler, Johann Bernoulli and Jacob Bernoulli stayed motivated and productive. (source info)

Always attack a special problem. If possible solve the special problem in a way that leads to a general method.
Read and digest every earlier attempt at a theory of the phenomenon in question.
Let a key problem solved be a father to a key problem posed. The new problem finds its place on the structure provided by the solution of the old; its solution in turn will provide further structure.
If two special problems solved seem cognate, try to unite them in a general scheme. To do so, set aside the differences, and try to build a structure on the common features.
Never rest content with an imperfect or incomplete argument. If you cannot complete and perfect it yourself, lay bare its flaws for others to see.
Never abandon a problem you have solved. There are always better ways. Keep searching for them, for they lead to a fuller understanding. While broadening, deepen and simplify.

-- Simon

mobius · « **Reply #3 on:** January 17, 2016, 06:35:18 PM »

these sounds like the "Oblique strategies" I mentioned yesterday. Speaking of which; you can buy Oblique Strategies on places like ebay... except it costs 500$

because it's a very rare thing supposedly.

Can you recommend some similar books and things but at a reasonable price? Or maybe website that has these things?

Simon · « **Reply #4 on:** January 18, 2016, 06:25:02 AM »

No, don't know any books on aphorisms to boost motivation. My bedtime literature tends to be technical books, flower math, and books on games. >_>

-- Simon

Simon · « **Reply #5 on:** January 23, 2016, 07:16:16 AM »

Problem that has come up occasionally: New forum users send a private message, instead of asking publicly for help on tech or levels. Don't send a private message. Find/make a topic, and ask in public.

Tech: Ask publicly! Level editors, handling files, Python scripting, programming, ... if you try new technology, don't have fear of looking stupid. We're extremely happy that somebody is diving into something new and exciting for them. Other people might run into the same problem later. If you ask publicly, they benefit, too.

Level solutions: Ask publicly! You will get the answer publicly, in a spoiler tag. Both level authors and level players like to share their solutions with people who're ready to read the spoiler. Don't have fear of looking stupid! Authors are happy that somebody is showing interest in their work!

Split off the new postings to a fresh thread: Object-oriented design with Simon.

-- Simon

Simon · « **Reply #6 on:** February 13, 2016, 04:20:51 AM »

Users never read manuals. [...] We cannot allow engineers to build products for an idealized rational user when real humans are irrational: we must design for the way users actually behave.
-- paradox of the active user

From 1998, the article is pretty old. But it even shuns "learning packages" along with manuals or anything that doesn't smell like getting things done.

I have wondered about Lix's tutorial pack. Every other option seemed worse. :> Large level packs are encouraged to start with flower levels, but they should not all shove full-blown tutorials down players' throats. Anyway, it's common with nonprofessional games to think endlessely about what new users would do, and then never watch new users. >_>

<SimonN> I have one person who has looked for the singleplayer browser's play-button at the bottom, not at the top
<SimonN> no way this is a technical bug, but it suggests further studies with new users, and maybe it's a design bug

-- Simon

ccexplore · « **Reply #7 on:** February 13, 2016, 06:40:38 AM »

Quote from: Simon on February 13, 2016, 04:20:51 AM

From 1998, the article is pretty old. But it even shuns "learning packages" along with manuals or anything that doesn't smell like getting things done.

(Disclaimer: haven't read the article yet) Well, do remember we're designing a game in this case, not a tool. I feel like there's a bit of a fundamental difference here since a tool is usually just a means to an end (so one can argue the less time user spent on learning about the tool, the more efficiently they actually reach their goal), but here the interaction with the game is the fundamental experience. The tutorial levels could still count meaningfully as "getting things done" for a new player in this context, I think, as long as they still provide positive experience for new players to complete them.

Simon · « **Reply #8 on:** February 13, 2016, 01:09:45 PM »

Yeah, that's a good view. If you don't know Lemmings, maybe you expect light hand-holding. The tutorials start with the skills and end with advanced techniques and control features.

If you know Lemmings, the game should shout "I'm mostly like that" and keep all non-L1 features discoverable. That's why I introduced tooltips in the C++ version last year. They obscure the panel text but seem acceptable aside from that bug.

-- Simon

Simon · « **Reply #9 on:** February 15, 2016, 02:52:32 AM »

IchoTolot will take a course on C at our university in a few weeks.

Everybody loves ghost stories before going to bed, so let's spook Icho with Simon's quirks of the C language. Nothing is new, but everything is written down by me. :-]

<namida42> the function examples with passing arrays, i think i get it
<namida42> but the stuff about function pointers... tehfuqq
<SimonN> hehe
<SimonN> yeah, it's meant to be scary

-- Simon

IchoTolot · « **Reply #10 on:** February 15, 2016, 03:18:37 PM »

Seems like I've got some reading to do over the next days

ccexplore · « **Reply #11 on:** February 16, 2016, 12:43:49 AM »

Quote from: Simon on February 15, 2016, 02:52:32 AM

Everybody loves ghost stories before going to bed, so let's spook Icho with Simon's quirks of the C language.

For "Examples of function pointer signatures", typedef can be used to slightly improve readability of those complex type declarations. I suppose it's true that if C's syntax didn't have some elements (eg. pointer dereference, return type) on the left and others on the right (eg. parameter list), the syntax would probably be a little less convoluted and more naturally readable even for complex type declarations.

Regarding static: it's still a quirk in that if you're not aware of the semantics, the syntax is definitely misleading, looking like the variable is initialized on each entry of the block rather than just once. But it's not too strange if you keep in mind that when you use static in block scope, you are basically really trying to declare a global variable without actually making it visible anywhere else except within the block.

Simon · « **Reply #12 on:** June 07, 2016, 12:36:23 AM »

Bug reporting sucks, and how to fix it

Lovely rant!

Tolerating the flaws in the software because it’s better than filing bugs about them (time frame: 2 weeks to a lifetime)
[..]
Sometimes, the subtle conditions that lead to the exposure of a bug are so difficult to describe that you end up with bloated sentences in which you’re mostly trying to convey something visual or with a far too complex linguistic parse tree.
[...]
What you find yourself wanting to do is take a video of the problem occurring, but that would require subjecting yourself to the hell that is desktop video recording software for Linux.

-- Simon

Simon · « **Reply #13 on:** July 02, 2016, 06:33:31 PM »

Controlling your technology

What's a single, concise word for this phenomenon? It's a strong desire to control your technology, even if you never invoke any of your rights.

Example 1. I have a Kinesis computer keyboard. This keyboard beeps on every keydown. When I got the keyboard 3 years ago, the beep annoyed me. I looked through the manual until I found how to disable the beep. But I didn't disable it. From then on, I didn't care about the beep anymore. It was okay.

Example 2. When Proxima assigns during pause, he likes the game to unpause. He doesn't like how Lix advances only by 1 frame. Advancing by 1 frame may be enough feedback, but Proxima wants to play on. Last week, I put a user option into D Lix: You can choose whether the game unpauses on assignment, or advances by 1 frame only. Proxima knows this, and that's okay. He didn't rush to update the game at once.

I told my Kinesis story to a handful of programmers at the D conference in May, and their eyes lit up. This sounded so familiar to them. Proxima and I are in good company when we feel like this!

In open source, you have the right to fork software, but you never exercise your right. Forking is an emergency break for ships careening entirely in the wrong direction, when you can't save anything with diplomacy. Because you're allowed to fork, you risk less by getting used to that software.

The Kinesis beep and Proxima's unpausing are different from open-source forking. I found the beep annoying after buying the keyboard, and didn't know it beforehand. Proxima lost his unpausing because I implemented the one-step advancement. He was already involved with Lix.

It's strange. Dangle the carrot in front of me!

-- Simon

Simon · « **Reply #14 on:** August 03, 2016, 06:36:59 PM »

I would like to criticize level repeats in Lemmings games. A level repeat is a level that copies another level's terrain verbatim, but allots different level constants and skills. I don't like repeats, but others like repeats. This is good thread material, I should make a fresh thread.

Level repeats violate the principle of low coupling. I find this easiest to explain with programming code. Maybe you can already guess how the corresponding level design argument would look like.

For horizontal alignment, do you ignore neighboring lines, and align each line by itself?
x = 20; width = 10;
Or do align horizontally according to neighboring lines?
x = 20; width = 10;
The horizontal alignment brings a maintenance problem. What happens when we insert a third line, or modify the name of an existing variable?
x = 20; width = 10; height = 30;
If you require horizontal alignment, you have to edit 3 lines now instead of 1 line. You have created an unnecessary dependency between all 3 lines. This is Christmas light code: One line goes out, they all go out.

Christmas lights are lovely metaphor for many things, and I should compare more things to christmas lights.

When you work on this code with several people, and several people change unrelated lines, the non-aligned code will still merge automatically. The Christmas light code, however, will give merge conflicts, and needs manual resolution.

These whitespace issues are the least problematic types of coupling in code, but the easiest to reason about.

More severe is semantic coupling in code: Module X depends on module Y, and module Y depends on module X. When one changes, the other may have to change. Can you cut the dependency in one direction at least? Can you make a new module Z with the common functionality, then have X depend on Z only, and Y depend on Z only? This way, because Z will often be small and require fewer changes, you can change X or Y each to your heart's delight.

Keep coupling to a minimum.

-- Simon

namida · « **Reply #15 on:** August 03, 2016, 07:52:43 PM »

NeoLemmix previously (in fact, the current stable version still supports it, but experimental does not and there are no plans to restore this support) supported a feature where a level could define a unique skillset / stats, while referring to another level for the layout.

I'm pretty sure my packs are the only ones that ever actually used it, rather than just having hard copies of the levels. Since it's not widely used, and complicated the code, that's why it isn't being supported anymore. Instead, the editor now has a feature that serves much the same purpose - it loads a layout from another LVL file, without loading the stats from that level, into the currently loaded level. I don't know if this is being used either; at least one person has indicated that they prefer to (upon modifying the source level) simply Save As the level and re-do the different stats / etc.

Simon · « **Reply #16 on:** August 19, 2016, 09:18:47 AM »

Rant topics that I never got around to rant about

Repeats: Levels with the same terrain as another level. There is lots of fire here. I have several arguments flying around and never wrote them down.

<geoo> SimonNa: where's your rant topic about repeats? :P
<SimonNa> I wrote about one issue, the need to keep otherwise unrelated data in sync manually. That didn't ring with anyone
<geoo> I actually agree with most of your points, I just reject your conclusion

Drawing alongside writing: I am writing a post, and I want to explain something visual. Ideally, I'd sketch with my hand right inside the post. The cumbersome solution is to open a painting program, draw a picture, then upload or attach. Way too cumbersome, and fragile. The image should be data right in the ~~code~~ text, and I should be able to draw on the screen somehow. Technology sucks here.

Generate subforum from topic: I have a topic to split up, but I don't want to generate multiple topics on the existing board. I want these to belong together clearly. Instead of forum topics, I want directories. A directory contains either exactly one linear discussion (screw tree discussions, they suck, everybody replies wrong) or more directories.

Everybody should split and merge: When you have >= 100 posts, you can move and split and merge forum topics to your heart's delight. Like Stackoverflow. The forum software should version everything, which it doesn't right now.

Coins should be square: Then they don't roll under the sofa. And you don't need a 20-cent piece when there exists a 10-cent piece. You learn that from every site that teaches choosing poker chip denominations. There should be a 1-unit piece, this is the smallest unit that you can trade with cash. Then a 4-unit piece, a 16-unit piece, a 64-unit piece, and so on.

Functions compose from left to right: Instead of y = f(x), write y = xf. Then h(g(f(x))) becomes xfgh. Vectors are row-vectors by default, then vM makes sense for a matrix M. Matrix multiplication can stay like it is. Everything becomes a Unix pipe! Stuff gets processed in reading order!

You can treat a piece of data, x in the above examples, as a function from the one-point set into your data domain. Then everything is a function. Everything is a set, everything is an object, everything is a file, everything is a function.

-- Simon

Simon · « **Reply #17 on:** August 19, 2016, 04:37:03 PM »

My favorite writer on the net is still cbloom.

Nowadays, the good things land on cbloom rambles: When I go to my editor and click on the "X" button, you don't pop up "this file has changed on disk do you want to reload it?". You just fucking close.
His classic rant that I've linked before, Fucking fuck the fucking web: Managers are hesitant to ever admit a mistake or cut a huge feature or redo work, because it reflects badly on them. That's terrible. It means that broken awful shit gets shipped just because they politically have to keep insisting "we did a great job".

But I've found Bob Nystrom's StuffWithStuff. This focuses purely on software design and language features. Some gems:

Higher-Order Macros in C++, let a macro write a list of code-generating macro calls.
The Impoliteness of Overriding Methods: To guarantee that overridden methods work well with your base class, you can mark the base method final, provide a second virtual method to override, and call the virtual method within the final method. This doesn't scale well with deeper inheritance. BETA was a niche language that made this pattern a core language feature: The base methods provided extension points within themselves, or were final.
What color is your function? This article made it to reddit/programming and hackernews last year. Languages lack abstractions over mixing sync and async function calls. If you don't want your application to wait on costly I/O, you must jump through too many hoops.

-- Simon

ccexplore · « **Reply #18 on:** August 19, 2016, 05:50:47 PM »

Wasn't it Simon who once complained about bad topic titles? I think it's time we change "open source != level design" to something more accurately reflecting the current trends of this thread.

==============

I'll see if I have time to actually and carefully read through Bob's gems. My gut reaction though is: "really? advocating for C++ macros? um..." (then again, it's possible the article is more just technical showoff of the crazy things you could do with macros in C++, not necessarily that you want to use them widely). I totally get where he's coming from with the sync/async thing, but can't help but suspect that there may be an unintended side benefit of not having completely identical syntax, in that it makes one more aware of a function being async, which I suspect can be a good awareness to have when you need to reason over code.

Simon · « **Reply #19 on:** August 19, 2016, 10:51:04 PM »

Topic name: Yeah, hm.

It's a blog, except that it's on Lemmings Forums and not on its own site. The benefit is that interesting people will read it here. A more permanent solution depends on how I handle asdf-down.

-- Simon

Simon · « **Reply #20 on:** August 30, 2016, 10:59:50 AM »

Board games with edge cases: I googled for stalemates in Shogi. Stalemates never happen in normal play, but they're a lovely edge case. Game rules should not have holes. The intuitive result is that the stalemated player loses, and I'm happy that it's the customary result, too.

I found a forum discussion on stalemates in Shogi on Little Golem, a turn-based server. The discussion produced the answers I had been looking for. But I was even more happy about this quote:

Anyone who sees the world in terms of clean logic has to be mystified and bewildered by many of the rules in popular board games. Especially ancient board games, like Go, that have suffered thousands of years of pollution from meddling humans... :-/ -- Darse Billings

Yes! When you have surprising edge cases in games, try to make rules as simple as possible while trying to fix them. Can you make the corner case part of the normal cases?

Empathy: Little Golem runs a daily game, Empathy, which is similar to our Quizmaster's Family Feud.

The master presents a single word, today's expression.
Every player private-messages the master with 10 different words. These 10 words should be in close association with today's expression, but players are free to send anything.
All answers are revealed. For every word you send in, you get 1 point per player who sent in that same word. Singulars and plurals of the same word count as a same word.

-- Simon

ccexplore · « **Reply #21 on:** August 30, 2016, 07:28:51 PM »

Quote from: Simon on August 30, 2016, 10:59:50 AM

Anyone who sees the world in terms of clean logic has to be mystified and bewildered by many of the rules in popular board games. Especially ancient board games, like Go, that have suffered thousands of years of pollution from meddling humans... :-/ -- Darse Billings

Too bad I don't know the exact rules of Go to really understand this. I was always under the impression that Go has simpler rules given the much lower number of different types of pieces with different move mechanics. Chess even has its share of special moves like castling, pawn promotion and en passant etc. that are just part of the game, you can't blame them on edge cases. Sounds like maybe Go is more prone to stalement-like conditions that require layers of special rules to deal with?

"Pollution from meddling humans" isn't necessarily a bad thing, or at least it can often be a necessary tradeoff. One thing that came to mind are the mechanics we introduced to lix to make the miner more resilient to canceling. From the rules perspective, those tweaks are not very clean at all, but it seems the "meddling" is called for based on issues encountered in the actual gameplay experience. In many ways it's like patching a level to prevent backroutes: it keeps the level more interesting by eliminating otherwise legal but trivial solutions, but often at the cost of complicating the level with unsightly traps and other such elements.

Simon · « **Reply #22 on:** August 30, 2016, 08:05:56 PM »

Quote from: ccexplore on August 30, 2016, 07:28:51 PM

mechanics we introduced to lix to make the miner more resilient to canceling. From the rules perspective, those tweaks are not very clean at all, but it seems the "meddling" is called for based on issues encountered in the actual gameplay experience.

Yes, miner-anti-shock fixes single-cancelling: If you have a working miner, there are lems in her tunnel, you could have canceled the working miner by assigning miner to a backwards walker in the tunnel tip. We believe that miner-anti-shock is free of unwelcome side effects. So far, it turned out okay.

Miner-anti-shock has complicated the code. We have spent our one chance to introduce a complicated fix: If we ever have to fix another miner behavior, we must check the two complicated fixes for a ton of interactions, or find a complicated fix that covers both cases.

Quote

In many ways it's like patching a level to prevent backroutes: it keeps the level more interesting by eliminating otherwise legal but trivial solutions, but often at the cost of complicating the level with unsightly traps and other such elements.

Yes, extra rules to patch holes are like unsightly traps and steel.

Extra game rules can be more severe, because unlike traps and steel, you must memorize them. Learning the game becomes more expensive. Some extra rules distract from beautiful pattern finding, because they introduce exceptions that feel arbitrary.

Quote

Too bad I don't know the exact rules of Go to really understand this. I was always under the impression that Go has simpler rules given the much lower number of different types of pieces with different move mechanics.

Go can be scored in different ways: Area scoring and territory scoring.

Area scoring is simpler, more beginner-friendly, and almost every computer program uses it. You get 1 point for each living stone, and 1 point for each node of territory. If you play unnecessary moves within your own territory, you don't lose anything: You have 1 more living stone and 1 fewer territory.

To resolve difficult positions, near the end of the game, you can play them out at no cost. Normally, players agree what is alive and dead. Playing out everything is rare, that's to settle disagreements. You may resume play and capture every dead stone.

Territory scoring gives 1 point for each stone you have captured, and 1 point for each node of territory. If you now play in your own territory, you lose a point.

If both players agree what stones are dead, they are removed after play at no cost. But if the players don't agree, you can't capture for free, because playing in your territory costs 1 point. You would really like to declare stones dead that you could capture unconditionally.

This demands that the rules have an understanding of life and death -- the property of stones to be immune to capture against best play. Japanese territory rules demand that you copy the local position to a second board, analyze it there, and use the result to declare stones alive or dead on the first board.

Here's the next can of worms: What is local? The rules must define that. Local positions play out differently than their inclusion in global positions if there is a ko.

The alternative, requiring all dead stones to be captured on the original board, would make plays into the other guy's territory attractive: You play one stone, but it takes 4 moves to capture it, so this play is worth +3 for you. This is unwanted, and thus has lead to such complicated rules for agreement. The obvious solution would have been area scoring. On most positions, they produce the same winner anyway.

-- Simon

Simon · « **Reply #23 on:** September 15, 2016, 08:28:34 AM »

I was bored this morning and looked for bugs in the NL assignment.

I didn't want to program, because that's hard, and didn't want to work on math, because that's hard, and I didn't want to play or design levels, because that's abstrusely hard. Yet I needed intellectual stimulation, and assignment bugs were it. Level backrouting and bug hunting scratch the exact same itch -- finding assumptions that clash with the real world, and building a better mental model from black-box testing.

It's not super useful to debug the assignment: I fished for bugs in code that will be redesigned anyway within the next weeks. Maybe others read the bug reports and treat it as warnings. But the highly artificial ways to trigger a bug make the bug unlikely in the wild. I found Desync on same-frame RR & assignment purely for my personal enjoyment.

The point is not to boast Lix over NL. If I had that goal, I would go develop and showcase my own results, not stir action on the NL board.

Zendo should be similar, but it's not like level backrouting, rather like level solving. In Zendo, I'm trying to discover the designed rule, and fight my own assumptions. But even higher than the beautiful, I value the strange. In backrouting and bug hunting, I find places that still need a design.

-- Simon

Simon · « **Reply #24 on:** September 17, 2016, 04:53:19 AM »

The level is the unit of culture

In singleplayer Lemmings, the level is the most important piece of culture. Everything else must support that, or it has a problem.

Packs and ranks are sets of levels, plus flowery extras: A meaningful order of levels, or cute rank names. Everybody is busy worrying about rank names, or sorting their levels. Icho worries even about a balanced distribution of graphic sets among the ranks.

That's okay, designers can worry about that, and strive for these extra goals. Still, I get a set of levels. I can enjoy the flowery extras, but aren't forced to pay attention to them.

Locked levels or hidden levels get in the way. They remove my random access of levels. It's a designed experience, sure, but doesn't allow the operations that I routinely invoke on a set of levels. I'm happy that the culture has moved away from locked levels.

Beware the bookkeeping

Menu screens, bookkeeping features, etc., all these are okay if they don't get in the way of level playing. Lemmini took notoriously long to restart a level, you had to go through 2 screens. If restart is at least moderately common, design out of existence these screens.

I tried to go too far with Lix, I tried to remove the end-of-game dialog altogether. Instead, the level went into a special kind of pause at end of game, didn't display any message, and didn't pop in any extra UI. The best approach is to pop in UI that's not modal, i.e., that doesn't take away control from the normal game UI. I have settled on keeping all game hotkeys alive in the end-of-game dialog, that's at least an intermediate step towards non-modality.

It's all about how to maximize time designing and playing levels, and to minimize bureaucracy outside of levels.

-- Simon

Simon · « **Reply #25 on:** October 08, 2016, 09:26:40 AM »

Interesting voicechat with geoo yesterday.

Definition (topographic prominence). Let M be a manifold and f a real-valued continuous function on M. Let x be a point of M that is a local maximum, but not a global maximum. Consider the set of all paths w on M that start at x and end at any higher maximum of f than x. For each such path w, we're interested in the minimum value of f along it, min(w) := inf { f(y) : y is in the image of w }. We define the topographic prominence of x as
inf { f(x) - min(w) : w is a path from x to a higher summit }.

Equivalent definition on wikipedia: The topographic prominence of a summit x is the height of the summit at x above x's lowest encircling contour line that doesn't encircle a higher summit than x.

Example 1. Consider the height f of a mountain range on a one-dimensional planet surface M.

The highest peak is special, we don't consider it. Every other peak has a vertical arrow below it that describes its topographic prominence.

Example 2. Consider a little spike on Mount Everest, 10 meters away from the highest summit. Even though this spike is very high absolutely, it has low topographic prominence. There is a path from the spike to the summit that goes down just a little, across 10 meters, and up to the highest summit. The "down just a little" gives the spike low topographic prominence.

Trivia question. We drain the earth of all water, making the mountains under the ocean visible. Our two-dimensional manifold M is the surface of the drained earth. The function f on M measures the height of the mountains.

The highest summit is Mount Everest. Not considering Mount Everest because it's the global maximum, what are the two points on the drained earth with highest topographic prominence?

Solution (click to show/hide)

-- Simon

Simon · « **Reply #26 on:** October 10, 2016, 11:17:18 PM »

The previous post left a trivia question about topographic prominence. I have added the solution to that post.

Simon rants about all the engines

Lemmini ate your files. Superlemmini (SL), because it's more super, creates files instead: SL generates lots of empty directories. Nepster is going to file an issue tomorrow. There is never a reason to create empty directories if you won't put anything inside. When you create a file in a nonexistant dir, create all parent directories along with the file.

NL and SL fade between screens, but don't load anything during this time. Bad, remove the fading. Fading is for music that runs alongside, not for the main content which should pop in ASAP. I wrote about this in a post above already.

Depends on the JVM.

NL has the disarmer that is full of corner cases and makes traps depend on the terrain. The disarmer is a boring key skill: Like a key for a door, it allows access to an area for you, and alters the landscape without flexibility in application. It's not an exciting swiss-army knife, like builders that can fulfil 3 objectives at once. Unlike most key skills such as the floater, the disarmer brings inconsistency and lots of arbitrary design decisions. The worst of all worlds.

The obvious cure is to cull the disarmer, then bomb or bash underneath the trap. Awesome disabled trap, and the idea fits 100 % into what the game is about: Alter the terrain to do things.

Spoiler (click to show/hide)

The NL editor doesn't fetch Lemmini styles and doesn't open Arty's levels. Arty is confused and "Nothing's working and I have to meet with my lab partner now" even when Nepster was there all the time for tech support. Good luck convincing Prince Jamie to develop for NL with this user experience.

Arty should put his levels under version control. Everybody should put their levels under version control! If it's creative work, version-control.

Here is my problem: teaching regular people to use version control is impossible. It just can’t be done in this universe. There is just no possible way a regular Joe can be convinced to start using Git. You know how I know? Because it is fucking near impossible to teach programmers to use it. -- Terminally Incoherent

Lix has too many skills and is intimidating. The imploder is boring, but seems necessary, it's exciting to sacrifice lems in a level design. Too many movement skills. Singleplayer shouldn't have runner, walker, or floater. Multiplayer needs the walker and jumper, but the only reason is "I tried both and this is more fun." I would still remove the runner and the floater, if people let me. :> mobius likes the runner, he likes the movement skills in general, but I don't.

Maybe the blocker should only block your own lems, and we remove the walker. Blocking other people's lems is annoying and not exciting. But we get an inconsistency: Blockers ignore enemy lems, batters bat enemy lems.

Walker skill assignments turn, or don't turn, depends on the previous activity. Bad! Skills should do similar things all the time! I want to cull the walker skill. Help me support this idea and barge forward into the sky of prisine design! L3's direct control sucks when your game isn't about skill pickups.

I haven't worked on D Lix in two weeks, I've been a lazy bum. The necessary work until the first networking tests is forseeable. Now that it's obvious how to do it, I don't need to do it, everybody could do it. >_>

Levels should be small. Or the interface should allow replay rebasing, where you insert skills into a running replay and modify the replay's tail accordingly, without cutting off the tail. Probably both, small levels and rebasing. Rebasing for replays is dangerous, the computer could easily try to be smarter than the user. And the UI that this needs. X-(

Nuke in singleplayer should not be part of the puzzle. The planned multiplayer concede-nuke closes exits in multiplayer when overtime runs out, then everybody explodes. Singleplayer nuke, therefore, should close exits, then everybody explodes. We can consider this to be a single rule for the nuke, because all singleplayer levels and selected multiplayer levels have no overtime.

Screw the 3rd-person-singular-s, it be obvious what the verb belong to, it introduce maintenance in part of the sentence that didn't change.

-- Simon

NaOH · « **Reply #27 on:** October 15, 2016, 06:39:01 PM »

Quote from: Simon on August 19, 2016, 09:18:47 AM

Functions compose from left to right: Instead of y = f(x), write y = xf. Then h(g(f(x))) becomes xfgh. Vectors are row-vectors by default, then vM makes sense for a matrix M. Matrix multiplication can stay like it is. Everything becomes a Unix pipe! Stuff gets processed in reading order!

You can treat a piece of data, x in the above examples, as a function from the one-point set into your data domain. Then everything is a function. Everything is a set, everything is an object, everything is a file, everything is a function.
-- Simon

This has been bugging me since you posted it. If you put a transpose sign after everything, then you can solve a lot of problems, while not breaking any conventions:

All vectors are column vectors by default
Matrices now index correctly, with x and y not being flipped weirdly. A^T_{x,y} = X_{y,x}
Matrices operate on vectors in front of them, left-to-right. x^TA^T = (Ax)^T

NaOH · « **Reply #28 on:** October 16, 2016, 02:29:41 AM »

About your solution:

Spoiler (click to show/hide)

Simon · « **Reply #29 on:** October 16, 2016, 02:46:16 AM »

Quote from: NaOH on October 16, 2016, 02:29:41 AM

About your solution:

How do you define protrusion of a peak? Height difference of the peak and the surrounding ocean floor? What's the exact height of the floor then?

Spoiler (click to show/hide)

-- Simon

Proxima · « **Reply #30 on:** October 16, 2016, 04:18:29 AM »

As I've mentioned before, walker is one of my favourite new skills, because of its multiple uses -- freeing a blocker, interrupting another skill use, turning a lix around -- and you don't know in advance which use will be part of the (intended) solution to a level. This can lead to very interesting resource management decisions.

Very few of my levels use runners, and on the ones that do, they could easily be replaced. Path of Wickedness uses a runner-jumper to clear a wide gap, but I could make the gap smaller instead.

However, at this point it's silly to talk of culling individual skills. The argument that seeing many unfamiliar buttons is intimidating is just as true with twelve as with fourteen. Lemmings had a nice friendly number, eight. But overall, the interesting puzzle potential of the extra skills in Lix vastly outweighs the initial intimidation factor.

DROD has a ton of different elements (roughly 90 in the latest game, which includes all elements from previous games). When the third game came out, I felt there were too many new elements at once and I couldn't get used to them, and soon architects were routinely incorporating the new elements into their puzzles and I felt left behind. I stopped playing DROD for years. What helped me get back into it was the main hold of the fourth game, Gunthro and the Epic Blunder, which is easier than the other main holds and deliberately restricts itself to a subset of elements, and Dan's Dungeon, a well-designed usermade hold that introduces the elements one at a time. Good introduction is much more important than number of elements. (This is the philosophy behind Entry Point, the ongoing project to make a similar introduction hold for all elements in the latest game.)

Simon · « **Reply #31 on:** October 16, 2016, 04:37:07 PM »

Hmm, thanks.

I'm okay with walkers turning, and I'm okay with walkers cancelling. My gripe comes from putting these two entirely orthogonal functions into the same skill.

But it's hard to take them out now: I scanned the community pack for walker usage, many levels have them. I haven't checked for how often they are mere panel decoration, or how often walkers occur in solutions. In any case, the walker is popular with lemforum levels.

The lemforum pack shall replace the skill tutorials, maybe we should improve the pack's walker introduction. The walker is special because it does two different things, and, as a second specialty, blockers can be assigned walker.

-- Simon

NaOH · « **Reply #32 on:** October 16, 2016, 07:44:54 PM »

Spoiler (click to show/hide)

Very cool problem though, thanks!

Simon · « **Reply #33 on:** October 25, 2016, 11:06:23 AM »

Most graphical user interfaces are (1. select object), (2. invoke method on object). Level editors are the best example.

Playing Lemmings is a glaring exception: We click the skill first, then the lemmings. When you have a dense bunch in a pit, it's important that someone bash to the right, we don't care what lem in particular bashes to the right. But is this good enough of a reason? At least it feels right -- geoo and I wanted click-skill-first in Clones when that had click-clone-first-then-skill. I hope it wasn't only out of habit.

The forum has become quiet this week. A nice change of pace. I should focus on real-life work and the occasional Lix work. Then everything will turn out okay in time.

-- Simon

ccexplore · « **Reply #34 on:** October 25, 2016, 07:04:32 PM »

One important case to consider especially in multiplayer is to rapidly assign the same skill to multiple rodents. I guess this actually can still work in the object-then-verb interaction model but requires the ability to select multiple objects first before selecting the verb, which IIRC is absent in Clones. As a result, the Clones interaction model has a glaring shortcoming compared to the verb-then-object model.

I think you are correct to observe that the verb-then-object model typically can be "dangerous" in other contexts, since object selection immediately commits the specified verb, and thus relies on the object selection process being usually error-free on the part of the user--which it tends to be in the game as the rodents are often idempotent in many situations.

The level editor provides an interesting and very different use case to compare the two models. For example, consider the classical case of selecting multiple level elements in the editor to move them as a single unit via drag-and-drop. One can imagine how in a verb-first model, you could perhaps start by dragging one of the elements to the destination, and then while holding some hotkey, just click on the other elements one by one to apply the same movements to them. You do actually get the same final outcome, and I have to say I'm not entirely sure how best to argue for the object-first model being better for this use case, beyond being widely used in other programs. (One thing that does come to mind is, if the destination of the movement is too far away from the source, the verb-first method would require an extra scrolling of the screen, as you had to scroll back to the source location in order to apply the movement verb to the remaining elements.)

Perhaps the verb-first model is mostly habitual when it comes to the game, and that there might actually be a object-first model that do not have any shortcomings. But habit is a mighty powerful thing, and many players have probably already been habituated from playing Lemmings. It also helps that there are a large class of games where the interaction model is basically "verb only", because the "object selection" is implicitly fixed to the one single character that you have "full" control over. So arguably the concept of specifying the verb first is not so foreign at all to many gamers.

ccexplore · « **Reply #35 on:** October 25, 2016, 08:01:41 PM »

Quote from: ccexplore on October 25, 2016, 07:04:32 PM

One important case to consider especially in multiplayer is to rapidly assign the same skill to multiple rodents.

Just occurred to me that the inverse case of the hero lemming, where you want to assign a sequence of different skills to the same rodent, is one case where "object first" is a little more optimal, as you're not forced to re-click the same rodent multiple times for each skill of the assignment sequence. Granted, this is probably somewhat less common in multiplayer, where you often still have to react to things happening elsewhere in the level.

This also brings up another point, that it's not strictly an either-or situation. You can design exceptions to the interaction model to optimize for these various use cases where the predominant model may fall short. For example, while I don't remember if this is specifically added per Simon's feedback, I believe Clones handled the spam-assignment case by implementing a special case of verb-first, where you hold down the hotkey for the skill, then click on multiple clones to assign that skill to each. Conversely, some console versions of Lemmings 2 provided the ability to do a "sticky" selection on a lemming, during which clicking on a skill automatically assigns it to the selected lemming--essentially an object-first method special-cased for the hero lemming.

Simon · « **Reply #36 on:** October 26, 2016, 04:30:43 AM »

Quote

level editor
move them as a single unit via drag-and-drop
how best to argue for the object-first model

The movement target can be complex, e.g., place a cluster of pieces as a unit into a given gap, such that the cluster is centered within the gap. You don't know where any single block will end up before you have moved the entire cluster. Object-first allows for WYSIWYG here.

We can abstract over such clusters in the data model: Create group, add each piece of the cluster to this group, move group. This works in both the object-first or the verb-first world. Maybe this abstraction in the data model is better because it captures our intention: We wanted to move the group as a unit, with requirements for the unit rather than for loose pieces. The downside is that the data model becomes more complex. You're forced to define the map layout in a high-level language.

Quote

rapidly assign the same skill to multiple rodents

Good reason. You need more speed when you assign the same skill to n rodents, compared to the speed where 1 rodent accomplishes several skills, necessarily one after another.

Even for a single assignment, verb-first is fast. While I'm still aiming and clicking with the mouse on the rodent, I have already hit the skill hotkey with the other hand.

Quote

"sticky" selection on a lemming, during which clicking on a skill automatically assigns it to the selected lemming--essentially an object-first method special-cased for the hero lemming.

IMO, this points at a fixable shortcoming of the normal assignment. With directional select and priority inversion, I haven't seen the need for object-first. Long levels with lots of assignments to a hero maybe.

With object-first, but without directional select or priority inversion, you must select the object far ahead of time, before the rodent gets clustered. That should be unnecessary: Assignments happen at a single time, but its input must now span over a long time interval.

Quote

But habit is a mighty powerful thing

Yes!

-- Simon

Nepster · « **Reply #37 on:** October 26, 2016, 06:20:00 PM »

Here are a few more issues to consider when comparing verb-first and object-first:

1) During the first few seconds, clicking on some skill buttons currently does something, i.e. the game responds to player action. With object-first there are (apart from raising RR) nothing the player can act on until the first lemming spawns, even though skill buttons are displayed. This is bad.
So we would have to gray out the skill buttons whenever no lemming is selected. Certainly a possible work-around, but always clickable skill buttons look nicer to me.

2) Changing skills (especially via hotkeys) is much faster than homing in on a lemming and clicking on it (even for a single worker lemming). With verb-first I can simply the order of hitting the hotkey and clicking on the lemming coincides with the order in which my hands finish their work. On the other hand with object-first, my left hand would have to interrupt its action and hover over the hotkey until I manage to click on the desired lemming.
Note that in editors and other applications this is the other way around (at least most of the time). Objects are large and easily clickable, but then I want to apply multiple actions, or a complicated one, or one requiring precision, which usually takes more time.

3) Assume we have objects-first and assume the selected lemming wanders out of the screen. Should we automatically scroll to keep him inside the screen or should we stay at the current position? Automatically scrolling will be annoying, because it takes control away from the player (at least partially) regarding an action that used quite often (namely looking at other places or lemmings in the level). Not scrolling is bad as well, because then it becomes very easy to forget that a lemming is selected which may easily lead to mis-assignments of skills to that lemming.
Again there are work-arounds, e.g. not scrolling and disabling skill assignments to lemmings outside the screen or alternatively splitting the screen and keeping track of the selected lemming in one of the parts.

Of couse I might be heavily influenced by habit, but I feel that verb-first allows for a cleaner workflow.

Simon · « **Reply #38 on:** October 31, 2016, 04:44:42 AM »

Quote

1) During the first few seconds, clicking on some skill buttons currently does something
gray out the skill buttons whenever no lemming is selected. Certainly a possible work-around, but always clickable skill buttons look nicer to me.

Awesome domain-specific reason. Greyed-out buttons have a meaning already in the verb-first design: This skill won't be available throughout the entire level.

I spent the entire Sunday on a loose DVI cable.

My Linux machine decided to boot only into 640x480 text mode. Neither X nor the desktop environment wanted to start. I still had the command-line shell, so I checked all drivers, kernel messages, X log files, ..., and everything seemed perfect, only that the gfx card found no monitor. Edited several config files and rebooted 20 times. If I get 640x480 text mode, it can't be a loose cable, right?

When your monitor plugs into your graphics card via DVI, information flows in both directions:
The gfx card sends the image to the monitor. This is the obvious direction.
The gfx card reads from the monitor certain device info, e.g., max resolution.

DVI connectors come with two screws. I found these screws annoying for years, and only fixed one screw at best. But this allows your DVI cable to jiggle ever so slightly. When your DVI cable isn't 100 % perfectly plugged in, it can prevent the gfx card from reading the monitor values. Apparently, there is this emergency fallback that I landed in: The gfx card still sent 640x480 text mode to a monitor it doesn't even know.

Post on Debian User Forums with detailed symptoms. I love how the author wrote about his solution even though nobody else had experienced the error.

Everyday design

When the designer of USB dies, his coffin will be lowered into the grave... and be pulled back up, rotated half a turn, and lowered into the grave again. Then it'll be pulled up one more time, rotated back to its original position, and buried for good.

baddesigns.com, an old site with lovely everyday examples. When simple things have signs, especially homemade signs, it is usually a signal that they aren't well-designed.

-- Simon

ccexplore · « **Reply #39 on:** October 31, 2016, 07:31:08 PM »

I do believe all of the more recent monitor cable types (eg. HDMI, DisplayPort, etc.) no longer have this particular problem of partial looseness.

I also wonder if there may be conflicting designs at work. Could it be possible that the DVI cable plug's pin layout is designed so that the ones least likely to affect display output (such as reporting back the monitor's data) are placed in the positions more proned to partial looseness? Whereas Linux decides in the potential absence of monitor, the best fallback is to text mode (since command line is king) and avoid graphics mode altogether? Granted, perhaps it would have been more desirable anyway for the DVI pin design to actually be more fail-fast, so that almost any looseness would immediately affect the display output in very noticeable ways.

With regards to USB, they did finally fix the reversibility issue with USB-C connectors. Of course, it'll take a long time before everything switches over to the new connector type, so the issue will still linger around for now.

mobius · « **Reply #40 on:** November 01, 2016, 09:07:59 PM »

I like idea of having buttons greyed out for a lemming which cannot be assigned said skill or if the skill is at zero. Why not both? I'd prefer either having skills always greyed and only light up when selecting a lemming than be assigned such a skill or they are lit up always (except if zero) then dim if the moused over lemming is not able to be assigned.

UWXBill warns against over-tightening the screws on your monitor cables. They only need to be tightened enough that the pins can't be effected if the cord would get yanked on.
Tightening one side and not the other sounds like a bad idea too; one side could pull out further than the other making some pins loose contact or disrupting the connection of all of them.

https://www.youtube.com/user/uxwbill/videos

Last year I had a monitor cable go bad and the result was my whole screen took on a piss yellow color for a while, then the color went away but the screen was left with blurry lines. Eventually it stopped working altogether.

Simon · « **Reply #41 on:** November 03, 2016, 07:40:07 AM »

Hnn, I don't like to tighten screws either, very hard to unscrew. There will always be the next time when you must unscrew something again.

If your monitor shows a weird tint, that's a good pointer to a cable problem. 640x480 text mode was not a good pointer -- maybe I would have found the cable problem faster had the monitor not shown a picture at all.

This machine has an Intel i5-6600 quad-core at 3.3-3.9 GHz. The D compiler parallelizes well over the 4 cores, and I enjoy blazingly fast compilation for Lix's 22,000 lines of D.

Lix itself runs only single-core, even when it verifies replays without displaying any graphics. Still, I get a nice performance boost here over the 10-year-old laptop:

	i5	10-year old laptop
Lix debug build	3 sec	18 sec
Lix release build	17 sec	1 min 40 sec
Verify 600 replays	23 sec	over 2 min
= replays/second	26	5

-- Simon

Simon · « **Reply #42 on:** December 30, 2016, 07:02:43 PM »

I'm back at my university town, the apartment is cold as fuck. I raised heating and shields to maximum power, but it'll take a while. How to stay warm? Good old UI rant!

Still a favorite example of bad interface design: Python shell.

$ python Python 3.5.2 (default, Nov 7 2016, 11:31:36) [GCC 6.2.1 20160830] on linux Type "help", "copyright", "credits" or "license" for more information. >>> quit Use quit() or Ctrl-D (i.e. EOF) to exit >>> quit() $

We know exactly that the user wishes to quit. It's unambiguous, there is no room for error. Every other shell in existence quits on quit. Thus, do we quit?

No, we tell the user to do it another way.

Lasse (reallife friend from university) compared speedrunning to playing the piano. The comparison is great, but it wasn't my first idea. I have compared speedrunning to a relationship. The moment you begin, all bugs turn into features.

-- Simon

ccexplore · « **Reply #43 on:** December 31, 2016, 01:39:36 AM »

Quote from: Simon on December 30, 2016, 07:02:43 PM

Still a favorite example of bad interface design: Python shell.

I'm surprised the introductory text doesn't end with "Type "help()", "copyright()", "credits()" or "license()" for more information."

I suppose because all four are considered nouns and not verbs?

Quote from: Simon on December 30, 2016, 07:02:43 PM

Lasse (reallife friend from university) compared speedrunning to playing the piano. The comparison is great, but it wasn't my first idea. I have compared speedrunning to a relationship. The moment you begin, all bugs turn into features.

Yeah, definitely like the relationship analogy more for this; the glitch-exploiting aspect doesn't really seem to have an analog in piano-playing.

The piano aspect I guess referring to practicing certain difficult parts over and over until it fully and flawlessly commits to muscle memory, which I guess in a relationship might be loosely like knowing the person so well that you can finish each other's sentences.

So maybe it's like a pianist having a relationship while also rehearsing for an upcoming concert?

NaOH · « **Reply #44 on:** December 31, 2016, 05:59:33 AM »

Quote from: Simon on December 30, 2016, 07:02:43 PM

Lasse (reallife friend from university) compared speedrunning to playing the piano.

I was just thinking this, too! When playing a very long and complicated piece, it's a game of "try to get to the end without messing up too badly," lasting several minutes without the ability to save state. Feels just like playing IWBTG.

Simon · « **Reply #45 on:** February 24, 2017, 12:48:08 PM »

Thanks for the responses. I haven't rambled in a while.

Banana trick: Another Simon trick to lose weight. Carry a banana with you, everywhere. Have normal meals as planned. Whenever you get the urge to buy bratwurst, fast food, sweets, or anything else extra -- consider to eat the banana instead. Happily, you will recognize that you aren't as hungry as you thought you were. Often, you won't even eat the banana immediately. It becomes an element of reusable object-oriented diets.

The banana should be greener than brown. Thorsten (reallife friend from the math department) suggests that the banana should not be perfectly yellow, unlike the pure sun. If the banana is yellow, you'll want to eat it!

The banana trick is a variant of the guinea-pig diet. Recall: For the guinea-pig diet, you eat lots of cucumber with everything, because cucumber stuffs well. It tastes good in small amounts; by force of nature, you don't want to over-eat cucumber -- perfect. And cut back on sugary drinks. Occasionally exercise. Imagine you're a guinea pig, everything will follow trivially.

-- Simon

Ramon · « **Reply #46 on:** February 24, 2017, 08:59:11 PM »

It doesn't happen to be the Thorsten Hohage does it :3

I don't know why Simon needs to lose weight. A Simon without his weight in my opinion is not the Simon. But I see where you're coming from. I was also about to ask whether you'd come to Vienna again this year, since you said in 2 years... 2 years ago.

Simon · « **Reply #47 on:** February 25, 2017, 04:35:44 PM »

Quote from: Ramon on February 24, 2017, 08:59:11 PM

It doesn't happen to be the Thorsten Hohage does it :3

Someone else. :-)

Quote

Simon without his weight in my opinion is not the Simon.

I went from 95 kg in summer 2015 to under 80 kg in spring 2016, and right now I'm around 82-83 kg. The secret is routine. Building routine requires overcoming laziness; afterwards, it's easier.

The banana trick is still recent routing, I haven't used it for long yet, and I haven't compared against old strats.

Quote

I was also about to ask whether you'd come to Vienna again this year, since you said in 2 years... 2 years ago.

Still hoping to finish the PhD this year in late summer or fall. >_>

-- Simon

Simon · « **Reply #48 on:** March 17, 2017, 07:44:44 AM »

I overrode Lemmingsforum's 78 % font with the 100 % font by custom client-side CSS, like I did 5 years ago when the youtube embeds annoyed me.

userContent.css (click to show/hide)

Arch updated fonts, now everything looks narrow. The forum font dropped under a personal threshold. Other sites are mostly OK, nonetheless wtf at sudden change in shipped fonts. I even rebooted the machine and cleared some caches to see whether I was insane. Maybe the change wasn't that harsh, but it was a change, and it triggered personal re-evaluation of the forum fonts. They seemed far too small.

A 78% default font size is ludicrous in the first place, that's 1990's web design. Modern style uses large, legible fonts, and prunes prunes prunes prunes prunes the writing instead of cramming small text. Prunes!

I'm admin now, but even though I found the 78 % value in LF's served CSSs, I kept that. This is partly carrot-dangling -- I wrote about carrots earlier in this thread: You're happy once you can turn off annoyances, even if you leave them on. And it feels partly like this ADmiral quote: The greatest masters know when to not execute their power. The best state leader is who could, but never needs to, punish citizens. Likewise, the best object-oriented designers know when object-oriententation is inappropriate.

6 hours later: Now Firefox shows the wider font again. I didn't revert the update, no idea what I missed earlier. Oh well, now the font is both wide and large. <3

-- Simon

ccexplore · « **Reply #49 on:** March 17, 2017, 11:01:19 PM »

All I can say is that I didn't notice any recent changes, but I'm not using Simon's custom CSS nor Firefox (nor Linux). I may well be mistaken but I thought this forum had just been using the SMF defaults? Changing the forums fonts without even so much as a poll would be very bad form indeed.

If there's concern about user's inability to customize things like font sizes on browsers not supporting custom client-side CSS, perhaps there's a forum mod out there that can provide a similar feature?

Simon · « **Reply #50 on:** March 18, 2017, 08:06:17 AM »

Lemmingsforums has been the same style since 2015, yes.

What I think happened: Archlinux updated a font package, and something in some font cache mismatched. This is normal and happened before. Apparently, waiting a few hours invalidates whatever cache I missed.

-- Simon

Simon · « **Reply #51 on:** March 27, 2017, 03:04:44 PM »

Just

Standard situation: You are working within environment E and are trying to do X. You google or ask people. Person A tells you: "Just do Y." This "just" means many things at once:

E is horribly broken and overdesigned.
X is a natural problem to solve, but has no adequate natural solution within E.
Y is a terribly brittle, but standard workaround. Use it, then mindlessly learn it.

Why does A write "just"? If Y were that simple and natural, they could merely state Y. No, they forcefully dressed up Y as simple, for fear that we might not consider it simple otherwise. Does A want to hide from themself their own double standard?

This pattern is absurdly prevalent with any typesetting problem in Latex. It sucks, it sucks, it sucks. You google for a seemingly straightforward X, land on Latex stackexchange, and someone tells you "just include 2 packages and copy 10 lines of crap into your header." Bon appetit. You can never guess the pattern behind anything. Unless you want to do exactly Y, and not a minor variant of Y, you're terribly stuck.

Mathematicians shouldn't have to put up with this, but it's standard, live with it. You're already the golden hero if you can git commit -am, and don't have 100 commented-out lines in your header that someone-else copied from someone-else-2's bachelor thesis.

Simple stands out by itself.

The principle extends to anything, not only simplicity. When people insist that X has a property, it doesn't have that property at all. There was this meme image: Genders are a social construct, but if you're fat, then it's a genetic thing. I should go home and insert that here.

When I wrote my PhD thesis, I made sure that I spent at least as much time on the research as I spent on typesetting. -- Scott Meyers

The actual simplicity of software is not proportional to the lines of code, or the number of actions or command line arguments or anything like that. It's proprtional to the number of questions about that software on stack exchange, or the number of pages in the book about how to administer it. -- cbloom, on how git is not simple

-- Simon

ccexplore · « **Reply #52 on:** March 27, 2017, 09:03:58 PM »

Quote from: Simon on March 27, 2017, 03:04:44 PM

Person A tells you: "Just do Y."

I think part of the problem is that most people Googling for answers tend to just want something they can quickly copy-and-paste into their own work. Often they don't actually want to take the time to really understand how it works or if it even really works correctly all the time. So answers of unknown quality and lacking detailed explanations become the kind that gets passed around a lot, not necessarily because they are good as that they are expedient for all (typical) parties involved.

And honestly, with today's technologies, you would think one should be able to just write out an equation with a stylus or finger and have it automatically converted to the relevant representation in code, be it Latex or whatever else is used. Even if the conversion isn't perfect I'd think that should save some time overall. Granted, you can argue that it encourages people not to understand the code layer, which does make things more difficult when they do have to manually fix-up code from a suboptimal conversion.

Simon · « **Reply #53 on:** April 05, 2017, 01:36:39 PM »

Wurst cutting game

Two players. Each player gets a nice, tasty sausage of equal weight. The game is played in rounds until one player has reached a goal score of N points, agreed before the game.

Each round, cut off from your wurst a piece sized as big as you like, and submit that piece for scoring. Neither player can see how much the opponent submits before both pieces are submitted. If you submit more than the opponent, you score 1 point, the opponent scores 0. Submitted pieces are removed from the game, and the next round starts with your remaining wursts. That's all the rules.

You can discretify the game like this: Each wurst weighs 1,000 grams, you may only cut off integer amounts of grams. Guarantee somehow that the game ends in finite time.

For this discrete game, you could rewrite the multi-round strategy tree as a single, huge matrix, then use Nash's theorem to show that there is a Nash equilibrium: There's an optimal probability distribution of how much wurst you should cut. I've never worked out the details of this equilibrium; at least it seems managable for a target score of 2.

I don't watch TV, but friends told me this. Schlag den Raab is a German game show. The host played the Wurst cutting game against another celebrity. You needed 5 points to win. The celebrity had 3 points already. The next round, the celebrity submitted his entire remaining wurst.

-- Simon

Proxima · « **Reply #54 on:** April 05, 2017, 03:12:27 PM »

That reminds me a little of Gops, which I played with my friend Laura in high school.

How to play Gops: Take a normal pack of cards (no jokers), and separate the suits. One player has the clubs, the other the spades. Shuffle the diamonds and place them in a face-down pile. The hearts are left out.

Turn over the diamonds one by one. For each one, after it's been revealed, both players bid for it by placing one of their cards face down, then both show their bids. The player making the higher bid (Ace is low) takes that diamond, but the bid cards can't be reused (so you have to use all 13 cards once each). If both players make the same bid, the diamond goes to the winner of the next bidding round.

At the end, add up the value of the diamonds you've won (A = 1, 2 = 2 etc up to K = 13) and the player with the higher total wins.

Simon · « **Reply #55 on:** April 09, 2017, 02:51:05 AM »

I've played Gops! We discarded tied diamonds instead of accumulating them. Either rule works and makes for an excellent, simple game. Very straightforward, can't prune anything from the design, and playable with a standard deck of 52 cards. Seal of rodent quality.

There is a variant of Gops sold as a commercial gard game, it gives tied prizes to the highest bid that doesn't tie, which may well be the lowest. I don't like that rule, it's too volatile.

ALSA black magic

ALSA, the Linux sound system, is trial-and-error. Discord didn't want to pick up my default sound input device. Yet every other program worked perfectly. I'm hesitant to assume bugs in widespread software, but this was so lopsided, I gave this a 50-50 shot to be a Discord bug, and that my config was as good as it could be.

.asoundrc (click to show/hide)

This solution was obviously nowhere documented, I had to hunt around the web for random things to try. But there it is. I'm dumping it here partly to rage, partly to help future me and others.

Maybe Discord or Electron call ALSA somehow differently library than my remaining programs call ALSA? Who knows. Discord is closed-source bloatware that does too much.

I still recommend the open-source Mumble for Lix. Mumble does one thing, and one thing well. But Arty would have been readily voicechattable only in Discord today, and the Jazz community uses Discord. Thus, happy that this works again.

Simon: The worst thing about Discord are the cutesy help pages
Simon: I want hard-ass debugging tips with pruned writing
Arty: Oh, Simon is still ranting about Discord. I guess I have to upload this video in the uncolored channel. (= not suitable for American children for profanity? profannyty? <_<;;)

-- Simon

Simon · « **Reply #56 on:** April 13, 2017, 05:32:02 AM »

Plans

Finish oriental tileset, merge physics changes from the git backburner. Release this before the now-unreleased physics changes turn 1 year old. <_<;;

Have a speedsolving competition, like Rubix hosted in 2014. The host prepares several puzzles, no contestant can see them in advance. Ideally, everybody sits in IRC. Time starts when the host shares the download link; time ends when you link to your zip file with proofs.

Maintain a normal sleeping pattern. Nepster leaves IRC every day at 0 German time, very consistent. Hats off. Night cap on. But how can you sleep easily when there might be exciting bugs discussed in IRC?

Find answers to the deep problems in life. When you update your physics, who is responsible to keep level packs up-to-date? What happens if maintainers leave after some years? Our culture with replay coverage is still young, we haven't ever faced this. Probably someone must step up and become maintainer of the orphaned pack. Should they force themselves to look at all solutions?

Make the eggplant-sucuc dish with Icho again. Last time we had that, I was a fat Leekdiana Jones. I used Gimp to manipulate a photo and put mustaches and pipes on everybody. I think the photo is gone by now, it was hosted on asdfasdf. Maybe it's on the old laptop, but I doubt it.

-- Simon

Simon · « **Reply #57 on:** April 17, 2017, 04:27:02 AM »

Youtube rage

I maintain videos on youtube, such as my 5-week-old Jazz Jackrabbit in 28:09 world record (youtube vid).

A happy viewer wrote a comment. A happy Simon replied. But my reply wouldn't show! I saw only the original comment, even hours after. This can't be related to browser cache.

I google for the problem. Search result: Youtube videos.

This is understandable. The problem is with youtube, therefore it will strike youtubers, therefore youtubers react how it feels natural for them: By creating a video. Eeeargh, sooooo. Today I'm going to show you how to view your comments on youtube. As you may or may not have seen, youtube doesn't show... eaahh, comments. Please like and subscribe. Have you checked your video settings? You will now be able to see your comments. If you like this video, please like and subscribe!

These have abysmal information density. And miserable hit rate. I skimmed through one or two of these -- every suggestion was either unrelated, or obvious and I've already checked for it before even googling. I did not subscribe.

Use the correct technology for discussing problems: Text! Maybe even an article with images. Good writing is random-access: You can skip over what you already know. Videos make that hard. If you think an un-postprocessed 2-minute screencast is best for your 2-paragraph, 10-second payload, you show technical incompetency. Good that it's sensable already from the form, not only from the content.

I found the answer only in later search results, IIRC in a reddit thread. Solution: My reply indeed got through, I can see it in a private-mode browser. It's a bug in the youtube page, not in the database. I like this, my data is OK.

Technical issue videos have one massive, good use: Record a bug live, then send the video to the developers. This is perfect. The screencast informs devs about a hundred things that you wouldn't have mentioned in a written bug report. Lix #159 happened when Flopsy plays Lix (youtube vid). I could see Flopsy use savestates and restart before the bug manifested, that was super helpful.

Similar phenomenon: Discord bot development. Bot writers use discord, therefore some require bug reports on discord, not on github. This is like one long forum thread with bugs burying other bugs, complete with off-topic banter.

-- Simon

ccexplore · « **Reply #58 on:** April 17, 2017, 11:47:43 AM »

I guess technical issues videos might also be occasionally useful for providing exact step-by-step to a complete novice, when you can't be there either in-person or via remote assistance software to do it for them (eg. the dreaded phone call assistance $:-\$ ), but maybe you can email them a link to the video and hope they can follow it better than you trying to describe what to do purely verbally over the phone. For the likes of us, video help are problematic for the reasons you listed, and tends to be more likely of a miss the more technical or non-obvious the problems/solutions are. To be honest, to someone like me who never livestreamed anything or produced much on youtube in general, it almost seems like more work to make a video than just make a post about a solution, but I guess like you said, for seasoned youtubers, making videos must be more second-nature compared with old-fashioned text. $:-\$

Simon · « **Reply #59 on:** April 25, 2017, 10:17:27 AM »

Yeah, videos for technical newbs are probably OK. I hope that my issue was not newb-level, but I'm never sure. >_>; The video results aren't completely bad, they had basic advice. I'm merely irritated how prominently this appears in search results.

Broccoli (inverted carrot)

I wrote about carrots earlier in this blog: A carrot is a feature that you want in a given program, maybe you push very hard for the feature. But once the feature is in, you don't use it, you're perfectly happy that you could access its power at any time. You believe that you'd be annoyed were the feature removed, even though maybe you wouldn't notice at all.

Carrots are orange, their interesting part is the bottom half. The top half is a boring bush.

Broccoli is green, and the interesting part of broccoli is the fractal twigs at the top. The bottom is a boring stem that tastes like wood. Children don't like broccoli, but it is excellent. It's the main ingredient in the awesome ham-broccoli-creme-fraiche sauce for noodles. Therefore:

A broccoli is a feature you haven't wished for, but once it's there, you clearly see its usefulness and grow accustomed to it. Were it removed, you'd notice its lack. Maybe you even push for it in related applications, but find it hard to justify. The feature looks too expensive for unclear benefit.

Performance is broccoli. Open source is broccoli. D templates are broccoli.

Staircase blueprints (a.k.a. shadows) before a builder assignment sound like broccoli, but I'm not sure. You can explain the idea to anybody on this forum in 5 seconds, and they realize why it's useful. It has minimal interaction with UI, will not break workflows. A good feature that I want in Lix, but not perfect broccoli. I've merely pushed it too far behind in the priority queue, that's the only broccoli potential of blueprints.

Re performance. I've changed a part of the Lix physics from garbage collection to reference counting. Now the automatic replay verifier is 3 % slower.

But that should become an entire post with design ideas and tradeoffs.

-- Simon

ccexplore · « **Reply #60 on:** April 25, 2017, 06:39:46 PM »

Quote from: Simon on April 25, 2017, 10:17:27 AM

The bottom is a boring stem that tastes like wood.

Perhaps you need better recipes.

To be fair it does take a little bit of work to get around the woodiness. You typically need to peel off a bit of the tough outer parts then slice it fairly thinly. Then you can use it kind of like a carrot in say an Asian-style stir fry or something.

Anyway, broccoli isn't exactly my favorite vegetable regardless of which part. It's for the most part not too terrible but typically I feel like in most cases you can substitute a better vegetable. I especially hate eating it raw.

Quote from: Simon on April 25, 2017, 10:17:27 AM

Performance is broccoli. Open source is broccoli. D templates are broccoli.

Not disputing the spirit of the blog post, but if broccoli is a feature, seems like we are stretching the word "feature" a bit to cover something like "performance" or even "open source".

Simon · « **Reply #61 on:** April 27, 2017, 06:38:01 AM »

Yeah, "feature" is stretched by what I wrote. What's a better word?

I already like how "issue" matches the reporter's point of view, where "bug" carries a judgement by the dev. I still use "bug" because the word feels so appropriate.

Calendar

I wrote a PM on how I'll stream the Lix multiplayer on Saturday, April 29, 16:00 UTC. In the PM, I wrote "Saturday, April 30", which is rubbish. I had to send a second PM to fix the date.

I was in a meeting yesterday, they discussed a schedule printed on paper. The schedule designer got a date wrong, but the weekday correct. The meeting spent two minutes agreeing on the right date, fixing it on everybody's printouts.

This happens all around the globe and costs billions of dollars. The poor dinosaurs died so that we can waste energy on the same pattern every time: Relating to the day of the week is easy. Day of the months have no meaning. Months by themselves feel interesting.

The solution is to adopt hexadecimal, then number the days from the beginning of the year. // TODO: is year still a reasonable outermost cycle? Doesn't align with the days

One ~~week~~ ~~doubleweek~~ heek is 0x10 days. The last digit of the date is the day of the heek. You can have 5 or 6 free days in a heek, which is a higher ratio than 2/7. Fix this ratio by removing Easter and other UI sins. Dates go from 0x000 to 0x16E, the first two digits of a date feel month-like. The revolting French didn't get their metric calendar past the church, but this is better anyway. :>

This is not new, I'm sure others have had the exact same idea.

Good image viewers for the command line: They must be dependency-lightweight and cycle between files in the selected dir. Eye of Gnome was good back on Debian 6 when I used the Gnome desktop. Here, on Arch with the xfce4 desktop, I don't want to install half of Gnome merely for an image viewer. Image viewer is now feh.

DESCRIPTION feh is a mode-based image viewer. It is especially aimed at command line users who need a fast image viewer without huge GUI dependencies, though it can also be started by (graphical) file managers to view an image.

-- Simon

ccexplore · « **Reply #62 on:** April 27, 2017, 10:27:46 AM »

Hmm, so if the calendar entry is serious and I read it correctly, the heekly cycle abruptly resets at the end of the year going into a new year? I guess I could live with that (well, as long as it translates to a built-in shortened work week and not an extra-long one). It is kind of unfortunate that it currently takes approximately 365 days for the earth to revolve around the sun, and 365 only factorizes into 5 x 73, making some sort of irregularity kind of inevitable (even ignoring the need for leap days).

How does one screw up the date anyway nowadays, when even your phone probably has a calendar to check with?

ccexplore · « **Reply #63 on:** April 27, 2017, 10:40:26 AM »

Come to think of it, the 7-day week basically comes out of the Bible. Kind of makes me wonder how other calendar systems with no biblical influences do weeks. I'd guess there are probably some (maybe even most?) that only have months with the occasional scattering of holidays here and there?

This really makes one appreciate the phrase "thank god it's Friday". Without the week based on Genesis with a church-mandated day of rest, we could well have ended up with a lot less free days. You can indeed thank (Judeo-Christian) god and religion for having the tradition of weekends.

Colorful Arty · « **Reply #64 on:** April 27, 2017, 01:49:30 PM »

Good luck implementing this change Simon. Also, you can't just get rid of Easter; no Christian is going to accept that.

Nepster · « **Reply #65 on:** April 27, 2017, 04:30:47 PM »

Sorry, but I feel that a lot of the latest arguments are not quite thought through:

Quote from: Colorful Arty on April 27, 2017, 01:49:30 PM

Also, you can't just get rid of Easter; no Christian is going to accept that.

And what about Jews, Muslims, Hindi, Buddhists, ... who get useless work-free days, but have to work on their own religious fests? A much better suggestion is to remove all religious holidays, but give employees some more vacation days. This of course creates other problems of its own, but at least it respects all religions.

Quote from: ccexplore on April 27, 2017, 10:40:26 AM

Come to think of it, the 7-day week basically comes out of the Bible. Kind of makes me wonder how other calendar systems with no biblical influences do weeks.

And as current dicture says that the bible are not the words of God directly, this should make you wonder how the 7-day week got to make its appearance in the bible in the first place... I believe the answer lies in the lunar cycle of 28 days. This is a very convenient time measure between single days and years, that can be checked almost every night, and where you can even measure ratios by the moon's appearance. So it makes sense to define weeks as quarters of the lunar cycle.

Quote from: ccexplore on April 27, 2017, 10:40:26 AM

This really makes one appreciate the phrase "thank god it's Friday". Without the week based on Genesis with a church-mandated day of rest, we could well have ended up with a lot less free days. You can indeed thank (Judeo-Christian) god and religion for having the tradition of weekends.

I highly doubt your last sentence. If I remember correctly, in Germany we switched from the 6-day work-week to the 5-day one in the 1950s. While Germany was a lot more religious at that time than it is now, barely any change in legislature or every-day life was dictated by religious concerns. Actually I cannot even think of any religious reason for this change, especially as the bible seem to suggest working on 6 days a week. Therefore I conjecture that for any community, there is an inverse relationship between the average working hours and the technical/social development, regardless of any religious concerns.

Quote from: Simon on April 27, 2017, 06:38:01 AM

The solution is to adopt hexadecimal, then number the days from the beginning of the year.

One ~~week~~ ~~doubleweek~~ heek is 0x10 days. The last digit of the date is the day of the heek. You can have 5 or 6 free days in a heek, which is a higher ratio than 2/7. Fix this ratio by removing Easter and other UI sins. Dates go from 0x000 to 0x16E, the first two digits of a date feel month-like. The revolting French didn't get their metric calendar past the church, but this is better anyway. :>

You completely failed to demonstrate why this change would solve any problem at all!
1) You mistakenly wrote "Saturday, April 30", but with your change you would have written "Saturday, 0x78", which is equally wrong. Sure, it is easier to see that the 8th day of the heek is not a Saturday, but what does that help? Did you intend to write "Octaday, 0x78" or perhaps "Saturday, 0x76"? And if you would just have written "0x78" without the day of the week, but meant "0x76", then noone would have realized that something is wrong here.
Note that you got the day of the week correctly, but messed up the date. So adding the day of the week (which is more or less independant of the date) adds a way to check the correctness, similar to checksums of bank accounts IDs.
2) Assume you want to compute the date of 20 days in the future, starting with May 21 or 0x8D. Do you really think that computing this is hex is less error-prone than in the current way? Sure, now you have to know how many days the month May has, but I would say this is pretty common knowledge

. In any case the errors comes from the change of the month resp. heek.
3) Finally your choice of hex is completely arbitrary: Why not use the base 7 which ties nicely to the current week scheme? Then each day of the year has a 3-digit number, and we only have to take the last three weeks of every year as vacation, because we cannot express the date any more

Simon · « **Reply #66 on:** April 27, 2017, 05:18:16 PM »

Quote from: Colorful Arty on April 27, 2017, 01:49:30 PM

you can't just get rid of Easter; no Christian is going to accept that.

Christians can celebrate that, I don't mind. But mandatory work-free days are not good, especially when they're as irregular as Easter. I am arguing from the standpoint of simplicity, but Nepster's secular argument is equally important.

Quote

1) You mistakenly wrote "Saturday, April 30", but with your change you would have written "Saturday, 0x78", which is equally wrong. Sure, it is easier to see that the 8th day of the heek is not a Saturday, but what does that help? Did you intend to write "Octaday, 0x78" or perhaps "Saturday, 0x76"? And if you would just have written "0x78" without the day of the week, but meant "0x76", then noone would have realized that something is wrong here.
Note that you got the day of the week correctly, but messed up the date. So adding the day of the week (which is more or less independant of the date) adds a way to check the correctness, similar to checksums of bank accounts IDs.

I would have written 0x76. The last digit of the date carries all the emotional meaning that "Saturday" carries today. There is no need to annotate the 6 à la "day 6 of the heek, 0x76".

In hex calendar, the mistake would happen so rarely that we don't need the checksum anymore. The mistake happens today because the day of the month carries almost no feelings. I don't care whether it's the 29th or 30th, but I certainly care whether it's Saturday or Sunday. In the hex calendar, we imbue this care into the date.

This is really the heart of the argument. I want to design the error out of existence, not find ways to fix it after it happens.

Quote

2) Assume you want to compute the date of 20 days in the future, starting with May 21 or 0x8D. Do you really think that computing this is hex is less error-prone than in the current way? Sure, now you have to know how many days the month May has, but I would say this is pretty common knowledge . In any case the errors comes from the change of the month resp. heek.

0x8D + 0x14 = 0xA1. This is straightforward.

May 20 + 20 days = May 31 + 9 days = June 0 + 9 days = June 9. This requires an extra step without any gain. Even though everybody knows that May ends after 31 days, it's a mental dependency. Whenever you can remove the need to think during a computation, you have more time to focus on more interesting things.

Quote

3) Finally your choice of hex is completely arbitrary: Why not use the base 7 which ties nicely to the current week scheme? Then each day of the year has a 3-digit number, and we only have to take the last three weeks of every year as vacation, because we cannot express the date any more

Hex has lots of powers of 2 in the base. You rarely want to divide by anything else. The usual counterargument I get here is "But what if you have one cake and 3 children?", to which the answer is "But what if you have one cake and 11 children? Why shouldn't the base be 1*2*3*...*19*20?"

Hex has an integral square root, 4, of the base 16. This makes it much easier to learn by heart the multiplication tables: In base 10, you must memorize everything. But in hex, you can learn the multiplication table for base 4, then split each hex digit into first and second nibblet, and do four multiplications in base 4. After you did this often enough, you'll see the emerging patterns. You'll grow accustomed to multiplication in base-16 in one go, and don't have to split into nibblets anymore.

Base 4 has both properties, too, but it's low. Base 64 is too high. Hex is the perfect base.

-- Simon

Nepster · « **Reply #67 on:** April 27, 2017, 05:32:01 PM »

Quote from: Simon on April 27, 2017, 05:18:16 PM

I would have written 0x76. The last digit of the date carries all the emotional meaning that "Saturday" carries today. There is no need to annotate the 6 à la "day 6 of the heek, 0x76".

In hex calendar, the mistake would happen so rarely that we don't need the checksum anymore. The mistake happens today because the day of the month carries almost no feelings. I don't care whether it's the 29th or 30th, but I certainly care whether it's Saturday or Sunday. In the hex calendar, we imbue this care into the date.

The question is: Is it more important that the person writing the date can check whether the date confirms with the intended day of the week, or is it more important the the audience can check this? As I don't have faith in general people to actually check whether the date they arrive at makes any sense at all, I very much like the ability to make a sensibility-check myself.

Quote from: Simon on April 27, 2017, 05:18:16 PM

0x8D + 0x14 = 0xA1. This is straightforward.

Go out on the streets and ask the first passer-by to compute that...

Quote from: Simon on April 27, 2017, 05:18:16 PM

Hex has lots of powers of 2 in the base. You rarely want to divide by anything else. [...]
Hex has an integral square root, 4, of the base 16. This makes it much easier to learn by heart the multiplication tables: [..]

When was the last time you wanted to divide or multiply the current date?

Simon · « **Reply #68 on:** April 27, 2017, 05:46:58 PM »

Quote from: Nepster on April 27, 2017, 05:32:01 PM

The question is: Is it more important that the person writing the date can check whether the date confirms with the intended day of the week, or is it more important the the audience can check this? As I don't have faith in general people to actually check whether the date they arrive at makes any sense at all, I very much like the ability to make a sensibility-check myself.

You propose that everybody deliver the checksum with the date -- not only when it's super important, but almost every time a date appears. Why do you like this only for dates? Are dates so much more important than anything else?

Would you like it for phone numbers, too? A culturally-encouraged hash whenever you write a reallife address or email address? Do you want the checksums for money, with the bank transferring lottery winnings saying "+1,000,000, one million euros, 11333311 in base-7"?

In the month-week system, you cannot get away from checksumming, and the system is complicated enough that it requires checksumming in the first place. Do you really see no complexity problem in the two misfitting bases running alongside each other, with the month base even changing between months, and the weeks not resetting between years?

Quote

Go out on the streets and ask the first passer-by to compute that...
When was the last time you wanted to divide or multiply the current date?

The assumption is that hex should be used not only for the calendar, but for everything, abolishing decimal. <_< You can certainly use decimal to count days from the beginning of the year, but then you'll have to fix the calendar again two years later when I push for hex-for-everything.

-- Simon

Colorful Arty · « **Reply #69 on:** April 27, 2017, 05:49:10 PM »

This is a very interesting topic. While hexadecimal is very useful, your average joe has never even heard of it, meaning changing it will be very difficult.

Also, I guess I misunderstood your point about Easter; my bad. The problem with adding more vacation days and removing mandatory holidays is that you could run into a situation where your department is so busy at Eastertime, taking Easter off isn't really an option. My solution is just give everyone their religious holidays off, but they don't have to take days off for religious holidays that they don't celebrate.

Simon · « **Reply #70 on:** April 27, 2017, 06:00:16 PM »

Hnn, thanks.

Most likely, in 50 years, we'll still use the old calendar and teach decimal in elementary school.

I merely got bitten by the same problem with dates twice in succession. I still believe that counting from beginning of year, merging the principles behind weeks and months, reduces 90 % of mistakes. I may have presented the design slightly too provocatively; I've tried to match this topic's tone.

-- Simon

Nepster · « **Reply #71 on:** April 27, 2017, 06:05:18 PM »

Quote from: Simon on April 27, 2017, 05:46:58 PM

You propose that everybody deliver the checksum with the date -- not only when it's super important, but almost every time a date appears. Why do you like this only for dates? Are dates so much more important than anything else?

Would you like it for phone numbers, too? A culturally-encouraged hash whenever you write a reallife address or email address? Do you want the checksums for money, with the bank transferring lottery winnings saying "+1,000,000, one million euros, 11333311 in base-7"?

In the month-week system, you cannot get away from checksumming, and the system is complicated enough that it requires checksumming in the first place. Do you really see no complexity problem in the two misfitting bases running alongside each other, with the month base even changing between months, and the weeks not resetting between years?

Average Joe does mathy computations with dates, but rarely does computations with email addresses or lottery winnings. And if my supermarket cashier regularly gets the return money wrong, I doubt you can make the date system so easy, that our Average Joe reliably gets it right.
Of course, the current system is complex and could be easier. But I still prefer it with its checksum property over a slightly easier system without checksum.

Quote from: Colorful Arty on April 27, 2017, 05:49:10 PM

The problem with adding more vacation days and removing mandatory holidays is that you could run into a situation where your department is so busy at Eastertime, taking Easter off isn't really an option. My solution is just give everyone their religious holidays off, but they don't have to take days off for religious holidays that they don't celebrate.

Only slightly exaggerating: Your system basically amounts to giving all people off the whole year and tell them to report when they want to work. That's basically the inverted version of my own suggestion.

ccexplore · « **Reply #72 on:** April 27, 2017, 08:11:59 PM »

Quote from: Nepster on April 27, 2017, 04:30:47 PM

Quote from: ccexplore on April 27, 2017, 10:40:26 AM
This really makes one appreciate the phrase "thank god it's Friday".<snip>
I highly doubt your last sentence.<snip>

Sorry, I really should clarify. In terms of religious influences I'm primarily thinking specifically of Sundays only. I'm aware that how Saturdays are handled wrt work week differs a little from place to place and time to time. As such maybe it is a bad choice to talk about TGIF which most definitely references a 2-day weekend starting on Saturday.

My main point is more about the possibility that there could've been no weekends at all. Certainly from point of view of a pre-industrial, primarily agrarian society, it's not like you would stop feeding your chickens and do whatever daily tasks a farmer/rancher needs to do just because it happens to be a certain day of the week.

It is interesting though that you point out the 28-day lunar cycle could form an alternate basis for a 7-day week, I haven't considered that.

Simon · « **Reply #73 on:** May 30, 2017, 11:15:54 AM »

Root partition

Tips around the internet suggest about 20 GB for the root partition on a typical Linux home system. The root partition hosts the operating system, programs installed for all users, libraries, temporary files, ... almost anything except for your personal data.

20 GB is too little in 2017. Anything with multimedia is fat, even when it doesn't yet output files. A workable system is already 5 GB. The video codec suite ffmpeg together with CUDA and other dependencies easily eats 5 GB. Maybe the OS wants to store old packages for emergency downgrades, etc., another few GB. Latex with common packages is over 1 GB. Interested in programming projects in different languages? Several hundred MB for each environment with libraries and toolchain.

40 GB seems much more adequate. When you can fit a walrus on the root partition, it's adequately sized. I conjecture we need 80 GB in 2030, 160 GB in 2040, doubling every 10 years. When I'll be 85 years old, in 2070, let's check how accurate this guess was.

-- Simon

ccexplore · « **Reply #74 on:** May 30, 2017, 06:37:37 PM »

Not much familiarity with Linux, but the fact that apparently installed programs and libraries has to go to the root partition too sounds like it could be tricky to keep it lean.

Out of curiosity, what are the advantages to separating personal data into its own partition? It seems quite annoying being forced to make a choice in the allocation of storage for root versus non-root.

Simon · « **Reply #75 on:** June 02, 2017, 02:10:52 PM »

Main reason is slight ease to keep data when replacing the system. With SSDs, we don't have to put the system or the most interesting files on the fastest disk area anymore, because everything is fast.

Indeed, I have reinstalled Arch several times in the first week because I trashed the system. But the reason remains weak. Maybe I should have put everything on one partition for simplicity.

Games that I invented 5-10 years go

I have a scrap heap of tabletop game ideas, sometimes entire games with full rule text files. Here are some of these games that weren't entirely terrible.

A two-player strategic game with secret information. You have a map with territories. New military units spawn regularly in your home territory. There is only one type of unit, like in Risk. Units take several turns to move between adjacient territories. You announce that your units move from a territory, but don't announce where they move; instead you place them on a face-down card that names the target territory. A die goes on the card along with the units, this die counts time. You can time your attacks such that units from different territories arrive at a target territory at the same time. The game is feels very slow and bureaucratic.

A solitaire with 52 face-up cards dealt to 10 tableau piles spread downwards. You can move single cards to build downwards regardless of suit (e.g., place a frontmost 8 on a frontmost 9). You can also build upwards in suit. Upwards builds (e.g. 5-6-7-8 in spades, with the 5 buried deepest) can be moved as a unit (the example 5-6-7-8 in spades can be be built on the 4 of spades, or on a 6 of any suit). Free spaces can accept any single card or upwards built. You win if you assemble all four suits in four long upwards builds.

Cluedo (a.k.a. Clue) without a board or dice, only with the cards. It's perfectly possible to play with three suits of varying length from a standard deck. Every turn, you suspect a triplet or make an accusation. It feels like this must be a very smart game, but I'm sure there are better deduction games.

A multiplayer trick-taking card game with more than 4 suits, but it works in a pinch with 4 suits. Card ranks are ordered, like in most trick-taking games, but suits are ordered too. In the 1st, 3rd, 5th, ... trick, you must follow suit. If you can't follow suit, you may trump with the lowest-ordered suit. In the 2nd, 4th, 6th, ..., trick, you must follow rank. If you don't have a card of the given rank, you may trump with the lowest-ordered rank. With 3 or more players, this game is really chaotic and we didn't see much strategy in it. But it's not a good beer-and-pretzels game either because the rules are so unintuitive.

A game where every player puts some cards from his hand face-down onto one shared pile, then everybody guesses or bets on the entire pile's content. This should be interesting because everybody knows other things about the pile. But I didn't find a good ruleset around this idea, it felt like a lottery. In hindsight, if you can somehow react to other players' guesses by adjusting your guess, we get close to Liar's Dice, a good game.

-- Simon

Simon · « **Reply #76 on:** June 15, 2017, 11:15:37 PM »

My first Mandelbrot-drawing code (click to show/hide)

Code: [Select]

import std.algorithm;
import std.complex;
import std.string;

import allegro5.allegro;
import allegro5.allegro_image;

alias Albit = ALLEGRO_BITMAP*;
alias Alcol = ALLEGRO_COLOR;

void main()
{
    al_run_allegro({
        al_init();
        al_init_image_addon();
        Albit bmp = makeMandel(300*6, 260*6);
        "./a.png".toStringz.al_save_bitmap(bmp);
        return 0;
    });
}

enum maxIters = 100;

Albit makeMandel(in int xl, in int yl)
{
    Albit b = al_create_bitmap(xl, yl);
    al_set_target_bitmap(b);

    foreach (int bx; 0 .. xl)
        foreach (int by; 0 .. yl) {
            Complex!double c = complex(
                -2.2 + 3.0 * bx / xl,
                -1.3 + 2.6 * by / yl);
            double darkness = clamp(
                (1.0 * maxIters - howManyIterations(c)) / maxIters,
                0, 1);
            al_draw_pixel(bx, by, Alcol(darkness, darkness, darkness, 1));
        }
    return b;
}

int howManyIterations(Complex!double c)
{
    int ret = 0;
    Complex!double z = c;
    while (abs(z) < 2 && ret < maxIters) {
        z = z^^2 + c;
        ++ret;
    }
    return ret;
}

I've never took computer science classes, therefore I never had to write this lovely toy program. I did it for fun tonight. The math isn't hard, the programming isn't hard, but the images are as awesome and intriguing as ever.

<SimonN> the standard mandelbrot belongs to f(z) = z^2 + c, this weird insect-like set is f(z) = z^2.1 + c
<mobius`> that's flippin' crazy man
<SimonN> I wouldn't want this to crawl into my bed at night >_>

Also attached is a bonus image that I generated on the next day, from the Burning Ship.

-- Simon

mobius · « **Reply #77 on:** June 18, 2017, 06:20:38 PM »

what is the equation for the last (new) one?
and why is it cutoff at the bottom or is this normal? Is that the limits of the program?

Simon · « **Reply #78 on:** June 18, 2017, 06:28:39 PM »

Iterate f(z) = (|Re z| + i |Im z|)^2 + c.

Burning Ship fractal on Wikipedia. I plotted one of the small ships at the left side. Nice zoom anim on youtube.

My image is cut off because I zoomed in on a part. The entire fractal has a unique shape, but I like these towers even better.

-- Simon

mobius · « **Reply #79 on:** June 19, 2017, 01:17:00 AM »

Quote from: Simon on June 02, 2017, 02:10:52 PM

Games that I invented 5-10 years go

I have a scrap heap of tabletop game ideas, sometimes entire games with full rule text files. Here are some of these games that weren't entirely terrible.

I'd like to see more of those if you're willing to share. The clue one sounded like a good idea I want to try that out, and maybe the others too. I used to play lots of cards years ago but haven't for a long time. Recently I've started getting back into it.

Simon · « **Reply #80 on:** June 20, 2017, 04:28:36 AM »

More renderings of the Burning Ship. This is the most beautiful math I've ever done.

The color scheme is discontinuous. I defined an arbitrary cutoff: How many iterations are still dark blue air, and how many iterations are the fiery-orange towers or sails? I chose 20 for the first and 23 for the second image. The more iterations a point takes to escape, the lighter the sails become.

(Re more games: I plowed through my collection, but no more sprung forward as worthwhile. Maybe one-card poker? Impose a linear order on all cards, i.e, order by suit whenever rank is equal, deal a card to each player. Start player posts a blind, then you have one street of betting. Highest card wins among the non-folders.)

Bonus image for Icho:
Armada to the left of the main fractal in 6240x1560.
Armada with transparent bg
Armada, only the background in blue

-- Simon

Simon · « **Reply #81 on:** August 16, 2017, 06:39:12 AM »

So Long Sucker

Found a strange 4-player tabletop game, So Long Sucker, invented by John Nash and others. If the linked rules on Wikipedia aren't clear -- the game appears subtle on first read -- consider the rules PDF linked on Wikipedia, and read that too. I believe I have fully understood the rules.

The driving mechanic: On your turn, you must make a play, thereby diminishing your stash of chips. You lose if it's your turn and you're out of chips. But having the move can be very good also, because you can capture chips under special conditions. You must decide whose chips to remove from the game, and you must decide who gets the next turn.

Coalitions, or agreements to cooperate, are permitted, and may take any form. No penalty for failure to live up to an agreement.

I don't dare to suggest play-by-forum.

In the negotiation games, you make and break your alliances as you see fit. That can leave even seasoned gamers with a sour aftertaste for weeks. To compare, the Lemmings Mafia went well, nobody got sour from Mafia -- but the teams were determined by the game. You don't backstab in standard Mafia.

-- Simon

Simon · « **Reply #82 on:** September 17, 2017, 04:16:48 AM »

#ifdef __cplusplus extern "C" { #endif __attribute__((__deprecated__))

Allegro 5 on Arch lacks .xm/.mod/.it support: A5 doesen't support the newest version of the DUMB library that interprets the music files. What to do? Dive into the internals of both libaries and connect wires yourself.

First, we ask around what people know, or have already tried. I'm lucky: I'm not the first to have run into this problem, 1-2 others have investigated already. Soak up all wisdom of the ancients.

C and git are the building blocks of culture, and you can safely assume that everybody in the world knows them well. Whoever doesn't know either one won't be able to help you in this quest anyway.

Build debugging versions of both libraries. Maybe script around the build systems if they need arcane flags. Finally, instead of opaque crashes, we get nice assertion failures.

We find a segfault in DUMB from null function pointer where A5 is expected to pass a function, but doesn't pass anything because the old DUMB version didn't have that pointer. What function should we pass? DUMB doesn't tell us because the docs are work-in-progress, therefore research and submit documentation yourself.

Realize that, by here, we already know more than whoever has tried this before. Even though we haven't contributed code to either library before, we're getting knowledge of the domain. If we get stuck, we can make educated decisions on what expert to ask.

Rage about C error reporting culture. Functions that produce data can often fail, and they return null pointer on failure. No exceptions, not even error codes. Want want want the program to blow up with a nice informative error message, but we don't get that in C land. The moment a function doesn't behave 100 % as expected, we must dive further into internals.

The biggest C hack is to return negative values to signal errors, and 0 or positive values as good results.
Zig gets that right: You have your function return exactly either a good result or an error, then the compiler checks that you handle that properly. Product types (structs) are popular, but most languages sorely lack sum types (= either-or-types).

Accept that you might get stuck halfway. Make the changes as readable as possible, preparing to publish them however far we get. Somebody else on the internet might be crazy enough to work on the same problem.

Edit: Pull request against A5!

-- Simon

mobius · « **Reply #83 on:** September 17, 2017, 04:38:55 PM »

'Culture' is not your friend:

https://www.youtube.com/watch?v=OdUCa5TrC9Q

thanks for liking our music so much

I wasn't so sure about the titles I picked but I closed my eyes and named them for what I saw in my head when listening.

Simon · « **Reply #84 on:** September 22, 2017, 03:23:12 AM »

How often does ccexplore have to post on Lemmingsforums until all the displayed hamsters match the rotational energy of the earth?

The earth weighs 6 × 10²⁴ kg, has a radius of 6.4 × 10⁶ m and spins at 7.3 × 10⁻⁵ radians per second. The rotational energy of solid spheres is 0.2 × mass × radius² × (angular speed)². A gold hamster weighs 0.12 kg. Measure the rotational speed of ccxeplore's avatar yourself -- rotational speed speed in radians is 6.24 / (time for one revolution). Assume the hamster ~~is very fat~~ is a sphere of radius 0.07 m for distribution of mass.

Points A and B are 1 km apart. A river flows from A to B with constant speed. We travel between these points on a motorboat that has constant speed relative to the water. From A to B, we take 2 minutes riding with the current. From B to A, we take 4 minutes against the current. How long would we take to travel 1 km with this boat in a lake without any water current?

-- Simon

nin10doadict · « **Reply #85 on:** September 22, 2017, 07:03:08 PM »

Problem 1 is a trick question because you said "displayed hamsters" and I can't fit enough hamsters on the screen at once to get that high of a value. My computer would probably crash from trying to display too many at once.

Simon · « **Reply #86 on:** September 27, 2017, 12:23:28 PM »

Quote from: nin10doadict

Problem 1 is a trick question because you said "displayed hamsters"

Hehe, this sort of answer classifies you as a good mathematician or computer scientist: Edge cases matter. Also good backroute.

Design of a search feature: Hide your complexity

tl;dr: Use fibers for expensive work.

Lix 0.9 will have a level search. Type a query into a search box, and the game presents you a list of levels that match your query. I'm proud of this feature because I thought of it first: No other Lemmings engine has it, nobody has requested it before, but I'm already using it in my regular level-maintaining workflow. Good stuff. Good broccoli.

I want to be Google! What are the hallmarks of Google search?

One good search box, no distracting options.
Searches in everything you might want to. In our case, filenames and level titles.
While you're typing, you're already seeing first hits on the screen.
As you type more characters, earlier hits vanish as they become irrelevant.
Hits appear and vanish in realtime. Very handy: You can stop typing when you've narrowed down to 1 hit.
All this good stuff happens magically in the background, it doesn't freeze the app.

Now, I said that the search matches both filenames and level titles. The operating system can quickly produce a list of files in levels/, but to filter for level titles, I have to open each file and read the first couple lines. Opening a file is crucially slow: With 1,100 files in levels/, if I open them all in one loop, Lix freezes for a second -- despite my decent CPU, RAM, and SSD.

I could read and index all levels when the program loads, but that goes against the general laziness of the design. I load resources only when I need them; in exceptional cases, I load them when I'll probably need them. Also, if I loaded everything at start of program, Lix would ignore when you move files externally while Lix is still open. And I'd have to hard-wire indexing of new files that you generate with the editor... Blergh, this is asking for bugs from outdated caches. No no no.

Instead, I index afresh every time I open the search dialog, but hide the work. Getting the tree of filenames from the operating system is fast, I do that immediately, eagerly. Then, Lix begins indexing the levels by opening the level files one after another, caching the level title. After a bunch of files, there comes the time to paint to the screen, read hardware input again, etc.; then we interrupt the caching and work with the half-done index. When the main loop hits the search dialog for the next time, again we work on opening some remaining files, improving the index. Eventually, 1 to 2 seconds into the dialog, the index is complete.

Even if this takes a couple seconds, we can already start typing into the search box, with good performance. We don't get 100 % perfect preview hits, but they will become better in the blink of an eye. On my fast machine, I don't even notice anything off, it looks instant. I'm sure it feels reasonably good on slower machines, too.

Most importantly, The game doesn't freeze during the indexing by definition.

We index while the game would wait on the next frame anyway, then we paint.

The general concept behind this is a fiber. It's not a full thread or process, but it's an expensive function in the main thread that you can pause and resume. You don't get the result ASAP, but you get it reasonably early, and you don't have to freeze your program meanwhile.

I have only this one fiber, and I even rolled my own code here. I simply let the fiber run until I would draw. This approach obviously doesn't generalize to having more fibers. If you want many fibers producing all sorts of good work for you, look into your language's standard library.

-- Simon

mobius · « **Reply #87 on:** September 29, 2017, 01:45:36 AM »

Quote from: Simon on September 27, 2017, 12:23:28 PM

Quote from: nin10doadict
Problem 1 is a trick question because you said "displayed hamsters"

Hehe, this sort of answer classifies you as a good mathematician or computer scientist: Edge cases matter. Also good backroute.

Design of a search feature: Hide your complexity

tl;dr: Use fibers for expensive work.

Lix 0.9 will have a level search. Type a query into a search box, and the game presents you a list of levels that match your query. I'm proud of this feature because I thought of it first: No other Lemmings engine has it, nobody has requested it before, but I'm already using it in my regular level-maintaining workflow. Good stuff. Good broccoli.

I want to be Google! What are the hallmarks of Google search?
One good search box, no distracting options.
Searches in everything you might want to. In our case, filenames and level titles.
While you're typing, you're already seeing first hits on the screen.
As you type more characters, earlier hits vanish as they become irrelevant.
Hits appear and vanish in realtime. Very handy: You can stop typing when you've narrowed down to 1 hit.
All this good stuff happens magically in the background, it doesn't freeze the app.

in my experience since they started the "While you're typing, you're already seeing first hits on the screen." feature; it definitely does freeze/slow down. It actually kind of annoys me. I see why it's nice; but I don't think I've ever needed this. I always know what I need to or can type in. I can wait (what; 0.X seconds?) to type and press enter again and again a couple of times.

Simon · « **Reply #88 on:** September 29, 2017, 06:46:29 AM »

Quote from: mobius on September 29, 2017, 01:45:36 AM

since they started the "While you're typing, you're already seeing first hits on the screen." feature; it definitely does freeze/slow down. It actually kind of annoys me.

I felt the same with the Google page 5 years ago, it slowed my 11-year-old laptop. I've resorted to typing in the browser's own bars, they call Google when you press Enter.

Searching from the browser bar is better anyway: We save one page load, the search engine's homepage.

Quote

I can wait (what; 0.X seconds?) to type and press enter again and again a couple of times.

I can understand this if you don't trust the computer during the fast operation, or the fast operation has an issue (like Google freezing, as you reported).

But in general, modern UI design suggests that we behave differently when a wait is 0.3 seconds than when it is 0.1 seconds. Even when we don't notice it, small waits break flow.

My pull request for tracked music in Allegro 5 on Linux got merged. The next A5 release won't crash anymore on module files.

This lifts a roadblock on Lix music. Of course, it takes time before such a change sinks into culture. The library has to release, then distributions have to update their packages, then users have to update their system, ...

-- Simon

Simon · « **Reply #89 on:** November 30, 2017, 07:16:26 AM »

Google's evil UI

Google search offers several tabs: [all] [images] [videos] [shopping] ...
But sometimes, it switches around: [all] [shopping] [images] [videos] ...

Because the first sequence is so common, lazy Simon is conditioned that Google's image search is on the second button from the left, and always clicks that second button without reading. Occasionally, that lands me on the shopping page. A nasty way to peddle stuff.

Overhead around video game rules

We have the core game rules of Lix, of NeoLemmix, of Nepster's BoxPuzzle, ..., and all these core rules are different.

Then we write applications around these rules, and the nice applications load level files, offer undo and framestepping, save and load replays, maintain backwards compatibilty. The programs must be documented and bugfixed. All this is far more elaborate than the implementation of the core rules.

But it's the only way, sadly. If you merge any two of these programs, the result would be an unmaintainable mess. The rules and physics differ in enough details to warrant separate programs with separate algorithms.

Their ecosystems are complex enough to always have bugs. You stop fixing bugs only when there is no more interest in a program, after many years. And every couple of years, a new idea pops into existence, warranting another large ecosystem to be developed around it.

It's the circle of life. Can you feel the bloat tonight?

Small level packs

I agreed with mobius how the recent small level packs are refreshing, with around 10 levels per pack. Culture handles them like it handles large packs: Replays get posted, maintainer checks whether they're intended, and fixes backroutes.

My view is that packs and ranks are arbitrary in the first place: Ranks are sets of levels, and packs are sets of levels, or of ranks. Others' feelings go deeper with ranks. That's fine, from the standpoint of distribution, we'll arrive at the same result with either feeling.

git

I still want a children's cartoon with a catchy singalong song that teaches people how to use git. I'm sure it would be a massive hit. After all, these things exist for other basic things in life.

-- Simon

ccexplore · « **Reply #90 on:** November 30, 2017, 09:10:16 AM »

Quote from: Simon on November 30, 2017, 07:16:26 AM

Google search offers several tabs: [all] [images] [videos] [shopping] ...
But sometimes, it switches around: [all] [shopping] [images] [videos] ...

Because the first sequence is so common, lazy Simon is conditioned that Google's image search is on the second button from the left, and always clicks that second button without reading. Occasionally, that lands me on the shopping page. A nasty way to peddle stuff.

Hmm, I guess it could also be A/B testing (Amazon e.g. does tons of these on its websites for obvious reasons), though with the first sequence being so common already it doesn't seem like ideal conditions for setting up such an experiment.

Also, any chance it's just a bug that repros on certain specific conditions?

All that said, I do like the idea that it could be an intentional clickbaiting technique. If that's the case then I expect the "video" position to be even more prone to the switcheroo, under the assumption that video searches may be more popular (granted, I have no data to back that up).

To be somewhat fair, I suspect Google has monetization affordances built into all 3 places anyway. Shopping may be most obvious and direct, but then considering that the other areas may enjoy greater volume of views and clickthroughs, which actually winds up generating the most revenue may well defy expectations.

Simon · « **Reply #91 on:** December 01, 2017, 04:41:32 AM »

Quote from: ccexplore on November 30, 2017, 09:10:16 AM

Also, any chance it's just a bug that repros on certain specific conditions?
All that said, I do like the idea that it could be an intentional clickbaiting technique.

I tested some more, and it seems to depend on the search term. The first slot is always [all], but the second slot depends on what Google thinks is most helpful.

If I search for "concrete" or "brick pillar", I get [images] in the 2nd slot. "music" gives [videos] in the 2nd slot, makes a lot of sense. "linux", "microsoft", "apple", I get [news] in the 2nd slot.

I guess that I never use Google for anything than the [all] and [images] tabs, and therefore only want to switch tabs when I want to image-search. But when I image-search, my search term is designed to give specific results on the [images] tab. Apparently, Google agrees that my image-searching terms are very often good image-searching terms. Only sometimes, it disagrees, and that leads to the switcheroo of the 1-2 posts above.

Undo

Quick-and-dirty undo by savestates is not that bad. It's fine if undo is moderately expensive.

I haven't written undo yet, even though the D Lix editor is approaching two years of age. I want the noble Command OO pattern, but that needs changes in the editor code everywhere. The result is that Lix has not even the quick-and-dirty undo.

I should advertize the issue tracker more and have others sort the issues by urgency.

-- Simon

Colorful Arty · « **Reply #92 on:** December 01, 2017, 02:02:30 PM »

Which is better through: code that may take a lot of resources (not very spacially efficient) that is fast, or slower code that makes the code as a whole look sloppier? It's one of those compromises a programmer must take.

nin10doadict · « **Reply #93 on:** December 01, 2017, 04:44:40 PM »

I'd like a catchy sing along that teaches people proper garbage etiquette, such as how to use a compactor properly. We can't have everything we want, though...

Please don't throw chairs in the compactor, guys.

Simon · « **Reply #94 on:** December 02, 2017, 06:04:39 AM »

Quote from: Colorful Arty on December 01, 2017, 02:02:30 PM

(not very spacially efficient) that is fast,
or slower code

The fast code, almost always.

On modern machines, CPU power is cheap, RAM is plentiful, but RAM access is slow. When the code is fast, you're often efficent enough in space already.

I bought 2 GB of RAM when the old laptop's 1 GB was not enough to build Lix anymore in late 2015. The reference D compiler never frees any memory until the entire project is built. That's fine, quick build times are paramount.

The tumbler activity is slow in Lix because it checks so many pixels during flight, hitting a ton of RAM. I have a rewrite on the backburner that is much faster, but doesn't preserve the exact physics. Hard decision whether/when to merge that.

I've never taken computer science classes, the typical examples there are probably merge sort versus quicksort? Merge sort is always N log(N), quicksort can be N^2 in worst case. But quicksort is often N log(N) on average and doens't have to allocate heap memory (the recursion goes on the stack, which is fast), therefore it's very good already.

-- Simon

Nepster · « **Reply #95 on:** December 02, 2017, 12:11:55 PM »

Quote from: Simon on December 02, 2017, 06:04:39 AM

I've never taken computer science classes, the typical examples there are probably merge sort versus quicksort? Merge sort is always N log(N), quicksort can be N^2 in worst case. But quicksort is often N log(N) on average and doens't have to allocate heap memory (the recursion goes on the stack, which is fast), therefore it's very good already.

Don't forget one more consideration: How does the algorithm perform in some of the most common cases in practical applications? In this example, this means to consider also the case: How does the algorithm perform for (almost) sorted lists?
For example a quicksort algorithm that always chooses the first (or last) element as a pivot element would be terrible, because that would mean a runtime of O(N^2) for already sorted lists, while ideally it would be close to O(N).

Simon · « **Reply #96 on:** December 09, 2017, 05:07:46 AM »

Thanks for mentioning the pivot element choice. Since I always call standard libraries and have never written quicksort, I didn't know how difficult pivot element choice could be. Nice evening with googling.

The only sort I've ever hand-written was selection sort. That seemed necessary when I wanted to print a list of L++ players ordered by score after a networking game, in 2009. Back then, I didn't feel that standard libraries should have something for such a problem.

Lemmings Heaven

This was a website around 2007 to 2013 at lemmingsheaven.info, but the domain is dead nowadays. They focussed on level design with vanilla Lemmini. Lacktardo and Dodo built many levels and released on Lemmingsheaven, but I haven't seen them anywhere. Pieuw and Prince Jamie were active, too, and have registered on Lemmingsforums since.

The Lemmingsheaven work is important history: Icho got into level design by finding youtube videos of Pimolems and Dovelems. He values these packs so much that he has converted them entirely to NL and maintains them to this day.

Lemmingsheaven had an IRC channel that is also dead today. I joined a few times around 2010, but I forgot any names of active IRCers there. I merely remember this conversation:

Simon: Have you looked at Lemmingsforums?
Person: No. They don't seem to focus on level design as much as Lemmingsheaven does. Lemmingsforums focuses far more on fan-art.

Well, this is certainly not true anymore. Today, Lemmingsforums focuses on software development.

-- Simon

Simon · « **Reply #97 on:** January 08, 2018, 09:33:14 AM »

How to prevent bugs by design

When you write a Lemmings-like game and you need replay functionality, do not let assignment clicks issue both a replay action and affect the lemmings directly. Instead, issue only replay actions. Then, for the next physics update, fetch these new assignments from the replay and apply them. If you design like this, you will kill an entire class of replay-desyncing bugs outright. This is good design.

The replay collection on github is not only a check that I ship 100 % solvable levels. It has massive value as an integration test. When the replays pass and not fail, I know that the physics, the tile-loading code, the replay code, etc., all behave well together.

D has built-in coverage analysis via optional compiler switch, and I gave that a go: Lix's unittests and the replay verification together cover about 40 % of the entire codebase. Compared with professional software development, 40 % is lousy coverage, you would rather aim at 90 % to 100 %. But most of the uncovered code is editor, GUI, networking, and similar areas that were not written with unittesting in mind. Considering that I haven't written those areas with tests in mind at all, 40 % coverage is surprisingly high.

For the networking, I wrote a separate small command-line tool that connects to the server and can chat, which was useful during the network development. But this is not automated testing.

When you have a complex program that depends both on some abstract model and on outside dependencies like images or networking, don't let the model depend on the outside dependencies. Ideally, make the model self-contained, therefore easy to test, and merely feed the outside dependency into the model as a very last step. Example: In Lix, multiplayer replays can play from a replay file, you don't need networking to watch that. The replay can play back locally with all of the physics and different player colors. The networking would merely supply inputs for the physics during a match.

-- Simon

Forestidia86 · « **Reply #98 on:** January 08, 2018, 01:39:53 PM »

I'm not sure if that's off to what you've said but there is a possibility that a replay desynches but nevertheless passes. But that's more a "problem" for single replays than for the huge replay base you have since for the latter it's unlikely that most of them are such corner cases.

Simon · « **Reply #99 on:** January 08, 2018, 11:54:52 PM »

Yes, it's always possible that tests pass despite a bug. But that's in the nature of such tests.

To mitigate, we can make more tests, or more precise tests that examine more corner cases.

-- Simon

Simon · « **Reply #100 on:** January 22, 2018, 02:12:06 PM »

D class references may be null

D still is the langauge that produces the fewest Simon rants. Many common problems have great, short solutions in D. But, as with anything worthwhile, it has its corners to point and and rant. What everybody loves most!

Class objects live on the garbage-collected heap. The basics of OO of D are similar to OO in Java and work great. Your class variables are references (pointers, names). If you want polymorphism in any language, you need reference semantics, therefore all this is consistent, good design.

The initial value of any class reference is null. That is also a good choice.

class Color { /* ... */ } class Porcupine { Color color; // implicitly null
}

But D has no way to statically enforce that a reference cannot be null in a given context. You may assert a reference's non-null-ness, but that happens at runtime. I want nice check at compiletime. Also, it feels slightly dumb to assert for non-null because your operating system already asserts this for you on every usage: The OS will print "segmentation fault" and you run your debugger.

I like to write several short methods, and naturally, some of them take class arguments. I really don't want to assert that my parameters aren't null every time over and over.

Structs in D are value types, they have no such issues. If I define Point to be a struct with two ints, x and y, then Point will occupy as much memory as two ints would, and its default value is x = 0, y = 0, because 0 happens to be the default value for int. (Everything in D is default-initialized, which kills a massive class of bugs from C++. If you're absolutely sure that the default initialization kills your performance, you can explicitly write Point p = void;)

Problem statement: I wish for a class reference that is guaranteed to be non-null. Assigning null to this reference is a compile-time error, no matter how indirect the assignment was. It's an acceptable hack to have it null by default, as long as nobody can ever read/dereference it before it's overwritten with non-null for the first time.

Let's attempt a solution: I could wrap all my nullable D class references in a templated struct, such as the following, where C is the template parameter.

NotNull!C (click to show/hide)

Then I can ask for a NotNull!C everywhere I'd normally ask for a C. This has 3 downsides:

It's a nonstandard hack. This problem is really really common in OO and it's worth a language feature, or at least a library solution. The D standard library has Nullable!S for structs, but no NotNull!C for classes.
It doesn't statically prevent me from instantiating the thing with null, e.g., auto x = NotNull!C(null);. It still passes compilation and only asserts at runtime. The benefit over normal class references is that it explodes already when we create the null reference, not merely when we dereference later, as a normal segfault would.
It's an abstraction inversion. The non-nullable type is type with simpler behavior, I can call all methods without segfault. The nullable type is the more complex type, I can either call methods on it or must check first for non-nullness. My NotNull implements a simple type in terms of a more complex type. This is bad design.

Who does it better? In Zig, your types cannot be null, not even pointers, unless you add ?, the nullable type modifier. You may not use a nullable type freely unless you specify what happens in the null case. The language has special, short constructs for exactly this problem.

In general, Zig is designed around easy passing of error conditions because it avoids exceptions and garbage collection. % is another type modifier, it means "either your type or an error code".

C# gets a mention here for its null-conditional dereferencing operator ?. that calls a method only if the reference is not null. This cures the symptom of having many ugly null checks throughout the codebase, but the original issue still stands -- it's not a compile-time prevention of assigning null to class variables.

-- Simon

ccexplore · « **Reply #101 on:** January 23, 2018, 08:32:36 AM »

I have to imagine that this is probably a relatively well-studied problem in computer science, and the literature probably has much more in-depth information on this topic. Very generally speaking, static verifications by the compiler can often either mean many false positives (so you end up not really paying attention to them), or else only work in limited cases (so you still have much code where the compiler can't help you, especially the "hard" cases where it would've mattered the most). I wonder if maybe this is difficult enough to do well (in one or both of the ways enumerated above) that for most languages (or even compiler writers, since it's probably possible to embed custom static asserts into existing language syntax like comments), it had been deemed not worth the effort?

Simon · « **Reply #102 on:** January 23, 2018, 01:26:32 PM »

I'm not well-versed in the academics of software engineering, but yeah, I assume there should be something. And I expect other modern languages (newer than both C++ or D) to have something in this direction.

C++ would have initializer list, that would be the obvious place to assign to the non-null-ref from a guaranteed-non-null-source like new expression, other non-null-ref, STL pointer with similar guarantee.

D has no initializer lists, but the D compiler analyzes program flow in constructors, it will already error if you assign a value to const/immutable field more than once. I believe the infrastructure for non-null is similar to such const-enforcing infrastructure.

I'd be okay if you could forcefully cast from nullable reference to non-null-reference. You can already cast away D's immutable and thereby assume responsibility for any undefined behavior. Memory-safe example: Allocate memory, do something complex in it, then assign that chunk to a pointer-to-immutable. This promises that the chunk will never change, not even through other references to the same chunk. If no mutable references to this chunk escape the scope, there will be no undefined behavior, everything is perfectly fine. For this hack, there is even a standard library function, assumeUnique, which merely wraps the cast to immutable under a descriptive name. I guess offering similar hacks for subverting null would be fine.

From the linked page:
The downside of using assumeUnique's convention-based usage is that at this time there is no formal checking of the correctness of the assumption; on the upside, the idiomatic use of assumeUnique is simple and rare enough to be tolerable.

I believe D offers only nullable references out of tradition, and it would be a massive breaking change. As I said before, the non-nullable class reference to a C should be C, whereas the nullable reference is the oddity that deserves the stigmatic name C? or Nullable!C or similar.

I would love to see such a massively breaking change, yes yes, I have no qualms smashing porcelain for a small extra gain. But I'm not everybody. >_>;; And when your language is used in the industry, this might well be infeasible.

-- Simon

Simon · « **Reply #103 on:** February 12, 2018, 05:55:55 PM »

Lix 1v1

I want to play Lix 1v1 on highly swingy maps, where a few mistakes lose a game in one shot and then you immediately play the same map again. The games are so rapid that even though you care about winning, the actual outcome never sticks in mind for long afterwards.

geoo has always loved to play in this style, but anybody is welcome as a 1v1 opponent. I merely know that geoo shares this taste in maps. I've shied away from heavyweight multitasking maps like Chasing Upwards, but I miss that also.

Maybe the nuke-exploders should be instant for an even more rapid series of games?

Discord

Closed-source, invasive privacy policy, bloated, and slow. Use IRC for chat, public logs and a forum for archiving, and Mumble for voicechat. There is vector.im as an open-source Discord alternative but I haven't ever heard about it outside of very narrow search queries for Discord alternatives.

The massive downside of forums is that you must register for every single one separately. Sadly, github issues is not a good forum.

Type popcorn

Rant from 2012, before Python got optional type annotations: Abscissa's Why I Hate Python (Or Any Dynamic Language, Really) -- A stab at type errors and missing-variable errors that a compiler would catch. The rant generated 74 comments, it's a phenomenal popcorn thread (= you can read it like you would watch an exciting action movie, munching popcorn along the way).

I still miss the non-null class refs in D. Good thing I occasionally re-read my own posts here, very instructive because the reasoning and implementation pitfalls aren't easy to keep in mind completely. >_>

-- Simon

Colorful Arty · « **Reply #104 on:** February 12, 2018, 07:01:18 PM »

I'd take Python Type Errors over C/C++ Segmentation faults ANY DAY. At least the Type Error tells you WHERE it happened for a quick and easy fix.

Simon · « **Reply #105 on:** February 19, 2018, 11:29:17 AM »

Quote from: Colorful Arty on February 12, 2018, 07:01:18 PM

Python Type Errors over C/C++ Segmentation faults

In a good system, the segfaulting/type-mismatching code doesn't even compile in the first place. See earlier posts.

Order

To compose a piece of email,

1. attach file.
2. Write body.
3. Write subject. If subject is hard to write, prune the body and it will become clearer.
4. Pull in the recipients and send.

To reply to email,

1. attach file.
2. Prune prune prune the other person's bloat.
3. Reply to pruned quotation.

The human mind is exceptionally good at detecting patterns, but has a terribly hard time formulating rules to explain patterns.

E.g., email composed in a different order than I presented. You type the prose that nobody cares about, then fail to attach the file because it's 100 % clear what you have to do and it's boring to do it. The human mind skips over this step because there is a glaring pattern here: We always attach the file that we made earlier.

E.g., copypasta of code, leading to long functions. The function has conceptual segments that aren't abstracted away. Even if it's clear to the writer because they know about the segments, it's not clear to the first-time reader; the first-time reader must assume that everything depends on everything. The cure here is to forcefully refactor anything that gets too long.

E.g., procrastination of dull work. If thesis is roughly finished and only debugging, writing introduction, proofreading etc. is to be done, the work is no fun. We don't want to do it. The pattern here is: Do random things until you have enough for the thesis, then add chrome and turn it in. The chrome is considered standard, but this time, there is no shortcut/catch-all solution, unlike with the earlier examples. Thus, procrastinate.

-- Simon

Simon · « **Reply #106 on:** February 19, 2018, 12:46:52 PM »

Mouse cable

-- Simon

Colorful Arty · « **Reply #107 on:** February 19, 2018, 03:24:54 PM »

Or alternatively, you could just get a wireless mouse.

Simon · « **Reply #108 on:** February 19, 2018, 04:04:02 PM »

I use the mouse only occasionally, every 10 minutes for a couple seconds. Wireless mice love to sleep whenever I'm not mousing and then take time (0.2 seconds or longer?) on the first input because they must reconnect. This means that most of my wireless mouse inputs have massive lag.

I switched back to cable mice to end this madness. Maybe wireless mice for over 100 euros do better, I haven't tried any of those.

-- Simon

Colorful Arty · « **Reply #109 on:** February 19, 2018, 07:04:55 PM »

That's fair. My problem is that I lost the USB connector for my wireless mouse, but since I use a laptop, wired mice are quite nice for me.

mobius · « **Reply #110 on:** February 19, 2018, 07:25:23 PM »

I've been using pic #3 for a long time now and haven't had any problems with the extra cord pushing; maybe it depends on type of cord or mouse. Also I wrap my cord around the legs of the keyboard. I guess that's more like a loop.

I used to use wireless mouse but occasionally I'd knock it off the table. Now if it falls the cord keeps it from hitting the floor and breaking.

Ryemanni · « **Reply #111 on:** February 20, 2018, 09:19:06 AM »

Finally someone mentions this problem, I've been struggling with this forever. I used to work with pic 3, but the cable kept pushing my mouse forward, so I ended up with pic 4. It's the most acceptable solution for now, but still feels a bit hack-ish.

grams88 · « **Reply #112 on:** February 20, 2018, 12:38:18 PM »

A while back a couple of years ago I used to have the old mouse with the ball in it where you had to sort of give it a clean to get the gunk out of it so it moves a lot better. It actually worked quite well for myself but a lot of people or family members were complaining and wanting me to get a wireless mouse.

The tape idea with the loop seems to do the trick. At the moment I've got a wireless mouse where you have to change the batteries or recharge the batteries when the batteries run out. The USB mouse is a good way to get round the battery issue.

Simon · « **Reply #113 on:** March 03, 2018, 04:13:59 PM »

Quote from: Raymanni

pic 4. It's the most acceptable solution for now, but still feels a bit hack-ish.

Hah, yeah. It's still a hack. It's merely the least-worst option that I found.

Shift + RMB = cmd here!

On Windows, in the file browser, you can right-click to create directory, create new file, etc., but a super-important command has always been missing: Open shell in this directory. The answer is to hold Shift while right-clicking. This gives many more options in the context menu, and one of them is to open a shell with that directory as the working directory.

<SimonN> optimally, you could right-click into any directory in the Windows file browser, and select a context menu option that opens a shell in this directory
<SimonN> it's probably possible to make this, but Windows doesn't offer it by default, which makes me sad
<Forestidia> SimonN, I've looked shortly through the web and there is a way to open cmd prompt in a folder: shift+right-click and then you have the option. Never thought of this possibility I have to admit.
<Forestidia> shift+right-click generally seems to give you more options like copy path if you have a file selected.
<kieranmillar> Wow, all these useful right-click options, hidden behind an unnecessary extra step
<kieranmillar> My life has been changed forever

Thanks for pulling this gem from the net! This is super useful to remote-troubleshoot people's problems -- omits the need to explain working directories, cd directory, and cd...

Type popcorn where it belongs

Around 5-10 posts earlier in here, I've ranted about D's lack of a non-null class reference. This bugged me enough to write my own post on the D forums.

That's a much better use of the fiery passion than a mere rant-post on Lemmings Forums.

It generated some nice discussion, with adequate popcorn for a language feature discussion. Even more importantly, I got a lot of answers from smart people, and some have attacked related issues with their own small libraries. I'll look into these solutions!

-- Simon

Simon · « **Reply #114 on:** March 05, 2018, 01:21:28 PM »

Shoelace bowknot into firm knot

I tie my shoelaces with the standard bowknot that most people use, and that the image shows. This holds well for me. To open this bowknot, you pull either loose end, e.g., the yellow loose end. This will pull the yellow loop through the knot and thus the knot falls apart.

Now, the mystery: When pulling on the loose end to remove the loop, there is a 10 % chance that the knot will not easily open, but instead transform into a very tight knot that is painful to open. This happened to me on two days in succession, and that's last straw. I will search the web about this problem.

Surprisingly, it's hard to find. Lots of sites describe how to tie shoelaces, but opening them seems to be no issue for anyone. I assume that in those 10 % of cases, I had already tied the bowknot wrongly in the first place by mistake, which will then lead to the firm knot problem on opening much later.

<geoo> I encounter this issue more frequently than 10%. I believe what happens is that the loose end you pull on went through one of the loops
<geoo> or maybe both of them must have gone through the respective loops of the other color

-- Simon

ccexplore · « **Reply #115 on:** March 05, 2018, 09:50:41 PM »

Interesting, I had long kinda sidestepped all this by basically never untying shoe knots: either the shoe doesn't use laces to begin with, or I tied them just loose enough that I can take the shoe on and off w/o retying/untying. Granted, I'm a bit of a couch potato, I imagine if I'm more athletic I probably can't get away with loose lacing quite as easily.

nin10doadict · « **Reply #116 on:** March 06, 2018, 01:22:05 AM »

I have encountered this shoelace problem too, but never really gave it much thought... I just kinda accepted it as one of those annoying facts of life, like how most people only have one hand that works well and the other just kinda... $:-\$
"Oh, one hand's all that works good? Ok! If you bought your body at Sears, you'd take it back and complain. 'Look, this hand throws the ball way out there, this one throws it way over there. Why?'" -Gallagher

Simon · « **Reply #117 on:** March 11, 2018, 02:54:04 AM »

I believe geoo is correct: The bowknot transforms into a nasty knot because the pulled loose end is entangled with a loop. This tangle happened over the many hours during which we haven't paid any attention to the shoe. Sadly, if this theory is correct, we cannot fix the initial knotting in any way -- it would have been nice to learn another way to tie shoes and thus prevent the problem altogether.

Eiderdaus Patience

Around 2009 to 2013, I was interested in card solitaire a.k.a. patience games.

Several games have a tableau to untangle sequences of cards; a common type of tableau move is moving available cards to build descending sequences. These games then have a separate foundation area where cards eventually must be played in strict ascending sequence.

In early 2011, I invented my own game to ditch separate foundations; instead, every single card acts like a foundation pile. I toyed with the number of tableau columns and different allowed cards to fill empty columns, and I was very satisfied with the results: The game seems to have reasonable depth, and the rules are simple enough that I still know them perfectly after all these years.

I was lousy in naming; eventually the name Eiderdaus Patience stuck, but I'm not happy with this name.

Rules of Eiderdaus Patience (click to show/hide)

Remarks and Hints (click to show/hide)

-- Simon

mobius · « **Reply #118 on:** March 11, 2018, 03:53:40 AM »

Quote from: Simon on March 05, 2018, 01:21:28 PM

Shoelace bowknot into firm knot

I tie my shoelaces with the standard bowknot that most people use, and that the image shows. This holds well for me. To open this bowknot, you pull either loose end, e.g., the yellow loose end. This will pull the yellow loop through the knot and thus the knot falls apart.

Now, the mystery: When pulling on the loose end to remove the loop, there is a 10 % chance that the knot will not easily open, but instead transform into a very tight knot that is painful to open. This happened to me on two days in succession, and that's last straw. I will search the web about this problem.

Surprisingly, it's hard to find. Lots of sites describe how to tie shoelaces, but opening them seems to be no issue for anyone. I assume that in those 10 % of cases, I had already tied the bowknot wrongly in the first place by mistake, which will then lead to the firm knot problem on opening much later.

<geoo> I encounter this issue more frequently than 10%. I believe what happens is that the loose end you pull on went through one of the loops
<geoo> or maybe both of them must have gone through the respective loops of the other color

-- Simon

I tie different kind of knots at my job and encounter pretty much the exact same phenomenon I would say about 10-20% of the time. I encounter it with shoes too but not often. It only happens when I'm rushing.

Either it gets looped or you've simply crossed over another string you didn't think would cause an issue. Although a different theory I have is that;
-You turned the knot around. It seems like this shouldn't matter for a shoelace knot; yet it happens in the same way. It's definitely applicable to say; the slip knot. You can tie it (but don't pull tight yet), now turn around so you face the knot from the opposite side, if you try to tie it or pull it tight quickly chances are you'll mess it up because you're pulling the wrong string or in the wrong direction.

In any case, I've found the solution (works 100% of the time for me): patience. Never rush to tie or undo the knot. I've never had it happen when I'm taking my time and following each step correctly.

I always try to avoid tangles; it can take you an extra 5 minutes to tie it slower; but it can take you 20+ minutes to fix a tangle.

thanks for the cool knot website

Simon · « **Reply #119 on:** March 13, 2018, 01:10:30 AM »

Quote from: mobius on March 11, 2018, 03:53:40 AM

(works 100% of the time for me): patience. Never rush to tie or undo the knot. I've never had it happen when I'm taking my time and following each step correctly.

I like this very much. This extends to general guidelines for proficiency. When you first learn a system, you toy around and make mistakes, sometimes even mistakes on purpose, to learn how the system reacts.

Then you focus on avoiding mistakes, even if it is expensive and takes a lot of time. Only over many repetitions, speed will come as a side effect while you focus on avoiding mistakes. You might not even notice the gradual improvements.

When you stream on twitch, you can set your streamed game to Lix.

twitch only allows games registered in the Giantbomb wiki, and I've applied for a page there, it got approved. The Lix page on Giantbomb is still empty and I should fill it eventually.

Split off from this thread: Lemmings 3D block structure.

-- Simon

Simon · « **Reply #120 on:** March 28, 2018, 10:13:55 AM »

Tank Chess

mobius likes when I write game rules, here's a game from my teenage. I invented this with a friend when I was 13 or 14 years old, and we played it between classes in school.

American readers: In German schools, you don't walk to teachers' classes; instead, your class always consists of the same ~~players~~ students in the same room and the various teachers walk to your class. With the reduced walking overhead, you can play little games during breaks.

Setup. Each player starts with 5 pieces: 4 tanks (with wheels and turrets) and 1 square block on their home row. Piece order is not fixed: Secretly choose an order for your own pieces, reveal when both players have chosen.

Objective. Kill the opponent's pieces. Usually, the next class starts before you've killed all.

Play. Players alternate taking turns. On your turn, you must make exactly one of these moves:

Move one of your tanks forward by 1 space. The target space must be empty. "Forward" is always defined as the direction away from the wheels. At the start of the game, any forward move therefore gets you closer to the opponent.
Rotate one of your tanks by 90 degrees. This changes where "forward" is for that tank, and where its turrets point. (The turrets cannot rotate independently; only the entire tank can turn as a unit. It's legal to rotate tanks such that "forward" means "back towards the player"; you'd need two rotations in two different turns to get this orientation from the starting position.)
Shoot at an opponent's piece. You can only shoot at pieces that are in range of at least one of your tanks' turrets. Orthogonally-pointing turrents all have a range of 2 spaces, diagonally-pointing turrets have a range of only 1 space. When you shoot at opponent's pieces 2 spaces away, the intermediate space must be empty. If the piece shot is a tank, it's removed from the board. If the piece shot is the opponent's block, flip the block over, it says "1 life" on the back, and remove it only when it's later shot a second time.
Move your block by 1 space orthogonally. The target space must be either empty or be occupied by an opponent's piece. The block doesn't have an orientation, it can always move into all four directions. If the block moves onto an opponent's piece, that piece is removed from the board.

Hindsight.

I believe killing all 5 pieces takes too long, maybe killing 3 or 4 should be the victory condition.
Giving the block 2 lifes was excellent balancing rule. The block must move through dangerous territory to even threaten an opponent's piece. And when you successfully kill a piece with the block, the block will be in a lousy position despite its excellent maneuverability.
The backwards-shooting tank is weak. Maybe it should be replaced with a tank that shoots diagonally backwards. Maybe it should even get all 3 turrets that point backwards and diagonally-backwards.
I've extended this game to 7x7 and played it with my brother. I believe 7x7 is boring because it takes a long time to reach the opponent at all. With 7 pieces, you need 2 extra pieces to fill your home row. I remember we designed a vacuum-cleaner piece that sucked pieces from its side and spit it out at the other side. That piece was a gimmick, it was weak, and I'd cut it from the design immediately today.
When a block moves onto the opponent's block that has 2 lives, I believe the opponent's block should be killed for simplicity. I don't remember what rules we had for this 18 years ago. Blocks moving onto blocks won't comes up in practical play because the other block can escape easily.

-- Simon

Simon · « **Reply #121 on:** March 29, 2018, 05:29:23 AM »

First Phobos PR

I've opened my first pull request against Phobos, the D standard library. 75 % of the change is the unittest.

That bug had caught me several times over the years, and the fix looked obvious to me.

I've always wanted to contribute to a large, prestigeful project, and I'm happy to present something as polished as I could make it. Now awaiting feedback, then possibly polishing the fix further.

UI design

I've noticed a pitfall when programmers present information in a user interface. Programmers instinctively focus on the abstract even when the user expects focus on the concrete. Example from a Discord bot that announces twitch streams:

Here's the slightly better way, from Lix:

The difference is that Lix emphasizes the concrete values with the strongest color, white. Insane Steve, he designed the level. 1/10, that's the goal. 4 lix saved, that's your best score.

This is reasonable. Often, you can already guess what the values mean without reading the abstract description. Any Way You Want, that's the level title even though I haven't printed "Level title:" next to that. Insane Steve, because it's a person's name, would probably be recognizable as the author even without annotation, but a short "By:" doesn't distract much. English readers habitually glance over such short words; they focus on the nouns and verbs.

By comparison, the Discord bot emphasizes the abstract categories with the strongest color, white. The stream is about a game, it happens that the game is Jazz 2. The stream has a title, by the way, the title is bla bla bla. With the white color, the bot draws your attention to the filler text -- the most uninteresting text in the entire announcement! You could even leave away "Stream title" entirely and the concrete title would keep enough information scent to keep it clear how that's the title.

-- Simon

Dullstar · « **Reply #122 on:** March 30, 2018, 05:01:51 AM »

By the logic presented for giving the strongest color to the concrete topics, might I suggest making the level titles also white? (It doesn't really matter that much; the contrast in the Lix example is much more subtle than the contrast in the bot example, so it's not terribly distracting)

The bot example is REALLY badly designed. The least important information stands out with so much contrast that it actually makes the darker text feel a lot darker (and therefore harder to make out) than it would be by itself.

One key factor, however, is the length of the text involved. If the text portions were large and took a bit to thoroughly read, having the headings stand out would help the reader identify which part of the text is most likely relevant to the information they're looking for. However, because this example is so short, giving the sections bright, easily noticed headings actually makes it harder, rather than easier, to find the information you're looking for.

Simon · « **Reply #123 on:** April 02, 2018, 03:10:47 AM »

Title should be in white instead of light blue: I agree. It's merely not white due to tradition; it was the first label in that section that I implemented and I didn't print anything in white back then.

The title appears twice in the dialog: Once in the list of levels on the left that I didn't screenshot, and once in the info section in the screenshot. Still, it's still very important and should be white. It's more important than author and own score. Only the save requirement is possibly more important.

-- Simon

Simon · « **Reply #124 on:** April 28, 2018, 12:43:33 PM »

I'm back at the guinea pig diet: Whenever you eat bread, e.g., with cheese or salami, always add lots of cucumber on top. Peppers on top of that are a welcome extra, but peppers aren't declared absoluely necessary by guinea pig diet experts, you're okay to omit them.

This works because you will naturally eat more cucumber and less of anything else. Preparing meals takes longer and you will not prepare excess food. In general, keep a rough total of how much you eat, and cut sugary drinks and sweet/salty snacks nearly entirely. Reserve such snacks for social gatherings.

Reasons for diet: Guinea pigs love cucumber, and I want to reach my lowest point of 78 kg again from 2016; I'm 1.92 m tall and 85 kg with ~~many quills~~ few muscles.

I made a bet with a friend to reach 78 kg by mid-November 2018. He's slightly taller than I am, but he's overweight at 147 kg. He wants to be at 135 kg by mid-November. That's a reasonable speed for both. The heavier you are, the easier it is to lose fat.

Gifs (click to show/hide)

-- Simon

grams88 · « **Reply #125 on:** April 29, 2018, 03:30:22 PM »

Is that Simon trying to tell us something maybe it might be his birthday, I think I see birthday material there behind the two guinea pigs.

My brothers getting right into the cooking and preparing meals, He's been getting into indian food. He's been trying keema the other day which he enjoyed, I'm not big myself on keema myself but I gave it a try yesterday and it was hot or spicy, I tend to get those two mixed up. He's been experimenting with different foods lately.

mobius · « **Reply #126 on:** April 30, 2018, 10:05:08 PM »

sounds very healthy.
Fyi: in your latest picture with Icho and Proxima you didn't look the slightest bit overweight to me. (nor in any other picture)

my cat likes being combed like that; but doesn't often stay still long enough to get the whole body.

Simon · « **Reply #127 on:** May 24, 2018, 04:59:07 PM »

Hah, no, I didn't have any birthdays recently. And yes, Indian food sounds nice, very spicy.

Wok

When I ever move out of this apartment, a long-term plan is to get a wok and learn to use that. Even today, most of my dishes work similar to wok dishes: Get vegetables, maybe get meat too, then cut everything to pieces. Fry everything together. Then make noodles/rice/couscous/... and serve both.

IchoTolot jokes that I say "When I ever move out of this apartment" far too often and I should finish on getting the thesis done for good. I believe I've already fixed all nasty bugs in the thesis.

The

Consider the following sentence from a logical point-of-view: The pope is male. Since first-order logic has no "the", only "for all" and "there exists", we have to agree on how to translate the sentence into first-order logic. Commonly accepted, and suggested by, e.g., Russell's On Denoting and by Frege, is:

1. There exists an X such that X is a pope. (At least one pope exists.)
2. For all X and Y, if both X and Y are popes, then X = Y. (At most one pope exists.)
3. For all X such that X is a pope, X is male.

Then, "The pope is male." is equivalent to (1 and 2 and 3).

What happens when "the" refers to a plural? Consider: The frogs are green. Which of these rewrites to first-order logic are equivalent to "The frogs are green."?

Rewrite A.
1. For all X, if X is a frog, then X is green.
(No claim of existence.)

Rewrite B.
1. For all X, if X is a frog, then X is green.
2. There exists an X such that X is a frog. (At least 1 frog exists.)

Rewrite C.
1. For all X, if X is a frog, then X is green.
2. There exist X and Y such that X is a frog, Y is a frog, and X ≠ Y. (At least 2 frogs exist.)

I have a strong preference (which I will keep secret temporarily, to not bias anybody) but I doubt there is a universally accepted rewrite. Forestidia disagrees with my choice here and has a strong background in philosophical logic. The classical examples on the internet don't help either, Russell's essay is purely about the singular "the".

-- Simon

ccexplore · « **Reply #128 on:** May 24, 2018, 08:55:03 PM »

I feel like there is an implied context of some sort when you say "the frogs". That is, from some previous communication (maybe a previous sentence, maybe something you said in IRC yesterday, whatever), a specific set of frogs had been specified, and then this sentence is referring to all members of that specific set.

Without the context I'd argue the sentence is ambiguous and poorly written. It would be better to just say "Frogs are...", or perhaps "All frogs are..." or "Some frogs are..." depending on the exact semantics desired.

Indeed, the same can be argued for singular "the". The interpretation given by Simon only works because in our world there is exactly one pope*. If the sentence had been something like "The man is tall", it would not be implying at most one man exists. It would be referring to a specific man via an implied context established in past communications.

*More precisely, exactly one person being the pope at any time.

ccexplore · « **Reply #129 on:** May 25, 2018, 11:05:56 AM »

While we're on this topic, what are your thoughts on the difference (if any) between

A dog is a mammal.

and

Dogs are mammals.

Is the usage of singular versus plural meaningful?

Forestidia86 · « **Reply #130 on:** May 26, 2018, 02:40:51 PM »

Quote from: ccexplore on May 25, 2018, 11:05:56 AM

While we're on this topic, what are your thoughts on the difference (if any) between

A dog is a mammal.

and

Dogs are mammals.

Is the usage of singular versus plural meaningful?

My feeling says no concerning logical analysis.

I would formalize both as: For all x: if x is a dog then x is a mammal

Edit: I assumed for the first sentence that you want to make a general statement about dogs and not to say that some dog happens to be a mammal.

Dullstar · « **Reply #131 on:** June 04, 2018, 05:41:02 AM »

Quote from: Simon on May 24, 2018, 04:59:07 PM

Consider: The frogs are green. Which of these rewrites to first-order logic are equivalent to "The frogs are green."?

Rewrite A.
1. For all X, if X is a frog, then X is green.
(No claim of existence.)

Rewrite B.
1. For all X, if X is a frog, then X is green.
2. There exists an X such that X is a frog. (At least 1 frog exists.)

Rewrite C.
1. For all X, if X is a frog, then X is green.
2. There exist X and Y such that X is a frog, Y is a frog, and X ≠ Y. (At least 2 frogs exist.)

I have a strong preference (which I will keep secret temporarily, to not bias anybody) but I doubt there is a universally accepted rewrite. Forestidia disagrees with my choice here and has a strong background in philosophical logic. The classical examples on the internet don't help either, Russell's essay is purely about the singular "the".

-- Simon

I don't have any background in formal logic, but I will make an attempt at this, as I don't really have anything better to do right now and I find this to be an interesting thought exercise.

It seems to me that there probably can't be a universal rewrite for this sentence, because there's insufficient context to determine the exact bounds of the subset "the frogs."

"The frogs are green" can be true or false depending on what "the frogs" refers to. We need context to determine that. Suppose there is a box containing frogs. I point to it and say, "The frogs are green." This extra context removes the ambiguity as to which frogs we are referring to - now it's the frogs that are in the hypothetical box, rather than an unspecified group subset of frogs. But now we must check to see if the statement is actually correct. It is possible for all the frogs in the box to be green^[1][2]. However, it is also possible that at least one of the frogs in the box is NOT green^[3][4]. For this reason, I can create a set of frogs for which the statement "The frogs are green" is false.

This is where I can no longer really work with the given information without more background knowledge. I am unsure of the exact meaning of "For all X, if X is a frog, then X is green." Is this statement defining the object selection, to state that all the frogs under consideration are green (i.e. if an object is a frog, and it is not green, it is not X)? Or is it a statement that, for any given object X, if X is a frog, it is green (i.e. stating that all frogs are green)?

Based on these two interpretations, I'd say the following:

If "For all X, if X is a frog, then X is green" is equivalent to the statement "If an object is a frog, and it is not green, it is not X" then I'd say that Rewrite C is best, simply because it clarifies that there is more than one frog, which is implied in the plain language "The frogs are green." Rewrite B also allows for the possibility that there is one frog, which is NOT a possibility implied by the plain language, and Rewrite A does not specify that any frogs exist.

If "For all X, if X is a frog, then X is green" is equivalent to the statement "All frogs are green," then, due to the pictures shown in [3] and [4], then Rewrites A, B, and C are all demonstrably false.

---
Regardless of the proper formalization of "The frogs are green," if we make the assumption that the statement is true, then the following items must be accounted for to avoid anything being lost in translation:

1) "The frogs" refers to at least 2 frogs, all of which are green.
2) The statement becomes false if "the frogs" is changed to "all frogs."
3) It is not possible to fully ascertain what frogs are being referred to by "the frogs" without additional context.

Forestidia86 · « **Reply #132 on:** June 04, 2018, 08:43:27 AM »

Quote from: Dullstar on June 04, 2018, 05:41:02 AM

It seems to me that there probably can't be a universal rewrite for this sentence, because there's insufficient context to determine the exact bounds of the subset "the frogs."

"The frogs are green" can be true or false depending on what "the frogs" refers to. We need context to determine that. Suppose there is a box containing frogs. I point to it and say, "The frogs are green." This extra context removes the ambiguity as to which frogs we are referring to - now it's the frogs that are in the hypothetical box, rather than an unspecified group subset of frogs. But now we must check to see if the statement is actually correct. It is possible for all the frogs in the box to be green^[1][2]. However, it is also possible that at least one of the frogs in the box is NOT green^[3][4]. For this reason, I can create a set of frogs for which the statement "The frogs are green" is false.

That's a very good point. Yeah, the statement is dangling without context. So formalization is probably not complete without catching somehow the context or that there is further context.

Quote from: Dullstar on June 04, 2018, 05:41:02 AM

This is where I can no longer really work with the given information without more background knowledge. I am unsure of the exact meaning of "For all X, if X is a frog, then X is green." Is this statement defining the object selection, to state that all the frogs under consideration are green (i.e. if an object is a frog, and it is not green, it is not X)? Or is it a statement that, for any given object X, if X is a frog, it is green (i.e. stating that all frogs are green)?

I'm not fully sure if I can pinpoint what you say there.

Generally "For all X, if X is a frog, then X is green." is an universal statement and is meant to formalize "All frogs are green.". One remark: This statement is equivalent to "For all x it is not the case that x is a frog and x is not green." Another remark: "For all X, if X is a frog, then X is green." doesn't imply in modern formal logic that there are frogs.

One point is that if one talks about all objects still the question remains for truth or falsehood what is the set of objects and how are expression like "frogs" and "green" defined or what objects are assigned to them.

In formal logics you have model-theoretic semantics, where a model has a set of objects as a domain and an interpretion function that e.g. assigns subsets of the domain to the one-place predicates (like "frogs" and "green"). Depending on the model the sentence is true or false in that model unless it's a logical truth, which the given sentence is not.

But in general if you formalize a sentence of natural language one has the model that fits to our understanding of the world in the back of their minds I would say since that's the background people are formulating these sentences.

I think generally formalization mainly tries to catch the logical structure of the sentence, is on the syntactical side and most of such sentences will be logically indetermined.

Simon · « **Reply #133 on:** June 06, 2018, 10:14:39 AM »

Thanks everybody for the exciting responses!

Quote from: ccx

Without the context I'd argue the sentence is ambiguous and poorly written.

Quote from: Dullstar

It seems to me that there probably can't be a universal rewrite for this sentence, because there's insufficient context to determine the exact bounds of the subset

Quote from: Forestidia

Yeah, the statement is dangling without context.

I have to agree. This problem draws more attention than what I wanted to discuss.

For my original interest, better would have been: I put a box in front of us all, point to the box, and say: The frogs in the box are green. Is this sentence then equivalent to All frogs in the box are green. or is it only equivalent once we, in addition, establish that there are at least 1 or 2 frogs in the box?

Quote

1) "The frogs" refers to at least 2 frogs, all of which are green.

This answers my original question: You prefer that, as long as the set is determined, that "The frogs in that set are green." require at least 2 frogs in the set to have any chance to be true.

Forestidia prefers also at least 2 frogs if the sentence comes from natural language. If it's clear that the sentence comes from a logical discussion, 1 frog may be enough for her, but never 0 frogs.

My preference is that "The frogs in the set are green." is equivalent to "All frogs in the set are green." Still, I would ask for clarification if this arose in natural language and the set turns out to contain 0 frogs.

Quote

A dog is a mammal.
Dogs are mammals.
My feeling says no concerning logical analysis.
I would formalize both as: For all x: if x is a dog then x is a mammal

I agree that both sentences mean "For all X: If X is a dog, then X is a mammal."

In natural language, there are disguised universal statements, such as: "The dog is a mammal.", still meaning "All dogs are mammals." This feels like abuse of language but it's still okay as long as we haven't specified any single dog before.

Quote from: Forestidia

if you formalize a sentence of natural language one has the model that fits to our understanding of the world in the back of their minds

Yeah, natural language has many implicit dependencies. The model is a common understanding of the real world unless I override that explicitly. I didn't override anything in my examples to keep them simple; I even made the examples too simple/undefined.

-- Simon

ccexplore · « **Reply #134 on:** June 07, 2018, 07:04:18 AM »

We've certainly been conditioned to expect 2 or more frogs. I could imagine though the case where everyone including the speaker did expect there were at least 2 frogs in the box, but then after speaking the sentence, someone open the box and somehow, the frogs weren't there anymore (maybe there's a hole somewhere in the box we all overlooked, whatever). Everyone would be surprised, but I think you could convince at least some people that the sentence is still true.

In contrast, if the box is transparent and has been in full view of everyone for a long time and there were never any frogs seen inside, you would probably have a much harder time convincing a layman that the same sentence being uttered would be true. It would "feel" wrong in this case and make people feel you are kind of being misleading.

nin10doadict · « **Reply #135 on:** June 07, 2018, 07:08:59 PM »

I mean, if there aren't any frogs in the box (whether they were there to begin with or not) then that's a null reference, right? It feels to me kind of like trying to divide by 0; it's something that just doesn't work. Yeah, all frogs in the box are green, but if there aren't any frogs, then how do we know that there isn't some non-existent purple frog? I feel that the sentence loses meaning if it references something that doesn't exist.

So is it automatically implied that "If the box contains a frog, then all frogs in the box are green?" More importantly, if there are no frogs, does that make the statement "All frogs in the box are green" true or false? It appears to have entered a third state, one of "irrelevance."

Forestidia86 · « **Reply #136 on:** June 07, 2018, 07:47:41 PM »

Quote from: nin10doadict on June 07, 2018, 07:08:59 PM

I mean, if there aren't any frogs in the box (whether they were there to begin with or not) then that's a null reference, right? It feels to me kind of like trying to divide by 0; it's something that just doesn't work. Yeah, all frogs in the box are green, but if there aren't any frogs, then how do we know that there isn't some non-existent purple frog? I feel that the sentence loses meaning if it references something that doesn't exist.

So is it automatically implied that "If the box contains a frog, then all frogs in the box are green?" More importantly, if there are no frogs, does that make the statement "All frogs in the box are green" true or false? It appears to have entered a third state, one of "irrelevance."

So you see a presupposition of existence of frogs in the box in a statement like "All frogs in the box are green" (like the ancients)?
For reference in classical modern formal logic:
If there exist no frogs in the box then sentences of this form are always true: For all x (x is a frog in the box then A), whereby A is some other formula, e.g. For all x (x is a frog in the box then x is green) but as well For all x (x is a frog in the box then x is purple). This results roughly from following principle: non-P then (P then A) or as a rule of inference: You deduce (P then A) from non-P.
This principle/rule is sometimes critizised by non-classical logicians as unintuitive.

What do you mean with third state of irrelevance? Is it a real third value or gap beyond true and false or are we only not interested in the truth value of such statements? In other ways: Can't an irrelevant statement be still true or false?
It seems actually to be kind of a corner case.

ccexplore · « **Reply #137 on:** June 08, 2018, 09:59:01 AM »

Maybe a way to illuminate the situation is to consider a third logical value of "don't know" or "not sure", and also think about how people tend to arrive at rules like "A implies B" through an iterative process of evidence gathering.

In other words, there are 3 cases concerning a statement of the form "A implies B":

1) A is true and B is true. This is an instance of evidence supporting the statement as true. The more examples of this case someone experiences, the more the person will become convinced that the statement is true.

2) A is true and B is false. This is an instance of counter-evidence disproving the statement. A single counterexample is sufficient to demonstrate the falseness of the statement.

3) A is false. B may be true or false. This is neither evidence for nor against the statement. These irrelevant cases have no bearing on someone's confidence on the truthfulness of the statement.

The extreme is if A is always false, like talking about a purple frog in the box when no frogs are in the box. Then by definition, there can never be any evidence supporting the statement, but also no evidence ever to disprove it. In classical logic we still consider the statement true. In most people's mind though, they intuitively want truth to correspond to a preponderance of evidence, and so when no evidence exists at all, they can't be comfortable considering it true.

Forestidia86 · « **Reply #138 on:** June 08, 2018, 12:25:20 PM »

Quote from: ccexplore on June 08, 2018, 09:59:01 AM

3) A is false. B may be true or false. This is neither evidence for nor against the statement. These irrelevant cases have no bearing on someone's confidence on the truthfulness of the statement.

It's an interesting point to see conditionals in a way of verification or falsification. The classical logical principle follows then the rule that if it can't be falsified it's true. Whereas intuition from your view (as I understand it) says that only what can be verified (or falsified) can be true. This is a very demanding view of truth which combines truth with the possibility of determining it.
It could be seen as problematic to mix up the logical conditional with natural language intuitions of "if-then" but since it's about formalization of natural language it's a valid point to question those formalizations. (The same applies maybe to the concept of truth.)

If you take the empty set that contains no elements: The fact that it contains no elements can be used with the logical principle discussed here:
E.g. You get to the conclusion that the empty set is a subset (or identical) of every other set.
This is because subset is defined in the following way:
Be x,y sets:
x is a subset (or identical) of y iff For all z (z € x then z € y). ('€' means "is element of")
Since z € empty set is always false, the whole universal sentence is (for x = the empty set) always true no matter which set y is.
Insofar I have a problem in calling such things irrelevant.

That leads to the question what is the consequence of the intuition that there is a "not sure"-value. Do we introduce this third value and how does our logic then look like? Does it have consequences for mathematics (in a very wide sense) as well or only for natural language?

ccexplore · « **Reply #139 on:** June 08, 2018, 09:39:00 PM »

Quote from: Forestidia86 on June 08, 2018, 12:25:20 PM

If you take the empty set that contains no elements: The fact that it contains no elements can be used with the logical principle discussed here:
E.g. You get to the conclusion that the empty set is a subset (or identical) of every other set.
<snip>

Yes, that may well feel very natural in the context of mathematics and logic, you're used to this kind of thing. But if you try to express this in natural language without making use of the word "set", I think you may find it a little tricky to come up with such a statement that sounds natural. Like, I don't know, "nothing is always part of any group of things"?

I feel like the only natural way to talk about the conclusion to a layman is to maybe re-state in the negative form, ie., you can never find something in an empty set that doesn't belong to any set. Even in this form it will feel a little strange, because the precise reason it is true is that nothing whatsoever ever can be found in the empty set anyway! Like you said earlier, it is a corner case.

I'm certainly not advocating that there is any inherent weakness or flaw in how classical logic is formulated. It has definitely served its domain (eg. mathematics) very well. I'm just pointing out that the human mind seems not wired exactly like classical logic, and it's this mismatch between how our brains are wired vs how classical logic works, that I theorize is at the heart of the conflicting views here.

Proxima · « **Reply #140 on:** June 08, 2018, 10:11:58 PM »

Quote from: ccexplore on June 08, 2018, 09:39:00 PM

I think you may find it a little tricky to come up with such a statement that sounds natural. Like, I don't know, "nothing is always part of any group of things"?

"If you have some things to choose from and may take any number of them you wish, taking nothing is one of your options."

Simon · « **Reply #141 on:** July 20, 2018, 06:27:09 AM »

Thesis grind

I want to submit the PhD thesis by end of July, ideally by Friday, 27th. Every day is thesis day. Icho will be happy. Still must find extra profs for the defense comitee, time is running, I'm sending emails like a madman.

Until thesis submission, I'm supressing the urge to write colorful rants here (even the juiciest entertainment doesn't help finish thesis). Suppressing the urge to kill bugs in Lix, to improve level search or replay management in Lix, and even supressing urge to refactor. Supressing the implementation of girlfriend mode a.k.a. networked singleplayer.

Nap time now.

-- Simon

Ryemanni · « **Reply #142 on:** July 20, 2018, 09:51:07 AM »

(•_•)
( •_•)>⌐■-■
(⌐■_■)

Every day is thesis day.

Simon · « **Reply #143 on:** July 27, 2018, 09:17:53 PM »

This is how it looks in my room. I've handed in the thesis.

I've slept for 9 hours afterwards. I'm not in the mood to celebrate after the grind this week: It's still hard to realize that there is no immediate university work.

Defense is on September 10th. I have slides for a 30-minute talk from July 2017 in Stockholm, that gives me a head start to prepare the defense. Will take a few weeks of break.

-- Simon

Colorful Arty · « **Reply #144 on:** July 27, 2018, 10:01:26 PM »

Congrats on finishing the thesis, Simon!

Akseli · « **Reply #145 on:** July 28, 2018, 06:48:01 PM »

Breathtakingly splendid, Simon!

This makes me very happy for you.

Simon · « **Reply #146 on:** August 01, 2018, 10:57:34 AM »

Thanks for the kind words!

Heat

It's 30 degrees C in Germany and the sun shines all day.

Consequences

Headaches, tiredness, dehydration
Eyes hurt from bright environment (sunglasses as extra bloat to carry/wear/forget)
Everybody becomes aggressive and unproductive

Benefits

Simon rants more?

Solutions

Freeze medical compresses, then wear one on the head. Buy 2-3 of these compresses to alternate: Whenever the current one thaws, re-freeze it and switch to a cold one. This works with headphones: Bend the phones' headband to the front and stick the compress behind the headphones, on the top of the head.
Siesta. Take at least one longer nap during the day. Or work entirely at night, should that fit into your social life.
Cover the outside of the windows with aluminum foil, or get proper window shades that block sunlight. Keep room dark at all times.
Swim in a lake.
Live in the US? Allegedly, more private houses in the US than here have air conditioning. Germans sure love their central heating.
Fans? Noisy and they produce more heat, but you be the judge.

-- Simon

Ryemanni · « **Reply #147 on:** August 01, 2018, 11:13:59 AM »

Most of the houses in Finland are not prepared for the heat either, only for the cold. My only tips are to not go outside, drink a lot, and invest on an ASHP.

nin10doadict · « **Reply #148 on:** August 02, 2018, 06:41:57 AM »

So I'm not the only one who's sick of the summer heat.
Seriously, I really don't like the heat. Some people get seasonal depression in winter. I get it in summer.

Colorful Arty · « **Reply #149 on:** August 02, 2018, 10:24:34 PM »

I never, EVER complain about summer heat. I'd take heat over cold any day, partially because my skin shrivels up in the winter.

Simon · « **Reply #150 on:** August 10, 2018, 12:32:20 PM »

The weather has become cooler again, that is very nice. It's still deep in the shorts-and-T-shirt weather. I wear sandals whenever possible, that's good for the environment because I don't have to launder any socks.

There will be a Family Feud round (forum game) by Forestidia and me, we'll think of the questions within a week.

Comma, more base-16

Germans use decimal commas and thousands-separating points: 1.234,5. That is weird and should be abolished in favor of the decimal point, 1,234.5, which seems to be more common around the world than any other separator. It's extremely confusing to read any kind of number in German when you're exposed to the decimal comma 80 % of the time.

Decimal is bad anyway and should be swapped for hexadecimal (not for base-12 even though many anti-decimal people want base-12). Powers of 2 are so useful that any other prime merely bloats the base, and 16 has an integer root (4) to generate patterns in the base-16 multiplication table that help memorizing the table.

■ ■ ■ ■
■ ■ ■ ■
■ ■ ■ ■
■ ■ ■ ■

The human brain is good at pattern recognition. It's also excellent at halving a visually presented quantity. Base-16 exploits that. A square tiled into 4x4 small squares is easier to grasp than a rectangle tiled 5x2 because of the 4x4's regularity and smaller max side length. Thus, let's design our numbers for humans, not for traditionalists.

Base-16 coins should be square (maybe some should be triangular?). They won't roll under the sofa, and they should get little tongues and grooves along their sides, then you can stick together 4 one-euro pieces to from a single 4-euro piece. The smallest coin available should be a 16th of a euro, anything smaller is unnecessary. In 30 years, even the 1/16-euro coin will be phased out, and the 1/4-euro will be the smallest.

No coin should be twice the value of another; coins should be a factor of 4 apart (maybe even 16 if coins can form a 4-times-larger coin by sticking them together). There should be as few different coins as possible and they should be easy to tell apart both by feeling and by looking.

There is no compelling reason to use base-10 other than tradition. The 10 fingers on our two hands seem like an after-the-fact rationalization of the bad choice that is base-10. Really, we don't have 5 similarly-shaped fingers on a hand; rather, we have 4 fingers and an opposing thumb. With 4 = 2^2 fingers and 1 = 2^0 thumb, we have 2 = 2^1 kinds of different stuff on each of our 2 = 2^1 hands. See, even nature ditches anything but powers of 2!

-- Simon

Dullstar · « **Reply #151 on:** September 05, 2018, 06:44:44 AM »

While the main reason to use base-10 is tradition as you've said, I think that in this particular case, the tradition argument carries a lot more weight than it normally would.

If you were designing everything from scratch, it *may* make sense to use base-16 from the start, rather than base-10. But we can't ignore the fact that base-10 is deeply ingrained, because this imposes a series of problems we would have to deal with in order to switch. In this sense, I think it would be a very, very, very long time (probably at a minimum several generations' worth of time) before any possible advantages of base-16 would make up for the costs (financial or otherwise) of the transition process.

Disadvantages of switching from base-10 to base-16:
- Most people have to learn a new number system (most people probably don't even know what base-16 is, let alone how to use it)
- Confusion regarding values represented by numbers in works prior to transition
- Ambiguity regarding values represented by numbers in works during transition (if you have the number 52, did the author mean that in base-10 or base-16? Most likely, not everyone will switch right away)
- SI system prefixes become harder to work with unless they are changed, in which case the world has to redo the transition to SI.
- Thought the fact that the US culturally refuses to use SI is confusing enough? Wait until any country decides they just don't feel like transitioning to base-16. Now, in order to understand any numerical values containing only the digits 0-9, we must know if it was produced in a country that used base-10 or base-16 at the time of production. At least with units, they have to be labelled, so there's no ambiguity regarding whether a paper intends a length to be interpreted in feet or meters.
- To eliminate any confusion, we'd have to start clarifying bases by some way, either by inventing new symbols for 0-9 in the base-16 system, or by giving a base label of some sort to every number. This will be much less convenient than the current system where we are almost always safe to assume a value is in base-10 if no base is specified.
- New number words would need to be created, at least in English, for numbers such as 2A (how would you even pronounce that? twenty-A?). New ones would also be needed in order to eliminate the ambiguity discussed earlier.

I'd say that in a realistic best case scenario, this change would create a situation where instead of just worrying about whether 1,234 is between 1000 and 2000 or 1 and 2, now we have to worry about whether 1,234 is 1,234 or 4,660.

nin10doadict · « **Reply #152 on:** September 05, 2018, 07:41:12 AM »

As a follow up to the 'pronouncing hexidecimal numbers' thing... Consider the number AD. How to say that? "Ay-dee" sounds much like eighty. "Ay-dee-dee?" How do we know that doesn't mean 8D? Would it be better to just read off every number one digit at a time? Perhaps add pauses in fixed locations for long numbers.

Anyone who's studied computer science should have an understanding of hexidecimal, but having it replace base 10 entirely would be a lengthy process that would encounter much resistance.

Simon · « **Reply #153 on:** September 05, 2018, 09:22:02 PM »

Dullstar and nin10doadict, thanks for the wise responses! Yeah, the tradition argument weighs heavily for base-10. I don't expect a serious real-world move away from base-10 in my lifetime.

In the dark corners of my mind, I want to see the world struggle, in all gruesome details, for the better future.

The switch to base-16 would be our generation's gift for the children in 20 to 50 years.

Designing new words for numbers: Yes. We must distribute 16 unique digit names in the space of all short, nice words/sounds such that no two of them are too close to each other.

Even today, eighteen and eighty sound far too similar. I want to call 18 ten-eight.

-- Simon

mobius · « **Reply #154 on:** September 06, 2018, 12:07:59 AM »

we could use a smaller number of symbols then alter them (like rotating 90 degrees for example) to represent higher or other numbers.

I always loved the fictional 'D'ni' number system from the Myst series;

it's a base 25 system, except there are actually only 4 symbols. Number 5 is 1 rotated, then 6 is 5 combined with (or superimposed with) 1. 7 is 5 with 2 etc. Then 25 and onward work similar to our 10, 11, etc.
Though I don't know if I'd describe this as 'better' compared to our system

http://dni.wikia.com/wiki/D%27ni_Numerals

ccexplore · « **Reply #155 on:** September 06, 2018, 04:29:29 AM »

Quote from: mobius on September 06, 2018, 12:07:59 AM

I always loved the fictional 'D'ni' number system from the Myst series;

Ah yes, I remember playing that game back in my teen days, fun times. I was able to work out the number system on my own, but kind of wonder how many people might have gotten stumped by it?

While base 25 is a reasonable description for the system, considering that the in-game mythology actually holds the number 5 as special, it is equivalent but perhaps somewhat more fitting to say it's a base-5 system with a unusual writing system for the "digits", where effectively you group them into pairs and rotate one of the two but otherwise write them out both overlapping in the same space. Basically imagine if instead of writing "13" for thirteen, you are to rotate the 1 ninety degrees so it becomes more like -, then you write both digits overlapping each other so you end up with something like a 3 with a - going through it. It's equivalent to think of such a system as both "base 100" as well as "base 10 with an unusual system of writing out the digits".

Simon · « **Reply #156 on:** September 10, 2018, 02:53:23 PM »

PhD

I defended my doctorate thesis today. It's a magna cum laude, 2nd best of 4 possible passing degrees. It's an excellent result, I didn't expect it this good at all. The thesis itself didn't get such a good grade, but the presentation and public quiz convinced the committee.

Forestidia said: The Jazz speedruns and the streaming helped me for sure with presenting, I talked loud and clear. Icho was there, too, and congratulated. This was even a spontaneous 3-person forum user meeting.

Technically, I'm not allowed yet to call myself doctor or PhD; that has to wait until October.

The next days, it's all chilling and getting up to speed with friends. Then, job hunting!

-- Simon

Ryemanni · « **Reply #157 on:** September 10, 2018, 03:28:59 PM »

That's worth a good ol' warm Congratulations!

Akseli · « **Reply #158 on:** September 10, 2018, 04:51:30 PM »

#neolemmix IRC channel logs Monday the 30th of July 2018:

[02:27:17]    <SimonN> Han nan nan nan, Akseli, I still have to defend to get the degree, and the degree is in maths, not in busting quacks
[02:27:31]    <SimonN> busting quacks, one learns that on the internet better than at any uni
[02:29:18]    <Akseli> are you saying your field is more hardcore than other fields? : P
[02:30:04]    <Akseli> just kidding, good luck for the defending : D I've been in three different defending events, they're fun at least here in Finland
[02:30:07]    <SimonN> no, merely that my field is unrelated, anybody can compute acceleration : )
[02:30:23]    <SimonN> heh yeah, it should go well
[02:30:39]    <Akseli> people are just laughing and telling jokes
[02:30:47]    <Akseli> the audience goes wild
[02:30:56]    <Akseli> everyone has a festive feeling
[02:31:00]    <SimonN> hoh, nah, we take it slightly more seriously
[02:31:06]    <Akseli> : D : D : D : D
[02:31:13]    <SimonN> it's mostly about the math still
[02:31:31]    <SimonN> the audience that is not well-versed in the field has a hard time following
[02:32:36]    <Nessy> : D
[02:34:45]    <Nessy> Yeah good luck Simon!
[02:36:23]    <SimonN> thanks!
[02:41:24]    <Akseli> yeah Simon, overwhelm the counter argument guy !
[02:42:23]    <SimonN> "why did you spend years on this trivial stuff?" -- "if it's trivial, why has nobody else done it yet?"
[02:42:42]    <Nessy> > ; P
[02:45:59]    <Akseli> yes, and the audience enjoys their life
[02:46:15]    <Akseli> "ha ha ha" echoes in the room
[02:46:23]    <Akseli> the counter argument guy blushes
[02:46:34]    <Akseli> Simon flashes his overly charismatic smile
[02:46:41]    <Akseli> people go wild yet again
[02:47:28]    <Akseli> after 2 hours and 7 minutes the event is over, and people gather outside the room to chat in joyful manner

____________________

Congratulations, Simon!

IchoTolot · « **Reply #159 on:** September 10, 2018, 05:53:17 PM »

Congratulations here as well.

I even understood some single things during the defense and the buffet afterwards was splendid!

Nessy · « **Reply #160 on:** September 10, 2018, 06:25:06 PM »

Another BIG congratulations Simon!

You worked very hard on this and you should be proud of your accomplishments!

nin10doadict · « **Reply #161 on:** September 10, 2018, 08:47:15 PM »

Sounds like you'll be getting more out of your degree than I've been getting out of mine. Best wishes

ccexplore · « **Reply #162 on:** September 12, 2018, 08:59:56 AM »

Congratulations! Looking forward soon to reading "Dr. Simon blogs".

grams88 · « **Reply #163 on:** September 12, 2018, 09:36:34 AM »

That must of been tough going, well done Simon. All the studying has been worth it.

Simon · « **Reply #164 on:** September 13, 2018, 04:55:50 PM »

Thanks everybody for the kind words!

-- Simon

Simon · « **Reply #165 on:** September 18, 2018, 12:02:05 PM »

Quote from: ccexplore on September 12, 2018, 08:59:56 AM

Looking forward soon to reading "Dr. Simon blogs".

I remember my first rant after passing: When you hand-write the digit 5 on paper, then move the hand to write another digit, but during the move, either you don't lift the pen properly or have the paper stick to the pen, you will draw a line through your 5 and make the 5 look like an 8. Digits should be designed more robust than this.

Weight bet

In April 2018, I weighed 86 kg at 1.92 m and made a bet to lose 8 kg of weight to 78 kg over 7 months. This week, 5 months into the bet, the scale shows 77.7 kg and I merely have to maintain this weight for 2 months to win.

When I picked a new suit for the defense, the clerk even said: Skinny tall guy, it'll be easy to find something fitting.

During the bet, I still played only my feeble amount of sports. Instead, I ate in moderation and cut off-the-shelf snacks and sugary drinks. One idea behind the guinea pig diet (put cucumber on every bread in addition to your usual salami/cheese/...) is to make the food more elaborate to prepare, and you will stop easily when satisfied.

Occasionally, I still indulged in snack feasts with friends. That's fine: By then, one is accustomed to a moderated diet and will adapt to such extra intake, eating less the day after.

Mafia replacements

Mafia (social game, we played by forum) has downsides: Early and frequent player elimination, and a moderator who can't play themself. I preferred lean Mafia rules with few roles, but then you must debunk liers by pure face-by-face observation, very hard in a forum game. Others like many extra roles to give the community more substance for clues and discussion.

But whenever you're stuck with questionable design, plastering extra rules on top is rarely correct. You should instead attack the root problems. Secret Hitler (2016) and The Resistance (2010) fix both the early player elimination and obviate a moderator. Were I to play a hidden-role party game, I'd probably propose one of these over Mafia to the game group. Secret Hitler seems to have a large growing fanbase.

Still, I believe that Mafia will be played for many years to come, because it's the simplest. It captures the game idea and isn't obviously broken.

-- Simon

grams88 · « **Reply #166 on:** September 18, 2018, 04:30:45 PM »

Hi Simon

It used to be a nightmare trying to get trousers to fit myself, it was the ones you would tend to wear for funerals and job interviews, weddings maybe. I'm around the 19 stone mark, I've been looking to trying to get back into the basketball as that was something I was quite good at back in the school and college days. My brother and I played a few one on one football games with a basketball. I ordered a basketball earlier this year and it has gotten my brother and myself out running a bit more. I can run at a fast pace but you do notice when you are at the 19 stone mark you do get out of breath a bit more. Still thinking about joining a basketball league in the future.

That's an interesting idea about making the food more elaborate when it comes to preparing that way you do tend to take steady approach to what you are eating. Do you play a little sports yourself, what's your favorite sport if you had to choose Simon?

Simon · « **Reply #167 on:** September 19, 2018, 11:26:11 AM »

Yeah, 19 stones (120 kg) sounds like the high end. Way to go with the basketball!

Weight loss, slowly over time, happens via diet: Look up your daily food energy requirement and actual intake. But merely dieting loses both fat and muscle. The sports counterbalance that, and keep you fit and happy.

My sporting -- I rode the bike each day to the math department and back. Now, Tim (reallife friend) has taken up Disc Golf, occasionally I join him on his weekly round: I get to spend time outside, and throwing those discs feels like starting lawn mowers.

I haven't considered joining a sports club. But even at home, I should practice pushups again, just a few.

-- Simon

Proxima · « **Reply #168 on:** September 19, 2018, 11:46:10 AM »

I've noticed lately that most of my trousers no longer fit me, and I think the reason is that my warehouse job, where I was for nine months, added up to a lot more physical activity than I realised. I haven't checked my actual weight any time over the last year, though.

When I visited Japan in 2013, I was there for three weeks and lost about 5kg very quickly. I guess that was a combination of visiting so many places, and Japanese food being so much healthier. I would love to go there again

nin10doadict · « **Reply #169 on:** September 19, 2018, 04:45:40 PM »

I've been at around 57 kg for at least 6 years now. At 1.8 m tall, this means it's also difficult to find pants that fit.
If I exercised more than what I get at my job then I might not have this problem...

Still, I'll take that over being too far in the other direction.

Simon · « **Reply #170 on:** September 30, 2018, 02:02:34 AM »

Quote collections

random3.txt: My personal list of collected quotes. Most of them are about design, psychology, games, software. I don't remember why the file is called random3.txt anymore, I don't have any such files with numbers 1 or 2, but the name sticks. Random quotations.
Akin's Laws of Spacecraft Design: Classic list about physical engineering. Most of it is applicable to software engineering, even though my instinct would tell that it is not. E.g., in software, the extreme solution is often the cleanest, and cleanliness has great value, but it pales against backwards compatibility.
Dutch Quotes: Collected by somebody unknown, but most likely by a Dutch. I'm rehosting this because the original disappeared from the net 10 years ago.

-- Simon

Simon · « **Reply #171 on:** October 10, 2018, 10:12:20 PM »

Aaaaaaa

I want to go to bed early, to fix sleep schedule by force. No computer time past 00:00 UTC+2 for next >= 1 week.

I sent email with missed attachment. Again because I didn't follow my own advice to always add attachment first, then write body, then write subject, then add recipients.

Had to resend, and now rant, and now it's 00:12. Good night.

-- Simon

namida · « **Reply #172 on:** October 12, 2018, 07:10:41 AM »

Quote from: Simon on October 10, 2018, 10:12:20 PM

I sent email with missed attachment. Again because I didn't follow my own advice to always add attachment first, then write body, then write subject, then add recipients.

Do you use GMail? If so, GMail has an "Unsend" feature that can be very handy - you need to enable it though, it's not enabled by default.

This isn't a true unsend, of course - that'd be pretty much impossible (and even if possible, there are possible moral issues with such a feature). Rather, it delays sending the email for a time period of your choosing - the maximum I believe being 30 seconds - during which you can cancel the send. Very useful for those cases where you click Send then immediately realise you forgot something.

Simon · « **Reply #173 on:** October 16, 2018, 10:39:32 PM »

Right, I've used Gmail.

Undo-sent-email is available for a few seconds, it wouldn't have helped me that time. Interesting that one configure its duration, I've set it to 30 secs, the max.

I remember how they were annoyed about their internal delay on sending email, and turned it into a user feature. Very nice hack!

-- Simon

Simon · « **Reply #174 on:** October 17, 2018, 06:52:43 PM »

Text-based configuration formats

All text-based configuration formats suck. (They're still the best. Binary sucks more. Databases are overkill for configuration.)

I'm considering to write Lix's trophies and options in a different place, and add trophy fields (author of level, title of level). I'm considering to write the trophies in SDLang, but there are many competing text file standards and they all have problems.

Why not use X, where X = JSON, Ini files, SDLang, TOML, YAML, XML, etc., for at least 10 formats, by the StrictYAML authors.
JSON as configuration files: please don't
YAML: probably not so great after all

Downsides of Lix's config file format: Hardly extensible. Even though the parser ignores lines beginning with unknown keywords, but the attributes after the keyword have no names, have a fixed order, and fixed types. Can't define nested structures. Tile groups in Lix levels already need a hack with an open-section-tag and a close-section-tag. (I will keep the level format and not change that anytime soon! This is only for options.)

Downsides of SDLang: Almost nobody uses it, few existing parsers for other languages besides D, complicated (does the application expect a tag with many values, or a tag with attributes, or a tag with child tags?)

-- Simon

Simon · « **Reply #175 on:** October 26, 2018, 11:24:40 AM »

Pure

It is nice if your function is weakly pure (doesn't read or write to global mutable state) or strongly pure (as weakly pure, and additionally doesn't dereference any of its argument pointers to mutable state) because the same inputs will then always yield the same outputs. The compiler can assume things about your function, replace function calls with cached results, or constant-fold everything.

It is nice if your function doesn't allocate memory, guaranteed. That's faster, that's compatible with more algorithms (leaves your callers in control about how to allocate), and makes your function simpler.

It is nice if your function cannot throw exceptions. Need fewer things in the mind before the code is complete and handles all conditions. Thus, it's simpler.

It is nice if your method promises to not modify the object. Your readers can reason about the system's state more easily, and focus on the real problems.

It is nice if your function, if it promises to return a class object by reference, guarantees that the reference is not null (we had this rant).

It is nice if ...

It is terrible if everything in your code is annotated with @property @safe const pure nothrow @nogc:

It looks ugly and complex.

It's brittle because simple changes produce nasty, cascading errors.

It's unworkable if only 98 % of your language's standard library follows the principle, you call into the standard library everywhere, and even if you file bugs or send patches to the library, it will take months before the changes have propagated to your self-building users.

It tempts to cheat the system. Surely, to round() a floating-point number should be pure? What if, in general, yes, it is pure, but only on one particular architecture, the library writes custom float-handling flags to the CPU, then rounds, then restores the old flags? Such assembler calls are the most impure building blocks of any function. Let us consider this hack to cast between pure and impure... Oh, some well-optimizing compiler doesn't like the hack 3 years down the road, and you get segfaults in unrelated-looking parts of the source.

It runs into rarely-used parts of your language. These parts tend to be particularly buggy and lack the necessary manpower. These parts are notoriously incompatible anytime you want to mix two features of the language.

Likely, at least one of these features was designed 15 years ago, and then software engineering theory has advanced, but the language is encrusted enough to stick with the old design.

Arg arg arg. This must be why people write their own toy languages all the time.

Crane: In your purity proposal, can you allow pointer dereferences to immutable external memory? Can Pascal guarantee that some object will never mutate? Typically, immutability and purity go hand-in-hand to make strong purity more usable.

-- Simon

Simon · « **Reply #176 on:** October 30, 2018, 04:47:24 PM »

Graphics card henchmen

The CPU is the criminal mastermind, capable of anything. But he must carefully delegate tasks that would take too long for him alone.

The graphics card is the mastermind's army of muscular thugs. If you can explain a task in simple terms, they're highly efficient at getting things done. These henchmen don't like drawing individual pixels on textures. But they can draw readily-prepared bitmaps with transparency, hundreds of them, in the blink of an eye.

Lemmings programming is special: Pixel-precise drawing on the graphics card's bitmaps is necessary, but, naively implemented, would be slow. Kitchen-sink libraries such as SDL2 or Allegro 5 have a hard time offering suitable abstractions for this. I'm already calling more specialized Allegro 5 routines for the graphics card's batch-processing of many small drawing operations. I can't shake the feeling that learning hands-on graphics card programming would immensely help my cause. But the Allegro 5 functions hit a sweet spot: It's fast enough and doesn't leave their abstractions (good because I rely on Allegro 5 bitmaps throughout).

Interface segregation

The interactive game has an effect manager: What sound effects should be played, what sound effects should not be played because they're merely from a recalculation of physics, what skill-highlighting arrows should pop up, etc.

The lixes need to know the effect manager to queue their sounds: Only the digger hitting steel can tell that a steel-hitting sound should be played. But lixes and physics should also run without interaction. Why should they depend on a class like EffectManager that is 95 % user interface bells and whistles? EffectManager doesn't affect physics at all.

Game with EffectManager	----depends-on---->	Physics
Physics	----depends-on---->	Game's EffectManager

The answer is to define the EffectManager's queuing interface, EffectSink, separately from its implementation. EffectSink is a part of the physics, and lixes know how to queue effects.

Game	----depends-on---->	EffectManager, Physics
EffectManager	----implements---->	EffectSink
Physics	----depends-on---->	EffectSink

This way, you have no circular dependencies in your program. Bonus points is that, now, you can define a NullEffectSink that auto-implements all EffectSink methods as empty methods -- a one-liner definition with the D standard library's BlackHole. Then, noninteractive replay verification gets passed a NullEffectSink and can unconditionally call its EffectSink instead of my old way of checking whether an optional EffectManager is really there (even with a special Optional library type, this was a nonzero effort at the call site). It's always nice whenever there is no need for null references.

Finding these abstractions is utmost joy.

This should really go into OO-with-Simon instead. Perhaps clarify the relation between Game and EffectManager, so it's clearer how either depends on physics.

-- Simon

ccexplore · « **Reply #177 on:** October 31, 2018, 06:29:01 AM »

Quote from: Simon on October 26, 2018, 11:24:40 AM

It tempts to cheat the system. Surely, to round() a floating-point number should be pure? What if, in general, yes, it is pure, but only on one particular architecture, the library writes custom float-handling flags to the CPU, then rounds, then restores the old flags? Such assembler calls are the most impure building blocks of any function.<snip>

In Crane's purity proposal that you link to, the focus there seems to be specifically about the function being deterministic such that same inputs always produce same outputs (and also that it's either side-effects free, or no one will take dependency on the side effect), so that for example you can precompute at compile time in some cases. It seems like you can assert something being deterministic separately from a definition of purity that is based on a function's implementation with respect to interactions with global states. So you could assert that round() is deterministic even if it might not be pure in some corner case, and may still reap a good portion of the benefits of doing so. Purity would imply deterministic, but you can assert something to be deterministic without being pure.

Simon · « **Reply #178 on:** November 08, 2018, 12:06:30 PM »

Quote from: ccexplore on October 31, 2018, 06:29:01 AM

Purity would imply deterministic, but you can assert something to be deterministic without being pure.

Right.

This is the idea behind compile-time function execution in D: You can execute nearly everything at compile time, even if it's not marked pure. The compiler will complain e.g. about I/O, but happily execute whatever it can, allocate memory for temporaries etc.

I'm not sure what the selling point behind D's pure keyword is then -- I presume it's some hint for the compiler that it should consider more ruthless optimization here.

C++ has constexpr to enable compile-time function execution. A very long keyword to type, very verbose if the headers are full of that.

I still believe that compilers should infer constexpr/const/immutable/pure/nothrow/@nogc etc., wherever they can. After all, they can check whether a keyword is allowed on a function. Only if we annotate the function explicitly, then the compiler should enforce the property.

-- Simon

Simon · « **Reply #179 on:** November 14, 2018, 05:08:31 PM »

Save-money coupons

The devil's contraption to waste everybody's time and money.

I was shopping at the supermarket. At another cashier, I observed two Asian students trying to redeem a voucher to save 1 Euro on toothpaste. This failed for some hard-to-understand reason. The students weren't 100 % up-to-speed with German either. Two extra clerks were called, and the customers behind waited for 4 minutes. That was longer than my entire wait and cash-out.

Let's summarize the disaster:
5 customers had to wait for 4 minutes = 20 minutes.
3 clerks busy for 4 minutes = 12 minutes.
2 other clerks interrupted from other work = 30 extra minutes to regain flow.
Already over an hour of lost time.
An hour is worth far more than the 1 Euro the coupon would have saved.

Cashback programs are similarly insidious: The clerk will ask everybody for their cashback card, that loses 3 seconds per customer even when no customer participates. The supermarket exchanges marketing data with the cashback firm. Nothing is free, the cashback customers are paying with their time and lost privacy.

For humanity's sake (the people around you), never participate in coupon programs or cashback programs that have even the slightest risk of slowing down public infrastructure. Coupons are less intrusive in online sales, but really, who cares about saving 1 Euro. Buy few things, but if you buy, buy high quality and don't mind small price differences.

-- Simon

namida · « **Reply #180 on:** November 14, 2018, 07:00:33 PM »

Quote

Nothing is free, the cashback customers are paying with their time and lost privacy.

I would question this in two ways - firstly, whether the sale will really be private in this day and age even without a loyalty / cashback card; and secondly, whether it's really that big a deal that some giant marketing firm who's never heard of you beyond as "customer #410757864530" knows which brand of toothpaste you buy.

I do however see the point in regards to it slowing down transactions. Stores here often handle this by allowing the customer to swipe their loyalty card while the cashier is ringing up their items, thus, no additional time is lost. Also, in my experience here from working in said stores in the past (which may not be the same in Europe), the majority of customers do tend to have these cards, although it's questionable how many ever bother to get the rewards (most customers are likely more interested in the additional, on-the-spot discounts - which can actually be quite significant, sometimes as much as $15 - $20 off a $100 order).

nin10doadict · « **Reply #181 on:** November 14, 2018, 10:37:48 PM »

Sometimes I go shopping with coupons in my pocket, forget they're there, and don't use them. The savings are nice but really not enough to merit me seeking them out; I just try to be frugal in other ways, such as keeping track of the prices of certain items and only buying them when the price drops. There are some cases where this is useful, because these items will always be marked as 'on sale' even when the price is high, so mentally tracking the price helps me determine when the so-called sale is actually real.

mobius · « **Reply #182 on:** November 15, 2018, 01:16:42 AM »

if you go out of your way to get or use a coupon (buying something you wouldn't have bought otherwise) then you're not saving anything. On the other hand if you use one that happens to fall into your lap (as sometimes happens) on something you were planning on buying anyway; it does save money, though a small amount. Over time it adds up if you're diligent with this method.

ccexplore · « **Reply #183 on:** November 15, 2018, 04:55:26 AM »

I sort of get what Simon's saying, but maybe it's a little disingenuous to pick the worst case example where the coupon isn't working; far fewer people would bother with coupons if they actually frequently break down like your example. It'll be kind of like applying a worst case example where the computer system has bad price information so barcode scanning an item simply on sale (ie. no coupon involved) did not result in the correct price, and then the junior clerk has to go get a more experienced clerk to sort out the mess. You can't exactly use that example to say the barcode scanning system is bad, unless it happens frequently.

I also always thought coupons are more the store's sneaky way to try to have their cake and eat it too. If they just simply put the item on sale for everyone, then everyone pays the same lower price (but yes, maybe it'll attract more people to buy in their store as opposed to some other place). But if they force you to cut out a coupon in order to get the lower price, at least some portion of people might not bother but still want to buy, and can then pay the higher price, while the truly price-conscious/obsessed people will take the extra time and feel good about getting the discount, and the store at least gets them to buy here as opposed to some other place. Yes, you lose a few people who'd reject both the higher price and the work needed to cut out the coupon, but maybe despite that, it still balances out in favor for the store?

Minim · « **Reply #184 on:** November 15, 2018, 08:53:49 AM »

This is right up my alley as I work as a cashier in my local supermarket. I feel your pain too as most of my regular customers suffer similar agonising waits as well.

Sometimes I have to ask a young-looking customer for their ID for any purchase of cigarettes or alcohol. 18 is the golden age for this, but annoyingly I have to follow the same rule for 16 year-olds buying Red Bull cans. On another day I sometimes need to ask for the same customer's ID presentation. It can infuriate them, particularly if they know me so well, so I only do this if managers are walking around, just in case they wag their finger at me.

Most customers buy fruit, vegetables and fresh bread without sticking a barcode sticker on them. The hard work has to be done by me to find the correct item on the system. The breads are most difficult because the pictures look so similar, especially the sourdoughs; And I can never tell a loaf from a crusty bread either. Anyway, afterwards, I sometimes have to weigh the product instead of add the quantity. (Sometimes the check weigh doesn't work, which consumes even more time)

As well as this, the system tells me to ask each customer for:

Their loyalty card. The main advantage for our shop is a free newspaper for £10 spent, including the paper. Some of our customers do, but some of them present me coupons before they show their loyalty card. If I try put coupons through the system before the loyalty card I get in trouble and need to ask a manager.
Cashback. This only comes up when customers place their debit card into the machine, instead of the simple contactless process. Some of our customers are fussy about how they would like their cashback, e.g. in coins.
Swipe their card: Some customers' cards don't work on our card machines. Sometimes this can be circumvented by me holding the card in, but after three failed attempts I swipe their card if there is a signature on the back of it. If there isn't then I have to ask the customer to pay with another card, or cash. (Sometime I ask them to use the cashpoint if they don't have cash, which fortunately isn't too fay away, but it's still an unnecessary waste of their time)

At the end of each transaction the receipt comes out, but occasionally another coupon comes out. Rather than feel guilty about not giving the customer the extra offer I always wait a few more seconds after the receipt prints off just to see if the additional offer will come out as well.

And that's all I can think of for now. Hope it's not too off-topic but it certainly feels like we're damaging our reputation with all these delays for these poor customers.

ccexplore · « **Reply #185 on:** November 15, 2018, 10:34:37 AM »

Interesting that in the UK you do barcodes for fresh produce. In the US I've never seen this so far, for fresh produce you (or more likely, the cashier) always have to do manual entry. On the other hand for things like meats and seafood, the butcher/fishmonger does apply the label with barcode as part of the process of weighing, cutting and packaging of the meat/seafood, so all you or the cashier has to do afterwards at checkout is to scan it.

In the US at least for the large corporate supermarkets, it seems there usually is a separate place in the store where you buy alcohols and cigarettes, you wouldn't even be dealing with those items in the regular checkout lines. [edit: actually now I think of it, that only applies to cigarettes and other tobacco products, not alcohol. I guess cashier would ask for ID on alcohol purchases. Kind of curious now what would happen with alcohol in the self checkout lanes.] Of course I imagine for smaller supermarkets the same cashier would handle regular and restricted items. Why does Red Bull require IDs in the UK? It isn't alcoholic AFAIK. In the US there is no legal regulation on caffeine AFAIK (certainly no federal regulations; state and local laws can in theory do this but I've never heard of it).

Simon · « **Reply #186 on:** November 15, 2018, 04:55:14 PM »

Quote from: namida

firstly, whether the sale will really be private in this day and age

Mostly yes, I pay cash for 90 % of my purchases.

Sweden: Customary to take bank cards for any bill, and people happily pay everything with that. Germany: Most places don't accept it unless the bill is 5 Euros. Thus cash is still popular.

Online purchases are a pain. The super-high-secure checkout sends unencrypted email afterwards.

Quote

whether it's really that big a deal that some giant marketing firm who's never heard of you beyond as "customer #410757864530" knows which brand of toothpaste you buy.

I thought cashback programs had you register with name? At least banks do. They'll keep this data in their super-high-secure datacenter, which falls prey to social engineering 3 years down the road. Or to an overworked maintenance programmer.

The main problem is that other people use cashback. That is the real time drain.

At my store, the cashback ad says:
Exchange your cashback points for vouchers!
200 points = voucher worth 2 Euros
500 points = voucher worth 5 Euros
1000 points = voucher worth 10 Euros
2000 points = voucher worth 20 Euros

Makes one wonder at how low a social level this list is aimed.

Also, calling the cashback point a "point" instead of 0.01 Euros. Who would swipe their card for 3 cents? Being unbothered must be worth more to even those people. But 3 points, sure, that's worth it! Numbers go up! Fun!

Quote from: nin10doadict

items will always be marked as 'on sale' even when the price is high

Hah, such simple technique, and I'm sure it works more often than it should. I haven't seen it conciously, but still sound advice.

Quote from: mobius

(most customers are likely more interested in the additional, on-the-spot discounts - which can actually be quite significant, sometimes as much as $15 - $20 off a $100 order).

Yes, I agree that this is a lot, and I would even let myself be bothered to get an extra 10 to 20 Euros. Saving 10 % is nice.

Quote from: mobius

on something you were planning on buying anyway; it does save money, though a small amount. Over time it adds up if you're diligent with this method.

I accept this. I'd say it costs too much time for the effort, and you risk end costing other people's time. If your experience is less annoying than mine, that's fine.

Quote from: ccexplore

it's a little disingenuous to pick the worst case example where the coupon isn't working;

It may be slightly over-the-top, but it's still representative, sadly. There are many other ways that produce excessive waits:

Old lady must be told several times that now is voucher/cashback time, then she digs in wallet for cashback card.
Person (even smart ones) forget to put vouchers on the counter until after the system seemingly-randomly expects vouchers to be entered. Transaction rollback is problematic, sometimes needing special keys or privileged members. (Also see Minim's post.)
Person wants to mix two types of voucher/cashback. How does it go? Ask the cashier risk other people's time? Memories of clashing features in computer programs come up. Even more memories of house rules in games come up that hook into the same event of the basic game and their interaction/timing is ill-defined.
The cashpack program has an annoying mascot that looks like on drugs, and it stares into your eye everywhere in the supermarket. By checkout time, I want to bite somebody's head off. I accept that this maybe doesn't apply to everybody. >_>;;

Every voucher/cashback program is one extra way how designers, over the years, manage to screw up every simple idea (buying at a physical store). The nastiness of these programs grows at O(n^2).

Quote from: ccexplore

You can't exactly use that example to say the barcode scanning system is bad, unless it happens frequently.

Barcode scanning is one alternative out of many mutually exclusive ways to register prices. It is far less error-prone. It's also ubiquitous and has grown bug-free. It doesn't collide with other cash-out-time stuff.

Coupons fail far more often. Certainly I accept that my specific failure is rare, but they can fail in many more ways, even if less time-consuming.

Quote from: Minim

Some of our customers do, but some of them present me coupons before they show their loyalty card. If I try put coupons through the system before the loyalty card I get in trouble and need to ask a manager.

This is beautiful.

I feel like all clerks should fail this step on purpose, every single time this ordering matters. The manager should be called every time. That is how nasty it is.

This really should have come up in user testing: Supermarket-manufacturing firms probably test their checkout processes on real clerks, providing fake customers with random such problematic cases.

The many kinds of different vouchers/cashback can't possibly be known at design time (when the supermarket-cashier-lane-manufacturer designs his cashier user interface), and no single voucher/cashback firm should be responsible to define all interactions with all other voucher/cashback firms. This is the main reason why vouchers/cashback are fundamentally flawed from a systems design point-of-view. Nobody can be made responsible for the mess. My hunch is then to cut such mess immediately from the design. (Of course my hunch won't make the marketers any money.)

Quote from: ccexplore

Why does Red Bull require IDs in the UK?

At least in Germany, there is only one age check for alcohol and tobacco at age 16. Hard liquor is locked behind glass doors and customers must ask a clerk to unlock.

Interesting that the UK introduces so many more more special rules.

-- Simon

namida · « **Reply #187 on:** November 15, 2018, 07:23:48 PM »

Quote

Mostly yes, I pay cash for 90 % of my purchases.

Sweden: Customary to take bank cards for any bill, and people happily pay everything with that. Germany: Most places don't accept it unless the bill is 5 Euros. Thus cash is still popular.

Interesting. It's quite different here; while credit cards sometimes do have a minimum spend (often in the region of $10 or so), debit cards generally do not, and many shops encourage customers to use debit cards rather than cash. Even without that encouragement, the general trend seems to be to prefer card here. I worked in supermarkets for a while in the past, and while cash was far from unheard of, card was definitely the more popular option - and I've heard this has only become even more the case since then.

It probably helps that fees are very minimal here. If you're happy to settle for a card that can only be used in NZ (or at certain international ATMs for a fee), it is possible to literally pay no fees - none on transactions, no monthly/yearly fees, I literally mean nothing at all. If you need online / international use of your card, you'll need a higher-tier card, but this still only costs in the region of $5 per year - and you can still avoid all the other fees.

Quote

I thought cashback programs had you register with name? At least banks do. They'll keep this data in their super-high-secure datacenter, which falls prey to social engineering 3 years down the road. Or to an overworked maintenance programmer.

Sure, but to them, "John Smith" is as meaningless as "customer #410757864530". They don't know who John Smith is, as such, just that a guy called John Smith (maybe "who lives at 123 Fake Street") buys lots of chocolate, or whatever. The worst they can do with this is send aforementioned John Smith advertisements for more chocolate. A minor annoyance, but I guess I kinda got over seeing it as being a huge deal. I guess after dealing with internet spam about "enlarge your penis!" and "buy [obscure prescription drug] cheap!", I'm not so bothered by offline ads that are at least somewhat relevant.

Now of course, there may be cases where anonymity is preferable. If you're buying, say, ingredients / equipment to grow / produce drugs, you probably don't want a record of that. But if you're simply buying bread, pasta and toothpaste, I really don't see how this is a big deal anymore.

ccexplore · « **Reply #188 on:** November 16, 2018, 11:01:31 AM »

One more thing I want to add, in the same vain as my earlier point how all this probably benefits the store more than the customers:

Yes, those things you mentioned waste everyone's time, but I think the store has much more capacity to absorb the extra times spent compared to individual customers, even when it comes to major issues like the example you cited. Because the store is pretty much never equally busy at all hours of day, extra time spent here and there will usually be balanced out by lulls elsewhere during the day. Also, it's probably comparatively rare that a customer who's already in line ready to pay will decide to give up the purchases altogether due to issues with someone in front of the line; in almost all cases they'll simply wait the extra time, very annoyed for sure, but ultimately the store does not lose the transaction from the customer.

Now yes, on a longer term basis, if a store consistently and frequently runs into these kinds of issues, some customers will definitely stop going to the store in preference for another place without such frequent issues, so it is still in the store's interest to minimize these kinds of issues. But beyond a certain threshold of "it doesn't happen often enough, or take up too much time or otherwise impact customers negatively", the store basically can absorb the occasional extra major time spent (and the more frequent little extra seconds here and there) with minimal risk of loss purchases or loss customer retention. And so there's no incentive from the store's perspective to get rid of the coupons or loyal programs or whatever, despite the inefficiencies they can introduce to the checkout process.

To put it differently: yes, what happened sucked for Simon. But will that rather unfortunate incident be enough to get even Simon to permanently boycott the store and shop elsewhere? I'm guessing no?

Proxima · « **Reply #189 on:** November 16, 2018, 01:15:46 PM »

We should perhaps also consider the collective time cost of the incident causing everyone to make all these posts about it

Simon · « **Reply #190 on:** November 27, 2018, 04:54:43 PM »

Right, I wouldn't boycott the store because of this one incident. Even though the store and the cashback program make money from this at the expense of customers' time, it's better for me to stay with this store than to walk anywhere further.

I enjoy the time spent ranting.

It may have been longer than the wait in the shop, but rants free the mind.

Let's all be merry and cheerful and in holiday mood! Cookies and tea for everybody's enjoyment. Cinnamon odor in the air. Red and golden ornaments. And animated tree gifs for everybody's homely nostalgic 90's website feelings.

How shall we be merry today? No focused rant about a single topic, but some small thoughts instead.

There is no widespread good Windows package manager. Most widespread is Steam, but that's closed-source malware and hard to get your software accepted. NuGet is promising, but who has heard of it? I bet that, were I to ship Lix with NuGet, everybody on the forum would still download Lix manually. You wouldn't want to install a package manager for one single application.

Chess world championship, they drew 12 games out of 12. I've only watched the 12th game on livestream. I didn't even pay attention to the scheduling; instead, I was hacking on my Lix release scripts to auto-build Win32, Win64, and Linux 64-bit. Still, the game commentary was exciting enough that I ditched my planned nap and drank 4 liters of tea instead.

Shogi (Japanese chess with flowery-named pieces such as odor cart) looks like a nice game, favoring romantic attacks even more. No more woodpushing to draw 12 out of 12, instead happy tactical king hunting every time!

Of course one would have to learn the kanji first, but let us assume that everybody can read the kanji easily. Even then, Shogi has massive UI problems.

Pieces should be colored by type. Piece ownership is indicated by pointing direction, but for this, the pieces should look much more triangular. Their existing obstuse arrow shape is almost rectangular. Some people have invented pieces that you can more easily recognize.

A possible approach, but these should be colored by type, and they should be much pointier.

But now, the roadblock is that this would never last beyond practice games. Even westerners easily memorize the kanji after a few games. Any tournaments would be played with the traditional pieces anyway. If one were to learn Shogi, one should use kanji pieces as early as possible, to reduce friction.

Compare the Shogi situation with Skat, a popular card game in Germany that is also played on a high level at tournaments. Here, the 4-color deck ("Turnierbild") has become tournament standard. It shows that some excellent UI improvements can overcome the hump of other people's accustomization to inferior standards.

40 years ago, in West Germany, 2-color French decks were standard, and in East Germany, the German deck with 4 completely different suits in 4 colors was standard. I believe that the Turnierbild has only gained enough traction because there was a need for a universal deck, and the Eastern Germans were already accustomed to 4-color decks. But anyway, the standard improved across Germany, which is what counts in the end.

Sadly, Turnierbild isn't used in Doppelkopf tournaments. At least my peer group at university played Doppelkopf exclusively with the 4-color Turnierbild.

In online gaming, you can choose your deck/pieces independently from what the opponents see on their machines. That's helpful to give less popular standards an opportunity to rise. All my UI considerations today are about offline games where everybody sees the same standardized playing material.

Ah, the some small thoughts became a UI rant again.

-- Simon

nin10doadict · « **Reply #191 on:** November 27, 2018, 05:14:00 PM »

You gave up your nap? Clearly you don't have enough pets. I have discovered that keeping the heat turned down low not only saves on the heating bill but encourages the pets to come and nap with me. Had an hour long nap yesterday because I had lost sleep Sunday night. Big Nubs actually crawled under the blankets with me, which he hardly ever does. Getting up from that nap was one of the hardest things I've ever had to do.

12/12 games drawn? I wonder how many of the 'draw game' rules they obey in the chess tournament. I would assume all of them, even the obscure ones like 'game is drawn if 50 turns pass with no captures or pawn movement' or 'game is drawn if the layout of the pieces is the exact same three separate times.' Keeping track of those without some sort of computer would be rather difficult, I think.

Proxima · « **Reply #192 on:** November 27, 2018, 05:58:02 PM »

Quote from: nin10doadict on November 27, 2018, 05:14:00 PM

12/12 games drawn? I wonder how many of the 'draw game' rules they obey in the chess tournament. I would assume all of them, even the obscure ones like 'game is drawn if 50 turns pass with no captures or pawn movement' or 'game is drawn if the layout of the pieces is the exact same three separate times.' Keeping track of those without some sort of computer would be rather difficult, I think.

The rules are actually: a draw may be claimed if 50 turns pass with no captures or pawn moves, or if the same position repeats three times. It's not automatic. Both are very rare in actual play; nearly all draws are by agreement. But these rules are part of the laws of chess, so they always apply.

Serious players are required to write down their moves, so it's easy to see when a 50-move situation is coming up, and for threefold repetition, the most likely situation is moving back and forth, not repeating a position from earlier in the game; captures would tend to prevent that.

(Although hilariously, there was a game where nothing was captured, and both sides' pawns got into a deadlock that prevented any progress. One player was stubborn and wouldn't agree a draw, and was confounded when his opponent successfully claimed one under the 50-move rule. I don't know who the players were; I found this game on Tim Krabbé's website that collects unusual games.)

Dullstar · « **Reply #193 on:** November 27, 2018, 06:20:32 PM »

I have mixed feelings about package managers. I've experimented with Linux in the past (though not so much recently), and one of the common frustrations I had was that the packages in the repositories were frequently out of date. But it's convenient for browsing for available software, and also convenient for automatic updates. One of my constant frustrations with NeoLemmix and Lix is updates.

ccexplore · « **Reply #194 on:** November 27, 2018, 11:37:49 PM »

Quote from: Simon on November 27, 2018, 04:54:43 PM

Shogi (Japanese chess with flowery-named pieces such as odor cart)

"odor cart": sounds like a bad translation perhaps? I believe with languages like Japanese if you attempt to only translate individual Kanji characters in isolation and ignoring contexts, you can sometimes end up with results that have almost nothing to do with the actual words or phrase in question. Also, doesn't some Kanji characters have multiple very different meanings (almost like homophones but actually written exactly the same way as well?). Do we know if "odor cart" isn't just creative cherry-picking on a particular reading of the Kanji in question, even though it isn't actually the intended/correct reading being used wrt the name of that particular Shogi piece?

Quote

Pieces should be colored by type. Piece ownership is indicated by pointing direction, but for this, the pieces should look much more triangular. Their existing obstuse arrow shape is almost rectangular. Some people have invented pieces that you can more easily recognize.

I went to wikipedia article for Shogi, and within the first sentence where it also mentions other chess-like variants in Asia with links to respective articles, I clicked through all of them and they all do use different colors to denote sides. Japanese Shogi seems unique in not using colors to differentiate sides.

That being said, if you can actually read Kanji, I think perhaps it's sufficient to tell that some piece's Kanji are upside down from your POV, and therefore not your side? I do agree though, a more prominent visual way to denote sides would seem preferable, especially for spectators.

On the other hand, none of the variants used different colors for different types (if by "type" you mean like pawns vs kings or whatever their equivalents are in Shogi). Then again, neither does Western chess, although in that case the types differ by shape. It seems for the Asian variants listed in Wikipedia, they either use different shapes for types, or else I guess the difference in Kanji is sufficient for the variants where Kanji are used on the pieces to denote types.

Proxima · « **Reply #195 on:** November 28, 2018, 12:29:49 AM »

Quote from: ccexplore on November 27, 2018, 11:37:49 PM

"odor cart": sounds like a bad translation perhaps? I believe with languages like Japanese if you attempt to only translate individual Kanji characters in isolation and ignoring contexts, you can sometimes end up with results that have almost nothing to do with the actual words or phrase in question. Also, doesn't some Kanji characters have multiple very different meanings (almost like homophones but actually written exactly the same way as well?). Do we know if "odor cart" isn't just creative cherry-picking on a particular reading of the Kanji in question, even though it isn't actually the intended/correct reading being used wrt the name of that particular Shogi piece?

It's just Simon poking fun at the weird way the Japanese language works. 香車 means "incense chariot", but 香 by itself can mean "smell".

ccexplore · « **Reply #196 on:** November 28, 2018, 12:57:41 AM »

Ah okay, so cherry-picking it is.

Unclear from OP whether it was tongue-in-cheek vs serious.

ccexplore · « **Reply #197 on:** November 28, 2018, 05:29:28 AM »

Quote

Pieces should be colored by type.

I'm actually a little surprised by this. Wouldn't having actually different shapes like Western chess pieces do, be even clearer for telling apart piece types?

Is the color by type idea mainly to compensate for having to recognize Kanjis? The pictorial approach seems mostly sufficient to me without also having different colors, though maybe the pictures used could be slightly better in some cases.

Simon · « **Reply #198 on:** November 29, 2018, 05:26:38 PM »

Quote

You gave up your nap? Clearly you don't have enough pets.

Yeah, I should not sacrifice naps. Watching the chess championship was a rare exception. In general, I shun television and try to avoid whatever imposes similar artifical schedules on my life.

Pets cost a lot of time. >_>;; I have too many hobbies already and pets are like an extra hobby.

I admit that I have gedankenexperimented with an African porcupine as a pet. Must build lots of mutual trust before you can safely cuddle.

Quote from: Dullstar

frustrations I had was that the packages in the repositories were frequently out of date.

Yes, I had the same frustration in Debian. It's slightly better in Ubuntu. But for two years now, I've been very happy with Arch's rolling releases to stay cutting-edge.

Quote from: Dullstar

constant frustrations with NeoLemmix and Lix is updates.

Right, this is the main problem.

Probably, many Windows people shun updates because they're so hard unless automated.

I shun installing new software that I don't clearly need, but I want to update the software that I decide to install.

Quote from: Proxima on November 28, 2018, 12:29:49 AM

Quote from: ccexplore on November 27, 2018, 11:37:49 PM
"odor cart": sounds like a bad translation perhaps?
attempt to only translate individual Kanji characters in isolation
results that have almost nothing to do with the actual words
It's just Simon poking fun at the weird way the Japanese language works. 香車 means "incense chariot", but 香 by itself can mean "smell".

Right. "Odor cart" came from a friend, he translated the kanjis separately. Even with the correct translation "incense chariot", it's still a flowery name for my taste -- incense has little to do with war, the theme of chess-likes.

Well, same criticism applies to bishop from chess.

Both stabs were intended: The floweriness of the name, and how Japanese connects unrelated kanji to give every single one a different meaning.

Quote from: ccexplore on November 28, 2018, 05:29:28 AM

Quote
Pieces should be colored by type.
Wouldn't having actually different shapes like Western chess pieces do, be even clearer for telling apart piece types?

Two Shogi rules:

When you capture a piece, the captured piece goes to your personal reserve. You may drop these pieces under your control back onto the board.
When your piece moves far enough ahead, you may promote the piece, i.e., replace it with a more powerful piece after its move. Already-promoted pieces cannot promote again. Promotion is permanent until the piece is captured; then, its unpromoted type goes to the opponent's reserve.

This restricts the physical design. Standard design here is two-faced pieces with a pointy side. To show control, orient the piece to point away from its controller. To show promotion, flip the piece bottom-side-up, revealing the kanjis for the promoted type on the original piece's bottom side.

Color-coding by player is not feasible with two-faced pieces because color cannot change during capture.

Shape-coding by type is hard because the piece must rest physically stable on the game board when flipped. Maybe design 3-D shapes that are merely ((2-D shape per type) x unit interval).

Or design a four-faced piece (e.g., some variant of a cube) to have symbols for all four states: player A or B, unpromoted or promoted. But hm, that object will probably show too many faces on its left/right outer sides by accident when it's not meticulously aligned straight...

Quote from: ccexplore

Is the color by type idea mainly to compensate for having to recognize Kanjis? The pictorial approach seems mostly sufficient to me without also having different colors, though maybe the pictures used could be slightly better in some cases.

I'm concerned about understanding the board at a glance. Chess, Shogi, Go, ..., they're all about pattern recognition. Anything that makes glancing hard strikes me as contrary to the game design.

Letters, and thus kanji, are harder to recognize than symbols or shapes.

Colors alone can already be problematic (color blindness, weak conventions for the meanings). Colors are best to further differentiate shapes. It's best when there is only a handful of different types to distinguish:

-- Simon

nin10doadict · « **Reply #199 on:** November 29, 2018, 08:42:45 PM »

Pets are expensive and time consuming, yes. They are nice but they are a big commitment.

As an avid Tetris Attack player, I will say that color is the main way you will differentiate the blocks in your mind when you get good at the game. The fact that there are only 4 different shades of gray in the GameBoy version makes it much harder to play, as they had to try to differentiate the blocks more by redesigning the patterns on them.
I do wonder if play would suffer if we had different color blocks but they were all the same shape? Without any way to test it myself I can't say for sure, but I think it might.

I was unaware that captured pieces could be used by the player that took them in Shogi. Neat idea, but indeed restrictive to the piece design.