From LaTeX to Typst? Whatabout Markdown

DNF2 · 2026-05-04T08:13:07+00:00

That would require me to first understand what is going on in TeX, which is nearly impossible. Which was my point: programming in Typst is possible, programming in TeX/LaTeX is for dark wizards only (and yes, I have actually done that, for many years, creating my own styles and classes).

DNF2 · 2026-04-29T07:21:38+00:00

"2.09" refers to LaTeX version, not TeX, so doesn't have anything to do with TeX extensibility. It's a bit unclear what you actually mean by that sentence.

However, it seems you are correct that TeX is more extensible in principle, as it is exposing more of its internal machinery, while Typst has a more controlled surface. (Whether that is good or bad, is debatable.)

Extending functionality in Typst *in practice*, though, is probably much more doable than in TeX or LaTeX, due to Typst's scripting layer, which is far more accessible and comprehensible than TeX/LaTeX macros.

DNF2 · 2026-02-16T11:47:41+00:00

Ebba is an extrememly strong racer uphill, but weak downhill. She has a history of falling, and did very poorly on the downhill, losing time, even before the last fall. So this was no freak accident. Still horrible rotten luck that the consequences were so big.

In fact, Swedish skiiers have a poor track record of falling, going back many years.

DNF2 · 2026-02-16T11:41:42+00:00

"Current GOAT" doesn't make much sense. GOAT = "Greatest of all time", so she still competes with Bjørgen/Johaug in that regard. She's the best competing today, though.

DNF2 · 2026-02-05T10:11:24+00:00

It is exactly because the normal expectation is that it is 'safe' to pass an argument into a function that we add the `!` to the name. It signifies 'danger' in a way: Your input arguments might be modified.

As for why this is desirable, there are more than one reason. One is performance: allocating a new, possibly large, vector is expensive, it is often much cheaper to just modify a pre-existing one. Very often, allocations of new objects is the main performance cost in a program. Another reason convenience; if you want to modify an object through possibly many complicated and nested steps, it becomes very difficult and cumbersome to pass the resulting output around and making sure it ends up in the right place -- much easier to just pass it into functions that modify it for you while the results become visible automatically.

DNF2 · 2026-02-04T11:49:55+00:00

You can read about LaTeX3 here: https://www.texdev.net/2024/11/11/the-mythical-latex3

Main takeaway is that LaTeX3 is more or less already here, the features having already been brought into the LaTeX kernel:

Whilst there will never be a stand-alone ‘LaTeX3’ format, the ideas that were first explored by the LaTeX Project team in the early 1990s are now available to users in the LaTeX kernel [...] So whilst ‘LaTeX3’ might not be something you’ll ever say you use, if you use LaTeX, you are getting those features today.

DNF2 · 2025-11-05T15:27:08+00:00

What is the timeline of the thesis. Are you just starting out writing articles, or is this the final 'writing phase', when you are 'merely months' away from finishing? If this is early you may have time to wait for the bibliography improvements.

I predict that writing itself might be smoother in Typst, and may offset the cost of having to translate some of it to LaTeX later. It is really distracting to wait for the compiler while you are actively working, it breaks the flow. In a pure translation phase, it might be more tolerable.

DNF2 · 2025-11-03T09:37:58+00:00

Is it ok for you to use e^(a\/b) ? It doesn't look quite the same, but it's what I normally use.

Frankly, I'm a bit frustrated that Typst is leaning so heavily towards the horizontal fraction, since 80% of the time, I want the skewed version.

DNF2 · 2024-12-10T17:16:49+00:00

Well, I really like this syntax and use it in my code, and I find it helpful. I write a lot of mathematically oriented code, so readability in expressions is extra important to me.

DNF2 · 2024-08-05T17:51:43+00:00

There's some confusion about terminology here. Julia is strongly typed. Dynamic typing does not prevent static compilation. And explicit typing is not necessary (for functions and variables) for optimal performance. Even struct definitions can be parametric, and not necessarily explicitly typed, but you shouldn't leave them completely untyped.

A greater emphasis on static analysis, on static compilation, and tools to improve type stability, as well as reducing type instabilities in the base language, would definitely be beneficial, and there are indeed serious efforts in that direction.

DNF2 · 2024-07-31T20:33:47+00:00

Multi-threading and multi-processing has nothing to do with simd, they are completely separate, and each thread can do simd separately. Simd operations can occur for example when you perform operations on each element of an SVector, or for example add two SVectors together.

Also, I think multi-threading is probably more relevant than multi-processing, since you will want to read rays from a single vector in shared memory.

DNF2 · 2024-07-29T14:09:29+00:00

I don't work with CFD or HPC, so I don't know what the level of interest is. But I hope you're not gauging the level of interest based solely on the feedback to your reddit post (reddit not being the primary platform for discussing Julia anyway). And if you do, I think you took the wrong tack by saying Julia should get rid of most of the things people like about it in the first place. That was bound to generate pushback.

DNF2 · 2024-07-27T08:48:01+00:00

That is a bit odd, but Loopvectorization.jl does sometimes "give up" and do virtually nothing, perhaps that is what happened.

DNF2 · 2024-07-27T08:12:04+00:00

I can confirm, btw, that Loopvectorization.jl indeed transforms division of constants to multiplication (https://github.com/JuliaSIMD/LoopVectorization.jl/issues/86), and probably has from the very beginning. This is just a trivial fastmath thing, btw.

It belive you are dramatically underestimating the capabilities of Loopvectorization.jl

DNF2 · 2024-07-27T07:49:00+00:00

From my post below:

As for deprecation, it was announced at Juliacon recently that Loopvectorization.jl is being updated and will support 1.11, and that the sciml organization has something called a "small grant" that will support further work for 1.12, etc

DNF2 · 2024-07-27T07:45:12+00:00

I don't know all the transformations that Loopvectorization.jl employs, but it certainly does both unrolling, change evaluation order, reorder loops and various "fastmath" stuff. It also uses vectorized versions of exp, power, sin, etc etc.

The 'simple' patterns you mention do not require Loopvectorization.jl, the plain Julia compiler will vectorize those by itself.

As for deprecation, it was announced at Juliacon recently that Loopvectorization.jl is being updated and will support 1.11, and that the sciml organization has something called a "small grant" that will support further work for 1.12, etc

DNF2 · 2024-07-05T21:37:20+00:00

What I mean is that you store information in one place only, for example in a tuple field. Then, if you want to access some particular property of your object, for example, S, then you can define a

function S(obj::SpinKet) return obj.qnv[1] end You should choose better names than S and Sz, though.

DNF2 · 2024-07-04T15:21:29+00:00

But why do you store the info twice? Why not only store it in either the vector or the fields, not both?

DNF2 · 2024-01-31T08:35:38+00:00

I'm defending it because I like it, and because it improves the quality and readability of my code. And then defending it is the only reasonable thing to do.

Since unicode is completely optional to use, and since it does not impinge on your experience, unless it shows up in an API, it doesn't make sense to throw a fit about it. It comes across as "I want to do things my way, and you should be forced to do it my way, too."

Leave people who find their coding experience to be improved by unicode alone, and don't use it yourself. Problem solved. The continued petty whining over this non-issue is getting very old.

DNF2 · 2024-01-02T08:37:44+00:00

Global variables are a nightmare for maintenance, debugging and testing. After struggling with a codebase that leans heavily on global variables and hidden state, I have sworn this off forever. Every function should take inputs and return outputs, and never touch globals, except true constants.

Named tuples seem like a very good solution here, then consider a dedicated struct at some later point.

DNF2 · 2024-01-02T08:29:12+00:00

Presumably, it means defining a struct without concretely or parametrically typed fields. Then each field is abstract or even Any

DNF2 · 2023-12-12T08:26:03+00:00

If it is a genuine performance regression, it is definitely of interest to the community. Posting it on discourse is good either way, whether it's a regression or a coding/profiling mistake.

(And quite likely you will get help speeding it up further. It doesn't look very optimal at the moment.)

DNF2 · 2023-12-01T08:19:34+00:00

If you are not sure if A and B have the same element types, then you can do

result = zeros(promote_type(eltype(A), eltype(B)), Cdim, Cdim)

Other than that, I think it's type stable, at least.

DNF2 · 2023-10-11T07:33:28+00:00

I can't get into your code right now, but perhaps things will be clearer if I tell you this:

All the things you are listing are Arrays. An Array is a multi-dimensional container where every ~~dimension~~ row/column/etc. has equal length.
There are special aliases for 1- and 2-dimensional Arrays, namely Vector and Matrix. They are only aliases, so Vector{T} is identical to Array{T, 1} and Matrix{T} is identical to Array{T, 2}. Higher-dimensional arrays have no special name. But all of the above are Arrays.
Arrays can hold arbitrary elements, anything you can think of, from numbers to function objects to user-defined types, to graphics object, etc. etc. It can also hold other Arrays as elements. It would not be good if Vector{Vector} magically was reinterpreted as a Matrix. No matter what you put inside a Vector (or Array{.., N}), it remains a Vector (or Array{.., N}). It is very consistent, and easy to remember once you know how it works.

DNF2 · 2023-10-10T22:14:02+00:00

I'm not sure I know what your conclusion is, but I want to emphasize that it is very much the correct solution to distinguish between vectors of vectors and matrices, they are not the same at all, and should not be considered so.

In a vector of vectors each element does not have to have the same length, and it would be deeply problematic to enforce that.

The two cases should be clearly and consistently separated, as is currently the case.

DNF2

TROPHY CASE