>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
>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
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,
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
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).
***** 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 >>>
>Yes, precision too high 4 SAS 4 Windows. I must have some
>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
>Regards - jim.
>. . . . . . . . . . . . . . . .
>Jim Groeneveld, MSc.
>6825 MJ Arnhem
>Tel: +31/0 26 376 7365
>Fax: +31/0 26 376 7305
>Showing statistically significant differences between
>generally all sporters, requires larger samples than usually
>From: Bart Heinsius [mailto:eombah@HOTMAIL.COM]
>Sent: Friday, June 25, 2004 14:08
>Subject: long string -> hex -> decimal
>I have a field in a database table that holds a string whose
>hexadecimal value is a decimal value with a special meaning
>So, the string value is : ØB...éã
>The hexadecimal value is : D84285E9E31F0009
>From Windows CALC, the decimal value is:
>I want to compute this in SAS but am running into problems
>precision, I think.
>With the program:
> 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.;
> put gl_element_range n=:32.;
>, n equals 15583164900239671296, which is different from
>It turns out the the last addition that SAS performs in the
> 15583164900239671296 + 9 = 15583164900239671296
>, which is obviously incorrect.
>I think I should be going to a solution where n is character
>Does anyone have an idea how to do this?
Sign-up for Ads Free at Mail.com