Some analysts seem to suggest that the things she said were bad.
But they're not.
They're a rare example of someone with some power saying cool honest stuff that comes across their mind.
Unlike the endless mandatory corporate bullshit we usually get otherwise.
Functional programming is a subset of imperative programming Updated 2025-01-10 +Created 1970-01-01
Ciro Santilli thinks imperative programming is just a superset of functional programming where you can have state.
Lists:
- www.gocoder.one/blog/ai-game-competitions-list/ Good list of interest.
- codecombat.com/
Every tree is a directed acyclic graph.
But not every directed acyclic graph is a tree.
Example of a tree (and therefore also a DAG):Convention in this presentation: arrows implicitly point up, just like in a and so on.
5
|
4 7
| |
3 6
|/
2
|
1git log, i.e.:- 1 is parent of 2
- 2 is parent of 3 and 6
- 3 is parent of 4
Example of a DAG that is not a tree:This is not a tree because there are two ways to reach 7:
7
|\
4 6
| |
3 5
|/
2
|
1- 2, 3, 4, 7
- 2, 5, 6, 7
But we often say "tree" intead of "DAG" in the context of Git because DAG sounds ugly.
Example of a graph that is not a DAG:This one is not acyclic because there is a cycle 2, 3, 4, 5, 2.
6
^
|
3->4
^ |
| v
2<-5
^
|
1There are two ways to organize a project:
- linear history
- branched history: history with merge commits
Some people like merges, but they are ugly and stupid. Rebase instead and keep linear history.
Linear history:
5 master
|
4
|
3
|
2
|
1 first commitBranched history:
7 master
|\
| \
6 \
|\ \
| | |
3 4 5
| | |
| / /
|/ /
2 /
| /
1/ first commitHere commits 6 and 7 are the so called "merge commits":
- they have multiple parents:
- 6 has parents 3 and 4
- 7 has parents 5 and 6
- they are useless and don't contain any real information
Which type of tree do you think will be easier to understand and maintain?
????
????????????
You may disconnect now if you still like branched history.
Generate a minimal test repo. You should get in the habit of doing this to test stuff out.
#!/usr/bin/env bash
mkdir git-tips
cd git-tips
git init
for i in 1 2 3 4 5; do
echo $i > f
git add f
git commit -m $i
done
git checkout HEAD~2
git checkout -b my-feature
for i in 6 7; do
echo $i > f
git add f
git commit -m $i
doneOh but there are usually 2 trees: local and remote.
So you also have to learn how to observe and modify and sync with the remote tree!
But basically:to update the remote tree. And then you can use it exactly like any other branch, except you prefix them with the remote (usually
git fetchorigin/*), e.g.:origin/masteris the latest fetch of the remote version ofmasterorigin/my-featureis the latest fetch of the remote version ofmy-feature
Generally means that he form of the equation does not change if we transform .
This is generally what we want from the laws of physics.
E.g. a Galilean transformation generally changes the exact values of coordinates, but not the form of the laws of physics themselves.
Lorentz covariance is the main context under which the word "covariant" appears, because we really don't want the form of the equations to change under Lorentz transforms, and "covariance" is often used as a synonym of "Lorentz covariance".
TODO some sources distinguish "invariant" from "covariant": invariant vs covariant.
A random field you add to make something transform locally the way you want. See e.g.: Video "Deriving the qED Lagrangian by Dietterich Labs (2018)".
This was the Holy Grail as of 2023, when text-to-image started to really take off, but text-to-video was miles behind.
There are unlisted articles, also show them or only show them.