]]>For decades, we have been told by systems programmers that counting from zero is "closer to the metal," "mathematically purer," and the definitive mark of a "real programmer." Languages that use 1-based indexing—like Julia, R, MATLAB, and Fortran—are often patronized as quirky tools for mathematicians who just "don't understand computer science."
I call bullshit.
0-based indexing is not a fundamental law of computing. It is an implementation leak. The first item in a sequence becomes the "zeroth" element only when you choose to describe it by its displacement from a memory address. While that perspective is perfectly valid for pointer arithmetic, buffers, and low-level boundaries, it is fundamentally the wrong way to name human-facing objects.
What started as a bare-metal address-offset convention in C was wrongfully elevated into a universal philosophy of language design. By forcing humans to adopt this machine-centric view for high-level mathematical modeling, the software industry has condemned generations of developers to a permanent, exhausting cognitive friction.
It is time to tear down this illusion. Let's start from the very beginning: how human beings actually perceive the world.
Before we even touch a keyboard, every single human being learns to count objects starting from 1. This isn't just an arbitrary childhood habit; it is the fundamental reality of discrete mathematics.
Let's look at a classic elementary school math problem—the "Tree-Planting Problem." Imagine a row of trees:
O O O O O O O O
1 2 3 4 5 6 7 8
Question: How many trees are there from the 3rd tree to the 7th tree, inclusive?
Any second-grader will tell you the answer: 7 - 3 + 1 = 5.
The formula for the number of elements in a closed interval [i, j] is j - i + 1. This formula is hardwired into human intuition because it accurately describes the physical reality of discrete objects.
Yet, the 0-based zealots will look at this and complain: "Ugh, that +1 is so ugly and error-prone! We should use half-open intervals [i, j) and 0-based indexing so the length is just j - i!"
This is where the delusion begins. To avoid typing a simple +1—a mathematical truth of closed intervals—0-based languages force you to shift your entire cognitive model of the universe. They demand that the first tree be called the "zeroth tree." They sacrifice the natural naming of physical entities just to make the arithmetic of interval boundaries look marginally cleaner.
Trading a massive, global cognitive distortion for a microscopic local algebraic convenience is not good engineering. It is anti-human.
The central distinction that the 0-based camp refuses to acknowledge is this:
1-based indexing names objects. 0-based indexing names displacements.
When humans refer to physical or mathematical entities, we use ordinal positions: the first child, the first employee, the first row of a matrix, the first equation in a dynamic system. Nobody naturally says "the zeroth apple" or "the zeroth physical unit."
Of course, a programming language can redefine reality. A language can dictate anything. But forcing a definition that violently conflicts with human cognition is the hallmark of poor language design.
Consider a simple sequence:
Elements: A B C
Object Index: 1 2 3
Offset: 0 1 2
Both integer rows describe something real, but they answer entirely different questions. The object index answers: "Which object is this?" The offset answers: "How far is this object from the chosen origin?"
A good language design should not pretend they are the same thing. The first element has a displacement of 0 from the beginning. That is a physical truth of memory layout. But it is still the first element. Confusing these two facts is the original sin of 0-based indexing.
The first object is not an offset. It is an object.
The root of this madness lies in the C programming language and its pointer arithmetic:
a[i] == *(a + i)
In C, i is not an "index" in the mathematical sense. It is an offset (displacement). It answers the question: "How many memory strides away are we from the base address?" The first element is 0 strides away, hence a[0].
As a low-level machine implementation, this is completely logical. But here is the critical distinction:
Offset is an implementation perspective. Ordinal (1st, 2nd, 3rd) is a user-facing identity.
When you write a mathematical formula like , represents the identity of the variable. It answers the question: "Which specific object is this?"
0-based languages commit the ultimate semantic theft: they take a machine-level offset coordinate and violently force it onto the user as an object identity. They force you to run a permanent, non-stop "translation daemon" in the back of your mind. Every time you want the -th element, you must subconsciously calculate k - 1.
This is not a "frictionless" programming experience. This is cognitive labor. You are manually doing the translation that the compiler was invented to do for you.
Machines are built to serve humans, not the other way around. If my mathematical model starts at 1, the language should start at 1.
So, how did this semantic theft become a religious dogma? Whenever you attack 0-based indexing, someone will inevitably quote Edsger W. Dijkstra's famous manuscript, Why numbering should start at zero (EWD831).
Dijkstra argued that using half-open intervals 0 <= i < N is the cleanest way to represent sequences, as the length is simply N - 0 = N, and adjacent sequences share a clean boundary.
Let's dismantle this sacred cow. Dijkstra was an absolute genius, but in this specific argument, he committed a massive semantic theft: he conflated objects with boundaries.
Look at a sequence of elements:
Elements: A B C D E
If you are slicing an array, inserting an element, or calculating a prefix sum, you are dealing with boundaries, or gaps:
Boundaries: 0 1 2 3 4 5
| A | B | C | D | E |
Yes, boundaries start at 0. The gap before the first element is gap 0. Prefix lengths start at 0. Displacements start at 0. Dijkstra perfectly optimized the algebra of boundaries.
But a programming array is primarily a collection of elements, not just boundaries. Element A is the 1st object. Element B is the 2nd object.
The fact that an algorithm has a zero state does not mean the data objects inside that algorithm should be zero-indexed.
Dijkstra's fatal flaw was forcing the numbering system of boundaries onto the objects themselves. Just because the boundary before A is 0, it does not mean the object A itself should be named 0. You cannot rename a discrete physical object just because it makes your slicing syntax slightly prettier.
The desire to unify everything under 0-based coordinates leads to the modern nightmare of LeetCode grid problems. When you do that, you get the modern nightmare of LeetCode grid problems: forcing developers to map a 2D physical grid starting from (0,0). A matrix cell is an object, not a displacement vector. Calling the upper-left cell (0,0) is not mathematics; it is storage layout leaking into the problem statement, violently bullying human intuition.
Another defense of 0-based indexing is that it creates one unified coordinate system:
element index
boundary index
prefix length
storage offset
slice endpoint
can all be represented with the same integers if indexing starts from 0. This supposedly reduces conversions and therefore reduces mistakes.
This sounds plausible only if one has already accepted the offset worldview. From the perspective of object-centered programming, it is not simplification. It is semantic compression with hidden costs.
But this is not true semantic unity. It is flattening different meanings into one number system.
The price of this flattening is that object identity gets distorted. The first element becomes 0 so that boundaries, offsets, and prefix lengths can look cleaner.
Even in low-level buffer manipulation, this should be understood as an implementation convention, not as a superior human-facing indexing model. It is certainly not a universal language design principle.
0-based indexing does not eliminate off-by-one reasoning. It relocates it. It reduces some boundary errors by creating object-identity errors.
In a 1-based model, we may still write transformations such as:
physical_offset = object_index - 1
That is fine. The point is not to make -1 disappear from the universe. The point is to put the cognitive burden in the right place.
If we are dealing with implementation offsets, let offset conversion happen there. If we are dealing with human-facing object indices, the first object should be 1.
A notation that is locally elegant for slicing but globally hostile to object naming is not good language design.
When defenders of 0-based indexing are backed into a corner, they almost always resort to the classic performance argument:
"1-based indexing is inefficient. If you start at 1, the compiler has to waste CPU cycles doing *(base + i - 1) for every array access!"
This argument is incredibly persistent, but it is fundamentally flawed. It exposes a profound lack of imagination regarding how programming language compilers and object models actually work.
The critique *(base + i - 1) assumes that the logical origin of an array must be the physical address of its very first element. Yes, if you blindly force a 1-based index into a 0-based origin model, you get a -1 penalty.
But why should we accept the 0-based origin model as absolute truth?
Enter the Virtual Origin Shift.
A modern, intelligently designed 1-based language does not patch a 0-based system; it redefines the origin. Instead of anchoring the array to the first physical element, the compiler can simply set the logical origin (the base pointer) to the position of a one-before-begin sentinel.
Physical memory: [ element_1 ] [ element_2 ] [ element_3 ]
^
physical_base
Logical origin: virtual_base = physical_base - sizeof(element)
Memory access: A[i] = *(virtual_base + i) for i = 1, 2, ...
Look at that. There is no i - 1. There is no performance penalty. There is no extra subtraction at runtime. The memory offset calculation for 1-based indexing (origin + i) is exactly as elegant and direct as it is for 0-based indexing.
C standardizes the "one-past-end" sentinel to make 0-based slicing neat. A 1-based language simply leverages a "one-before-begin" virtual origin. Both models are perfectly coherent at the hardware level. The difference is that the 1-based model hides the offset translation inside the compiler, leaving the human user with a clean, mathematically accurate interface.
0-based indexing is not the "natural consequence of memory." It is the natural consequence of choosing the wrong origin and forcing the human to do the compiler's job.
Another desperate defense is that 0-based indexing prevents "off-by-one" errors (OBOEs). The claim is that half-open intervals [0, N) magically solve boundary mistakes.
Let's be brutally honest: 0-based indexing does not eliminate off-by-one errors. It merely relocates them.
It reduces some errors when slicing buffers, but it creates a massive, permanent source of errors in object identity and algorithm design. When you are writing a complex Dynamic Programming (DP) algorithm, or implementing a mathematical formula from a research paper, you are inherently dealing with -th states and -th characters.
In a 0-based language, if state i represents the first i characters, but the -th character itself is at string[i-1], you have engineered a cognitive nightmare. The code becomes littered with s[i-1] patches. This isn't just "writing a few more characters"; this is severe semantic misalignment.
When a language design forces you to constantly doubt whether i means "the -th object" or "an offset of ", it breeds paranoia. In 1-based languages, if the math says , the code says A[i, j]. The boundary of the physical entity perfectly aligns with the logical boundary.
The debate between 0-based and 1-based indexing is not just about syntax. It is about who yields to whom in the software engineering hierarchy.
The 0-based paradigm demands that the human mind bends to accommodate the machine's memory layout. It wraps this compromise in the guise of "elegance" and "professionalism," punishing those who rely on natural human counting.
1-based indexing, when implemented with modern compiler architecture, proves that we do not have to compromise. We can have bare-metal, C-level performance without sacrificing the purity of mathematical modeling.
It is time to stop pretending that is the start of a sequence of objects. Zero is a count. Zero is an offset. Zero is empty.
But the first element? The first element is exactly that: 1.
If we truly want to reduce cognitive load and rediscover the pure joy of programming, it begins with choosing the right origin. It begins by counting from 1.
If the mathematical and architectural arguments for 1-based indexing are so robust, why does the mainstream programming community defend 0-based indexing with such religious fervor?
The answer does not lie in computer science. It lies in social psychology. The relentless defense of 0-based indexing is a textbook manifestation of two well-documented psychological phenomena: Cognitive Dissonance and the Sweet Lemon Effect.
Every Computer Science student and IT professional has gone through the painful, counter-intuitive process of rewiring their natural human cognition to adapt to the machine's 0-based memory layout. It took years of debugging Index Out of Bounds errors and mentally calculating i - 1 to finally make this unnatural habit feel "automatic."
When you present these developers with the fact that 1-based indexing is a superior, zero-friction design for object modeling, it triggers massive Cognitive Dissonance.
To accept that 1-based indexing is better is to accept a devastating truth: The immense mental effort they spent over the last decade adapting to the machine was largely unnecessary. It means admitting that their "hard-earned programming intuition" is not a mark of high intelligence, but merely a scar left by a 1970s hardware compromise.
Human ego inherently rejects this. To protect their self-worth and justify their sunk costs, they instinctively lash out. They must fiercely defend 0-based indexing, not because it is mathematically correct, but to convince themselves that their suffering had meaning.
The second psychological barrier is the brutal reality of the job market.
Deep down, many smart engineers know that 1-based languages (like Julia) offer a far more elegant and mathematically pure experience. But they also know they are trapped. The corporate world, the tech giants, and the global job market are completely dominated by C, Java, Python, and JavaScript. They are chained to the 0-based monolith to pay their bills and advance their careers.
When you cannot have what is good, the mind protects itself by deciding that what you do have is actually exactly what you wanted all along. This is the Sweet Lemon Effect (the inverse of sour grapes).
Instead of facing the depressing reality that they are just digital laborers forced to use suboptimal, legacy tools dictated by corporate momentum, they deceive themselves. They hallucinate non-existent mathematical elegance in 0-based slicing. They convince themselves the "lemon" is sweet. They chant "0-based is closer to the metal" to mask the bitter taste of having no choice in the matter.
The defense of 0-based indexing is rarely about logic anymore. It is an industry-wide coping mechanism.
Whether you are building a high-level mathematical model, a web backend, or a low-level memory buffer, demanding 1-based indexing is not just a syntactic preference. You are rejecting the cognitive labor imposed by a 1970s hardware constraint. You are demanding that the language design enforces a fundamental separation of concerns: the compiler handles the offsets, and the human handles the objects.
And objects start at 1.
]]>At first glance, the market looks full of convenient tools. There are AI poster generators, AI slide makers, AI document editors, AI diagram tools, AI writing platforms, and many polished Software as a Service (SaaS) products that promise to turn a prompt into a beautiful output. For many users, this is attractive. You type a sentence, pick a template, drag a few objects, and export a PDF.
But once I looked at the problem from the perspective of a geek, the surface convenience became less interesting than the underlying structure.
A poster is not just a picture. A technical diagram is not just decoration. A paper is not just formatted text. These are user assets. They encode ideas, methods, assumptions, structures, relationships, workflows, evidence, and arguments. If these assets are created inside a black-box platform, then the user may be able to edit them visually, but does not fully own the logic by which they are represented, rendered, transformed, and preserved.
That distinction matters.
Many AI poster tools probably do not rely purely on image generation. Behind the scenes, they likely use some internal object model: text boxes, shapes, panels, coordinates, fonts, colors, and layout constraints. The final poster may be editable in a web GUI. In that narrow sense, they are not merely producing a dead image.
But that does not solve the real problem.
The issue is not whether a poster consists of editable objects. The issue is whether the user has access to the object model, the file format, the rendering logic, and the toolchain that turns source representation into visual output.
A closed SaaS platform may give me objects to drag. But those objects live inside someone else's system. The platform controls the schema, the renderer, the export logic, the templates, the pricing, and the future compatibility of my work. I can edit what the platform allows me to edit. I can export what the platform allows me to export. I can preserve what the platform allows me to preserve.
That is not the same as owning the asset.
This is why I became interested in a very different workflow:
Natural language intention -> LLM-assisted source editing -> open structured file -> open renderer/editor -> human visual refinement -> portable output.
In practice, one concrete version of this is:
LLM -> draw.io XML -> diagrams.net/draw.io GUI -> SVG/PDF/PNG export.
At first, this sounds like a cheap trick: instead of paying for an AI poster SaaS, ask an LLM to edit a draw.io XML file directly.
But the deeper point is not cost. The deeper point is control.
It is tempting to say that draw.io works well with LLMs because its file format is XML. XML is text. LLMs can read text, modify text, and produce text. Therefore, LLMs can edit draw.io files.
That explanation is only half correct.
Many commercial formats are also structured. A .docx file, for example, is essentially a package containing XML files. It is not a mysterious binary blob in the old sense. In principle, one can inspect it, modify it, and generate it.
But anyone who has dealt seriously with Word documents knows the problem: readable does not mean predictable.
Word processing formats carry decades of historical compatibility. The specification may contain behaviors inherited from old versions, compatibility modes, layout conventions, default settings, and implementation-dependent interpretations. You may edit the XML, but the GUI may not behave as expected. You may change a paragraph style, only to discover that numbering, spacing, table layout, floating objects, fonts, or pagination are affected by rules hidden somewhere else.
The file is structured, but the system is not fully transparent.
This is the critical distinction:
Structured format is not the same as controllable toolchain.
For LLM collaboration, the problem is not simply whether the file can be read. The problem is whether the LLM can reason about how the file will be interpreted.
In the case of draw.io, the advantage is not merely that the .drawio file is XML. The important point is that the editor and renderer are open enough for the behavior of the file to be studied, debugged, and understood. If something goes wrong in the XML, one can inspect not only the file, but also the logic that interprets the file.
That changes the nature of LLM assistance.
Without access to the rendering logic, the LLM is guessing. With access to the source format and the implementation, the LLM can work within an intelligible graphical language.
XML provides editability. Open implementation provides explainability. The GUI provides human correction. The export formats provide portability.
The power comes from the combination.
The same idea also applies to documents. This is why LaTeX has remained important for serious technical writing.
LaTeX is not valuable simply because it produces beautiful PDFs. Its deeper value is that it turns documents into source files. A paper becomes something that can be edited as text, version-controlled, searched, diffed, compiled, debugged, and reproduced.
The workflow is transparent in a way that GUI-based document editing often is not. There may still be complexity. LaTeX templates can be painful. Packages can interact in obscure ways. Compilation errors can be ugly. But the document is fundamentally source-driven.
That makes it a natural partner for LLMs.
LLMs are much better at modifying source representations than manipulating opaque GUIs. They can revise Markdown, LaTeX, XML, SVG, YAML, Julia code, configuration files, and structured documents. They can explain diffs, trace errors, update repeated patterns, and refactor text. They can operate where the work is represented as explicit structure.
This is why I currently prefer Quarto for many documents.
Pure LaTeX is powerful, but it can be unnecessarily heavy for everyday writing. Quarto provides a practical front end: Markdown for readable writing, YAML for metadata, Pandoc for conversion, and LaTeX or other backends when needed. It preserves the source-file philosophy while reducing the friction.
In that sense, Quarto is not a rejection of LaTeX. It is a more ergonomic layer over the same general principle:
Keep the core asset as an open, text-based, version-controllable source file.
The strongest form of LLM-assisted work is not "click a magic button in a platform."
It is this:
The user expresses intent. The LLM translates that intent into modifications of open source files. The open toolchain renders or compiles those files. The user inspects and corrects the result. The final asset remains portable and maintainable.
This is fundamentally different from using an AI feature inside a closed SaaS editor.
In a closed platform, the AI is embedded inside the vendor's environment. The output is often a platform object. The history, schema, rendering, and future compatibility are controlled externally.
In an open-source-file workflow, the LLM is a replaceable assistant. It does not own the document. It does not own the diagram. It does not own the project. It only helps transform an asset that remains under the user's control.
That is the key architectural difference.
For posters, this means LLMs should generate or modify draw.io XML, SVG, Mermaid, Graphviz, Typst, or other open representations, rather than only producing flat images or platform-locked designs.
For documents, this means LLMs should work on Markdown, Quarto, LaTeX, BibTeX, CSL, YAML, and related source files, rather than only operating inside Word or a proprietary cloud editor.
For software, this means LLMs should work with code, tests, documentation, CI, and reproducible environments, rather than only producing isolated snippets.
A screenshot is dead. A source file is alive.
A screenshot can be viewed, but not meaningfully edited. A source file can be modified, regenerated, reviewed, and reused. A screenshot captures a moment. A source file captures a process.
This matters especially for technical work, because communication is iterative. Figures change. Terminology changes. Models change. Equations change. Experimental results change. Reviewers ask for revisions. Collaborators ask for different layouts. Posters need new dimensions. A method diagram becomes a figure in a paper, then a slide in a talk, then documentation for software.
If the asset is a flat image or trapped inside a SaaS platform, every revision becomes manual repair.
If the asset is source-like, revisions become engineering operations.
This is why "Poster-as-Code" is not just a slogan. It means treating visual communication as something closer to software or LaTeX: structured, inspectable, editable, and reproducible.
A poster should not be a one-time visual artifact. It should be a maintained representation of an argument.
It is easy to frame this as an open-source preference, but that is too shallow.
The real issue is not moral purity. The issue is whether the toolchain allows understanding, debugging, migration, and long-term maintenance.
Open source matters because it makes the interpreter visible.
For a document, the interpreter may be a LaTeX engine, Pandoc, or a rendering pipeline. For a diagram, the interpreter may be the draw.io/diagrams.net editor and renderer. For software, the interpreter may be a compiler, package ecosystem, test runner, or CI system.
If the source file is visible but the interpreter is hidden, the workflow remains partially black-boxed. The LLM can edit inputs, but it cannot fully understand why outputs behave as they do.
This is the lesson from Word-like systems. A document format may be technically inspectable, but if the actual rendering behavior depends on a closed, historically layered GUI engine, the result is difficult to predict.
By contrast, when both the source representation and the interpreting toolchain are open, LLM collaboration becomes much more powerful. Errors become traceable. Behavior becomes explainable. Outputs become reproducible. The user can intervene at every layer.
Open source is therefore not merely about avoiding license fees. It is about reducing epistemic dependence on tools whose behavior cannot be fully inspected.
For serious work, that is not a small issue.
Of course, cost matters. Many students, independent creators, and small teams cannot casually pay for every commercial SaaS tool, design platform, document service, or specialized editor. The financial burden of modern tooling is real.
But the deeper cost is lock-in.
A cheap SaaS tool can become expensive if it captures your assets. A convenient platform can become costly if leaving it means losing editability, structure, metadata, or reproducibility. A polished editor can become a liability if its internal format changes, export quality degrades, or pricing model shifts.
This is why I do not think the goal is simply "never spend money."
A better principle is:
Spend money on replaceable resources, not on locking up irreplaceable user assets.
Compute is replaceable. API providers are replaceable. Models are replaceable. Hardware can be upgraded. Even a commercial LLM API can be acceptable if it is only used as a temporary intelligence layer.
But the core assets should remain portable: source files, open formats, version history, reproducible builds, editable diagrams, and local copies.
In my current workflow, an OpenAI API call may help modify a document or diagram. But the resulting asset is not stored inside OpenAI. It is not a proprietary AI-platform object. It is a Quarto file, a Markdown file, a draw.io XML file, a Julia source file, an SVG, or a PDF.
The LLM service can be replaced later by another API or by a local LLM running on my own GPU. The core workflow remains intact.
That is the difference between using a commercial service and being owned by one.
The long-term direction is clear to me: a personal workstation built around open tools.
Today, the LLM layer may depend on a cloud API. Tomorrow, with local hardware, it may run locally. That transition should not require changing the structure of the core assets.
This is the architecture I care about.
Not "AI replaces tools." Not "LLMs generate everything." Not "LLMs make design automatic."
Rather:
LLMs become source-level collaborators inside an open, inspectable, user-controlled toolchain.
That is a much more durable vision.
Modern SaaS tools often sell convenience. Convenience is not bad. But convenience can hide a transfer of control.
The user gives the platform intention, content, structure, and data. The platform returns a polished output. In the short term, this feels efficient. In the long term, the user may discover that the real asset has never fully belonged to them.
Serious work should not work that way.
A user should be able to inspect the document source, understand the diagram representation, reproduce the figure, migrate the project, regenerate the output, and continue editing years later without depending on a vendor's web interface.
That is not nostalgia for old tools. It is a practical requirement for serious intellectual work.
AI makes this even more important. As AI systems become more capable, the temptation to work entirely inside closed AI platforms will increase. But the more powerful AI becomes, the more important it is to decide where its outputs land.
If AI produces platform-locked artifacts, then AI accelerates dependence. If AI produces open source assets, then AI strengthens independence.
That choice is architectural.
The central question is not "Which AI tool can generate the best poster?"
The central question is:
Where does the asset live, and who controls it?
If the asset lives inside a closed platform, the user is renting convenience. If the asset lives in an open, inspectable, version-controllable source format, the user owns a durable piece of intellectual infrastructure.
This is why I care about workflows such as Quarto for documents and draw.io XML for diagrams. They allow LLMs to collaborate without taking control away from the user. They turn communication into something closer to engineering: transparent, reproducible, editable, and portable.
The goal is not merely to save money. The goal is to make money less relevant to the ability to create, express, revise, and preserve work.
Money can be spent on compute. Money can be spent on hardware. Money can be spent on replaceable services.
But money should not have to be spent to keep one's own assets editable, understandable, and alive.
That is the real promise of LLMs combined with open formats and open toolchains:
not automatic content generation, but the return of control.
User assets should belong to users.
]]>The Jacobian-Free Newton–Krylov (JFNK) method is a nonlinear solver that combines Newton’s method with Krylov-subspace linear solvers without ever forming the Jacobian matrix explicitly.
At each Newton iteration we solve the linear system
using a Krylov method (e.g. GMRES). Rather than assembling , JFNK approximates Jacobian–vector products via finite differences:
with a small . This “matrix-free” approach reduces memory and computational cost when is large or expensive to form, and allows reuse of existing residual-evaluation code. Preconditioning can still be applied by approximating or its inverse action. JFNK is widely used in large-scale simulations (e.g., fluid dynamics, reactive flows) where explicit Jacobian assembly would be prohibitive.
using LinearAlgebra, LinearMaps, Krylov, Printf
F(x) = [x[1] + x[2]^2, x[1] + 2x[2] + x[1] * x[2]]
function JFNK(F, x0; tol=1e-10, k_max=20, verbose=true)
n = length(x0)
x = copy(x0)
r = copy(F(x))
# *using `LinearMaps` create a matrix-free operator for Jacobian-vector product J*v ≈ (F(x+δ*v) - F(x)) / δ
Jop = LinearMap(v -> Jv_product(v, F, x, r), n, n)
k = 0
solved = false
while !solved && k < k_max
k += 1
v, stats = Krylov.gmres(Jop, -r)
x .+= v
r .= F(x)
normr = norm(r)
verbose && @printf(" %2d: x = [%.2e %.2e], ||r|| = %.2e\n", k, x[1], x[2], normr)
if normr < tol
if verbose
printstyled("Equation solved.\n"; color=:green)
println("Because the residual norm is less than specified tolerance.\n")
end
solved = true
end
if k == k_max
if verbose
printstyled("Failed to solve the equation.\n"; color=9)
println("JFNK not converge in $k_max iterations.\n")
end
end
end
return x
end
function Jv_product(v, F, x, r)
# Finite-difference parameter
δ = sqrt(eps()) * max(norm(x), 1.0)
return (F(x .+ δ .* v) .- r) ./ δ
end
x0 = [1.5, 0.1]
x = JFNK(F, x0)
Inputs
F (Function):
The nonlinear residual function . Each call F(x) returns an -element vector.
x0 (AbstractVector{<:Real}):
The initial guess for the solution, of length . The algorithm will refine this vector.
tol (Real, keyword; default 1e-10):
The stopping tolerance on the residual norm. Once , iteration stops.
k_max (Integer, keyword; default 20):
The maximum number of Newton–Krylov (outer) iterations allowed before giving up.
verbose (Bool, keyword; default true):
If true, print progress each iteration (values of x and ) and a final success/failure message with colored output.
Internal Variables
n: problem size (length of x0).
x: current iterate (updated each iteration).
r: current residual, .
]]>using PkgTemplates
t = Template(
user = "Your_GitHub_username",
authors = ["name <your_email@example.com>"],
# Specify the directory where the generated package is stored
dir = "D:\\packages",
# Specify the minimum Julia version required by the package
julia = v"1.10",
# Configure multiple plugins to customize various aspects of the package
plugins = [
ProjectFile(version=v"0.1.0-DEV"), # Creates a Project.toml.
# version::VersionNumber: The initial version of created packages.
Tests(),
Readme(),
License(name="ASL"),
GitHubActions(extra_versions=["1", "lts"]),
TagBot(),
# Automatically check for dependent updates and generate PRs
CompatHelper(),
# Add GitHub Actions-based online documentation build support for packages
Documenter{GitHubActions}(),
# Logo information for documentation.
Logo(),
BlueStyleBadge(),
ColPracBadge(),
PkgEvalBadge(),
# Create a .JuliaFormatter.toml file
Formatter(),
# Sets up a PkgBenchmark.jl benchmark suite.
PkgBenchmark(),
# To ensure benchmark reproducibility, you will need to manually create an environment in the benchmark subfolder (for which the Manifest.toml is committed to version control). In this environment, you should at the very least:
# pkg> add BenchmarkTools pkg> dev your new package
]
)
Use the template to generate a new package, and name the package "MyNewPackage".
generate(t, "MyNewPackage")
get
Dict, Array) or other containers with customizable interfaces.get(collection, key, default) will attempt to retrieve the value for key from collection. If the value is not found, default will be returned.d = Dict(:a => 1, :b => 2)
println(get(d, :a, 0)) # 1
println(get(d, :c, 0)) # 0 (Due to :c not existing)
getproperty
.).obj.someproperty syntax on an object obj, Julia will call getproperty(obj, :someproperty) to get the property. You can also define/override the Base.getproperty method in your custom types to execute some custom logic when accessing properties (such as lazy loading, redirecting to other fields, calculating virtual properties, etc.).struct MyType
x::Int
end
function Base.getproperty(m::MyType, sym::Symbol)
if sym === :y
return m.x + 1
else
return getfield(m, sym) # fallback to default field access
end
end
m = MyType(10)
println(m.x) # Actual call getproperty(m, :x) -> getfield(m, :x)
println(m.y) # Actual call getproperty(m, :y) -> Custom logic returns 11
getproperty.getfield
getfield(obj, :fieldname) is low-level access to a field of a structure and does not trigger the overriding logic of getproperty. In other words, it just “gets the actual field in the object” and does not execute additional custom methods.struct MyType
x::Int
end
m = MyType(10)
println(getfield(m, :x)) # 10
getfield when you need to bypass any possible getproperty overloads or when you explicitly want to access the fields of the underlying structure directly. For example, in a custom implementation of getproperty, getfield is often used to get the actual field value.get is a high-level "safe" getter function for data structures that provides default values to handle missing keys.getproperty is the mechanism behind the dot syntax (.), allowing users to customize property access behavior through overloading.getfield is the lowest-level function that directly accesses the fields of a structure without any overloading. It is generally only explicitly called when writing low-level code or customizing getproperty.To iterate over the elements within an array, there are several different ways to write the code. Now suppose we have such an array: a = copy(reshape(1:16, 4, 4))
4×4 Matrix{Int64}:
1 5 9 13
2 6 10 14
3 7 11 15
4 8 12 16
In Julia, matrices are stored column-first. Hence, eachindex() iterates over matrix a in column order.
eachindex() returns the index of each element of a matrix, of type Intfor i in eachindex(a)
println("Index: $i, Element: $(a[i])")
end
Index: 1, Element: 1
Index: 2, Element: 2
Index: 3, Element: 3
Index: 4, Element: 4
Index: 5, Element: 5
Index: 6, Element: 6
...
in a returns each element of a matrix, of type eltype(a)for element in a
println("Element: $element")
end
The pairs() function, when used as an iterator, can iterate not only over arrays, but also over Pairs and dictionaries.
pairs(a::Vector) returns a pair of index and value, of type Tuple{Int,eltype(a)}pairs(a::Matrix) returns a pair of index and value, of type Tuple{CartesianIndex{2},eltype(a)}pairs(::Dict) returns a pair of key and value, of type Tuple{eltype(a.keys),eltype(a.vals)}A [println("Index: $i, Element: $element") for (i, element) in pairs(a)] gives:
Index: CartesianIndex(1, 1), Element: 1
Index: CartesianIndex(2, 1), Element: 2
Index: CartesianIndex(3, 1), Element: 3
Index: CartesianIndex(4, 1), Element: 4
Index: CartesianIndex(1, 2), Element: 5
Index: CartesianIndex(2, 2), Element: 6
...
The first parameter i produced by enumerate is the index of natural number starting from 1.
A [println("Index: $i, Element: $element") for (i, element) in enumerate(a)] gives:
Index: 1, Element: 1
Index: 2, Element: 2
Index: 3, Element: 3
Index: 4, Element: 4
Index: 5, Element: 5
Index: 6, Element: 6
...
This function iterates over the nth axis of array a.
for element in axes(a, 1)
println("Element: $element")
end
Element: 1
Element: 2
Element: 3
Element: 4
An iterator can be created using parentheses wrapped around an array and a for loop -> (a[i] for i in a)
For example, we can create a row index iterator for matrix x:
x = rand(1000, 4);
eachrow_x = (x[i:i, :] for i in axes(x, 1));
eachrow_x = (view(x, i:i, :) for i in axes(x, 1));
eachrow_x = eachrow(x);
for (i, xi) in enumerate(eachrow_x)
println("Index: $i, Element: $element")
xi[1] = 0.0
end
Line 2 let the for loop performs a slicing operation on the matrix x at each iteration, producing a new vector for which a memory allocation occurs.
Lines 3 and 4 are equivalent iterators that let the for loop produce a row view of the matrix x per iteration. No memory allocation.
print("\033c")
println("Press any key to continue...")
readline()
println("Continuing execution...")
input = stdin |> readline |> split |> x -> parse.(Int, x)
There are many ways to print a matrix, and I'm going to cover all the ones I know of.
matrix = [0.0 2.3456 20.0;
4.5678 5.0 123456.7890;
0.001234 123.456 0.0000078901]
The most straightforward way is to enter the variable name matrix into the REPL, which is equivalent to display(matrix) and @info "Message" matrix, they all call Base.show(stdout, "text/plain", matrix).
We will get the following output:
3×3 Matrix{Float64}:
0.0 2.3456 20.0
4.5678 5.0 1.23457e5
0.001234 123.456 7.8901e-6
"text/plain"orMIME("text/plain)as the second argument indicates a human-readable log format.
Another set of output functions are print(matrix), println(matrix), and show(matrix), they all call Base.show(stdout, matrix). Their output is more concise and easy to use as input/output for program data streams:
[0.0 2.3456 20.0; 4.5678 5.0 123456.789; 0.001234 123.456 7.8901e-6]
To print all decimals, use Base.print_matrix(stdout, matrix)
0.0 2.3456 20.0
4.5678 5.0 123456.789
0.001234 123.456 7.8901e-6
If the numbers in the array are not on the same order of magnitude, or if some of the numbers are integers but the whole array is Float64, these integers are forced to be appended with a ".0", which makes it hard to read, such as the above variable matrix. The following line of code allows you to pretty print the matrix in "%7.3g " format.
using Printf
# for a matrix, one can use
foreach(row -> (foreach(x -> @printf("%7.3g ", x), row); println()), eachrow(matrix))
# for a vector, use
println("matrix=[" * join(map(x -> @sprintf("%.4f", x), matrix), " ") * "]")
In this way, the integers in the matrix are not accompanied by “.0” and the length of each number is controlled.
0 2.35 20
4.57 5 1.23e+05
0.00123 123 7.89e-06
PrettyTables.jl provides a format for printing matrices specifically, and the same can be done with "%.3g " for pretty printing.
using PrettyTables
pretty_table(matrix;
tf=tf_matrix,
show_header=false,
formatters=ft_printf("%.3g"),
isplay_size=(-1, -1)
)
┌ ┐
│ 0 2.35 20 │
│ 4.57 5 1.23e+05 │
│ 0.00123 123 7.89e-06 │
└ ┘
The
display_size=(-1, -1)statement allows you to print the entire matrix, whether the terminal is large enough or not. However, when the terminal is not large enough to print the matrix using the built-in function above, part of the matrix will be omitted.
To put a comma between every third number, use the following method:
using Format
s = cfmt("%'d", 123456789) # fast
s = format(123456789, commas=true) # medium
Output is a string:"123,456,789"
vscodedisplay(matrix) opens a new window in VS code that displays the variables in a tabular form.
using DataFrames, XLSX
fname = "report.xlsx"
isfile(fname) && rm(fname)
writetable(fname, "Report A" => DataFrame(matrix, :auto))
I really had to write about the PlotlyLight package because it starts up much faster than other plotting packages, both in terms of first run time and first plot time. So how fast is it?
@time import Plots # 1.757127 seconds
@time Plots.plotlyjs() # 17.849170 seconds
@time Plots.plot(1:20, 1:20, type="scatter") # 3.281065 seconds
@time import PlotlyJS # 1.746334 seconds
@time trace1 = PlotlyJS.Plot(PlotlyJS.scatter(x=1:20, y=1:20, mode="markers")) # 1.760041 seconds
@time using PlotlyLight # 0.114527
@time p1 = plot.scatter(x=1:10, y=rand(10), mode="lines+markers"); # 0.101052 seconds
To get started, You can directly copy and modify the template below, which already includes most of the commonly used options.
function set_PlotlyLight_template(; theme::Symbol=:light)
template = Config(
font=Config(family="Arial", size=16, color=theme == :light ? "black" : "#dbdbdb"),
plot_bgcolor=theme == :light ? "white" : "rgba(0,0,0,0)",
paper_bgcolor=theme == :light ? "white" : "rgba(0,0,0,0)",
margin=(l=60, r=15, t=10, b=60, pad=0),
xaxis=Config(
showline = true,
linecolor = theme == :light ? "black" : "#dbdbdb",
linewidth = 1.5,
mirror = true, # Mirror image has axes on all four sides
ticks = "inside", # Orientation of the ticks
title = Config(standoff=1),
gridcolor = theme == :light ? "rgba(0,0,0,0.1)" : "rgba(255,255,255,0.2)",
zeroline = false
# titlefont = template.font,
# domain = (0, 0.6), # 60% of width in x-direction
),
legend=Config(
bgcolor = theme == :light ? "white" : "rgba(0,0,0,0.5)",
x = 0.01, # Relative position of the horizontal to the anchor point
y = 0.99 # Relative position of the vertical pair of anchors
# xanchor = "right", # Anchor x-axis alignment datum ("left", "center", "right")
# yanchor = "top", # Anchor y-axis alignment datum ("top", "middle", "bottom")
# borderwidth = 0,
)
)
template.yaxis = template.xaxis
return template
end
PlotlyLight.settings.layout.template.layout = set_PlotlyLight_template()
# equivalent to `PlotlyLight.settings.layout.template = Config(layout=my_template)`
Let's plot a figure to see this.
using PlotlyLight
p1 = plot.scatter(x=1:10, y=rand(10), mode="lines+markers", layout=set_PlotlyLight_template())
# The above can be simplified as
p1 = plot(x=1:10, y=rand(10))
# Now we save it
using PlotlyKaleido
PlotlyKaleido.start()
savefig(p1, "myplot.png") # .svg
Plots is a visualization interface and toolset. It sits above other backends, like GR, PythonPlot, PGFPlotsX, or Plotly, connecting commands with implementation. If one backend does not support your desired features or make the right trade-offs, you can just switch to another backend with one command. No need to change your code. No need to learn a new syntax. Plots might be the last plotting package you ever learn.
fig = plot(-10:0.1:10, sin.(-10:0.1:10),
bg_color=RGB(0.12),
label="sin(x)",
linewidth=1.5,
linecolor=:yellow3,
marker=:circle,
markersize=3,
markercolor=:yellow3,
markerstrokewidth=0,
title="Plot of sin(x)",
xlabel="x",
ylabel="y")
savefig(fig, "sin.png")
It can be very annoying to enter so many parameters every time you plot, so Plots provides a default parameter function. You can set the global default parameters via default().
default(fontfamily="arial",
bg_color=:transparent,
framestyle=:box,
tick_direction=:none,
linewidth=1.5,
tickfont=(12, RGB(0)), # RGB(0)=:black
guidefont=(12, RGB(0)),
fg_color_axis=RGB(0),
fg_color_border=RGB(0),
fg_color_grid=RGB(0.82),
markersize=3,
markerstrokewidth=0,
legendfontsize=11,
legendfontcolor=RGB(0),
legend_foreground_color=RGB(0))
To add a plot to the current figure, use the ! version of the function, e.g. plot!(). To draw on a specified figure, use fig as the first argument: plot(fig, ...).
CairoMakie is suitable for drawing two-dimensional, static images. It offers many parameters for detailed customization. We can write a function to wrap commonly used settings.
"""
cairomakie_plot(x, y; lable=nothing, yscale0=identity)
`yscale0`: identity, log10
"""
function cairomakie_plot(x, y; lable=nothing, yscale0=identity)
with_theme(theme_dark()) do
fig = Figure(fontsize=14, size=(700, 400))
xrange = (minimum(x), maximum(x))
ax = Axis(fig[1, 1],
xlabel="x", xtickalign=1, xgridvisible=false, # xticklabelsize=14
ylabel="y", ytickalign=1, yscale=yscale0,
limits=(xrange, nothing))
lines!(ax, x, y, linewidth=2, linestyle=:solid, color=:tomato, label=lable)
scatter!(ax, x, y, marker=:circle, color=:tomato)
axislegend(ax, labelsize=15) # position=:lb
display(fig)
# save("my_first_figure.svg", fig)
end
end
The syntax of with_theme() do ... allows a one-time application of theme styles. The default style is restored on the next plotting.
To permanently change the drawing theme, one can use set_theme!(merge(theme_dark(), theme_latexfonts())).
Let's draw a sine function and save it as a vector graph:
using CairoMakie
f(x) = sin(x)
x = -10:0.1:10
y = f.(x)
cairomakie_plot(x, y)
time()
time() function gets the system time in seconds since the epoch, with fairly high (typically, microsecond) resolution.
start_time = time()
# ...
elapsed_time = time() - start_time
println("Elapsed time: $elapsed_time seconds")
@elapsed
@elapsed is a macro to evaluate an expression, discarding the resulting value, instead returning the number of seconds it took to execute as a floating-point number.
elapsed_time = @elapsed begin
# ...
end
println("Elapsed time: $elapsed_time seconds")
TimerOutputs.jl
TimerOutputs is a small Julia package that is used to generate formatted output from timings made in different sections of a program.
using TimerOutputs
const to = TimerOutput() # create a timer
# Define a function that needs to be timed
function compute_sum(n)
sum = 0
@timeit to "Loop over elements" for i in 1:n
sum += i
end
return sum
end
@timeit to "Total computation" begin
result1 = compute_sum(100_000)
result2 = compute_sum(200_000)
println("Result 1: ", result1)
println("Result 2: ", result2)
show(to)
end
using BenchmarkTools
a = rand(100,100)
b = rand(100,100)
@btime begin
c = $a + $b
end
A description of “$” can be found at stackoverflow.
]]>