Yup!
5,143 karma · joined June 11, 2012
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?
> To me, 0.1000000000000000055511151231257827021181583404541015625 + 0.200000000000000011102230246251565404236316680908203125 = 0.3000000000000000444089209850062616169452667236328125 feels less surprising than 0.1 + 0.2 = 0.30000000000000004.
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.
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.
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
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 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.
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.
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:
13a3029435b core/lib/random.c (adamdunkels 2009-02-11 11:09:59 +0000 52) return (unsigned short)rand();
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.
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...
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.
I agree that people in Sweden just tend to call it Bluetooth nowadays.
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.
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).
Here is a good list of them: https://en.wikipedia.org/wiki/April_Fools%27_Day_Request_for...
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."
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.
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/
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.
"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.