(φ (μ (λ)))
01.04.202518:27
Differential of a real-valued function at a point for vectors and operators.
From Alan Kennington's Differential Geometry Reconstructed: A Unified Systematic Framework
From Alan Kennington's Differential Geometry Reconstructed: A Unified Systematic Framework
28.03.202519:00
Emacs package from a friend to archive web pages into Org files:
https://github.com/nitincodery/org-dex.el
Chrome Extension:
https://github.com/nitincodery/org-dex.crx
Firefox Extension: https://github.com/nitincodery/org-dex.xpi
https://github.com/nitincodery/org-dex.el
Chrome Extension:
https://github.com/nitincodery/org-dex.crx
Firefox Extension: https://github.com/nitincodery/org-dex.xpi
27.03.202509:36
25.03.202521:46
Since this package is almost entirely based on using dynamic modules in Emacs, I wrote a detailed blogpost on how this works in Emacs and why it should be used more.
I'll soon add RSS support for the site. It is based on Pollen, a Racket DSL for typography, and in my opinion, supersedes all SSGs. Source is available.
https://www.phimulambda.org/blog/emacs-dynamic-module.html
I'll soon add RSS support for the site. It is based on Pollen, a Racket DSL for typography, and in my opinion, supersedes all SSGs. Source is available.
https://www.phimulambda.org/blog/emacs-dynamic-module.html
24.03.202517:01
To those who might not have read Spivak, he not only encourages the reader to go through the original Gauss paper, but he includes it himself! Chapter 3, of Volume II, A Comprehensive Introduction to Differential Geometry is entirely just this paper of Gauss. He leaves his footnotes, remarking about each derivation, each equation and telling you, that regardless, it is still worthwhile to redo those equations. If the original feels too terse, which it shouldn't, one can go through the aforementioned chapter and it'll slightly be better with Spivak's annotations.
24.03.202514:36
Got it to be stable, and found a way to do superfast scrolling.
Most of the magic is done by C + MuPDF and Emacs' SVG rendering support. Would soon release for ELPA as I finish EPUB support.
Most of the magic is done by C + MuPDF and Emacs' SVG rendering support. Would soon release for ELPA as I finish EPUB support.
27.03.202523:36
25.03.202512:00
24.03.202516:50
The original paper that paved the way for understanding curvature, and of course for Theorema Egregium in differential geometry. It is really readable, both in notation and exposition, for the modern reader and rich in intuition for all the "fundamental forms" that one sees in elementary differential geometry. I remember when I first studied differential geometry from do Carmo (1976), widely considered a go-to for the uninitiated, and I always had the wonder of why exactly the fundamental forms have to be the way they are. Later on I got better intuition, through Spivak, or when I did differential geometry on manifolds, but still I think one can provide a much more refined constructive intuition about such fundamental things without necessarily having to show them as special cases of a general theorem.
The typical representation of Theorema Egregium is the following:
The Gaussian curvature of a surface is invariant under local isometry.
Now, that makes sense, of course, but the intuition is still lacking, even when you look at a proof. Gauss' theorem and its proof both resolve this, where he says:
If a curved surface is developed upon any other surface whatever, the measure of curvature in each point remains unchanged.
Now that is the proof statement, but something that you can read, and get some intuition about.
The typical representation of Theorema Egregium is the following:
The Gaussian curvature of a surface is invariant under local isometry.
Now, that makes sense, of course, but the intuition is still lacking, even when you look at a proof. Gauss' theorem and its proof both resolve this, where he says:
If a curved surface is developed upon any other surface whatever, the measure of curvature in each point remains unchanged.
Now that is the proof statement, but something that you can read, and get some intuition about.
23.03.202510:24
27.03.202515:50
Me and some OCaml friends did some discussion and comparison between implementations of a Segment Tree in Haskell and Reason/OCaml. We were mostly trying to analyze space & time complexity and the extent to which you can remain in pure functional realm or fall back to imperative design. It was fun, my implementation is here. And after the discussion I found two things that it lacks:
1. Not general enough: It works only on arrays of
2. Parent Reference: It uses the standard
While the solution to the first problem is to just use
The Reason/OCaml implementation isn't yet public, but soon would be, during the discussion's stream, funnily enough the implementation developed into using
For those who want to be part of the ongoing discussion or join next time, this happens at the discord server of Reason OCaml India.
1. Not general enough: It works only on arrays of
Int elements, and the combination operators it takes are rigidly stuck to the type (a -> a -> a) when one can simply do a Monoid.2. Parent Reference: It uses the standard
Data.Tree which does not provide any reference for the parent of a child node, thus you'd be tracing the patch from the root node and running in linear time O(n) when in an imperative language it'll simply take a reference and thus be constant time O(1). While the solution to the first problem is to just use
Monoid, the second one isn't that trivial. I forgot that there is a classic Functional Pearl that brought forth the idea of Zipper monad in Haskell, this allows you to locally look up in a general data structure in constant time. So I would probably go the path of that, and maybe also not use arrays and base the tree entirely on a list, since they are efficient in Haskell.The Reason/OCaml implementation isn't yet public, but soon would be, during the discussion's stream, funnily enough the implementation developed into using
for loops, which kind of defeats the point of doing functional programming. In the coming days we might improvise on the implementations and do a benchmark of their time complexity. I might also write a blogpost about Zipper and Segment Trees in Haskell. Segment trees are actually widely applied in computational geometry, and Berg, et.al Computational Geometry (1997) has a nice section (10.3) devoted to this. That was one of the references for my implementation.For those who want to be part of the ongoing discussion or join next time, this happens at the discord server of Reason OCaml India.
26.03.202512:02
In an OOPL data type definitions belong to objects. So I can’t find all the data type definition in one place. In Erlang or C I can define all my data types in a single include file or data dictionary. In an OOPL I can’t - the data type definitions are spread out all over the place.
Let me give an example of this. Suppose I want to define a ubiquitous data structure. ubiquitous data type is a data type that occurs “all over the place” in a system.
As lisp programmers have know for a long time it is better to have a smallish number of ubiquitous data types and a large number of small functions that work on them, than to have a large number of data types and a small number of functions that work on them.
A ubiquitous data structure is something like a linked list, or an array or a hash table or a more advanced object like a time or date or filename.
In an OOPL I have to choose some base object in which I will define the ubiquitous data structure, all other objects that want to use this data structure must inherit this object. Suppose now I want to create some “time” object, where does this belong and in which object…
Joe Armstrong, Why OO Sucks
Let me give an example of this. Suppose I want to define a ubiquitous data structure. ubiquitous data type is a data type that occurs “all over the place” in a system.
As lisp programmers have know for a long time it is better to have a smallish number of ubiquitous data types and a large number of small functions that work on them, than to have a large number of data types and a small number of functions that work on them.
A ubiquitous data structure is something like a linked list, or an array or a hash table or a more advanced object like a time or date or filename.
In an OOPL I have to choose some base object in which I will define the ubiquitous data structure, all other objects that want to use this data structure must inherit this object. Suppose now I want to create some “time” object, where does this belong and in which object…
Joe Armstrong, Why OO Sucks
25.03.202508:52
David Turner, Total Functional Programming, Journal of Universal Computer Science (2004)
24.03.202516:41
Karl Friedrich Gauss, General Investigations of Curved Surfaces (1825-27)
23.03.202508:22
Emacs Lisp Animations
https://dantorop.info/project/emacs-animation/
https://dantorop.info/project/emacs-animation/
29.03.202517:43
27.03.202511:22
25.03.202522:16
While my DNS server and Codeberg fix the issues, here's the Org file for the blogpost.
24.03.202517:19
And then he continues to make that case for curvatures:
24.03.202516:40
Кайра бөлүшүлгөн:
A Math Book
22.03.202518:27
Abstract Algebra: An Inquiry-Based Approach ( Jonathan Hodge - Steven Schlicker - Ted Sundstrom ), 2nd edition. CRC Press 2024
Көрсөтүлдү 1 - 24 ичинде 141
Көбүрөөк функцияларды ачуу үчүн кириңиз.