That implementation of the max(A, X) operator that is described in the article is very clever. Obviously not super practical, since it needs to allocate one specific zeropage location for it to work ($8A), but that type of requirement is pretty typical for lovely tricks like this one! And the beauty here is in the trick, not whether or not there may be some practical application of it.
But this also raises the question: is there some clever way to use the undocumented SAX instruction, which does an AND between the A and the X registers, to achieve something similar? There is and old trick to compute min and max using no branches, which is not immediately applicable (https://graphics.stanford.edu/~seander/bithacks.html#Integer...) - but maybe there is some other trick hiding in there?
This may seem like a minor nit, but I think there is a problem with using the term "unreliable" to describe UDP. The more commonly used term, and IMHO better term, is "best-effort" [1]. UDP makes its best effort to deliver the datagrams, but the datagrams may be dropped anyway. But it does not make UDP inherently unreliable.
As a fellow Swede: having grown up in northern Sweden, I have both heard of this, and have personally witnessed cheese especially made for this practice in regular stores, but I have never tried it myself.
I'm not sure it is necessary for the author also post the link to the tweet that referred to the tumblr post, since the tumblr post is where the actual proof is.
According to the article, they built a total of 1574 planes. This number happens to be equal to 2 * 787. The significance of this would be that 787 is also the model number of one of Boeings current generation jetliner, the Boeing 787 Dreamliner. I, as a small-time-wannabe number nerd and small-time-wannabe airplane nerd, reacted positively when I happened to see this connection.
I have no idea if there is any intent behind this specific number of produced planes, but I suspect that there would be people at Boeing who feel the same kind of mild satisfaction as I did when I saw the number of aircraft produced.
After seeing this, I can't be the only one who got curious as to how many emojis there actually are on iOS.
Obviously, a quick google doesn't work right now.
So I did this to try to figure out: emojipedia.org, the site that supposedly breaks google, has a page that appears to show all the available emojis on iOS [1]. On this page, all except the first 21 emojis are displayed in a way that uses lazy loading of the images. These images are contained in <li class="lazyparent"> elements. Assuming that there are no other <li class="lazyparent"> elements on the page, we should get the number of emojis on iOS simply by counting those elements.
Those examples are all relatively low-level. Many high-level languages provide a floating point interface on top of such an underlying integer pseudo randomness algorithm. This is the reason why much high-level code use multiplication to get a ranged value.
This post goes into some detail about how the V8 JavaScript engine creates a [0, 1) floating point pseudo random value from its underlying integer pseudo-random algorithm: https://v8.dev/blog/math-random
The automated translation of that article turned out a little bizarre. This is the automatically translated version:
> The analysis shows that it is a Swedish remote-controlled craft (Seafox) that the Norwegian Armed Forces use to detect, for example, minors.
Not only does this translation fumble the translation of the word "naval mines", which amusingly becomes "minors", but it also somewhat surprisingly changes the nationality of the military power involved.
The correct translation should be:
> The analysis shows that it is a Swedish remote-controlled craft (Seafox) that the Swedish Armed Forces use to detect, for example, naval mines.
This article defines the concept "improper noun" as a phrase that carries a specific meaning that may be different from its colloquial meaning. Such phrases can be confusing because they carry a double meaning, and because most people would only be familiar with only one of them - the colloquial meaning.
I believe that this confusion is strongest for native speakers. When you learn a language as a secondary language, you get used to pattern-match phrases in the new language. At first, each phrase is just a combination of words that you have to learn what they mean, one by one. After a while, you start to see the connection between phrases and their words, but you still retain that ability to simply pattern-match phrases and assign an arbitrary meaning to them. As a native speaker, it is much easier to interpret the colloquial meaning and you may have to almost force yourself to pattern-match the non-colloquial meaning.
I would also think that there are several subjects of study that may be helpful in interpreting these improper nouns:
* Mathematics. You soon get used to the style of thinking that starts with an assumption and proceeds to reason around the assumption, without defining exactly what the assumption is. "Assume we have a number, i, that satisfies i^2 = -1", and so on. It is straightforward to extend this type of thinking to improper nouns.
* Programming. In programming, we just define things, such as variable names or classes, and then we use them. The same thinking can be applied to improper nouns.
* Law. In contracts and agreements, is important to have precise meaning of every term, so contracts often start by explicitly defining all terms used in the contract. This type of thinking is easy to extend to improper nouns.
It is cool to see such a central piece of the Internet puzzle get an updated specification.
This quote from the RFC provides both the context of this document and is an indication as to why it seemingly took so long for this particular update to be published:
> This document is largely a revision of RFC 793, of which Jon Postel was the editor. Due to his excellent work, it was able to last for three decades before we felt the need to revise it.
I think part of the message here is to not be afraid to come off as inexperienced as an engineer.
This particular call to rand() was written by a person with decades of experience with writing code like this. This person maybe isn't a starninjarock developer, but definitely experienced. Who did it? Let's git blame the code:
OP of the article here. You are absolutely correct. The statement in the article is very much a simplification: in the real world, wireless communication is tricky. Not only are there issues such as the hidden node problem (and the exposed node problem, for that matter), but it also changes over time.
It is possible to take these issues into consideration, but as you say, that requires a very different infrastructure than what this article is talking about. The way we do it at Thingsquare is to use a software-based simulator where we can both emulate the software on the devices and have full control of the simulated radio medium - if we need it. Sometimes using RF attenuators and/or cabling is useful.
In the end, what it comes down to that each tool has one or more use cases where it shines, but there is no one tool that fits all.
OP here. I think Helium(*) is super interesting. They are building an access network for LoRa by using crypto coins to incentivize people to deploy base stations. You essentially get crypto coins for every packet that passes through your own base station. And anyone who wants to use the network pay for access using crypto coins.
The idea is that if you are designing and selling a product, say, a dog collar, you can build Helium(*) capabilities into your product by including a LoRa chip in it. Your customers can then use the Helium(*) network to communicate with the dog collar, for example to locate a missing dog. The fees for this service then flows to the people that have deployed the base stations that facilitate this communication.
To me, this seems like a great way both to build an access network and to get people invested in (and excited in) the process. There are now also a bunch of companies who are taking advantage of this network for their products.
(What we at Thingsquare is doing, and what is discussed in the article, is a little different from what Helium(*) is doing. We are providing a single-purpose network for one system/product, such as a street lighting system. That entire system is connected using its own mesh network, and that mesh network is typically not used for anything but that product's communication needs.)
While the Lazy Jones soundtrack is a pretty good demonstration of how early SID music sounded like, it does not even come close to what more recent music players are able to produce - on the same hardware.
If you want to be blown away by the sounds the SID chip can produce, I would recommend some of LMan's work. This is one impressive tune: https://youtu.be/h0qMNfpiLmE
And this is done with the hardware that Bob Yannes designed for the Commodore 64, in his early 20s.
The story I heard some 20ish years ago was that the Blåtand name was so popular inside Ericsson that employees were actively encouraged to use the name Bluetooth and not Blåtand. At the time, "everyone" called it Blåtand, outside of Ericsson too.
I agree that people in Sweden just tend to call it Bluetooth nowadays.
One common problem when explaining ideas is that we often jump right into talking about the solution, and just assume prior knowledge of the problem we are talking about.
But since the audience probably doesn't know the problem as intimately as we do, this tends to make our explanation hard to understand - even if our solution is straightforward.
A simple trick I once learned is to structure the explanation into four parts, with one sentence for each part: (1) state the problem, (2) state the consequences of the problem, (3) state the solution, (4) state the consequences of the solution.
Since the explanation now automatically includes both the problem and the solution, it usually is both more compelling and easier to understand.
You should come to Stockholm, Sweden, during the week at the beginning of December when the Nobel prizes are awarded. While it is not an entire month of celebrations in the name of science, at least it is one full week: https://www.nobelprize.org/ceremonies/nobel-week-2021/