Results 1 to 10 of 56

Thread: Beginner Programming Challenge 13

Threaded View

  1. #1
    Join Date
    Jan 2010
    Not Texas
    Ubuntu 14.04 Trusty Tahr

    Lightbulb Beginner Programming Challenge 13

    Beginner Programming Challenge #13

    Welcome to the 13th Beginner Programming Challenge!

    Hi fora, as the winner of the last beginner programming challenge, I am pleased to present the next challenge.

    For the next challenge, let's make a simple banking program that will take the following as input:

    transaction_code account_number amount
    The transaction codes will be as follows:
    wd - withdrawal [money taken out of the account]
    dep - deposit [money put into the account]
    cred - not what you think it is: [money taken out of the account] YES: this is a withdrawal
    deb - not what you think it is: [money put into the account] YES: this is a deposit
    fee - this is money taken out of the account, but not given to the accountholder. Although basically a withdrawal, this is the only code that allows a withdrawal if it makes the balance less than zero OR if the balance is already less than or equal to zero.

    OK, the program will accept as input in the above-named format and make a record of account numbers and the respective balances. The account can NEVER go negative [from the account-holder's perspective] EXCEPT in the case of a fee. In the event of an "overdraft", the withdrawal/credit will NOT be processed, but a fee will be assessed.

    Here's the challenging part: NO existing database or existing hashing sequence can be used. Hint: I would recommend using a hashing technique, but as long as an existing database/MySQL method isn't used, I will allow any implementation.

    To simplify what I mean here: the programmer should make everything here from scratch except the container for the data and/or the method of resizing the array. Or in other words. Some languages have an "insert" or "append" entry for arrays. C has remalloc. These are both acceptable or *anything* comparable. If a sort or search method is used, you must make this from scratch. If there is a you can't use it.

    : If you want extra credit, make your table with a max number of entries so that your overall array can not be a) resizeable b) greater than xx% greater than the maximum number of entries. At the point that you start using malloc and resize, you would have to sort or redo the whole hash table, which is very inefficient. So, to simplify the task, we'll just set a maximum number of entries at 200. That would make the array's maximum size of 200+200*.xx. Want more credit: find out what the minimal percentage is that still allows an efficient hash search/recall routine.

    Please note: regardless of implementation, it will need to accommodate 200 account numbers.

    I will submit a file that will contain sample entries. The bank program won't "open" the file, but the file will be redirected as the std input. This file may contain any number of entries to facilitate making a decisive choice on speed. To clarify, the speed factor is just to encourage people to be wary of the method they choose in storage/retrieval of the account # & balance.

    Here is how I will be judging the entries:
    1) Readability and appropriate commenting. Following standard code formatting will make your code more readable. Although I have a tendency to comment quite a bit, if you use strategic commenting, you would be surprised how little commenting can actually be useful
    2) Elegance of design. While not as obvious, consider how a feature is being implemented to see if there is a better way.
    3) Overall program speed. To reward those who do this in a way that maximizes speed. Specifically, use whatever implementation you want, but bear in mind that some methods will mean speed sacrifices.
    4) Robustness of design. If the program handles all the above-named things without crashing and is able to handle all exceptions this will look very good.
    5) Extra credit.

    Extra credit section: I will try to make two files, one that has 100% correct entries [as in no invalid transaction codes] and one that has many transaction codes. The format for all the data will be correct and inviolable [you don't have to worry about getting text for the account number or dollar amount of transaction]. The account number will be a number with no leading zeros. It will also be an integer. Assume whole dollar amounts.

    Another extra credit will be to see how small a percentage over the max account numbers you can get while still being able to fulfill the maximum account numbers. Or in other words, it should be possible to fit 200 accounts in a 240 entry table.

    This challenge may seem daunting, but once you figure out your hashing routine, the rest of the challenge will be much easier.

    Good luck

    and p.s. until I get a file uploaded, you can test your program with normal input or make up your own file.
    The file will be 3 items wide, separated with a space, the lines will be terminated normally.
    An example input file would be

    dep 11111 25
    wd 11111 22599
    wd 11111 -2525
    Last edited by texaswriter; June 6th, 2010 at 03:41 AM. Reason: clarified

Tags for this Thread


Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts