Add invisible metadata in front of the units

[Ants-Aare]

this allows for querying of units & numbers, and allows packages to reason about any units or numbers they receive, without changing anything for the user.

I had to move some things around, because I want all of the metadata to be outside of context and basically just be a parsed representation of the underlying data. I also added a method to utility so that it's easier to retrieve the data from a content we know is a unit/number.
With the current implementation units will have a unit metadata in front of them, as well as the number metadata inside of it. I personally don’t think this is necessary, and would prefer to use show-num inside of the qty function, but because we are calling the num function we inherit the attached metadata from that as well.

I wasn't sure if adding the named and positional arguments would be necessary, since digits and round:precision/figures are kind of important and relevant information. But for now I left it out.

The main reason for this PR is because I would like to use this in a package.

[Mc-Zen]

Hi @Ants-Aare ,

Numbers and units will of course be queryable (is this a word?) when all of them become proper types. This is a high priority to me once Typst introduces them.

Until then I'm open to exposing the internals via metadata like you did, as long as it does not hurt performance (especially in tables and for Lilaq tick labels, this is critical).

Could you tell me more about your use case for this and which info you exactly need? We need to keep in mind that not all fields might be accessible when num etc become types because a lot of the internal parts are "synthesized" from the arguments (e.g. the input usually differs quite a lot from the value that is displayed ). Just to be careful not to rely on info that is available now through metadata and that might not be available later when this is replaced with types because eventually I don't want metadata to be hidden in num etc after they are types.

[Ants-Aare]

I basically just expose the info dictionary that is synthesised right now. the reason for this is that it's easy to modify it and pass it back into num(). let's say I want to remove the sign, or manipulate the unit in some way. Additionally I expose the number as a float value with all the "e3" stuff applied, so that the number always exists as a processable value, even if it may loose precision from floating point, same for the uncertainty. keeping the raw value in it's unmodified form may be useful for some people, but I don't personally need it.

[Ants-Aare]

What I'm working on right now is a refactor/ ground up re-implementation of the pariman package. I like the Pariman package, but I don't like the API. Also it's currently doing a lot of work that zero already does and there are some weird edge cases around uncertainty/places where it does things on top of zero. I basically want to ideally make a package that's "zero-calc" which allows for all/most of the features in the typst calc namespace to be used with zero units. This would also include some displaying functions to display the calculation steps that were used.
I already made a PR for the original Pariman package to add error propagation and I intend to add it to "zero-calc" as well, so that uncertainties are kept up to date.

[Ants-Aare]

the reason I'm refactoring Pariman is because I am currently working on a package for the typsium chemistry rendering project I'm part of, where I want to automate the calculations involved in mixing solutions, dilutions, etc. Which is similar to the zero API where I declare a "unit" i.e. a molecule such as water and then I can use #water(ml(50)) to display "50 ml of water" and then use set rules etc to change if it should be displayed as grams or moles or if the formula/structure should be used. And since the least amount of work is done with raw substances it's important to be able to make mixtures, so mix(water(ml(50)), nacl(g(58))) will then display as "1molar NaCl solution". and then obviously you could continue to use that variable to calculate further. I want things to mesh neatly together with zero, even if it's probably heavier doing it this way than just using regular good ol floats.

[Ants-Aare]

I really like what you did with your approach to accessibility in the sense that the names are decoupled from the declarations in zi. This makes it a lot easier to synthesise units along the way and have accessibility still work perfectly.

I'm waiting for the types API too... 😔
I fiddled around with elembic a lot and it's great, but I don't think it's quite the right approach. I hope types get support for functions as well. Since I have different representations of variables, either the result of the calculation or the displaying calculation method, it would be nice to return the type and the user can decide if they want to use .display or .display-error or .display-calculation

[Mc-Zen]

That sounds indeed very exciting! I'm stoked to see the result.

I have a few remarks but the performance seems fine.

[Ants-Aare]

I applied the typstyle formatter with default settings to the files I touched, this changed the formatting of some other parts of the file, but I think it is okay. Let me know what formatter and settings you use if you disagree and I can revert the formatting commit. I also added some hints for other package authors which I think might be useful to the documentation because that part was empty. The accessibility file was also missing from the impl namespace, so I added that.

[Mc-Zen]

Thank you very much! This looks very good, please just review my latest comment and otherwise it's ready to merge!

[Ants-Aare]

already done

[Ants-Aare]

with your permission I would like to publish this package as "zero-calc", since it is a package that is directly reliant on zero I feel it is an appropriate name. Just like many of the presentation packages have the prefix of the package they rely on and I would need to keep the package updated to match latest changes in the zero package.

it is still WIP and doesn't yet support all of the operations, and the API isn't 100% finalised, but I'm working on it.

#let operation1 = calc.add(m[1+-0.1], m[10+-0.2])
#display-method(operation1) = #operation1
#display-error-method(operation1) = #display-error(operation1)

#let operation2 = calc.div(m[11+-0.16], s[55+-5])
#display-method(operation2) = #operation2
#display-error-method(operation2) = #display-error(operation2)

let me know what you think, I can change it of course.

[Mc-Zen]

That looks pretty cool!

As it integrates that tightly with Zero and if you plan to update it after Zero changes to use custom types, then I'll gladly give you permission for that name.