fjfaase

An interesting article about parsing techniques that were developed half a century ago when there were still severe memory limitations. It would be nice if it at least would mention that these techniques were developed because back-tracking was not considered as a valid option for parsing, because it was simply not feasible to store a whole file in memory. Nowadays the whole source code of the linux kernel easily fits in RAM.

For many applications, using a back-tracking parser with some memorization/caching, is feasible. IParse Studio [1] is an example of an interpretting parser that parses a grammar and an input at each change on the input and demonstrates that it works for rather complex grammars [2] on realistic input [3].

[1] https://fransfaase.github.io/MCH2022ParserWorkshop/IParseStu... [2] https://fransfaase.github.io/MCH2022ParserWorkshop/C_grammar... [3] https://fransfaase.github.io/MCH2022ParserWorkshop/scan_pc.t...

The example ignores the fact that pinmode is not just an initialization kind of method that you need to call once, but that there examples where you have to use it in the 'loop'. The most common is the bidirectional serial communication over a single wire, as is used with the DHT22 digital temperature and humidity sensor.

Original scientific paper: https://www.pnas.org/doi/10.1073/pnas.2216268120

This implies that the Mayan must have been recording the positions of the planets with great accuracy over a rather long period of time, probably spanning several generations.

I saw Koyaanisqatsi in the theater when it was released in the Netherlands (june 1984).

If they would have cared about civilian casualties, they should not have started the invasion of Ukraine in the first place. They had zero legit reasons to start it in the first place.

chatbot like chatGPT, which when I tried it just now, has been showing three blinking dots as a reply to a short question for some minutes now.

I am not sure what is harder: learn separate characters for words or learn the correct spelling for words? Especially with English where there is a big gap between spelling and pronouciation, learning the correct spelling for words takes a lot of memorization effort.

The fact that many adult cannot spell 100% correctly, proves that spelling is difficult.

Writing a language is always harder than reading. Many people rely on muscle memory when writing words. It might be that this works better for writing chinese characters than for words, which is more likely to fail when words contain multiple instances of characters.

It might also be the case that the number of strokes needed to write an average characters is about the same as writing an average word.

I am a bit surprised about the number of 'unknowns' in the data for my mother toungue (Dutch) [1]. Are these still open questions with respect to the Dutch language or is it simply that no expert on Dutch grammar has been asked to contribute.

[1] https://grambank.clld.org/languages/dutc1256

Would be interesting to see how fictional/constructed languages compare to the collected data.

The main problem with humanity is the lack of wisdom, not the lack of progress. Discovering something is nice, but if you are not able to handle it, it is of no use. When antibiotics were discovered, it made a great improvement on health of people. But instead of using it in a wise way, it was grossly overused, resulting in widespread resistance, slowly undoing all it positive effects. And that is how it basically has gone with every discovery.

Funny little language. I used it in an exercise for the a workshop I gave at MCH2022 called 'Workshop: A practical approach to parsing' [1]. My solution can be found at GitHub [2] and can be used with IParseStudio [3] to execute programs written in Tabloid using the build-in interpreter.

[1]: https://fransfaase.github.io/MCH2022ParserWorkshop/ [2]: https://github.com/FransFaase/MCH2022ParserWorkshop/blob/mai... [3]: https://fransfaase.github.io/MCH2022ParserWorkshop/IParseStu...

Bert Hubert has an interesting idea about the reasons for interons. He explains this in his talk 'DNA: More Greatest Hits (SHA2017)' The interesting bit, with some introduction, starts at: https://youtu.be/rCdhsN--Mdo?t=1440

This is a follow-up talk to his talk: 'DNA: The Code of Life' https://www.youtube.com/watch?v=EcGM_cNzQmE

I do like the npf_pprintf function with a call-back that is called for each outputted character. It would have been nice to have such a function in the C standard.

Even beter would be an interator interface, that gives you the next character each time it is called.

I just noticed that some of the tiles need to be placed up-side down. In a strict sense it consists of two tiles that eachother mirror.

I feel this article is not very balanced. It does not mention that having a colonoscopy is not without risks (perforation is 1 in 2000) and could potentially lead to death (3 in 100,000) [0]. Combining this with the high false positive rate of stool-based tests puts you in a complex situation when you do get a positive outcome of these.

[0] https://en.wikipedia.org/wiki/Colonoscopy#Risks

VB6 is often underrated as a programming language, but it did have some neat things that are still not present in existing programming languages. (They were dropped in VB.NET.) In a sense VB6 is still ahead of its time.

One is the transparent intergration with COM objects, allowing you to access objects in another process (possibly from a different executable) in exactly the same way as in-process object. All the marshalling is done under the hood. The only problem with this is that the execution of a single statement could be intermixed with another statement in another thread. I once had to deal with a nasty bug that was obscured by this fact, which was actually caused by using a programming mistake where someone had used a global variable for something that should have been a method argument.

The other is the very nice event mechanism where there is no need to (un)register event handlers. They are automatically registered and unregistered. Very powerful mechanism that I started to use more and more the longer I worked with VB6.

I do not know of a simple example, but I have heard there are some example in the C++ grammar where the look-a-head can be as large as possible. Parsers for C(C++) are often not purely grammatical, but also keep a symbol table to resolve these problems. For example, the statement 'a * b;' can either be type definition or a multiplication (with no result) depending on whether 'a' is a type or a variable. Note that in C++ it is possible to defined an *-operator with a side effect.

Interesting approach. Maybe it is even better to first start with a back-tracking parser. Although back-tracking has the reputation of being slow, there is a rather straightforward mapping from grammar to functions. Although it is slower than traditional parsing techniques, it is fast enough for many practical applications.

One easy trick to optimize back-tracking is memoization.

Another is the left-recursion into right-recursion trick, which is also rather straightforward to apply.

These two tricks are used in IParse Studio [0] which is an interpreting parser that parses a grammar and uses that grammar to parse some input. I also can help you with rewriting the grammar using the described approach.

[0] https://fransfaase.github.io/MCH2022ParserWorkshop/IParseStu...

The mathematics in this article looks not all that complex. From the little that I understand about it, it is not a direct proof that the equations are stable, but that it is based on a definition of enthropy and a stochastic argument. That argument gives good reasons to assume that the equations are smooth, but I wonder if it proofs that it is smooth in all cases. In this regard, it is interesting to note that in a recent paper [0] it was shown that Euler equations (a simpler system than the Navier-Stokes equations) might be instable.

[0] https://www.wired.com/story/a-new-computer-proof-blows-up-ce...

Functional is a good way to 'specify' how a certain calculation/change has to be performed. When working with distributed systems with multiple actors making changes, you have to treat the whole system (distribute database) as a single value on which your functions operate. Then you can use the commutative properties of function to implement transactions. (If two operations on the system commute, they can be applied in either order on the system, to result in the same state.)

But from such a specifying approach to a working system, is a long way.

I once had to implement Arabic support in an existing editor. It also had to support mixed RTL and LTR input. Interesting to see how the cursors walks differently through the text when going going forward and backwards and how text selection works. Most document editors (MS Word, Libre Office with CTL, for example) and browsers implement this correcly as well. So, you can just compare if a text is displayed correctly by comparing how it looks in a document editor or a text box in an HTML file.

This has been discussed before: https://news.ycombinator.com/item?id=27890790

Interesting exposition about how to use Exact Cover to solve a Sudoku. But in case a sudoku has one solution, it is possible to solve it by reducing the exact cover. For example, if you have a column that is a true subset of another column (with respect to the 1-s) you can remove all the rows that have a 1 in the row with the larger number, because these rows can never be selected.

Also when solving an Exact Cover there are some (rather simple) strategies that can improve the speed of finding solutions.

I used Exact Covers a lot for solving all kinds of puzzles (most of them far more complicated than Sudoku's). See: https://www.iwriteiam.nl/Dpuzzle.html#EC for a list of blogs I wrote over the time.

Just a few days ago there was a mentioning of the source code being published: https://news.ycombinator.com/item?id=34801636

When as a human player, you learn to play go, there are a number of concepts you have to grasp. It starts with understanding when how a group of stones can be captured. Next you have to learn when a group of stones is dead or alive. And there are all sorts of complexities in this (like ko-fights). And the next thing you have to learn is aji (taste in Japanese), which is also a lot about potential. A group does not need to have a defined life or death state, if it has some potential to become alive or able to escape and connect to stones that are alive. At an even higher level, you need to understand learn to view the balance of the whole board, grasping what is urgent and/or important. This is something many amateur Dan players wrestle with.

Now when professional Go players were defeated by AIs, it looked like these AIs mastered all those concepts. They excelled at playing a very balanced game, came up with very creative moves that had excellent aji, avoided bad aji. But now the adversary strategy, which can be explained in a few sentences to every Dan level amateur player, reveals that the AIs do not even have a good understanding of life and death. They fall for 'trick' moves that even I, a weak amateur (about 10k) player would have how to defend myself against. If you see some of the final boards, it almost looks the kind of outcomes you would see for players at my level.

The interesting thing is that the adversarial strategy can be explained in a few sentences to any amateur Dan level player in a sufficient manner to use it successfully, assuming to be sufficiently strong.

When learning to play Go, you go to a number of steps, where sometimes you have to unlearn something you learned in a previous step. I am a weak amateur player (around 10k) and I only have a vague idea about aji (taste in Japanese) and no idea what good aji and bad aji is. I even don't master life and death. When AIs started to beat professional Go players, it seemed that they had a good understanding of aji, because they created good aji and avoided bad aji. They also played a very balanced game, overseeing the whole board, something that non-professional players often fail to do, and now the adversary strategy reveals that the AIs do not even have a good understanding of life and death and even fall for 'tricks' that I would have been able to counter.

True, one AI was used to found a weakness in another AI. But then it turned out that the weakness could easily be used to defeat that the AI by a strong amateur level player. 6 Dan amateur is about 1 Dan professional, realizing that Lee Sedol was a 9 Dan professional player. I guess that many amateur Dan players can master the weakness. It also seems to shows that the AI does not have the 'deep understanding' of Go as it was thought to have to be able to beat the top professional players. We might be still a long way away from an AI that truly understand the game. And if this is true for one game, it might also be the case for many other AIs. The road to General Intelligence might still be a long road.

It looks like this shows that GO AI does not have the 'deep understanding' of Go as it was thought to have. It seems that many amateurs Go players can learn the tricks to exploit these weaknesses.

In some sense it is more sensational than Lee Sedol beating AlphaGo, because it shows that Go is not yet beaten by AI and that this is only the true start of the battle between humans and AI with respect to Go.