|
Yes I agree Ted. I expected (perhaps unjustifiably) that formatting values
using BEST30. or something similar would output character values that could
be re-converted to numeric with no loss in precision. Although forcing use
of the hex format could technically solve the double conversion precision
issue, to me the unreadability of the resulting character representations
for numeric values would be undesirable in many cases.
Perhaps there is a bug in the format or corresponding informat used in your
test case which prevents full precision conversion from/to numeric.
However, I suspect it is more likely that the true source of the problem is
unavoidable round off error when converting exact decimal fractions to
binary represenatation. If so, then I don't believe there is any easy way
around this problem using a decimal character representation for numeric
values.
After considering various possibilities, I suggest the following
modifications to the previous NOFORMAT/NOINFORMAT idea:
The user can specify zero or one of the following two options:
NOINFORMAT - for transposed values where source is char, if dest is char
value will be read unformatted, else value read using 30.
HEXINFORMAT - for transposed values where source is char, if dest is char
value will be read unformatted, else value read using HEX16.
Neither of these options have any effect if the source variable is numeric.
The user can specify zero or one of the following two options:
NOFORMAT - for transposed values where dest is char, if source is char value
will be written unformatted, else value written using BEST30.
HEXFORMAT - for transposed values where dest is char, if source is char
value will be written unformatted, else value written using HEX16.
Neither of these options have any effect if the destination variable is
numeric.
What do you think?
----- Original Message -----
From: "Ted Clay" <tclay@ASHLANDHOME.NET>
To: <SAS-L@LISTSERV.UGA.EDU>
Sent: Monday, January 25, 2010 23:24
Subject: Re: SASware ballot #18 Proc Transpose preserving variable
attributes
> Kevin,
> OK, a solution exists -- hex format. (Thank you, Data) How would you
> implement it? One possibility is that the character representation would
> look like a hex constant, with quotes followed by "X". Would this happen
> only when necessary to prevent loss of precision, or all the time? It
> seems
> a shame to make integers unreadable just because you request "NOFORMAT".
> Clearly there are some design trade-offs to wrestle with.
> Ted
>
>
>
> -----Original Message-----
> From: SAS(r) Discussion [mailto:SAS-L@LISTSERV.UGA.EDU] On Behalf Of Data
> _null_;
> Sent: Monday, January 25, 2010 6:39 PM
> To: SAS-L@LISTSERV.UGA.EDU
> Subject: Re: SASware ballot #18 Proc Transpose preserving variable
> attributes
>
> HEX16.
>
> 105 data _null_;
> 5106 x=1/3;
> 5107 xc=put(x,hex16.);
> 5108 newx=input(xc,hex16.);
> 5109 if x=newx then put 'Same';
> 5110 else put 'Different';
> 5111 put xc=;
> 5112 run;
>
> Same
> xc=3FD5555555555555
>
>
> On 1/25/10, Ted Clay <tclay@ashlandhome.net> wrote:
>> Here is a test case trying to cause data loss when converting numeric to
>> character to numeric:
>>
>> data _null_;
>> x=1/3;
>> xc=put(x,30.28);
>> newx=input(xc,30.28);
>> if x=newx then put 'Same';
>> else put 'Different';
>> put xc=;
>> run;
>>
>> Different
>> xc=0.3333333333333300000000000000
>>
>> Is there a way to fiddle with this code to make "Same" come out? Is this
>> character representation truly at the limit of resolution, comparable to
> how
>> numbers are stored in SAS? Or is there more information "in there" that
> can
>> be somehow coaxed out? I found that hard-coding an extra "3" in XC did
>> nothing, but adding an extra "33" did the trick.
>>
>> To put this in perspective, a separate Proc Compare showed the difference
>> was on the order of E-15.
>>
>> Ted
>>
|
