Simon blogs

[Simon]

87 kg after one month. (Goal weight is 80 kg by end of year. Donation to Lemmings Forums hosting will be 1 euro per 100 g over 78 kg.)

Link dump

Duke Nukem 2 is a classic DOS platformer where you blow up stuff ("Duke... You have destroyed everything. Excellent!"), enjoy grammar on which Proxima and I didn't agree ("It is the strongest of any weapon!" while I insist that this must be written "It is the strongest of all weapons!") and enjoy graphics ripped from Turrican.

To sort items by rating, don't sort by average (bad when an item has few votes), and don't sort by absolute difference either (bad when an item has many votes). Sort by the statistically lowest-plausible score by admitting larger variance when an item has only a few ratings.

The collection of "page is under construction" gifs contains some gifs with Lemmings. Can you find them?

-- Simon

[namida]

("It is the strongest of any weapon!" while I insist that this must be written "It is the strongest of all weapons!")

I suggest a quick read into descriptive vs prescriptive in linguistics.

[Dullstar]

Personally, I would consider both to be correct. If I were forced to choose one I would probably go with the "all weapons" version instead of the "any weapon" version, but I would not cite grammar as the reason for choosing it. You could also just say that "It is the strongest weapon" if you want to be concise. You could also go with something like "It is the strongest weapon in existence" or something along those lines. Really, the meaning is the same between all the variants, and it's just a matter of personal preference.

[Simon]

86.5 kg after the second month. It's the slowest of any diet.

"It is the strongest of any weapon!", in a strict sense, I still feel like that's the wrongest in all grammars, at least there are much clearer phrasings. But I accept that "any" is special in English and will bend the phrase to mean what (is closest to the original phrase) and (still fits the type system). Since a weapon -- in a computer game where we cannot combine weapons -- cannot be the strongest weapon of a weapon, "any" will bend to the closest meaning: The weapon is the strongest overall.

Counterexamples: "The skin is the biggest (organ) of any human." or "Number 1 is the smallest of any standard six-sided die." In each of these, "any" has no reason to bend, but will merely mean what it means in colloquial mathematics: "For all six-sided standard dice, number 1 is the smallest."

"It is the strongest weapon.", very nice. This is the best.



Game of Skill

We have a singleplayer game. We can play it randomly, or we can strategize and plan and find optimal moves as often as possible. It's possible to apply skill to nearly any move during the course of the game. If we strategize consistently, our chance to win is 20 times higher than when playing randomly. Is it a game of skill?

My intuitive answer is yes.

Another view is that the relative impact of strategy (20x) doesn't matter, only the absolute impact. E.g., to quote Morehead and Mott-Smith from The Complete Book of Solitaire and Patience: No game that has a slight chance of being won -- say worse than one chance in ten -- can be a game of skill, because the choices will not have sufficient effect on the outcome.

There is lots of wisdom here. We should value our limited time.

-- Simon

[Simon]

I worked the past Saturday. Peaceful refactoring evening, no collegue will ever interrupt by calling. (Probably never. You can't be sure in software development.) The type system is your trusty friend late at night. Feature is now ready for a smoke test on Monday morning.

To compensate, I spent the Sunday outside. Nobody from the group of university friends had time today, and I took a two-hour walk in the forests alone.

I want to play more Zendo in reallife. The physical pyramids have a certain attraction that words or drawn pictures don't have. Maybe it's nostalgy for 2014 and 2015 when I played Zendo excessively with university friends.

I bought a kilogram of honeycomb. Quality Brötchen topping.

I tend to take days off work in small chunks. There won't be time in 2021 for a full week off that I could pour into any single hobby. All hobbies will proceed slowly. Lix is still cooking. Eventually, I'll post updates in End-of-singleplayer screen.

-- Simon

[WillLem]

I bought a kilogram of honeycomb. Quality Brötchen topping.

Mmm nice! Is this similar to a Crunchie?

Regarding the diet: weight does not always equal health status. However, it seems to me like the choices you're making to reach your goal weight are all improving your overall health also, which is great

[Simon]

86 kg after 3 months. We're not getting anywhere, are we.

I still eat too much and exercise too little. Let's see. Right, weight is largely a matter of how much you eat, not necessarily correlated with fitness.



Brötchen are German bread rolls that you cut in half, then top with butter and sausage/cheese/... For images, see my post Brötchen in Mobi's blog and Icho's wonderfully adequate praise of Mettbrötchen in Mobi's blog.

Honeycomb is what it literally means: The waxen structure by bees, filled with honey. You can eat honeycomb, no problem, and it's become my favorite way to have honey. Honey or jam are best on lighter Brötchen.

-- Simon

[mobius]

do you go for walks/jogs/biking anything like that? Forgot part of your post before writing this. I do that once on a roughly weekly basis. I sort of gotten addicted. If I miss just one week; I really miss my hike. I love being out in nature and getting the exercise.  Besides the exercise it's also a great way to think and brainstorm if you're alone or even with someone else.

Never had honeycomb but I am curious. I love honey but rarely have a use for it. Oatmeal is about the only thing I use it for. I don't put sugar in coffee or tea. ....I haven't eaten oatmeal in a while and I like it. I should get back into that.

[Simon]

87 kg a month before the end of the bet. This will be a wholesome donation for LF.

Sleeping rhythm is botched from complex git merging at work that riffled across way too many repositories. geoo asked me via PM tonight why I was up at such unholy times; this merge was the biggest reason.

I haven't been active here much in the past 1-2 months. I've lurked a lot. Many smaller non-Lemmings projects have come together, and are still coming together. It's always tempting to let projects sit at 80 % once all the thinking is done. But pushing projects to 100 % is healthy: You'll get the sweet, sweet peace of mind.

Lix is getting 16 in April 2022, sweet sweet sixteen. And still no end in sight! I'll write the roadmap later in 2021.

-- Simon



Split off the Baba discussion into the Baba Is You thread.

[Simon]

Thinking

Mathematicians, scientists, puzzle fans, chess players, ... are supposed to be good thinkers. What does it mean: To think?

I conjecture:

Thinking is waiting for a good idea to arise. This activity takes little effort; instead, it takes experience and intuition in your area of work.

Thinking hard means focussing on how good partial solutions work or do not work towards a full solution. The effort here is in blocking area-unrelated thoughts. One way to achieve this is to mentally grind the already-categorized work again and again. Another way is to force yourself away from distractions.

I'll state this once more, because it's the main point of this conjecture. The effort during thinking hard is not spent by grinding the brain against the new work. Thinking hard means spending effort on unrelated or already-done related things, keeping them out/in mind, to let the brain think in peace, to give the brain the best conditions for the effortless generation of ideas.

You can spend further effort on preparation: Sleeping well, eating healthy, providing caffeine, ..., it all comes down to making it nice for the damn uptight brain to do what it does effortlessly, if it so wants.

-- Simon

[WillLem]

Thinking

Mathematicians, scientists, puzzle fans, chess players, ... are supposed to be good thinkers. What does it mean: To think?

Given the philosophical nature of this question, I'm surprised that you didn't include "philosophers" on this list

I'd also add artists (musicians included in that term), since a lot of making art involves thinking and problem solving; most creative processes essentially involve a series of decisions, some of which are in response to problems that arise during the process itself.

Also, that way, I can be included on this list - I'm certainly not a mathematician or a scientist; I enjoy puzzles, but only ones I can solve so I probably wouldn't call myself a "fan"; my chess skills are probably average at best, although again I do enjoy an occasional game. So, when it comes to thinking I'm much more of an artistic and philosophical thinker; I'm interested in questions more than answers, and exploration more than destination.

It's interesting that you posit a definition of "hard thinking." I'm not sure I entirely understand the difference here... for me, I'm either focusing on something properly or I'm not. I would consider "hard" thinking (by your definion) to be part of the same process, albeit perhaps further into it should it need to be extended or intensified for any reason.

Interesting topic!

[Simon]

you didn't include "philosophers" on this list

I didn't include software engineers either.

Hmmm... why is your first reaction that you want to be included in a list of stereotypes of who are merely supposed to be good thinkers rather than be a good thinker?

add artists (musicians included in that term)

Yes, most likely the same process.



Bettings Ends

84.7 kg before breakfast. For 5 weeks, I got lots of sleep and didn't overeat.

I'll call it here. Donation for LF hosting will be 67 Euros at the promised rate of 1 Euro per 100 g over 78 kg.

-- Simon

[mobius]

This stimulates my thought to a question; I wonder if anyone else has these feelings;

When thinking very hard, particularly, or most noticeably for me, at least, on a logical type of problem/puzzle, I know for certain when I'm in a deep state of though/concentration and when there is in fact 'something to' the problem I'm trying to solve. A good example of such a problem here is a puzzle that I don't know is solvable or not like some random Cheapo Level I come across . This is very difficult to describe but I'll try anyways;
Solving a complex logical puzzle requires memory and ordering items around in your mental space. Something I love a lot but always struggled with. But I honestly feel a distinct mental feeling when this takes place. Almost a 'physical' feeling but that word may be misleading here.* And its so satisfying when you figure out something complex like this and see it to completion.

I feel a similar albeit quite different feeling when creating artistically. Though with video games or music the same Eureka feeling can happen, I think the memory part is very different (or non-existent). For me when creating it often involves starting by mushing random things together or going over practice routines and then veering off into randomness or unknown territory. Eventually you hit upon something that strikes your fancy and you follow it to more interesting things. I don't think much memory is required here (at least in the logical sense I use above, different from other types of memory, obviously memory of your routine or skills is needed etc.) But idk; correct me if this is patently wrong.

*The better I get to know my mind and how it words the more I've noticed and have been able to detect these different discrete types of mental feelings. That is when I'm not dead tired, which is most of the time because of my job >_>

[Simon]

Killing a Rule

When a rule (e.g., in a tournament ruleset for a game, in a programming style guide, in real-world law, ...) isn't pulling its weight, remove it. Users will have a much easier time to focus on the real work, or on the meat of the game. Also, the rules that matter will be easier to follow, and they stand out better in the rulebook.

Problem: In the committee for maintaining the rules, it's tough to flat-out abolish a rule. People are happy to change rules, add rules, ..., but it's harder to abolish one. Surely, they think, the rule must have served some purpose ages ago (usually, yes, but was it worth it?), and the cost-benefit-ratio must have been good ages ago (less often so, this statement often lacks proof), so the committee should salvage the spirit (but why, given the rule sucks today?). And sunk-cost fallacy hits: We wrote the rule down, we can't cut it without replacement.

For example, if your committee has 5 members, of which 4 prefer the flat-out cut and 1 wants to keep it, it's tempting to put in compromises that nobody wants in that exact form, just to finish the discussion. I'm sure that this is the source of a lot of rules garbage in real life.

Takeaway: When you enter a committee, be careful not to introduce junk rules. Don't expect that it's okay to make mistakes and that others will clean it up when it sucks. Future committee members will have a surprisingly hard time killing the junk.

It would have been much harder to cut the player-variable spawn interval a.k.a. release rate from Lix in a committee. VSI had nonzero benefit and still sparks debate.

Split off: Loap, Coarse-grained Spawn Interval



Stuff that one finds on the internet:

Lovely 2012 music CD cover

-- Simon

[Simon]

Wisdom from the ages

When you serialize information, build into the format some amount of redundancy. Not too much, but not too little. Here's an example.

In v1 of the networking protocol, the server sends to the client a single packet to describe several Foos at once.

Header (8 bytes)
Foo #0 (32 bytes)
Foo #1 (32 bytes)
Foo #2 (32 bytes)

...for a total packet length of 104 bytes about 3 Foos. When there are 4 Foos, we'll send 136 bytes, when there are 5 Foos, we'll send 168 bytes, and so on. One header per packet, followed by the Foos.

When the v1 client receives the packet, let's assume he knows only the length of the payload. To deduce the number of Foos in the packet, the client will deduct 8 from the length for the header, and divide the remaining number of bytes by 32. Very nice.

Now, in v2 of the networking protocol, it turns out that the Foos gained another special feature, let's call it X. Feature X is optional, Foo works with or without it in v2. We don't want to cramp X into the existing 32 bytes; instead, we decide to send 40 bytes per Foo with X.

Header (8 bytes)
FooX #0 (40 bytes = 32 for the old Foo + 8 for X)
FooX #1 (40 bytes = 32 for the old Foo + 8 for X)
FooX #2 (40 bytes = 32 for the old Foo + 8 for X)

The server happily sends out v2 to the newly updated clients that understand Foo with X.

Naively, you can't send these packets to a v1 client. If a v1 client gets a packet of length 88 with two FooX, he will deduct 8 for the header, and then decide that 80 isn't divisible by 32. Even if he doggedly interprets the bytes starting at offset 8 correctly as Foo #0, he will misinterpret the bytes at offset 8+32 as Foo #1 even though Foo #1 starts at offset 8+40.

Even worse: When you send a packet with 4 FooX to a v1 client, he'll be thoroughly confused because the packet length of 168 bytes makes complete sense to him. He'll divide 160 by 32, interprets it as 5 Foos, and won't even notice the problem from the packet length.

For the v1 clients, there are three possibilities in this new world where all the cool kids are doing X, but they're still happy with the X-less Foo:

• Don't allow v1 clients on the v2 server.
  
• Write extra decisions into the server to send v1 packets to v1 clients and v2 packets to v2 clients, and also take care to interpret packets coming from v1 clients one way, and v2 packets another way. Lots of extra code in the server. Who's up for long nights of romantic object-oriented refactoring?
  
• When you write the v1 server, anticipate the need for growing Foo in v2 six years down the road. Don't make the clients rely purely on the division by a previously agreed struct length. Already in v1, write the length per Foo into the header. This way, clients (both v1 and v2) can receive the v2 FooX packets correctly: Both deduct 8 for the header, then iterate the remaining bytes by the stated length of FooX, 40, and interpret the first 32 bytes correctly as Foo #0. The v2 clients will know, in addition, what to do with the following 8 bytes for X #0. The v1 clients will cleanly discard those 8 bytes before starting to interpret Foo #1.
  

Instead of writing the length of a transmitted Foo, you can also write the number of Foo, assuming the receiver knows the total packet length and will then divide. Either allows the clients to deduce the other from the total packet length. For the recipient, I feel it's easier when he's told the length per Foo.

I'm sure there are more related ideas in network serialization, but this one is particularly annoying and enlightening in hindsight. It's more natural to anticipate this when you've designed binary file formats in the past. I've always avoided inventing binary file formats and it shows in the networking packet design.

The art in protocol or format design, as in code design, is to anticipate the most likely change, and keep the design open to changes in that direction. It's okay if most other changes are hard and need more code.

--  Simon