Skip to content

add a promote to the SigFig macro to handle other expressions#28

Open
pstaabp wants to merge 1 commit intosigfigfrom
sig-fig-promote
Open

add a promote to the SigFig macro to handle other expressions#28
pstaabp wants to merge 1 commit intosigfigfrom
sig-fig-promote

Conversation

@pstaabp
Copy link
Copy Markdown
Owner

@pstaabp pstaabp commented Jun 17, 2025

As noted in #25 (comment) @dpvc noted that if SigFigs are passed to subroutines that have non-sigfig numbers that those other numbers will be promoted to sig figs. In general, this is not what is wanted (see the average function in the link above.)

This adds a promote to the SignificantFigures::Real package that will promote non-sig fig numbers to have infinite sig figs.

pstaabp pushed a commit that referenced this pull request Oct 28, 2025
@pstaabp
Copy link
Copy Markdown
Owner Author

pstaabp commented Mar 9, 2026

@dpvc: could you take a look at this and the other two branches (#27 and #30)? Worked on this a bit in the couple of months and would be good to get this into the release over the summer.

@dpvc
Copy link
Copy Markdown

dpvc commented Mar 16, 2026

I approve this PR.

For #27, there is a problem. Since you removed all the operators, that means you removed unary minus, so you can't produce any negative numbers.

One solution would be to make the number pattern include the optional leading negative sign. The drawback to that is that if someone entered something like 1.2-3.4, it would-be treated as 1.2 * -3.4 and they would get a message about multiplication not being allowed. That would be confusing for their initial expression.

The other solution would be to allow unary minus and override it to check that it only applies to a (positive) Real. You might also want to remove parentheses as well, in order to avoid -(3.4) if that matters to you. Finally, you might allow commas, so that you can have lists of numbers.

For #30, I have been thinking about a new possibility that would handle the situation better. It would allow x to be a variable, but still use 1.23 x 10^3 for scientific notation. One question, though. Do you want to require 1.23 x 10^1 or is 1.23 x 10 acceptable as well?

I've been experimenting with the needed updates (it is a bit complicated), and should be able to fold in the negative number issue for the strict context. I'll let you know when I have something to share.

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