True discard of precision with round

[Tim Evans]

Hi all, I'm using Stata 14 and wish to round data in one of my variables to 1 dp. I shall be retaining the original variable but for export purposes I need to display only 1 dp in the output file. However when I use -round- I end up getting, what appears to me, spurious information and extra dp information that I thought and expected to be discarded. This is how my data are set up:

* Example generated by -dataex-. To install: ssc install dataex
clear
input str9 AreaCode float p50
"P81032"  2.592737
"B86024" 2.4379544
"C82018"  2.123174
"C88656" 3.6908944
"G85027" 2.5807104
"J82622"  2.200846
"B86054" 2.3315396
"N84018"      4.18
"M81074" 4.1080074
end

I then run the code

generate p50_rounded = round(p50,0.1)

On initial inspection the code seems to have worked, however if you inspect the data in the data editor I find for the first record ("P81032") the value for p50_rounded is 2.5999999 with Stata displaying 2.6. When I export to Excel, the value that gets exported is the 2.5999999.

What can I do to force Stata to export what is displayed?

Thanks in advance

[Tim Evans]

Having looked further into this, I dont think its possible to store numeric value to 2 d.p (https://www.statalist.org/forums/for...e-command-line)
So from the above post I taken to creating a string version of the value using this:

gen test1 = string(p50_rounded, "%3.1f")

[Maarten Buis]

Alternatively, you can multiply by 10 and store the integers exactly (as long as they are not very very large):

gen test2 = round(p50*10)

[Tim Evans]

Thanks for your suggestion Maartin. I dont think that will work for me as I want to be able to report 3.1 whereas when I run your suggestion it truncates to 3!

[Nick Cox]

@Maarten (NB spelling) is right. Let me expand on what he said.

Two issues are often confused or even conflated.

Display of numbers to a given number of decimal places is controlled by a display format.

In contrast, rounding to almost anything other than integers often disappoints because it can't possibly do what people want if they don't appreciate fully that computers use binary arithmetic.

Thus if you consider any numbers with fractional parts 0, 0.1, 0.2, 0.3, 0.4, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9 only two of these, 0 and 0.5, can held exactly in binary With fractional parts 0.00 to 0.99 in steps of 0.01 only 0.25 and 0.75 are added to that list. Informal summary: almost all exact decimals don't possess simple binary approximations.

For export, the only remedy that satisfies what you seem to want is to convert to string with a specified display format.

That still leaves the question of what people are going to do with the export. If all they want to do is look at the results, no problem; if they want to do something numerical, you have just handled them degraded data.

More at https://journals.sagepub.com/doi/10....867X1801800311

[Maarten Buis]

I dont think that will work for me as I want to be able to report 3.1 whereas when I run your suggestion it truncates to 3!

It should truncate to 31:

. di round(3.1415927*10)
31

I suspect you missed the multiply by 10 part. This is crucial.

[Tim Evans]

Thanks Nick & Maarten for your suggestions. I've stuck with my suggestion of converting to a string. It is not anticipated that further processing of the data will be undertaken so no degraded data are being provided. I on the other hand will be retaining the original data so can revert back if so needed.