I think the format is 9(13), which I've seen in COBOL code, meaning a 13
digit number.
Infix would have messed up the last couple of digits of the variable when
read in as a float, not as a string, due to rounding. If you explicitly
declare it to be stored as a double that should work too.
If this variable is quantitative data is it really measured precisely out
to the 12th or 13th digit? In other words does the rounding matter in the
slightest?
> It doesn't surprise me that -infix- doesn't
> behave as expected or hoped with input like
> 9(13). How would you expect or hope -infix- to
> interpret 9(13)?
>
> As you say, one option is to read in the data
> as string and carry out later surgery.
>
> Another option is to fix the problem upstream
> of Stata with a text editor or scripting language.
>
> I doubt there are any other options.
>
> Nick
> n.j.cox@durham.ac.uk
>> Rima Chakravarty
>>
>> I am trying to import an ascii file into Stata using the
>> infix command.
>> There are fields which has the format as 9(13), without any decimal
>> place but numeric. Stata is messing up the last two numbers of that
>> specific field in the imported Stata file. But if I import
>> that field as
>> a string field then it is importing it correctly. I have been
>> trying to
>> figure out why this is happening for quite sometime. Just
>> wondering if
>> anybody have an answer for this.
