The Toit language isn't bound to run on ESP32s.
We routinely run it on our desktops as well.
564 karma · joined March 29, 2013
We routinely run it on our desktops as well.
Here is, how we pronounce it: https://www.youtube.com/watch?v=JVKb8cm1B20
I know for sure that the compiler compiled to it, but I'm pretty sure I also had a "hello world" that worked.
I would need to find that branch and see if it still merges cleanly.
In all seriousness, though: if you like Go, then tinygo could be a good solution.
Personally, I find coding in Toit just a much more pleasant experience.
They represent 250 banks across Europe (according to their web-page): https://www.nets.eu/who-we-are
For example, Danske Bank (the biggest Danish bank) uses them.
This makes fraud much harder, while still allowing online payments with credit cards.
It is probably also helping smaller shops, as even Amazon customers now need to do something when they buy there.
First page I found ranks the US as having more income from natural resources than Finland.
https://www.theglobaleconomy.com/rankings/natural_resources_...
The index table needs to be sparse (for the hashing to work), and thus has quite a few entries unused. It also wants to be small in memory to improve cache locality.
Therefore you want to have the entries in the index-table as small as possible.
As example, let's say you have n entries in your map which is 2/3 full. Let's assume the key and the value each take 1 word.
In the index+key+value case you would thus use: n1.5 words for the indexes, and n2 words for the keys/values. -> 3.5 words per stored key/value.
In the key+value case you would need (2n)1.5 words. -> 3 words per stored key/value.
However, that assumes that the index-table uses a full word per entry. That's usually not the case, as you can use smaller types while the map is small enough. On 64-bit machines, the index-table will rarely use more than 32-bit arrays. In that case you would only need 2.75 words per stored key/value.
That's not really fair, though, as the value/key table has some unused space, so that it doesn't reallocate/copy every time a new key/value is added. Implementations can play with how much extra space is allocated for those unused slots.
Also, the "hash" you mentioned can be combined with the redirecting index. For Toit (the map of the blog post), the index table uses 32 bits. In these 32 bits it stores both (part of) the hash code, as well as the redirecting index.
It might be the case that the hash+key+value approach uses less memory, but I would not be confident to say that it's always the case.
The hash map as described in the article doesn't seem to waste any memory.
There is no reason for that. A sorted list doesn't need more memory than an unsorted list. And an insertion-sorted map doesn't need to use more memory than a map that doesn't keep the order.
Independently, some properties we deem valuable are often side-products of the way the data-structure works. For example, an efficient binary search tree will naturally tend to be balanced. In the case of efficient hash maps, it is now common to add the key/value pair at the end of an internal vector. Maintaining the insertion order this way doesn't add any cost.
The default hash map visits the keys in arbitrary order (https://doc.rust-lang.org/std/collections/struct.HashMap.htm...).
You could use a BTreeMap, but that's not insertion order and requires the user to come up with some sort of ordering.
A very similar chocolate seems to be Vivani (from the same manufacturer). "Vivani edel bitter 70%". Maybe that one is easier to find.
It's very hard to present tables on Medium. If someone knows a better technique I would be happy to learn about it.
For the "Knack": I'm not 100% sure either. I think he meant that it had a nice snap/crunch.
Used http://toit.io to connect the ESP32 to the cloud so I could control it from my phone (with a tiny Flutter app).
Don't have a source right now but I remember because we wondered if we should take a test as well. In retrospect (now 40+ years old and still looking very similar) it's hard to understand why we every doubted.
Wrote a blog post about the most interesting things I found: https://medium.com/@florian_32814/date-time-526a4f86badb
https://chrome.google.com/webstore/detail/ctrl-access/glmoeh...
The idea was copied from Konqueror.
Up to a certain point, countries adapt. For example, Germany and France are in the same timezone, but their schedule is shifted. This can be easily seen when looking at the TV schedules. In Germany, evening TV starts at 20:15 (the start of movies, ...). In France it's more like 21:00. When I lived there it was 20:50, but TF1 now seems to start at 21:05.
German TV: https://www.zdf.de/live-tv
French TV: https://www.programme-tv.net/programme/chaine/programme-tf1-...
Similarly, schools and kindergardens are usually not at the same time.
This local shifting works more or less, but can't be stretched too far. Especially multinational companies have expectations that workers come in at certain times. This is the problem that Spain faces. (I couldn't easily check by how much Spanish are shifted as Spanish TV schedules don't seem to coordinated like in France or Germany).
I really hope this will change, though. Skilled AIs could make so many games more interesting and better.
Many online games really suffer from bad multiplayer experiences. Players that drop in the middle of a game, ...
If Overwatch, Destiny, ... had really good AIs, that would make the game more attractive. If a player drops, they could replace it with similarly skilled AI. Instead of waiting for 12 players of the same skill-level, they could just play with some AIs.
They could even make it such, that humans win 70% of the time, and let the AIs just lose more often.
Where alphastar shines, is in making a strategy work. It won't attack into something that looks dangerous. It won't forget to build more units. It won't be distracted on two fronts. (That said: Alphastar did some really stupid mistakes as well.)
I agree with you, though: it would be much more interesting, if Alphastar was actually handicapped in the micro (at least at a later point in the game). Then it would really need to find interesting strategies and counter opposing units with more cost-efficient ones.
One could, of course, add more restrictions (like not noticing things on the minimap all the time...), but that's not what's it about anymore. At this point, micro is comparable to humans, and we can start to compare macro and strategy.
Fwiw, when I watched some of the replays, I was disappointed by AlphaStar. It's a very consistent player with few mistakes, but it isn't very reactive and definitely not inventive. Instead of switching tactics when things don't work out, it generally continues with the chosen strategy. Often, that's enough: a well executed strategy with few errors often wins, even if it wasn't optimal.
Similarly, AlphaStar would not play with group hotkeys, but use a different technique. However, in none of the analyses, people noticed things that would give AlphaStar an unfair advantage.
"Correct" conversion, where the length doesn't matter (which could be called "fixed length" for a certain length that is big enough) is easier, because one can avoid a lot of rounding and imprecision issue: using the right technique, just produce enough digits until the imprecisions don't matter anymore.
However, fixed length is as difficult as the shortest, if the length is limited, since the last digit sometimes lies on the boundary and thus runs into the same difficulties as the shortest digit. Think of it this way: needing to decide whether 6 digits is enough, is often similar to asking whether the 6th digit is a 0 or a 9 (roughly speaking). This means that producing the best fixed-length representation (for length 6) runs into the exactly same question.