MartyConnelly
martyconnelly at shaw.ca
Wed Mar 22 10:48:03 CST 2006
You could try dll's like this, there is a dos command line function available as well with MAPM You need these when computing things like least-squares curve-fitting algorithms above 10'th order polynomials There are a lot of these packages out there, including commercial packages right up to the cost of SAS and SPSS Most engineering companies will have already purchased these types of packages. You will lose a factor of 10 to 20 in speed using these packages. I haven't really touched them since doing stress analysis of icebreaker hulls. but now they are becoming more needed in fields like genome and genetic research. Anyway this is a freebie MAPM, A Portable Arbitrary Precision Math Library in C. Open source http://www.tc.umn.edu/~ringx004/mapm-main.html Article C++ user Journal http://www.tc.umn.edu/~ringx004/article-main.html Steve Erbach wrote: >Marty, > >Thanks for the excellent technical description. On the demo web site >for the hex conversion there's a breakdown into those three segments >you mentioned, so one can see how it's divvied up. > >I am intensely curious as to whether the Virtual Calc 2000 routines >are callable in VBA. When you consider that Long Integers only go up >to 2^20, and that functions like Mod are limited to numbers of that >size, too, the achievement of folks like Po-Han Lin and Stephen >Wolfram is even more marvelous. > >I'd love to be able to call a routine that would, say, convert a >string of text (in base 62, say) to base 36 after multiplying by pi to >100 decimal places. The only way that Access could handle numbers of >that size, of course, would be as strings...but that would be more >than adequate if it could just be done as a function call. > >Mr. Po-Han's calculator is really something. I'm going to buy the >shareware version so that I can directly manipulate scientific >notation. I intend to write to him to find out about whether he has a >DLL available with those fabulous functions. > >Steve Erbach >http://TheTownCrank.blogspot.com > > >On 3/21/06, MartyConnelly <martyconnelly at shaw.ca> wrote: > > >>There is no decimal point. It is implied. >>Double Floating Point numbers are encoded by IEEE 754 for MS >>1 bit sign (high order bit) really part of exponent by normalization >>11 bit exponent >>53 bit mantissa >>However Intel FPU registers can handle 80 bits but that's another story >>for bedtime. >> >>3FF is 1023 or 1 less than 1024 so there maybe some exponent bias to >>handle negative numbers and exponent >>for 32 bit exponent bias is =127 or 7F approx 2^7 so needs 7 bits and >>1 sign bit storage >> >>This is where it gets weird and has to be groked otherwise read the IEEE >>754 floating point standard >> >> The bias of the exponent. Usually some fixed integer (typically >>127 or 128 for an 8-bit exponent) is added to the exponent as a >>"bias", since an exponent of all zero bits usually is reserved to >>represent the number zero, which must be treated as a special case >>since it cannot, like non-zero numbers, be represented as a >>normalized floating-point number (a "normalized" f.p. number has a >>most significant mantissa digit that's non-zero; if the most >>significant mantissa digit is zero, the number is normalized by >>shifting the mantissa left one digit while decreasing the exponent by >>one, and repeating until either the most significant mantissa digit >>becomes non-zero or until the exponent reaches its smallest possible >>value, whichever comes first. Since the number zero has all mantissa >>digits zero, it cannot be normalized). >>. The representation of the sign of the mantissa. Keeping the sign >>in a separate sign bit, is called the sign-magnitude representation >> and seems to be the most common representation today. >> Other, less common, representations is to use either ones-complement or >> twos-complement representation of the entire mantissa. >> >> If the mantissa is represented in binary normalized form, the most >>significant bit will always be one (unless the the entire number is >>zero) - therefore this bit need not be stored but can be implicit. >>The IEEE 32-bit and 64-bit floating-point formats does not store this >>bit. Other formats (e.g. the 80-bit "extended IEEE" format used in >>Intel x86 FPU's) does explicitly store the most significant mantissa >>bit. IEEE 854 double-extended-precision format (1 sign bit, 15 >>exponent bits, >> 16 empty bits, 64 mantissa bits). >> >>Now if you think this is weird try it on a 36 bit word mainframe. >> >> >> >> >> >_______________________________________________ >dba-Tech mailing list >dba-Tech at databaseadvisors.com >http://databaseadvisors.com/mailman/listinfo/dba-tech >Website: http://www.databaseadvisors.com > > > > -- Marty Connelly Victoria, B.C. Canada