>From: Jack Hamilton <JackHamilton@FIRSTHEALTH.COM> :

>I think SAS should support BigNum arithmetic, where all >numbers (integer and >real) are stored as character strings, and calculations are >done as you say >(with some optimization).

I suspect that something (I know not what) in the way of greater precision has been/is under consideration ...

>Lots of SAS would have to be >rewritten to support >it, but that would be needed only once.

Ah, but it would necessitate p'raps artificial organ transplants into "The Belly Of The Beast"? I wonder how many (remaining) SI folks are fully qualified for such work. What it would cost.

>It might not be any >less work than >adding an integer type,

SAS is both famous and infamous for storing all numerics -only- as floating-point representations. I'm not certain they could/should change now.

>then adding a quadruple type,

You mean quadruple integer as an internal data rep?

>then adding whatever is >used in the next generation of computer chips - octuple >precision, also used by >certain deep-sea creatures, is bound to come along someday.

Perhaps it would be better to leave octuple in the deep, blue sea, at least for the foreseeable future. :-)

>It would be less efficient than using native binary formats, >but I don't know >how much less efficient.

Nor do I. I would hope that SI has certain performance standards. Perhaps BigNum would fail miserably even if it were practical to implement. Perhaps not ...

>[Pretend to be David Cassell] Perl supports BigNum [End >pretension] as does >Rexx. Java also, I think, as a class, and Python.

Was BigNum intended for ordinary usage, or just for special circumstances? Again, the performance question.

As possible evidence of my architectural naivete, back around 2000 I kinda/sorta figgered that SI would take a quantum leap in perhaps 2008 and write a truly 64 bit SAS ("a SAS that addressed 64 bits of mem on appropriate HW/SW i.e. Sparc/SunOS or Itanium/Win64") and at the same time default numerics to quadruple float (128 bits), obviating precision problems for many years to come (maybe "forever").

This was based on the assumption that -we- (servers and desktops) would be moving to appropriate 64 bit platforms before too long.

More recently I hear that perhaps 80% of the server box-counts sold in recent times are 32 bit (mostly Xeon). And, of course, finding a 64 bit desktop can be very, very difficult

So, even if my naive conjecture were correct (SI would no doubt think I was star-struck or worse <g>), it looks like 32 bit computing is very much alive/well for many years to come. This doesn't mean they've not started writing a truly 64 bit SAS but it might mean they don't really know what-all they wanna do with it and how it's to be done.

I agree with Jim re quadruple precision and I'm not 100% certain it's not practical to implement quadruple float on the 32 bit systems. Numerics could still default to double precision, but the po' pgmr could code LENGTH BIGUN 16; when needed. This alone would likely involve an overhaul of SAS memory allocation design. Doesn't sound at all trivial. Anybody know if all SI supported platforms support quadruple float? Is there a viable (universally observed and efficient) IEEE (or other) standard for at least the ascii systems?

To summarize, I think demand (for additional precision) is material and growing. As to supply in, say, the next 6 years, I've hardly a clue what will be done (if anything).

Zalut, Puddin'

******************************************************* ***** Puddin' Man **** Pudding_Man-at-mail.com ******** *******************************************************;

"Somebody done Hoo-Doo'd the Hoo-Doo Man!" - John Lee "Sonny Boy" Williamson

>>>> "Groeneveld, Jim" <jim.groeneveld@VITATRON.COM> > 06/25/2004 6:07 AM >>> >Hi Bart,

>Yes, precision too high 4 SAS 4 Windows. I must have some >BASIC (Basicode) >program at home from more than 15 years ago (DOS), which >could do that kind of >calculations with integer numbers of up to 255 digits. It >did the computations >the way you would do it yourself on paper, all >alphanumerically. But I think, >even if you could mimic that in SAS, you would end up with a >value which you >still can't represent binary. So you would have to rewrite >all of it, mimicing >the calculations wanted. Well SAS should have some quadruple >precision for that >purpose. Can't you try to find alternative software for your >goal?

>Regards - jim. >-- >. . . . . . . . . . . . . . . .

>Jim Groeneveld, MSc. >Biostatistician >Science Team >Vitatron B.V. >Meander 1051 >6825 MJ Arnhem >Tel: +31/0 26 376 7365 >Fax: +31/0 26 376 7305 >Jim.Groeneveld@Vitatron.com

>www.vitatron.com

>Showing statistically significant differences between >football teams, >generally all sporters, requires larger samples than usually >applied.

>[common disclaimer]

>-----Original Message----- >From: Bart Heinsius [mailto:eombah@HOTMAIL.COM]

>Sent: Friday, June 25, 2004 14:08 >To: SAS-L@LISTSERV.UGA.EDU

>Subject: long string -> hex -> decimal

>Hi,

>I have a field in a database table that holds a string whose >hexadecimal value is a decimal value with a special meaning >(an >account number).

>So, the string value is : ØB...éã >The hexadecimal value is : D84285E9E31F0009 >From Windows CALC, the decimal value is: >15583164900239671305

>I want to compute this in SAS but am running into problems >with the >precision, I think. >With the program:

>data a; > set fap.gl_acct_list_lines(obs=1); > n = 0; > do i=0 to 7; > c = rank(substr(gl_element_range,i+1,1)); > n = n + c*(256**(7-i)); > put c= n=:32.; > end; > put gl_element_range n=:32.; >run;

>, n equals 15583164900239671296, which is different from >what CALC >calculates. >It turns out the the last addition that SAS performs in the >program >above is: > 15583164900239671296 + 9 = 15583164900239671296 >, which is obviously incorrect. >I think I should be going to a solution where n is character >instead >of numeric. >Does anyone have an idea how to do this?

>Thanks already, >Bart.

-- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm