As other commenters have said, you're just going to learn the decoder ring from context, but I'm also curious. If I take off the keycaps to clean the keyboard and then put them back, do I need to relearn the defects? If I rip out all the switches and rearrange them, do the defects follow the switches or is it more about the position of the key? Is there some resonance that could change if I move the keyboard onto a desk pad. If I switch to Dvorak in software, obviously the key presses mean something different, but also I'll type completely differently. How much does user cadence/timing matter? To what extent is user cadence/timing identifying?
Anyway, I assume the answers aren't known because it would be an ethics/privacy nightmare to run these kinds of experiments on anyone but yourself.
Yeah, lots of different uses for a keyboard with wildly different frequency distributions. Writing an English letter != text chat in Spanish != data entry != league of legends. It's also not quite a substitution cipher due to modifiers (shift), toggles (caps lock), non-printable characters (escape, volume up/down), and deletion (backspace/delete).
It's an interesting problem you'd probably try to solve with Markov chains back in the day, but now you'd just throw machine learning at.
>> Hashmaps don't have guaranteed performance characteristics
>Of course they do
No, they do not, at least not worst case O(1). If you write a very poor (but functional!) hash function or an adversary is choosing your items, then congratulations, your hashmap is now a linked list with extra steps.
Sure, you could use a robust cryptographic hash function, but you didn't because (a) it's not the default in your language and (b) it's slow and you are "a lot more interested in a low-constant-factor O(1) best case".
I mean it's kind of pedantic but yes hash maps do have guaranteed performance characteristics. They are not guaranteed to be O(1), but they will never be something like O(2^N) either. You can give guarantees about their performance if you can make guarantees about the distribution of the inputs and the properties of the hash used.
In my own experience, most uses of hash maps are typically O(logn). A good rule of thumb is hash maps are preferable unless you need predictable worst case performance or your hash maps are directly exposed to the public.
> A good rule of thumb is hash maps are preferable unless you need predictable worst case performance or your hash maps are directly exposed to the public.
Also, obviously, features only one of them provides e.g. if you need range queries then a hash table is quite useless. Meanwhile if you need insertion ordering, that’s reasonably easy to do with a hashmap.
Also if it's big enough that recursing will blow out your stack.
Yes, you can throw the nodes on an array in the heap to allow tail recursion, but at that point you're going to be losing to a map with all but the biggest datasets, and even then the copies really aren't desirable
I'm no expert, but there are approaches to reinforcement learning where you build a table of the expected payoff for each scenario, and these can recursively reference other entries in the table. Take a look at Q-learning, for example.
Maybe in general, but this is in the context of "time loop logic". Ordinarily, you can have entangled states where measuring both parts will produce the same (random) outcome. Unfortunately the outcome cannot be influenced by either party, so it's useless for communication, as you say.
Now suppose that the first party resolves to go back in time and kill his grandfather unless the bits he measures are precisely the message he wishes to send. The universe can't tolerate the paradox, so it is corralled into the only non-paradoxical outcome: both parties read the desired message. Something like that, anyway.
Ah I guess I misunderstood what was being claimed. I thought the claim was "you can use entanglement to instantly send messages", but it's actually "you can use entanglement and this model of how time travel might work to send messages instantly".
Obviously these are rather different. In fact I feel like the entanglement doesn't even help in the time-travel protocol. If you want to send messages instantly and you can send messages back in time, you can "just" send yourself the message distance/c seconds in the past and send it then. Some messing around let's you arrange for it to arrive at exactly the time you want to send it in the future.
Assuming what I wrote above is correct (I don't actually know anything about closed time-like curves), it's actually weirder than just going back in time and mailing a letter early so it arrives when you want. Specifically, once you set up the entangled state, no other communication between the parties is necessary.
Yeah I understand the proposed protocol using entanglement. I'm just saying that if you're assuming we have access to the ability to send messages back in time there are much simpler protocols to achieve instant communication /without/ having to do anything involving entanglement.
IMO this is like those discussions where someone says FTL communication is possible by using a very long solid rod, jiggling one and and monitoring the other... except on closer inspection it'll only work if the rod is infinitely rigid, which is already a violation of many of the same underlying physical laws.
So it's a kind of circular logic, or at best an observation that having one kind of supernatural magic power would let you cause another kind of supernatural magic outcome.
In this case, if only I had a time machine I could break the speed of light. (Or possibly vice-versa.)
