20
1
Challenge
Given a number x and a number n, round number x to n significant figures and output the result.
Significant figures
The significant figures of a number are digits that carry meaning contributing to its measurement resolution. This includes all numbers except leading zeroes.
Bear in mind that leading zeroes after a decimal point are still insignificant figures.
When rounding a digit, you must round away from zero if the following digit is greater or equal than five.
All trailing zeroes after a decimal point are counted as significant.
Input
The first number will be x, the number to be rounded. The second number will be n, the number of significant figures you should round x to.
x will be a number (your code should handle both integers and floating points) between -1,000,000,000 and 1,000, 000,000 inclusive. n will be a positive integer between 1 and 50 inclusive. n will never be greater than the nunber of digits in x.
The input will never be 0 or any form of 0, e.g. 0.000 or 000.
Examples
Inputs: 2.6754, 2
Output: 2.7
An output of 2.7000 would be invalid because the trailing zeroes after the decimal point are counted as significant figures.
Inputs: 0.00034551, 4
Output: 0.0003455
Inputs: 50237.1238, 3
Output: 50200
Note that this must not have a decimal point.
Inputs: 2374905, 1
Output: 2000000
Inputs: 543.0489, 4
Output: 543.0
Inputs: 15, 1
Output: 20
Inputs: 520.3, 3
Output: 520
If you wish, you can output 520. instead but not 520.0.
Inputs: -53.87, 2
Output: -54
Inputs: 0.0999, 2
Output: 0.10
Rules
Built-in functions and libraries which allow you to round a number to n significant figures are disallowed.
Winning
The shortest code in bytes wins.
Yea it looks like that's right, for some reason I was remember incorrectly that leading zeros only applied to the whole number portion. – Suever – 2016-09-16T17:23:01.653
Would
2.7000be another valid output for2.6754, 2? – Arnauld – 2016-09-16T17:56:05.137@Arnauld No, because trailing zeroes are counted as significant figures – Beta Decay – 2016-09-16T18:00:00.017
What's the output for
2.700000000, 5?2.7000? – mbomb007 – 2016-09-16T18:08:47.160@mbomb007 Yes, exactly – Beta Decay – 2016-09-16T18:10:02.317
4For
Inputs: 520.3, 3, isn't the decimal point in the answer520.crucial? – Greg Martin – 2016-09-16T18:10:21.323@GregMartin No, why would it? – Beta Decay – 2016-09-16T18:11:43.180
5@GregMartin I believe that it is, as that's the only thing that makes it have 3 sig figs vs. 2 – Suever – 2016-09-16T18:12:56.230
@Suever I disagree, in
520.3, the zero is significant, and although it isn't technically significant in520, it is counted as a sig fig – Beta Decay – 2016-09-16T18:16:05.4303@BetaDecay No it's not. The decimal point would be required for that. – mbomb007 – 2016-09-16T18:16:29.740
@DLosc 1. Check the question body, 2. No, it isn't valid input – Beta Decay – 2016-09-16T18:16:47.110
3"200 is considered to have only ONE significant figure" - http://chemistry.bd.psu.edu/jircitano/sigfigs.html – mbomb007 – 2016-09-16T18:17:50.907
@mbomb007, sure that may be the actual rules, but this is a simplified version of the problem, intended to be easier for programs to perform – Beta Decay – 2016-09-16T18:18:36.553
@mbomb007 Yet
200is necessarily ambiguous, as it's also the result of rounding200.1to two significant figures. I don't see a problem with allowing it to represent 1-3 sig figs versus 1-2 sig figs. – DLosc – 2016-09-16T18:26:24.1634@DLosc That's why if that was the result you'd actually write it as
2.0 x 10^2, showing the 2 sigfigs. – mbomb007 – 2016-09-16T19:13:38.8972Please add a test case for
0.0999, 2. Both of the current answers produce0.1, but I think it should be0.10. – DLosc – 2016-09-18T03:52:24.250@DLosc I've added it – Beta Decay – 2016-09-18T09:57:26.567