We bank with Mercury and I couldn't get a hold of them in business hours after receiving this email at 5:30PM CET on a Friday (unsurprisingly). This email seems odd to me, Mercury shows a transaction posted as of March 9 for employee payments, and another posted as of March 10 for tax payments. Had I was successful in contacting Mercury, would they even be able to reverse them?
Rippling should be working with FDIC to sort out these in-flight payments, not asking their customers this. When I reached their support team for what the additional instructions are, I couldn't get an answer. This situation sure doesn't look great.
Does the set of validators really need to be static (or fixed-size)? I may be missing something obvious, but it seems like we can also support a dynamic set. Consider the following scheme:
- In addition to transaction data, each validator stores three sets: CURRENT, the current validator set; IN_PENDING, the set of clients who are to join the validator set; OUT_PENDING, the set of validators who are to leave the validator set.
- Validators support four additional requests: v_nominate, v_initialize, v_remove, v_eject.
- When a client wants to join the validator set, it sends the v_nominate request to all validators. Validators who agree add the client to IN_PENDING, sign the tuple (CURRENT, IN_PENDING) and reply.
- If the candidate client receives 2 * f + 1 signatures where f = (max |CURRENT| - 1) / 3 (maximization is over all responses), it sends the v_initialize request to all validators (along with the signatures). Validators receiving this request remove this candidate from IN_PENDING and add it to CURRENT.
- When a validator wants to remove a validator (can ask to remove itself) from the set, it sends the v_remove request to all validators. Validators who agree add the outgoing validator to OUT_PENDING, sign the tuple (CURRENT, OUT_PENDING) and reply.
- If the validator who originates the removal request receives 2 * f + 1 signatures where f = (max |CURRENT| - 1) / 3 (maximization is over all responses), it sends the v_eject request to all validators (along with the signatures). Validators receiving this request remove the outgoing validator from OUT_PENDING and CURRENT.
Wouldn't arguments similar to the ones in the article also work for showing consensus on these sets?
I was thinking about the signature issue as well. In flat space (i.e. Minkowski metric), this would imply a constant four-potential with an imaginary 0'th component, which I can not make sense of.
IIUC the authors are saying that if we associate the metric with the four-potential via an outer product, they get a picture coherent with the current understanding of how electromagnetism "works" in GR under certain circumstances.
I can somewhat see how to interpret the mathematics in free space. But what about when there are massive bodies in the picture? They will result in a non-flat metric... does that imply they create their own electromagnetism?
So if we have a theory expressive enough to make statements about ordinary (Peano) arithmetic, we can always form a self-referential statement within the framework of this theory which we can not prove or disprove. So far, so good. Here is my question: What happens if we restrict/weaken the theory to preclude self-referential statements? Obviously, we will lose our ability to express certain arithmetic statements which correspond to self-referential statements in the original theory. But what else? Is that the only class of statements we lose? Also, are there any other kinds of statements that still make the theory incomplete?
You are talking about Sprecher's modification to the original Kolmogorov-Arnold theorem, right? This version, and its implications, have been a lingering wondering for me for quite a while. Are you aware of any research on 3-layer networks where the unknown transfer function is also learnable? I suspect such an approach does not result in good models (otherwise we would have known about them!), but I can not articulate why. Where exactly does the K-A reasoning fail when we try to apply it in practice?
No, but s/he might tell you that it is safe to count on God being an important concept to many people for the foreseeable future. In the same vein, gold will likely be perceived as a good store of value for the foreseeable future, which is what matters in this context.
Clear, concise and to the point. Looking forward to reading the rest. If you finish the whole series and fix/improve the posts in this sequence using the feedback from here, I think it might serve as one of the go-to pages for technically inclined people who are interested to learn about Bitcoin and blockchains.
I don't understand if they use windowing as a fixed computational step that is active both in training and scoring time, or, if they use sliding windows only to chop up the training data.
Also, I wonder if they checked how a feed-forward NN that operates on the contents of a sliding window (e.g. as in the first approach above) compares with their RNN results. I am curious about this, as it would give us a hint whether the RNN's internal state encodes something that is not a simple transformation of the window contents. If this turns out to be the case, I'd then be interested in figuring out what the internal state "means"; i.e. whether there is anything there that we humans can recognize.
Your "invisible frogs" would not be a reformulation of Newtonian Mechanics (NM). A reformulation needs to make the exact same predictions as the original theory. There are many reformulations of both NM and GR, and they are quite useful (and interesting) in various contexts. This is a solid, interesting work that does not deserve being dubbed "horse shit" by a person who does not even have a formal training in the field.
Yes. I don't know the exact dynamics of their toy problem, but thinking about it this way can help: When the rod falls over, it will stay there from then on. In terms of the number of possible future states, there are less possibilities for the system.
Rippling should be working with FDIC to sort out these in-flight payments, not asking their customers this. When I reached their support team for what the additional instructions are, I couldn't get an answer. This situation sure doesn't look great.