Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add fractional values as main quantities #41

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

bojohnson5
Copy link

I really like this package! I found myself needing whole fractions as the primary number in some cases and have added that feature here. So you could use something like

num("1/100")

or

qty("2/3", "erg/cm^2/s")

or even

num("1/100+-0.03")

but it doesn't support using fractions in uncertainties, something num("1/100+-1/100") wouldn't be allowed (at least for now). I added a couple examples to the example.typ file. Let me know if this is a worthwhile contribution.

@idoric
Copy link

idoric commented Nov 4, 2024

On reflection, fractions are not enough when all results need to be given in an exact form (which happens mainly in mathematics, very rarely in physical and engineering sciences). We can quickly end up with results such as 58pi cm, 3 + sqrt(2) m, 5 sin(35°) km, or even a mixture of all of these. And I come to wonder if it would not be simpler to respond to all these cases to authorize the entry of a math block for the body of the functions qty, numrange and qtyrange. Examples: qty($2/3$, "erg/cm^2/s"), qty($58 pi$, "cm").

However, it would not be possible to mix with error intervals (like in num("1/100+-0.03")). So I wonder who needs error intervals with an exact value?

@bojohnson5
Copy link
Author

Yeah I understand your reasoning there. One example is when dealing with whole numbers with units and then taking an inverse. So yes, there would be no uncertainty there, say with speed of light, but having the ability to take its inverse and still share that with units would be important. Maybe I could update this PR to only allow fractions but not with uncertainties?

@idoric
Copy link

idoric commented Nov 5, 2024

I reread this part of the documentation:

num uses string parsing in order to typeset numbers, including separators between the thousands. They can have the following form:

- float or integer number
- either ({} stands for a number)
    - symmetric uncertainties with +-{}
    - asymmetric uncertainties with +{}-{}
- exponential notation e{}

and I think that maybe the best way to keep things simple from a user perspective is to make the line “float or integer number” become “float, integer number or math formula”. It might not even be necessary to surround it with dollar signs: once the string has been broken down into its three parts, if it turns out that the first one is not a float or an integer, then the script should try to interpret it as a math formula. And in case of ambiguity which would lead to a bad division into three parts, adding parentheses around the first part could solve the problem. Examples: qty("2/3", "erg/cm^2/s"), num("1/100+-0.03"), qty("58 pi", "cm"), num((sin(35)+5)+0.05-0.2e-6).

The principle could even be extended to the second part (even if I don't see any use cases).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants