REQUEST: Significant Digit Calculator

[Lavaloon]

I noticed that the most of TI calculators can round answers to significant digits. How come HP Prime doesn't have that feature? This feature will make HP Prime more useful in Chemistry and Physics courses.

****
EDIT
****
If you don't know what it significant digit calculations look like, here's an example:

Addition/subtraction:
2.345+8.5=10.5, an answer is rounded to least number of decimal places
7.93-4.6729=3.26, same as above

Multiplication/division:
5.843x1.97=11.5, an answer is rounded to least number of significant figures
4.284/3.7=1.6, same as above

[Tim Wessman]

Please give an example of how this is done?

The only things I have seen are some very limited programs that aren't general use and hence not very useful.

[Helge Gabert]

Does ROUND help at all?

ROUND(7.8676,-2) returns 7.9 (two sig. digits).

[Joe Horn]

(01-22-2018 01:32 AM)Helge Gabert Wrote:  ROUND(7.8676,-2) returns 7.9 (two sig. digits).

Other functions (like ROUND) which let you control the number of significant digits include:

TRUNCATE(7.8676,-2) --> 7.8 (notice the negative sign)
evalf(7.8676,2) --> 7.9 (the second argument's sign is ignored)
approx(7.8676,2) --> 7.9 (the second argument's sign is ignored)

And if you want all your results to automatically be rounded to 4 significant digits, just set the Number Format (in Home Settings) to Scientific 3.

Prime's built-in Help system, with its own search function, is your friend.

[lschroeder1947]

(01-22-2018 03:58 AM)Joe Horn Wrote:  

(01-22-2018 01:32 AM)Helge Gabert Wrote:  ROUND(7.8676,-2) returns 7.9 (two sig. digits).

Other functions (like ROUND) which let you control the number of significant digits include:

TRUNCATE(7.8676,-2) --> 7.8 (notice the negative sign)
evalf(7.8676,2) --> 7.9 (the second argument's sign is ignored)
approx(7.8676,2) --> 7.9 (the second argument's sign is ignored)

And if you want all your results to automatically be rounded to 4 significant digits, just set the Number Format (in Home Settings) to Scientific 3.

Prime's built-in Help system, with its own search function, is your friend.

Edit 1: 1/25/2018

Post 2 and 3 from my thread on Xcas videos have screenshots showing evalf(Expr,[Integer]) being used in various situations. Below are our friends, the help screens that Joe mentioned. It looks to me like Round (value, [places]) would be the most appropriate because it can handle place value when we add/subt and significant digits when mult/div/powers.



Post 1 examples implemented for Joe's other functions.



End Edit 1

(01-22-2018 12:56 AM)Tim Wessman Wrote:  Please give an example of how this is done?

The only things I have seen are some very limited programs that aren't general use and hence not very useful.

In my book HP Prime Guide Algebra Fundamentals I wrote a program to store current settings, switch to scientific with desired digits, and switch back to original settings. The main feature of the book is on using the CAS view and HOME view to help you with learning or reviewing Algebra. I am new at programming the Prime, so hope you can be a little forgiving at my programming. As Tim said most scientific notation programs are limited and mine probably falls in that category. I thought it might be useful to some. In the book it takes several pages to document its creation and use. Below are a couple of excerpts from the book.



Edit 2: 1/25/2018

As Joe said you could just set the number of digits manually. The screen below shows the result from toggling from 5 digits back to original settings. Be careful the Home Setting "Scientific" "Digits" is different than significant digits. For Joe's above example we would set scdigits(3) to get 4 significant digits. The bad side effect of the changing the Home Setting or using my function scdigit is all non exact values in the History area are changed. By using the user "Apps" key at the end everything in History area will be returned to its original values.

End Edit 2

PHP Code:

Export gclsdigits, gclscount, gclshformat, gclshdigits;

K_Eex();
K_Apps();
first();

EXPORT scdgts(digits)
BEGIN
 LOCAL message;
 first( );
 IF (digits >= 0 AND digits <= 11) THEN
  gclsdigits := digits;
  HFormat := 2;
  HDigits := gclsdigits;
  message := "Scientific";
 ELSE
  message := "Error: Range 0-11"; 
 END;
 RETURN message;
END;

KEY K_Eex()
BEGIN
  first();
  IF HFormat <> 2 THEN
    HFormat := 2;
    HDigits := gclsdigits;
  ELSE
    HFormat := 0;
  END;
  STARTVIEW(-1,1);
  RETURN 10;
END;

KEY K_Apps()
BEGIN
LOCAL message;
 message := "Unknown";
 IF gclscount <> 0 THEN
  HFormat := gclshformat;
  HDigits := gclshdigits;
  gclscount := 0;
  gclsdigits := 0;
  CASE
   IF gclshformat == 0 THEN message := "Standard"; END;
   IF gclshformat == 1 THEN message := "Fixed"; END;
   IF gclshformat == 2 THEN message := "Scientific"; END;
   IF gclshformat == 3 THEN message := "Engineering"; END;
   IF gclshformat == 4 THEN message := "Floating"; END;
   IF gclshformat == 5 THEN message := "Rounded"; END;
  END;
 END;
 STARTVIEW(-1,1);
 RETURN "Restored Number Format " + message + " - Press Esc";
END;

first()
BEGIN
 gclscount := gclscount + 1;
 IF gclscount == 1 THEN
   gclsdigits := 6;
   gclshformat := HFormat;
   gclshdigits := HDigits;
 END;
END; 


[Tim Wessman]

(01-21-2018 09:39 PM)Lavaloon Wrote:  Addition/subtraction:
2.345+8.5=10.5, an answer is rounded to least number of decimal places
7.93-4.6729=3.26, same as above

Isn't the point here that the last digit is the one that contains the "error"? Wouldn't that mean that your answer is only valid to +/-1 on the last of 2 digits? You've specified 3 digits in your "correct" answer.

This type of thing in my experience is a "good idea", but in practice has been implemented wrong. The system simply assumes your numbers are correct up to the last digit in all case. In reality, the user needs to be able to specify where the error is (some numbers won't have uncertainty, or varying levels of uncertainty) and the amount of the error. Thus these become a simple "black box" thing that doesn't actually aid understanding or be useful.

The better solution is to enable interval math, and that is something we have on the long term goals...

[Claudio L.]

(01-24-2018 08:47 PM)Tim Wessman Wrote:  This type of thing in my experience is a "good idea", but in practice has been implemented wrong. The system simply assumes your numbers are correct up to the last digit in all case. In reality, the user needs to be able to specify where the error is (some numbers won't have uncertainty, or varying levels of uncertainty) and the amount of the error. Thus these become a simple "black box" thing that doesn't actually aid understanding or be useful.

The better solution is to enable interval math, and that is something we have on the long term goals...

I agree 100%, except the "good idea" part. The machine is tasked with adding the numbers, let the human evaluate the confidence intervals, unless like you said, you can explicitly specify the error in each and every number you type on the calculator, and use interval math (which would slow down your use of the calculator by a lot).
Based on the original poster, if you type 5/2 the result should be 2 and not 2.5, since the calculator would assume your 5 and your 2 are only accurate to the integer digits. That would be disastrous on any calculation outside of a school environment.

[ndzied1]

Maybe you could just use this to measure everything... ;-)
   

[DrD]

(01-22-2018 12:56 AM)Tim Wessman Wrote:  Please give an example of how this is done?

The only things I have seen are some very limited programs that aren't general use and hence not very useful.

I think this would be a good feature. Perhaps something like this could be modeled:

1. A checkbox to select significant figures (sigfigs) mode.

2. Follow the guidance from: https://en.wikipedia.org/wiki/Significant_figures. Specifically, the "Arithmetic" section.

Having a significant figures mode would be helpful to avoid overstating accuracy, both in the sciences, and real world data processing. I encountered this frequently in the natural gas industry. Data collection and control devices, capturing field information, got number crunched into values with unrealistic reported accuracy, not possible with the A/D and D/A converters available at the time.

A technician could find it useful for calibration or result verification to validate, independently, the field information that gets telemetered to control centers.

[enriquephilippe]

This featured is so much needed.

[StephenG1CMZ]

To avoid the loss of precision in examples like 5/2 =2 to 1 sigfig, one could keep the additional digits but indicate the possible limitation of accuracy visually (for example, by changing the colour, or using bold).

So 5/2 is 2.[/red]5
Or 0.625*1.0 is 0.6[/red]25

That avoids the inaccurate 2 but gives a reminder that the result may exceed the precision of the input values, where needed.

[Wes Loewer]

(01-22-2018 12:56 AM)Tim Wessman Wrote:  The only things I have seen are some very limited programs that aren't general use and hence not very useful.

Quite true. The ti-84 has a SIG-FIG CALCULATOR option in its SciTools app. It's useful for perhaps teaching sig fig's, but not very practical for actual use. You can only use it for basic arithmetic. The rules for uncertainty for other functions like square root, tangent, or log aren't really suited for expressing results using just sig fig's.