I'm not sure I understand the prime density thing. Of the numbers up to 8258, about 12.5% are prime. Accounting for the fact that about a quarter of these primes ends in 101, i.e. cannot occur, I would expect about 10.7% = 12.5% * (3/4) / (7/8), which is fairly close to the observed 9.4%.
The 2.1% in the README seems to be the density of primes < 1000 among numbers up to 8258. That's not what was counted.
I haven't read all of that, but the problem at hand seems significantly less complicated.
We're mapping the numbers from 1 to 1000 to distinct numbers up to 8258, and the README claims that we should expect 2.1% of the resulting numbers to be prime. I see no reason for this claim, and as I understand it, the 2.1% comes from pi(1000) / 8258, which seems like nonsense to me.
Oh, I meant it's impossible to mix ST with actual exceptions as implemented in the RTS, rather than with ExceptT which simulates exceptions in pure code (like StateT simulates mutable state in pure code).
You're right, through a stroke of luck it's possible to use `ExceptT e ST r` and either handle the exception part first, to get `ST r`, or handle the ST part first to get `Either e r`, so in that sense you can "mix" exceptions and ST. That doesn't work for all transformers though. If you have `Stream (Of a) ST r` then you must consume the stream first. You can't run the ST part an get a pure stream `Stream (Of a) Identity r`. So in that sense ST can't be mixed with other effects. Bluefin does allow you to do that, though.
Yes, but transformers have a few drawbacks: the order of stacking alters behaviour, and you need to write n^2 instances for n transformers.
Compare ExceptT e (StateT m a) and StateT (ExceptT e m a): if you just want your computation to have state and exceptions the difference shouldn’t matter.
> if you just want your computation to have state and exceptions the difference shouldn’t matter
But... you don't just want that. You almost certainly care whether state changes are discarded when an exception is thrown. I don't claim that the types there are the most obvious or natural way to specify that, but there is a meaningful difference that shouldn't be handwaved away.
The fact that with transformer stacks you can wind up with state changes being discarded on exception if you get the stack arranged in a particular order isn't what I'd call a _feature_ of transformer stacks :-)
If effect A is invoked before effect B, effect A should happen and stay that way: if I update state before an exception is thrown, the update should persist. If I send a network message before an exception is thrown, the network message is still sent. If I launch the nukes before an exception is thrown, the missiles are still flying.
If I want to batch up state updates to only happen together as a unit, I'll use a transaction effect.
I might have this wrong but I think if you want state and exceptions you probably want StateT (ExceptT e m a). The alternative would be to have state or exceptions, i.e. when you have an exception you no longer have state (which might be a legitimate type in some cases).
Remember that transformers are "inside-out", i.e. `StateT (ExceptT e m) a` is isomorphic to `m (Except e (State a))`. If we want to keep state if an exception occurs, you need a `m (State (Except e a))` which is `ExceptT e (StateT m) a`.
The way I remembered it, before I internalized it, was to think about applying the run functions one at a time. runSomethingT will take a `SomethingT ... m ... a` and give you some kind of `m (... a)`.
Not actually all-pairs max flow, you can fix the source and consider all possible sinks. In the AoC problem we also know that the min-cut is 3, so we can abort the flow algorithm as soon as we have found a 4-flow.
grep doesn't eat the colours, apt detects that it is not outputting to a TTY and suppresses the colours. Try `printf 'a \e[36mb\e[0m c\n' | grep a`, the colour is preserved just fine.
Some tools have an option to force coloured output regardless, e.g. GCC's `-fdiagnostics-color` or grep's own `--colour=always`, but apt doesn't seem to have anything like that.
In theory one could have a command in the style of nohup or stdbuf which sets up a PTY to trick the command into outputting colours. So one could run `fakepty apt search whatever | grep another` ...
Some switch around the "s" and "sh" sounds, so it is pronounced roughly like "shtratsiatella". "st" at the beginning of a word is pronounced as "sht" in German.
Don't tell me, my native language uses a bunch of those weird çharacters. I also know that it always eventually cause problems because there's always legacy software that doesn't handle them properly.
But what really is the purpose of allowing supporting in key names? Current keyboards - at least those sold in Europe - do have a key for €, but imagine some lunatic "app developer" insists that another INI key name should be spelled "value in ¥". Customers, coworkers, support desk staff, everyone will curse them.
The 2.1% in the README seems to be the density of primes < 1000 among numbers up to 8258. That's not what was counted.