home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / c / 12436 < prev    next >
Encoding:
Text File  |  1992-08-17  |  2.8 KB  |  61 lines
  1. Newsgroups: comp.lang.c
  2. Path: sparky!uunet!haven.umd.edu!darwin.sura.net!mips!sdd.hp.com!news.cs.indiana.edu!umn.edu!thompson
  3. From: thompson@atlas.socsci.umn.edu (T. Scott Thompson)
  4. Subject: Re: POWER OF LARGE NUMBERS
  5. Message-ID: <thompson.714074422@daphne.socsci.umn.edu>
  6. Sender: news@news2.cis.umn.edu (Usenet News Administration)
  7. Nntp-Posting-Host: daphne.socsci.umn.edu
  8. Reply-To: thompson@atlas.socsci.umn.edu
  9. Organization: University of Minnesota
  10. References: <1992Aug12.135106.12924@cs.uow.edu.au> <thompson.713734408@daphne.socsci.umn.edu> <1992Aug16.052157.1991@organpipe.uug.arizona.edu> <QUANSTRO.92Aug16132245@mari.StOlaf.edu> <1992Aug17.060243.11404@organpipe.uug.arizona.edu>
  11. Date: Mon, 17 Aug 1992 18:00:22 GMT
  12. Lines: 47
  13.  
  14. dave@cs.arizona.edu (Dave Schaumann) writes:
  15.  
  16. >In article <QUANSTRO.92Aug16132245@mari.StOlaf.edu>, quanstro@mari (goon) writes:
  17. >>In article <1992Aug16.052157.1991@organpipe.uug.arizona.edu> dave@cs.arizona.edu (Dave Schaumann) writes:
  18. >>
  19. >>   >>    Does any one know how to raise power of possibly 100 digits 
  20. >>   >>to possibly 100 digits. Any algorithm or code will be appriciated.
  21. >>   >
  22. >>   >Is there any hope of solving this?
  23. >>
  24. >>   Only if you're willing to give up most of the significant digits.
  25. >[...]
  26. >>
  27. >>You just contradicted yourself. It is possible. It just takes more
  28. >>memory and more programming (you can't expect the hardware to handle
  29. >>this sort of case). Check out the man page for mp (a set of arbitrary
  30. >>precision arith. functions) if you are on a UNIX system. There is also
  31. >>a GNU version of these functins.
  32.  
  33. >Take a look at the specification again.  We're talking about calculations
  34. >that will yield results with 10 ** 10 ** 100 digits.  Try to do that with
  35. >a so-called `arbitrary precision' software package, and you'll find out
  36. >that it wants memory for that precision.  We're talking about numbers so
  37. >hugely vast we can't even talk about how many *digits* they have without
  38. >using exponents!  A megabyte has (about) 10**6 bytes in it, so we're talking
  39. >about 10**94 megabytes just to hold the result.  Suppose you can load 1
  40. >megabyte in a 10**-12 seconds (new warp-drive technology), it would take you
  41. >10**78 seconds to load your value.  That's more than 10**71 years.
  42.  
  43. >So I restate my point: yes, you can write software to deal with numbers
  44. >that large, but NOT without dropping 99.9% of your accuracy.
  45.  
  46. Actually it is worse than that since the number of digits needed is
  47. (roughly!)
  48.                 10 ** (10 ** 100)
  49.  
  50. which is _much_ larger than (10 ** 10) ** 100.  (Remember folks, 
  51. exponentiation is _not_ associative!)
  52.  
  53. I am no physicist but I'll go out on a limb with this conjecture:
  54.  
  55. No "arbitrary precision" package can compute the solution because the
  56. number of bits needed to represent the answer exceeds the number of
  57. atoms in the universe.
  58.  
  59. (Well, I suppose we could wait for the new "quantum" computers to
  60. come along. :-) )
  61.