However, it does suggest that there is an opportunity for factoring "Dog" out in the code, at least by name spacing (e.g. Dog.Model).
1,755 karma · joined January 20, 2015
However, it does suggest that there is an opportunity for factoring "Dog" out in the code, at least by name spacing (e.g. Dog.Model).
I didn't understand this part:
> I strongly believe that if GA would make this distinction they would lose a lot fewer people. It is a completely interesting and useful thing to talk about “a representation of a particular class of operations that makes composition and inversion easy”, and completely offputting when you blur the distinction between operators and geometric objects themselves, and write every operation in terms of the geometric product when only a few of them are really compositions of operators.
I can't tell what "a few of them" refers to. What is this potential distinction between operators and geometric objects? Sounds like the the distinction between a group action and a group object?
I am willing to believe that GA is an unnecessary renaming of other simpler things, and also that it has these kind of culty vibes, but I'm focusing on the claim that (I understood as) "unifying the operators and geometric objects" is a bad feature rather than a good feature.
But, pedagogical treatment is a separate question from what is linear algebra.
Should these all be the same wikipedia page?
- https://en.wikipedia.org/wiki/Exterior_algebra
- https://en.wikipedia.org/wiki/Multilinear_algebra
- https://www.georgehart.com/research/multanal.html (okay, not mainstream enough to have a relevant page, but it is extremely relevant in any engineering practice of linear algebra)
Or normal vs tangent vectors transforming differently?
The comment about crashing due to spelling error really should be addressed by some form of static analysis, not by making name lookups more relaxed, in my opinion.
But there is probabilistic sampling that happens (see "temperature").
If you can losslessly convert between the two models, then it seems like you could make git's conflict resolution smarter without changing the underlying data model.
This is probably what you mean by how it's invisible to the user. When does it actually make a difference?
Rationals of bigints doesn't work in general. First of all, you still have to do approximations if you take e.g. a square root or a sine. And even if you have an algorithm that is closed under rational numbers (like the Simplex method for solving linear programs), the number of digits you need in your integers blows up unless you have a tiny problem.
My rough sketch is that inv(A) involves det(A) in the denominator, and the number of digits in det(A) is exponential in nature (n! if A is n-by-n).
I wasn't sure how to debug it.
I would be happy for someone to prove me wrong and show how, e.g. `git branchless` lets you work on a stack from multiple machines.
If I can expand on your "kind of", it would be that because of the kernel trick, it actually does matter that the data itself can determine the "linear" (in an infinite dimensional space, that would require infinitely many parameters under the primal formulation) model.
This is most clearly seen with conversation functions between types defined in different libraries. A collection class might have a method like "from_Array".