Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!uupsi!sunic!ugle.unit.no!nuug!ulrik!nenaas From: nenaas@ulrik.uio.no (Nils-Eivind Naas) Newsgroups: comp.sys.hp Subject: Re: Comparison of HP and Sun Message-ID: Date: 17 Jun 91 07:48:47 GMT References: <1991Jun4.164957.10585@hellgate.utah.edu> <91165.115530YTHNMADD@MTUS5.BITNET> Sender: news@ulrik.uio.no (Mr News) Organization: University of Oslo, Norway Lines: 38 In-Reply-To: YTHNMADD@MTUS5.BITNET's message of 14 Jun 91 16:55:30 GMT Nntp-Posting-Host: ulrik In article <91165.115530YTHNMADD@MTUS5.BITNET> YTHNMADD@MTUS5.BITNET (Noel Maddy) writes: In article <1991Jun4.164957.10585@hellgate.utah.edu>, knechod%peruvian.utah.edu@cs.utah.edu (Kevin Nechodom) says: > .. >I anticipate mostly database (don't know what yet) and stats (probably SAS) >applications. I have been told that Sparc floating point is abysmal, but that >DB and stats are mostly I/O intensive, and Sun is better than HP for I/O. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Actually, I believe SAS (and probably most other stat packages??) always uses floating point internally, even if the number is an integer. This would make floating-point performance a larger criterion. In fact, many statistical packages use exclusively double precision (64-bit) floating point for all numerical work. They even store data on file in this format. At least, both SAS and SPSS do so by default. Then, stats are more than cross-tabulation tables! Try running multi-nomial logit or tobit analyses on a 2000 case survey, and you will discover that "stats" can be computationally demanding as well ! .. > >Kevin Nechodom >University of Utah >CSSRD/STACC >(801) 581-6410 >nechodom@cc.utah.edu >Disclaimer I: I know nothing about my ideas. >Disclaimer II: The University knows nothing about my ideas. >ergo: I and the University are one. -- Noel Maddy ythnmadd@mtus5.bitnet Nils-Eivind Naas nen@isaf.no ISAF, Oslo or nenaas@ulrik.uio.no