Skip to content

add fractional values as main quantities - #41

Open
bojohnson5 wants to merge 1 commit into
ChHecker:mainfrom
bojohnson5:main
Open

bojohnson5 wants to merge 1 commit into
ChHecker:mainfrom
bojohnson5:main

Conversation

@bojohnson5

Copy link
Copy Markdown

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

idoric commented Nov 4, 2024

Copy link
Copy Markdown

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
Copy Markdown
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

idoric commented Nov 5, 2024

Copy link
Copy Markdown

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