244 karma · joined July 1, 2020
Random browsing => no javascript.
Play a browser game => javascript.
I have this today with Flash, would be nice to have it for all client-side code execution.
https://slehar.wordpress.com/2014/03/18/clifford-algebra-a-v...
> Multiplication of all three basis vectors (e1^e2^e3) produces a three-dimensional volume segment or trivector, with unit cubed volume. This trivector has some peculiar properties that represent the scale of the whole space, it is often called the pseudoscalar of the space, I, it performs the function of the imaginary number i, but extended into three dimensions. Multiplication by the trivector represents a 90 degree turn in all three dimensions. Therefore two such 90 degree turns in each of the three dimensions results in a total reversal of direction, which is equivalent to a simple negation, and thus I2 = -1.
https://en.wikipedia.org/wiki/Geometric_calculus#Interior_an...
An attempt. To map an R^2 vector into G^2 is trivial, (a,b) => a x + b y = (1, a, b, 0). The reverse is hard. s 1 + a x + b y + d xy = (s, a, b, o) => (?, ?). Or perhaps G^2 is a superstructure of R^2, and most elements of G^2 can only be projected (somehow? perhaps trivially?) to R^2, but with loss of information. Which leaves the grok question: what does a vector in G^2 actually represent? Perhaps scale + x position + y position + orientation angle, as the use of 'i' suggests? If so, then in R^3 xy, xz any yz represent rotations in the respective planes? Which leaves a bonus puzzle: what does (multiplying with) xyz represent?
FWIW, at this point it's likely I can compute the answers using the code in the OP and well crafted multivectors. Time permitting :)
Within that context, just grokking R^2 or R^3 would be great progress. To be fair, the article does present the fundamental identity, uv = u.v + u /\ v, where u.v is the usual dot product (scalar denoting relative projective size) and u /\ v = |u||v|sinθi (something related to area and the plane induced by u and v). Even if the article does exemplify with R^2 by defining i = xy, and then dropping the ball: "i is interpreted to mean the plane generated by x and y". I can't grok this part :(
* This looks like (almost) a circular definition, defining uv in terms of the specific xy, where x and y are the two orthonormal R^2 vectors forming the basis. What is xy? Is it a scalar? A vector? A normal vector? How does a normal vector work in R^2?. A tensor of some dimensions? For example, assuming x = (1,0) and y = (0,1), how does one compute i = xy?
* Plane generated how? a u + b v, given any two scalars a and b?
* When moving to R^3, i'd think uv / xy define a plane. What does uvw / xyz mean?
* Minor quibble, is it sin(θ * i) or sin(θ) * i?
There is a simple mechanism to model multiplication of vectors represented using elements of an orthonormal basis. Each (multi)vector is a linear combination of terms, and each term is an ordered sequence of basis elements. Multiplication of (multi)vectors works as usual. Multiplication of terms simply concatenates the 2 terms, then canonicalizes using identities vv = |v|^2 and uv = -vu. There is a cost, the number of terms in a (multi)vector is O(2^n) for an n dimensional space, but that's OK.
And then I'm lost. How does this map back to geometry? What does '2 + 3xy + 5yz - 7xyz' mean geometrically speaking? What does multiplication mean geometrically speaking? Can't build an intuition, not even for R^2 or R^3 :(
There is a method behind it. The formulas are derived from the study of relatively simple ODEs, in this example f'(x) = x.f(x) + 1 and g'(x) = x.g(x) − 1. The latter was solved 100 years prior by Jacobi. While the solutions are non-trivial, they are fairly compact, accessible to a high schooler. The presentation linked from the blog is pretty good at unveiling the magic.
This is to say that, with proper guidance, the kid down the street can too become as cool as Ramanujan.
https://math.ucr.edu/home/baez/ramanujan/ramanujan_whittier_...
Most people will skim the title. Some will read the abstract. Few will read a specific paragraph or two of details. Yet, the writer doesn't know who's going to read what. Could be the writer himself, 6 months down the line. Often times those details are pure gold.
For reference, I use FP as in 'eschew mutable state', and not 'let's use category theory to solve FizzBuzz using compile-time type metaprogramming'.
Re autocomplete, there is no technical reason why auto-complete couldn't trim down the search space based on the arguments of the functions, for example by using reverse polish. But reverse polish is unusual, we really like SVO anyways, and modules as subjects are very useful, if only as an autocomplete anchor, in tooling or in one's brain. OOP/SVO is here to stay for the foreseeable future, and embracing pure functions principle makes it rather pleasant to work with. If only we could decouple 'modules as namespaces' useful idea from all the misguided baggage that comes bundled with OOP, of which the 'active data' antipattern deserves special 'please avoid' mention.
The big OOP idea is the subject-verb-object interface, confusingly named object-method-arguments. The SVO structure matches the cognitive linguistic bias of the human brain, thus feels obviously right to most humans. Even if better programming alternatives exist. The endless litany of new Verber(args0).verb(args1) is here to stay.
https://golang.org/doc/faq#assertions
> Why does Go not have assertions?
> Go doesn't provide assertions. They are undeniably convenient, but our experience has been that programmers use them as a crutch to avoid thinking about proper error handling and reporting. Proper error handling means that servers continue to operate instead of crashing after a non-fatal error. Proper error reporting means that errors are direct and to the point, saving the programmer from interpreting a large crash trace. Precise errors are particularly important when the programmer seeing the errors is not familiar with the code.
> We understand that this is a point of contention. There are many things in the Go language and libraries that differ from modern practices, simply because we feel it's sometimes worth trying a different approach.
Fundamentally, the Go team made the correct choice between explicit and implicit error handling. Yet one would hope for a bit terser syntax and language supported stack traces, 11 years after launch.
For a good overview of the issue: https://go.googlesource.com/proposal/+/master/design/go2draf....
https://github.com/golang/go/issues/32437
https://github.com/golang/go/issues/32437#issuecomment-51203...
1. Transformers are an extension of the attention mechanism, a well known LSTM extension that worked well for machine translation (2014, https://arxiv.org/abs/1409.0473). A transformer model is essentially building a multi headed attention module, analogue to CNNs, then stacking several layers of them, analogue to CNNs / stacked LSTMs. (1998, http://yann.lecun.com/exdb/publis/pdf/lecun-01a.pdf)
2. Transfomers use residual blocks, which were introduced by the ResNet CNN arhitecture (2015, https://arxiv.org/abs/1512.03385). At the time, ResNet was topping the ImageNet benchmarks. This technique helps preventing the vanishing gradient problem during training.
3. Transformers use normalization extensively. Layer normalization and attention normalization. This helps keeping internal vectors in the neighborhood of 1 and prevents vanishing gradient training collapse.
4. Correct initialization of the network vectors also helps preventing the vanishing gradients problem.
5. Unsupervised pretraining was one of the first tricks to make deep networks work (2009, https://www.jmlr.org/papers/volume11/erhan10a/erhan10a.pdf)
6. Pretraining was used extensively in the vision community for transfer learning, i.e. reusing the weights of a network trained on ImageNet and replace the top layers / loss function to tackle a different problem.
7. Finally, language modelling, that is predicting the next word in a sentence, was a well known technique to make machine translation work better. Researchers were looking for better language modelling techniques using large corpora (2013, https://arxiv.org/abs/1312.3005, https://www.kaggle.com/c/billion-word-imputation)
The paper: The motivation is a problem suitable to be solved via rule systems. It's a bit unclear why the rule system needs to be grafted on top of an actor model.
Actors: Programming with async messages is hard. Message ordering matters, no clear error reporting, no stack traces, distributed state. This is hardware hard, as in bring in formal verification methods hard. To be avoided in favor of a centralized coordinator solution if at all possible.
I wonder if, alternatively, one could use Rx processing over the stream of events.
Motivating example from the paper:
1. Turn on the lights in a room if someone enters, and the ambient light is less than 40lux.
2. Turn off the lights in a room after two minutes without detecting any movement.
3. Send a notification when a window has been open for over an hour.
4. Send a notification if someone presses the doorbell, but only if no notification was already sent in the past 30 seconds.
5. Detect home arrival or leaving based on a particular sequence of messages, and activate the corresponding scene.
6. Send a notification if the combined electricity consumption of the past three weeks is greater than 200 kWh.
7. Send a notification if the boiler fires three Floor Heating Failures and one InternalFailure within the past hour, but only if no notification was sent in the past hour.
> You can think of this as subtracting older from yours and adding the result to mine, or as merging into mine the changes that would turn older into yours.
The point stands: taking history in account is unconvincing, as it assumes intent where none is explicitly given. In the example, if the top branch had a single commit, AB => ABGAB, then there is no way to reliably infer that A 'intended' [+ABG]AB, vs. AB[+GAB]. Even with the given history, maybe the author of the top branch really intended AB => AB[+GAB], but made an error, corrected in the 2nd commit. The problem is fundamentally ambiguous. We can argue which of the diff3 or anu/pijul heuristics are better. In practice I suspect the difference is not that large.
For completeness, here's a guess of what diff3 does, assuming merging top into bottom, following https://blog.jcoglan.com/2017/05/08/merging-with-diff3.
[bottom] => A [+X] B
[top] => AB [+GAB]
B O T
A A A
+X
B B B
+G
+A
+B