Any plans to make it possible to run shellcheck on the embedded scripts?
672 karma · joined January 29, 2020
My solution doesn't use SIMD, but is actually takes about the same amount of time as the the solution in the article, given the same number of cores, though an glaring weakness of my approach is that it can only scale up to 7 cores as written.
Rough outline of how mine works:
- Set current best GCD to 1.
- Search through all valid board configurations.
- Bail out from the search early if the current partially generated board couldn't have a GCD greater than the current maximum found, e.g. if we've only generated two rows of the board, and the GCD of those two rows are already less than the max.
- Update the current best GCD as you find higher ones.
- Share the current best GCD value across multiple threads. That way the longer the program runs, the earlier and earlier the searches will start bailing out.
- Don't always read from the shared variable to avoid contention. Instead, each thread has its own copy of the last value it read which we compare with first before copying and caching the shared value.
- Another interesting property of this approach is that it can be used to validate the correct solution even faster than it takes to find it. Instead of initially setting the max GCD to 1, set it to `solution - 1`. That way branches in our search will bail even sooner from the beginning. This leads to the program running about 20% more quickly.
Source: https://gist.github.com/lazytype/35b45f3ea81b5c1c5555546fe6f...
- What does writing asynchronous code look like
- Will it have any novel or less mainstream features, e.g.
- Algebraic effects [1]
- Contexts/Capabilities [2]
- Linear types [3]
- Is the type system sound and does it support/need type casts
- Does the language support interfaces/traits/protocols
- How rich are generics, e.g.
- Explicit variance annotations on type parameters
- Lower or upper bound constraints on type parameters
- Higher-kinded types
- Is structural vs nominal subtyping more prevalent
- Does it have algebraic data types? Generalized algebraic data types?
[2] https://docs.hhvm.com/hack/contexts-and-capabilities/introdu...
> Inevitably, there will be users who, for whatever reason, don't want their usage of Fig to be personally tracked. Of course. It's your data and software on your device. You shouldn't even need a reason. We want to cater to these users. And we will. But unfortunately, we are so early on in the process of building Fig that we need to be able to speak to our users. De-anonymising telemetry for the time being while minimisng the events tracked enables us to do this in a non intrusive way. But it is of course not for everyone. Therefore, once we reach a critical mass of usage in the coming months, we will then anonymise all telemetry, making Fig more accessible.
It has been several months since this was written. Are they still collecting de-anonymized user data?
It prompted me to learn a bit more about IFS and discover one of my favorite fractals ever. The word "chaos" where each stroke is made up of the word "chaos" [1]. I spent a bunch of time coding up the fractals on that site [2] on my calculator
[0] http://manualsdump.com/en/manuals/texas_instruments-ti-83/13...
I wrote-up a high-level comparison between the type systems of TypeScript and mypy here that might be of interest to type enthusiasts
If you prefer playing as an app over in a browser
https://store.steampowered.com/app/1086630/Spelling_Quest_On...
Converting code to Rust while keeping the logic one-to-one wouldn't work. Rust isn't ensuring memory safety by just adding some runtime checks where C/C++ aren't. It (the borrow checker) relies on static analysis that effectively tells you that the way you wrote the code is unsound and needs to be redesigned.
If your Python code relies a lot on dynamic dict objects instead of classes you'll have a rougher time. You have to use `TypedDict` which is not very expressive and syntactically verbose. This could be considered a good thing since you'll be pushed to use things like `NamedTuple`, `dataclass`es, or (a third-party extension) `attrs`. Most JS/TS code is probably using plain objects rather than `Map`s. The TypeScript syntax for expressing object types is extremely expressive, though annoyingly `Object.keys` and `Object.entries` are not precisely typed (For legitimate soundness reasons. Object types are "inexact", whereas in Flow you can express both "exact" and "inexact".)
mypy supports union types, but not intersection types, unlike TypeScript. The closest you can get is creating a `Protocol` (i.e. interface) that extends multiple `Protocol`s, but this can be cumbersome.
mypy's generics are strictly worse, both syntactically and expressively. In mypy you can express both co/contra-variance explicitly, whereas in TypeScript variance is implied by the readonly-ness of an object's properties and variance of its methods.
Both mypy and TypeScript have `Any`/`any` types, but only TypeScript has the safer `unknown` type. You can kind of use `object` in mypy for this purpose.
Both have a "bottom" type, "NoReturn" and "never", respectively.
mypy has decent support for classes and subclass type-checking. TypeScript doesn't truly understand sub-class relationships nor even prototypal inheritance.
Both are very configurable in terms of the strictness checks, but mypy's flags are more poorly documented and it requires more work to increase the level of strictness. Enabling "strict" in TypeScript enables most of what one would want.
Anecdotally, I would say TypeScript has better control flow analysis. With mypy you have to cast a lot more often.
The TypeScript ecosystem is much stronger. Most new packages have types as do major packages (located in DefinitelyTyped repo). Python's typing ecosystem is fairly poor. There are barely any packages in Typeshed and a lot of new packages are still untyped.
TypeScript has a dedicated team at Microsoft working on it with a public roadmap and milestones, though big features only come around one or twice a year. Python's type ecosystem is more design by committee. A lot of conversation happens over mailing lists, monthly video calls, and a yearly conference. Since there are multiple Python type checker implementations, there isn't a single unifying vision. The core mypy team is employed by Dropbox, who has them spending most of the time migrating the giant monorepo from Python 2 to Python 3.
The TypeScript team is fairly decent at fixing true bugs between releases, but a lot of "bugs" are really feature requests that tend to become long-standing Github issues. On the other hand, last I checked, there are still some long-standing bugs in mypy that haven't been fixed (as not to spread FUD, I will say that they tend to be very edge-casey and more for power users).
Note that there are multiple type checkers for Python at this point with varying capabilities, but they share the same syntax and basic types since they're built into the language runtime. I expect Pyright (also from Microsoft) to come out ahead as more people start using the Pylance VSCode extension. mypy's editor/IDE support is not great, based on my VSCode experience. I haven't tried it with PyCharm.