i think you can always use let id={$op("id")$} in your document source.

That's just unnecessary boilerplate. And we already got that framework for det etc. why not use it?

As I'm not a mathematician, I don't know how common these are. We can't support every operator, but of course we should support common ones. We should also seek to prevent confusion, int for example could be mistaken for an integral (when reading the source).

I think that adding every math operator under the sun as predefined is a slippery slope. Both because their names are less agreed upon (im(T), Im(T), ran(T), rng(T), R(T) are all examples I've seen of notation for the range of an operator for instance), and because it "polluted the namespace". Where do you draw the line for what to add? Should Jacobi elliptic functions be added? Then someone will write sn(x) when they mean sin(x) and get no error, which is obviously not great.

There is already https://typst.app/docs/reference/math/op/ for you to define operators to your heart's content.

In this PR I'd claim that tr is the least controversial with regards to agreed upon notation and lack of confusion.

(I say this as a mathematician)

We should also seek to prevent confusion, int for example could be mistaken for an integral (when reading the source).

That's the first thing I thought of. Also, we have to be careful to not create a footgun for ourselves, as adding too many operators means we won't be able to declare functions with their names in the future without causing a breaking change. So this must be treated carefully.

As an aside, perhaps a way to tackle this would be to hide extra operators behind a module or function scope? Such as op.im, op.tr ... Or even some sort of math.extra module (=> extra.im, extra.tr, ...). Just a thought I had. Although, of course, there's always the option of just having typst packages which define stuff like #let tr = op("tr").

Quick side note to "i think you can always use let id={$op("id")$} in your document source": #let id = math.op("id") is cleaner :)

I am a mathematican too 😊 And yes they are definitely common. And I of course agree we can't support all of them but should predefine the most common ones. The int-integral confusion shouldn't be a big deal hopefully because the interior is mostly used with brackets like this: int() and operates on sets. That just doesn't make sense for integrals. Also the interior and an integral don't often show up in the same place. And people who write with typst will know that the integral symbol is named integral I guess.

@Enivex This PR isn't adding every math operator under the sun...
Of course there are many ways to write the same thing but I think im is clearly the most common. I don't think we should add the Jacobi elliptic functions. I think the most basic and fundamental stuff should be predefined. Like stuff that you learn in the first year in a mathematics bachelor. And yes there are many ways to write the same thing but it all cases that would be relevant there is clearly a most frequently used one. The notation used in the Wikipedia is a good reference for that tbh.

@PgBiel I think the op. notation for everything that goes beyond the fundamentals is a good idea. Also yeah it's math.op in your snippet :)

I'd argue that the ones I want to add are fundamental to mathematics. If you still pull your veto in the end lets make it at least consistent and remove things like ker (which IMO would be a big loss though)

I'd argue that the ones I want to add are fundamental to mathematics. If you still pull your veto in the end lets make it at least consistent and remove things like ker (which IMO would be a big loss though)

I'm not arguing that they aren't, just that the notation is less universal.

I'll just point out that LaTeX also has ker, but none of the operators you propose here.

https://www.overleaf.com/learn/latex/Operators

As an aside, perhaps a way to tackle this would be to hide extra operators behind a module or function scope? Such as op.im, op.tr ... Or even some sort of math.extra module (=> extra.im, extra.tr, ...). Just a thought I had.

Would it be possible to import them in such a way that one does not need the verbose prefix if one actually wants to use them?

As an aside, perhaps a way to tackle this would be to hide extra operators behind a module or function scope? Such as op.im, op.tr ... Or even some sort of math.extra module (=> extra.im, extra.tr, ...). Just a thought I had.

Would it be possible to import them in such a way that one does not need the verbose prefix if one actually wants to use them?

Yes, you can use #import op: * or #import extra: * (for example).

I'm not arguing that they aren't, just that the notation is less universal.

Yes that part referred to Laurenz and the fact the we all agree only important and fundamental operators should be predefined :)

Weird that LaTeX is missing some important stuff too :(

Weird that LaTeX is missing some important stuff too :(

The reasons are likely similar to what I mentioned here.

Thankfully, it seems like a no-brainer to have additional categories of operators that can be imported, based on what @PgBiel says. (I think it should be more than one "blob" though)

What if, instead of hiding operators behind an op module, we hid field-specific things behind a module for that field?

For example, when writting a document on, say, linear algebra, you would import the linear-algebra module, which would contain operators like tr, det, rg, etc.. When working on a chemistry document, you would import the chemistry module, which would contain all element symbols and perhaps functions to help you write structural formulae. A units module could contain ops for units.

This solution lets us add specific operators without fear of cluttering the main namespace, and it prevents operators from different fields from interfering with each other (a bit like Im and im already do). For example, the symbol for Rhenium ("Re") would be clearly distinguished from "ℜ".

Hmm. Makes sense yes. It should be a sub module though like op.linalg or operators.linear-algebra (if the - even is valid). Even with those modules there should still be some predefined operators like sin, ln, lim etc. which are so basic one shouldn't have to import them. Anything beyond them can then be located in modules.

Also Im and im don't collide because it's case sensitive.

Also Im and im don't collide because it's case sensitive.

Yeah but in general I think relying on case only is something that should be avoided when possible. It just makes it more confusing.

Are there any of these operators for which there is consensus that they should be globally available, e.g. tr? If so, we can reduce the PR to that. Otherwise, it should be closed.

I don't know. I guess a consensus is impossible to reach. Someone always will disagree. Someone just has to make a decision. They all won't hurt but I agree that someone would need to create a module system which fully resolves this "problem" by grouping operators for example in "trigonometry", "linear-algebra", etc. and deciding on a few fundamental ones that work out of the box. Deciding on these while trying to make everyone happy will be impossible. Someone with power just has to do it ig 🤷‍♀️

For now I think id can't wait. And IMO im is also important. Or we remove ker. Having one without the other will make people angry. Either both or none.

Sorry for the long wait. We discussed a bit more on Discord. I would be on board with adding id, im, and tr and dropping the rest.

Oh don't worry. Sounds good to me! I will update the PR later today.
The new package manager looks good. I might add a package(s) for math operators :)
Oh and I think a list of the default ops should also be part of the docs. (@reknih)

There is a list on the text operator page. It is not automatically generated though.

Oh perfect! Sorry for the ping then.