Big Numbers (Base 256)

This is a discussion on Big Numbers (Base 256) within the C++ Programming forums, part of the General Programming Boards category; Hullo hullo, If I wanted to manipulate: 72057594037927936 That could be trouble. Now, to make it shorter, I could convert ...

  1. #1
    Epo
    Epo is offline
    Registered User
    Join Date
    Jun 2003
    Posts
    361

    Big Numbers (Base 256)

    Hullo hullo,

    If I wanted to manipulate: 72057594037927936

    That could be trouble. Now, to make it shorter, I could convert it to hexadecimal and then write my own mathematical functions.

    But, to make it even shorter, technically I could, break it up into base 256, based off of 256 available ASCII values (using an array of characters, one for each "digit").

    So, that long number above would merely be:
    char base256[7] = {chr(255), chr(0), chr(0), chr(0), chr(0), chr(0), chr(0)};

    And thus, multiplication between 7 digits should take a lot less time than multiplication of 18 digits. This is my thought-process going into this situation, but I've never really worked with my "own" algorithms for numbers of base 256, so I'm just wondering if there's something inherently wrong with going about it this way?

  2. #2
    VA National Guard The Brain's Avatar
    Join Date
    May 2004
    Location
    Manassas, VA USA
    Posts
    903
    I think our TI series calculators.. handle (large) numbers by using a logrithm to exponentally get a result.

    For example:

    2,456,456,987,123 + 100,345,457,164,221

    Store the numbers into variables for easier reading:

    store 2,456,456,987,123 -> A
    store 100,345,457,164,221 -> B

    Apply logrithmic properties:

    LN A + LN B => (about 29 + 32'ish)
    or LN (A*B)

    so you are dealing with much smaller numbers at this point
    (manipulation at this level should be much easier/faster)




    to get your final answer, just perform an anti-log

    e^(28.5397) + e^(32.2396) = 1.02802 x 10^(14) = 102,801,914,151,344


    I think this is pretty close to how our professor explained it.. Hope this offers a different and perhaps some sort of useful perspective to your problemo.
    Last edited by The Brain; 11-13-2004 at 02:19 AM.
    • "Problem Solving C++, The Object of Programming" -Walter Savitch
    • "Data Structures and Other Objects using C++" -Walter Savitch
    • "Assembly Language for Intel-Based Computers" -Kip Irvine
    • "Programming Windows, 5th edition" -Charles Petzold
    • "Visual C++ MFC Programming by Example" -John E. Swanke
    • "Network Programming Windows" -Jones/Ohlund
    • "Sams Teach Yourself Game Programming in 24 Hours" -Michael Morrison
    • "Mathmatics for 3D Game Programming & Computer Graphics" -Eric Lengyel

  3. #3
    S Sang-drax's Avatar
    Join Date
    May 2002
    Location
    Göteborg, Sweden
    Posts
    2,072
    Quote Originally Posted by Epo
    And thus, multiplication between 7 digits should take a lot less time than multiplication of 18 digits. This is my thought-process going into this situation, but I've never really worked with my "own" algorithms for numbers of base 256, so I'm just wondering if there's something inherently wrong with going about it this way?
    No, it should work. If you want it even faster, use base-65536 or base-2^32 if your processor supports 64-bit integer.
    Last edited by Sang-drax : Tomorrow at 02:21 AM. Reason: Time travelling

  4. #4
    Epo
    Epo is offline
    Registered User
    Join Date
    Jun 2003
    Posts
    361
    Hmm, thanks for the pointers. Now, if I combine BOTH! That...would probably be beyond me

    But, given two ridiculously large numbers (I.e. 99999999999999999999999999999999)....wow, LN of that is just 73 (and some change). K, but I said ridiculous, so, let's assume a number with one million digits, even LN would still be fairly large I'd hope, then conversion to base 65536 (am I correct this is a short?), would then yield something even smaller.

    All that's left to do is write conversion algorithms, and then functions to display the data without ruining a computer. Sounds good enough to me

  5. #5
    Magically delicious LuckY's Avatar
    Join Date
    Oct 2001
    Posts
    856
    That's very funny that you mention this. I happen to have just been discussing the same thing. See this link.

  6. #6
    Epo
    Epo is offline
    Registered User
    Join Date
    Jun 2003
    Posts
    361
    Getting into the brute work of this project, I'm just curious...

    LN will definitely reduce the size of the number I'm working with by a very large factor, but, like most people know, LN, is just LOG with base "e" (2.something).

    Is there a specific reason you picked to LN the number? Because LOG base 10 would further reduce a million digit number to the range of 1000000-10000000 (smaller than what LN would reduce to). Now, of course, LN Base one million would further reduce this, but that would be slightly impractical.

    I'm just curious why you suggested (perhaps if there's a specific reason that TI uses LN) the LN function as opposed to the LOG with a larger base? Simply for the reason of making a choice or some deeper meaning?

  7. #7
    Toaster Zach L.'s Avatar
    Join Date
    Aug 2001
    Posts
    2,686
    You might use natural log essentially because you don't carry around an extra multiplicative factor for all of your computations (although, there is no reason why doing that would not work). Here is a link with the relevant info: http://mathworld.wolfram.com/NaturalLogarithm.html
    Notice the extra factor you have when dealing with derivatives and integrals of/relating to logarithms to another base.
    The word rap as it applies to music is the result of a peculiar phonological rule which has stripped the word of its initial voiceless velar stop.

  8. #8
    #include<xErath.h> xErath's Avatar
    Join Date
    Jun 2004
    Posts
    722
    Quote Originally Posted by Epo
    Is there a specific reason you picked to LN the number?
    Tradition perhaps... and note that when calculating a number's logarithm you lose precision. So with log base 1000000 your results would be very unacurate.

  9. #9
    Epo
    Epo is offline
    Registered User
    Join Date
    Jun 2003
    Posts
    361
    Awesome, thanks for that link and the tips.

    I figure I'm just going to stick with natural log mixed with some of my own conversion methods. What exactly those'll be, well....I guess we'll just have to wait and see
    (Mainly because I don't know what they are yet)

  10. #10
    Magically delicious LuckY's Avatar
    Join Date
    Oct 2001
    Posts
    856
    Out of curiosity, Epo, how do you plan on performing a log (or ln) of an extremely long number?

  11. #11
    Epo
    Epo is offline
    Registered User
    Join Date
    Jun 2003
    Posts
    361
    That would be the tricky part wouldn't it To use LN, the number has to be representable, but if it's representable, then it's small enough that we don't really need LN (Is what I'm expecting)

    My plan so far:
    Store the number in an array of characters to start;

    Then, have a series of "possible" conversions, based on the size of the numbers being worked with, consisting of:

    1 - Decimal Place conversion that'll make the numbers more relative
    2 - Convert to base 65536.
    4 - LN it. (will most likely lose out to...)
    8 - Apply Epo's personalized LN that actually works with arrays of shorts. (I'm assuming this could be a little tough to code An extensive chat with my Calc prof is looming on the horizon)

    And perhaps some more. The number beside each method gets added on to a running total, which will keep track of which conversions have taken place (and thus far, they're ranked in the order of importance I feel is right...I.e. never LN BEFORE Decimal Point conversions, but LN without the initial conversion is still okay). So if the running total = 5, I know a Decimal Point and Traditional LN conversion has taken place, so I know how to backtrack.

    Alot of this is still up in the air, I'm juggling my CS weekly assignments with my Winsock Server with my full-on 3D "project", and now with this. This one is more of just a curiosity though, so it often ends up at the back of the list of things to do.

    I don't know if my own LN function will be out of my reach, can't say I've ever tried anything like this before. I'm expecting that if I can get the LN (oh, and also reverse-conversion back to the actual raw number) down, then many other conversions won't be necessary. (The only reason I plan to convert to base 65536 to begin with is that it should reduce the number of elements in the array that I'll have to apply the LN to).

    So, to answer your question, I still don't know. It's all up in the air and is something that I'm counting on being able to tackle when I get there. Perhaps I'm in over my head. Perhaps people do this everyday. I've no idea what to expect But I guess we'll see.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Converting Base 10 numbers to Base 2, 8, and 16
    By killcapital in forum C Programming
    Replies: 5
    Last Post: 03-10-2008, 10:05 AM
  2. converting to base 10
    By xp5 in forum C Programming
    Replies: 11
    Last Post: 08-31-2007, 02:28 AM
  3. A (complex) question on numbers
    By Unregistered in forum C++ Programming
    Replies: 8
    Last Post: 02-03-2002, 05:38 PM
  4. Number system base M, print numbers N digits wide...
    By biterman in forum C Programming
    Replies: 12
    Last Post: 11-19-2001, 03:31 AM
  5. converting numbers from one base to another
    By partnole in forum C++ Programming
    Replies: 4
    Last Post: 10-04-2001, 12:29 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21