Current implementation gives inconsistent height of angles and vertical bars in braket. Until typst/typst#641 have merged, I propose to use following workaround to make the formula more pleasant.

#let braket(bra, ket) = style(styles => {
  let height = measure($ bra ket $, styles).height;
  let phantom = box(height: height, width: 0pt, inset: 0pt, stroke: none);
  $ lr(angle.l bra lr(|phantom#h(0pt)) ket angle.r) $
})

Result:

The abbreviation of evaluated conflicts with typst built-in function eval.

When the first element in vecrow() is a Greek letter, there are unexpected spacing and upright style issues, like the first three lines in the following. The last three lines are how the output is supposed to be.

I found a temporary solution that is to use italic(alpha) instead of just alpha in the first element, though.

$
& vecrow(alpha, beta) \
& vecrow(alpha, italic(beta)) \
& vecrow(alpha, b) \
& vecrow(a, beta) \
& vecrow(italic(alpha), beta) \
& (alpha, beta) \
$

Currently, typing in vb(u) or vu(u) makes the vector u appear bold and italicized. However, in some style guides it is customary to make vectors only appear bold without being italics. It would be nice if an option was added to support this.

This is beautiful, but maybe it needs a versioning in the file just so that we can see if there was updates since last time?

As per the latest manual of physica, the behaviour of iprod() should be the one shown in the first line. However, the actual output is the one in the second line.

$
& angle.l u, v angle.r \
& iprod(u, v) \
& braket(u, v)
$

As mentioned in #7 (comment), the PDF manual is not automatically generated now.

Do you want a CI for that? Say, when you click some buttom on GitHub or git push --follow-tags, a workflow will run and create a new release with the PDF manual.

Pros:

• Easier for maintenance and PR.
• Reduce the repo size in future. (because PDF will be stored in releases)

Cons:

• Setting up a CI from scratch is complicated.
• Being too dependent on GitHub.

More information:

• GitHub Actions usage is free for public repositories.
• yusancky/setup-typst can download the typst binary from https://github.com/typst/typst/releases. (You can look up Awesome Typst for alternatives.)

If you like it but are busy, I can make a PR in one or two weeks.

This code snippet
$ mel(phi_n^0, sqrt((2 hbar) / (m omega))(a^dagger + a), phi_n^0) $
gives

in which the vertical bar is too bold and slightly higher than my braket. Besides, the space between alphabet and bar is too tight.

Hi, I am encountering an error when using the pdv function, for example $ pdv(,t,2) $ and am trying to find the cause. In an empty document it works fine:

#import "@preview/physica:0.8.1": *
$pdv(x,y)$

But in my document:
typst 0.7.0 (bcab7705)

#import "template.typ": *
#import "@preview/metro:0.1.0": qty
#import "@preview/truthfy:0.2.0": generate-table, generate-empty 
#import "@preview/codelst:1.0.0": sourcecode
#import "@preview/physica:0.8.1": *
#import "@preview/big-todo:0.2.0": todo
// ...
$ pdv(,t, 2) $

the following error occurs:
error: unknown variable: content
┌─ @preview/physica:0.8.1\physica.typ:549:19
│
549 │ if type(last) == content {
│ ^^^^^^^

help: error occurred in this call of function partialderivative

Where my template contains no variable called content.

This could of course just be a conflict with other includes, but I did not find the cause and am wondering if it could be an error in the library. Thank you for a response.

Actually it seems to be specific to my compiler or version of typst.

$vec(1,2,3, delim:"[") vecrow(1,2,3, delim: "[")$ produces

I think a user would expect the signature for vecrow to match vec (https://typst.app/docs/reference/math/vec/)

When writing out a formula, I would want to achieve something like (3).
Only (1),(2) and (4) are easily feasible in typst (with physica), without the manual size adjustment in (3) and (5), which is still not exactly the same as automatic typesetting would have it (compare the size of the parentheses in (5)).

I know little about typesetting (and typst), but I thought it might be an improvement upon things when one doesn't have to manually 'guess' the size for these parentheses, but let it be done automatically by the dv function?

// No aligment, see e.g. https://github.com/typst/typst/pull/1849
$ &dv(          (f(x) plus.minus g(x)) ,x, s:#none)  &= ... $
$ &dv(          (f(x) plus.minus g(x)) ,x, s:slash)  &= ... $
$ &dv(,x)   lr( (f(x) plus.minus g(x)) ,size: #200%) &= ... $
$ &(dv(,x))     (f(x) plus.minus g(x))               &= ... $
$ &(dv(,x)) lr( (f(x) plus.minus g(x)) ,size: #200%) &= ... $

1. What is your opinion on this? Should this be supported by physica, or is my way (lr(... ,size: #200%)) the 'best' way (I'd like to think not...)?
2. If this could be supported by physica, how would one do this?
   • I would suggest to have another option in the s: argument of dv (and similar commands).
     This option would ask that the function is pretty large and thus needs this particular typesetting.
     How would we call this option? large_function, ...
   • The implementation could look something like the following pseudo-code?
     size = maximum(height of the content box, height of the d/dx box)
     where size is the height of the parentheses.

From the manual:

The Hessian is the matrix of second order partial derivatives, so for 3x3 matrices and higher the matrix should still consist of $\dfrac{\partial^2}{\partial x_i \partial x_j}$. Currently for 3x3 hmat generates a matrix with elements such as $\dfrac{\partial^3}{\partial x \partial z}$, which is incorrect. The superscript in the numerator should always be 2 no matter the dimension.

From the wikipedia page:

Thanks for all your hard work on this package! It's now a must have for me when using Typst.

Hi! Thank you for this amazing package, it's a huge help to the whole Typst community :)

I wanted to ask, should there be a single-argument form of pdv? Intuitively I'd expect pdv(x) to give diff / (diff x).

This is a great package! But people may miss it if they don't dive into the demo (physics-manual.pdf)…

How about add a screenshot to README?

Additional information

Typst, KaTeX, MathJax and all of them have screenshots.

Does it make sense to add an abbreviation for the Euler constant upright(e) e.g. eu?
Background: elementary charge e and Euler number e in nearby or same equation