adunk

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.

[1] https://en.wikipedia.org/wiki/Best-effort_delivery

Wikipedia has a nice list of software using the algorithm: https://en.wikipedia.org/wiki/Raft_(algorithm)#Production_us...

I like to view mathematical proofs as code for a virtual machine that is executed in the minds of the readers of the proof.

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 really like this quote from the article as way of explaining this whole perceived anomaly:

To me, 0.1000000000000000055511151231257827021181583404541015625 + 0.200000000000000011102230246251565404236316680908203125 = 0.3000000000000000444089209850062616169452667236328125 feels less surprising than 0.1 + 0.2 = 0.30000000000000004.

The first sentence in the blog post contains a link to the proof itself, which seems to have been posted to tumblr: https://theapproximatepresent.tumblr.com/post/51484587425/a-...

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.

Opening up the console and running

  document.getElementsByClassName('lazyparent').length

[1] https://emojipedia.org/apple/

This article goes through a bunch of ways to get both biased and unbiased random numbers by using a variety of methods, some of which use division: https://www.pcg-random.org/posts/bounded-rands.html

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.

OP here.

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:

  13a3029435b core/lib/random.c (adamdunkels  2009-02-11 11:09:59 +0000 52)   return (unsigned short)rand();

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.)

*: Helium recently changed their name to Nova Labs but I'm not sure exactly how that will effect the naming of the Helium network: https://blog.helium.com/elevating-the-helium-network-with-ne...

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/

One of the things I really like about the tau manifesto (the proposal to use tau == 2 * pi instead of pi in many situations) was their explanation of how tau made this equation all the more interesting (IMHO) by making it "almost like a tautology":

https://tauday.com/tau-manifesto#sec-euler_s_identity

For everyone that, like me, like to read only the headline and then proceed directly into the comments:

The title of the link currently is "Why E, the Transcendental Math Constant, Is Just the Best".

But the article really is about Euler's constant - the lower case e - and not about any of the capital E:s out there (like the capital E sometimes used in scientific notation, or the expected value in probability theory).

FYI: this is one of the RFCs that sometimes get published on the first of April as an April fool's joke.

Here is a good list of them: https://en.wikipedia.org/wiki/April_Fools%27_Day_Request_for...

This is from a study published in April in The Lancet Public Health.

Previous studied showed a correlation between physically demanding jobs and a shorter life.

What's new here is that the authors were able to crosscheck and control for other factors, such as smoking habits and income.

With this information, it turns out that physical exercise is beneficial, even if it comes from a physically demanding job. "Every movement counts, regardless of whether you are active at work or during leisure."

I have been in the embedded domain for many years. I really like the approach taken by the team here. Particularly since this team is really well-versed in developing virtual machines and programming languages. But I am very much biased in their favor.

Embedded development is tricky, and anything that can help improve the productivity is useful.

The problem is that there have been many, many attempts at doing this exact same thing over the years. And they all have to fight the same fight: to get some serious traction for their particular approach.

Back in the 00's, Sentilla did a Java VM for the MSP430. This got a lot of traction - they even had James Gosling himself vouch for the project.

More recently, Electric Imp and Particle.io have taken similar approaches, but with other languages.

Micropython and a variety of mini-JS engines are also around. Espruino, Tessel.io, and many more.

In a technical sense, running a virtual machine on a microcontroller is a really good way to go. You remove a lot of low-level friction that you otherwise have to deal with. And you get a lot of things almost for free, such as Over-The-Air (OTA) updates, and more control over security.

But when you get down to actually doing the work, you frequently end up wanting to have all that low-level access, even if you have to endure a bit of pain. Sometimes you don't even want to have an operating system with a hardware abstraction layer. You kinda want the bare metal.

So Toit are in a tricky situation. They may have a really good product. But they will have to get some serious traction. Developing a rock solid programming language and virtual machine is hard. Really hard. But it is way easier than to get that sweet, sweet traction.

The query "to our surprise" currently shows around 219 000 results. The query "not surprising" has about 1 620 000 results. That's about 7 times as many.

I have no idea if this is surprising or not.

Somewhat more surprising is that the query "italian mad scientist" has 4 results in Google Scholar. Those are all due to the SCIGen fake scientific paper generator, which sometimes outputs this phrase: https://pdos.csail.mit.edu/archive/scigen/

One way to introduce the idea that a number represented as decimal digits can have multiple representations is to talk about the numbers 1 and 1.0 being exactly the same. And that 1.00 is the same as 1. Just like 0, 0.0, and 0.00 are the same number. Most people would agree at this point.

Then keep stretching the number of zeroes to 0.000... - which, again, is exactly the same as 0.

From there, it is not a huge stretch to be able to go from that 0.000... is another way to write 0, then 0.999... is another way to write 1.

I have always thought that this slight cognitive dissonance was deliberate:

"A Swede stays silent" as one meaning, while suggesting "a Swedish roaring aggressiveness" as the other meaning. In wartime, I think both these would make perfect sense, and combining them into one in a simple three-word message is very effective.

This is great reading for everyone who grew up watching Terminator 2 and was fascinated by the chase scene where the T-1000 terminator bursts through a bridge down into in the LA river.

This seems to be the bridge: https://goo.gl/maps/3v3LK6h75LqrzexSA

More info in their Mobicom paper: https://dl.acm.org/citation.cfm?id=3345436