I wrote a Chrome extension with a similar purpose.
https://chrome.google.com/webstore/detail/ctrl-access/glmoeh...
The idea was copied from Konqueror.
707 karma · joined March 29, 2013
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.
Internally it uses the same algorithm, Grisu, (with some additional optimizations) so there shouldn't be any difference in output.
If it's easier to use for you, just go with it!
I'm guessing the double-conversion library is a bit more flexible, but I could be wrong.
These algorithms (Grisu, Ryu, ...) all satisfy the "internal identity requirement", which means that they can print a double and read it back in to the same double.
The harder part is to also produce the shortest of all possible string-representations. (And then picking the closest if there are many).
It's really surprising, how long it took to find the most efficient algorithms for double-conversions. In 1980 Coonen already published a good algorithm, but that one was kind-of lost.
For a long time Steele & White's algorithm was the state-of-the-art (with some improvements here and there over time).
Now, Ryu is by far the fastest algorithm out there, but that took ages...
Unfortunately, there doesn't seem to be an easy-to-use, complete library for Ryu yet.
The Grisu library (https://github.com/google/double-conversion) is probably still the go-to library if you don't want to implement it again...
It's almost sad that Massachusetts switching wouldn't even make it into that document... (too normal)
- better type promotion (`if (x is! A) throw "not A"; useAsA(x);`.
- Optional new/const.
- Allowing named arguments at any position at the call site.
These are all easier to specify and implement, and reach more users.
We intend to work on it at a later point again.
Currently, we are not spending resources on parallel execution (with isolates), either. There are other easier features that have more impact.
Eventually, we will revisit this topic, and see if we can make things easier. Multithreading itself is extremely unlikely, but there are other ways we can make parallel execution better; for example with easier data sharing between isolates.
However, it's still on the list of features we would like to work on. Adding it later gets harder (because we don't want to break our users), but we hope that we can find a good migration path.
Brad Green already posted a follow-up post on the omission of Dart on his slides: http://angularjs.blogspot.dk/2017/04/official-languages-at-g...
(I work on Dart.)
It's based on http://florian.loitsch.com/publications/dtoa-pldi2010.pdf
I'm obviously biased, but I think the API is easier, and the algorithm is faster.
However, it's in C++ (which might not suit your needs), and it requires more code (especially with the precomputed constants).
Grisu is also proven to be always correct. As mentioned in another comment: you have to define "correct". Grisu is always accurate, but may bail out if you need the shortest or closest result.
Basically: Grisu will always print a number that reads back to the input. However, it may not be able to print the shortest or closest number (when two decimal outputs have the same shortest length). In that case, it knows this, though, and can tell the user.
I would say that the combination of Grisu and Errol is currently the state of the art.
Errol is not the fastest, nor is it (afaik) proven to always return the closest result.
However, combining Grisu with Errol (as fallback) would probably yield the fastest complete algorithm.
Grisu is accurate, but not always optimal. However, it figures out when that happens and lets you bail out to a slower algorithm when that happens. If you want full speed you should use Grisu, and then use Errol as a bailout.
A bit more context: there are 3 important properties when printing floating-point numbers.
- accurateness: you want the printed number to read back to the same number.
- shortness: often you want the shortest decimal representation: "0.3" and not "0.2999999999999999889". The latter is more precise, but reads back to the same number as "0.3".
- closeness: given two decimal representations of the same length, you prefer the one that is closer to the actual number.
I call the combination of these three properties "optimal".
Note that shortness and closeness are not always crucial. For example, a json-encoder could easily drop those, if the encoding is faster without them. Also, some languages drop shortness in favor of printing something closer to the input.
Grisu always produces accurate results. However, it sometimes can't tell if it already has the shortest and closest number. However (by being conservative) it can tell the user when that happens. In that case, one can fall back to another complete algorithm.
The double-conversion library (http://github.com/google/double-conversion) does exactly that. It uses the slower bignum algorithm in these cases.
Same repo: projects in Google are encouraged to use other project's code. You can only do that if the versions of their dependencies match. The general guideline is that all projects use the latest version and move in sync.
Breaking Changes: I have never been involved in such a huge breaking change, but I would expect that the conversion is done gradually. Ideally, some teams are also helping in the migration (or sign up as guinea pigs to test the latest versions).
Automatic refactoring: These refactorings are done with a tool called Rosie. Search for "Google refactoring, Rosie" to find some papers/documents about it. One of the first hits was this document: http://cacm.acm.org/magazines/2016/7/204032-why-google-store...
Things get more complex if you want to implement the double/integer distinction that exists in Dart. That would either require to box integers or doubles, or to come up with some kind of tagging.
The Dart language and its spec are independent of dart2js (which is just an implementation striving to implement the spec). Clearly there is a huge connection between both (same team, ...), but in the end we decided to accept the non-conformance for the benefit of a better language. On the server Dart developers can already enjoy the more complete number-hierarchy, and, even if it takes time, I still have the hope that client-side we will eventually be able to enjoy Dart VMs everywhere. (Call me "optimist" ;)
Wrt debugging: the VM has a mode where it detects incompatibilities. For example when a number exceeds the 53bits of JS. This should reduce the difficulties in developing cross-platform tremendously.
I was part of the team that started Dart (right place at the right time :), and helped design the language. Obviously we have some emotional binding to the language and would like to drive it into the right direction, but most of us are perfectly happy with others taking the relay.
We still have some ideas and proposals that we have worked on and that we want to champion, but all in all I just hope that the TC52 members will do a good job.
Dart2js is not conformant. You could, maybe, twist the meaning of the spec this way, but it goes against the spirit of the sentence and the spec.
Tbh we never implemented a fully compliant dart2js backend. We have seen how slow the output is when some of our optimizations don't trigger (i.e. when we have bugs) and numbers are not correctly inferred.
Eventually we would like to give it a try, but there are much more important and useful issues we want to fix first.
In practice, numbers are a surprisingly small problem. Programmers have learned to look out for big numbers, and, while a nuisance, they are rarely the source for bugs.