Date:         Tue, 26 Jan 2010 13:53:31 -0800
Reply-To:     Ted Clay <tclay@ASHLANDHOME.NET>
Sender:       "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From:         Ted Clay <tclay@ASHLANDHOME.NET>
Subject:      Re: SASware ballot #18 Proc Transpose preserving variable
              attributes
Comments: To: Kevin Myers <KevinMyers@austin.rr.com>
In-Reply-To:  <767B7908AAB44C5EBEEF375A7ADC5C50@KAM1720>
Content-Type: text/plain; charset="us-ascii"

Kevin,
You could bundle lots of features into "ATTRIBSIN" and "ATTRIBSOUT".  Then
you are free to use "NOFORMAT" without confusion.  The compromise is in
accepting defaults names.
ATTRIBSIN would look for and use any standard-named variable, like _FORMAT_,
_TYPE_, and _INFORMAT_.  In fact you could have it look for _NAME_ and
_LABEL_ too if the user does not give an ID or IDLABEL statement. (That
might be the least-surprising behavior, in fact.)
ATTRIBSOUT would produce standard-named variables, only when needed, or with
"FORCE", always.

Your modification would require these options, and no additional statements:
For output: ATTRIBSOUT NOFORMAT   HEXFORMAT   FORCE
For Input:  ATTRIBSIN  NOFORMATIN HEXFORMATIN

Ted

-----Original Message-----
From: Kevin Myers [mailto:KevinMyers@austin.rr.com]
Sent: Tuesday, January 26, 2010 10:46 AM
To: Ted Clay
Subject: Re: SASware ballot #18 Proc Transpose preserving variable
attributes

I agree regarding potential usability concerns surrounding FORMAT vs.
NOFORMAT and INFORMAT vs. NOINFORMAT.  I don't really like the NOFORMAT and
NOINFORMAT option names, but haven't been able to come up with anything
better that doesn't result in very long and cumbersome names.  Any
suggestions?

Your suggested warning seems like a good idea.

----- Original Message -----
From: "Ted Clay" <tclay@ashlandhome.net>
To: "'Kevin Myers'" <KevinMyers@AUSTIN.RR.COM>
Sent: Tuesday, January 26, 2010 11:57
Subject: RE: SASware ballot #18 Proc Transpose preserving variable
attributes


> This works, technically speaking, though the solution is not particularly
> aesthetic.
> Speaking of usability, your "FORMAT" and "NOFORMAT" options are not
> opposites, but that is what a user might expect, by the "principle of
> least
> surprise".  Also, maybe a WARNING should be issued if NOINFORMAT writes
> out
> a numeric value whose unformatted character representation fills more than
> 14 (or some number) spaces, which would indicate that some precision has
> been lost.  So most of the time "NOFORMAT" would work fine, and the user
> would find out when "HEXFORMAT" is needed.
> Ted
>
>
>
> -----Original Message-----
> From: SAS(r) Discussion [mailto:SAS-L@LISTSERV.UGA.EDU] On Behalf Of Kevin
> Myers
> Sent: Monday, January 25, 2010 10:54 PM
> To: SAS-L@LISTSERV.UGA.EDU
> Subject: Re: SASware ballot #18 Proc Transpose preserving variable
> attributes
>
> 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
>>>
>
>
>