Not sure if this is appropriate, but you can do this instead which is equal to the rounded number of 0.3

[GhbSmwc]

0.1 is 1/10, which is rounded to 0.1000000000000000055511151231257827021181583404541015625 in double precision
0.2 is 2/10, which is rounded to 0.2000000000000000111022302462515654042363166809082031250 in double precision
0.3 is 3/10, which is rounded to 0.2999999999999999888977697537484345957636833190917968750 in double precision

Adding the first two results will result a number that is the name of this repository instead of 0.299999... because we are adding 2 numbers that are rounded, Each arithmetic operation rounds to the nearest representable value.

All three cannot be represented in any floating point formats with finite significand digits. However, there is a way to mitigate this rounding so it only rounds at the last operation:

((1+2)/10) == 0.3 // true

What happens is that the numbers are treated as a fraction, and didn't round in the steps before the last. Because the first two fractions are the same (10), we can just add the numerators, and the total will be the numerator of the result and keep the denominator (3/10).

Another thing is that I am not sure if anyone also notice that you can more accurately represent a percentage by doing: Percentage = N*100/D instead of Percentage = N/D *100. Notice that the more accurate version did division last, and division is prone to having rounded quotient. Here is the result with the fraction 1/3 (the correct answer is 33.[3] (bracketed means repeating)):

1*100/3 -> 33.33333333333333570180911920033395290374755859375 (first 16 digits are correct)
1/3*100 -> 33.3333333333333285963817615993320941925048828125 (first 15 digits are correct)

Notice the former is more accurate. All of the maths here are tested using javascript in a browser.