The Daily WTF: Curious Perversions in Information Technology
Welcome to TDWTF Forums Sign in | Join | Help
in Search

Sore losers

Last post 06-07-2007 4:23 PM by Chicken Little. 13 replies.
Page 1 of 1 (14 items)
Sort Posts: Previous Next
  • 06-01-2007 12:56 PM

    Sore losers

    Anyone who didn't make it to the finals, didn't submit, or didn't write one, feel free to post your code here

     I'm in the last category, my idea was to have a switch statement in each function, indexed on the first argument.

  • 06-01-2007 3:15 PM In reply to

    • dsharp
    • Not Ranked
    • Joined on 05-10-2007
    • Posts 9

    Re: Sore losers

    I can describe my entry.  It was inspired by IBM's Pandoora architecture and consisted of:

    View Layer

    Controller Layer

    Business Object Layer

    Peristence Layer

     

    Communication between layers was handled via "contracts" that were first validated, and then passed to "services"  that actually talked to the lower layer's objects.  At least that's how it was supposed to work.

    Services for a lower layer were retreived from a Service Manager class by name.  In the event of a lookup failure, the service manager would perform a lookup by soundex and call any service with a name that was phoenetically similar to what the programmer had typed.

    Calculations were handled by two different classes, Long and Float.

    Long implemented an integer class capable of represent integers using an arbitrary (but hard coded) number of bits.   Bits were represented by an array of ints.  Addition was a simple carry ripple algorithm.  Subtraction involved converting the right hand term to a negative number (using twos-complement representation) and performing addition.  Multiplication and division were done using elementary school algorithms.

    Float implemented a class that represented numbers as  whole part + numerator + denominator.  In this manner, all calculations involving rational numbers could be represented without errors (unless they required an integer value larger than could be represented by the Long class using its hard-coded bit length).  Math operations were again implemented using elementary school algorithms.  All calculations are exact, rounding only occurs when the number is displayed, as a result Float could potentially use an unlimited amount of storage space, except for the fact that Long is implemented using a static hard-coded bit length.

    The calculators memory function is provided by the persistence layer in the form of two separate persistence services: GetMemoryPersistenceService and StoreMemoryPersistanceService.  Actual storage is accomplished via the filesystem in a text file named "omgwtfMemory.txt"

    Other (mis)features included gratuitous namespace pollution (using namespace std; in headers), and a lack of const correctness.

     

  • 06-02-2007 6:10 AM In reply to

    Re: Sore losers

    Wow, that''s very enterprisey. I too made an enterprisey solution but using web services instead - where the web services are the Google calculator and the OMGWTF test cases page. The application's service layer (a separate exe that is launched by the calculator "client") issues an HTTP request to either of these "services". For optimal speed, the calculator launches two executables to fetch the result from both Google and the test cases page in parallel and uses the result from the server that responds first.

    But this is a little off topic since I submitted my entry. Of course all code is written in the header files to "optimize" the compile time.

  • 06-03-2007 7:58 PM In reply to

    Re: Sore losers

    I wanted to create a full blown OpenGL game sort of thing. Something along a full 3D calculator with its spinning moving places and changing size as you type. Then I could make the numbers dance-dance-dance as they wait for the result to be computer.
    But, alas, I had my AP tests and that prevented me from finishing it on time. And microsoft's virtual PC is really bad at virtualizing opengl apparently....8FPS is not too bad but the 8FPS were just for the window itself.


  • 06-05-2007 2:54 AM In reply to

    • araxon
    • Not Ranked
    • Joined on 05-01-2007
    • Posts 4

    Re: Sore losers

    OpenGL game calculator? Based on Quake engine maybe? I imagine the "Final Result Room" with the "=" button and a display, and offcourse with The Very Bad Final Boss guarding it...
  • 06-05-2007 4:33 PM In reply to

    Re: Sore losers

    I was going to do something similar, with a full FPS game in which you had to shoot rocket-launcher-wielding robots that had the symbols you wanted written on them (so to do, say, "2 + 3 = ", you'd destroy the 2, robot, the + robot, the 3 robot, and the = robot).  And of course the robots would be shooting back, and if you died you'd have to start all over again.

     But I never did have enough time to implement it.

    It's funny because it's out of context.
  • 06-05-2007 9:19 PM In reply to

    Re: Sore losers

    Albatross:

    I was going to do something similar, with a full FPS game in which you had to shoot rocket-launcher-wielding robots that had the symbols you wanted written on them (so to do, say, "2 + 3 = ", you'd destroy the 2, robot, the + robot, the 3 robot, and the = robot).  And of course the robots would be shooting back, and if you died you'd have to start all over again.

     But I never did have enough time to implement it.



    Yeah, thats how I was working on it too XD. And I borrowed heavily from the quake source code... but still not enought time plus Virtual PC was way too slow sadly.
    It would have been great tho! But now that the contest is over I decide to reuse my code for a cards game. It's going great except that  if I go for 16x FSAA, then it gets bogged down to 80FPS. If I go for 4x FSAA then its fine.


    Here is the 4x FSAA shot. 
  • 06-06-2007 10:26 AM In reply to

    Re: Sore losers

    Random832:
    Anyone who didn't make it to the finals

    Looks like this is my case, based on that "no email from Alex" thing.

    Too bad, I was actually quite proud of my self-destroying objects (not to mention the runtime-patched ASM code) :-(

    Maybe those were just too technical WTFs for this contest...

  • 06-06-2007 10:58 AM In reply to

    Re: Sore losers

    Massimo:

    Random832:
    Anyone who didn't make it to the finals

    Looks like this is my case, based on that "no email from Alex" thing.

    Too bad, I was actually quite proud of my self-destroying objects (not to mention the runtime-patched ASM code) :-(

    Maybe those were just too technical WTFs for this contest...

    The runtime-patched ASM was pretty sweet. Well commented, too. I didn't even know that was possible (using a function pointer to ASM code in memory like that). Which one was the self-destryong objects -- PolyCalc? If so, we couldn't follow it very well -- it looked like template abuse mostly... not so well commented.

    As far as why they didn't make finalist, it's not that they were too technical, it's just that they weren't complete enough solutions compared to others. Other entries did ASM (like today's second article, though I think you were the only one who rewrote it) and did stuff on top of that...

  • 06-06-2007 11:10 AM In reply to

    Re: Sore losers

    Alex Papadimoulis:
    The runtime-patched ASM was pretty sweet. Well commented, too. I didn't even know that was possible (using a function pointer to ASM code in memory like that). Which one was the self-destryong objects -- PolyCalc? If so, we couldn't follow it very well -- it looked like template abuse mostly... not so well commented.

    That's probably true, but understanding what it does was part of the fun ;-)

    There's a base Operation class which defines a DoOperation() virtual method, which is then implemented by the derived classes (Add, Sub, Mul & Div); so, if you have a pointer to an Operation object which actually points to an instance of one of the derived classes and call DoOperation() on it, the proper operation is performed. This is just plain polymorphism, so there's nothing magical in it :-)

    The magic comes when you call the ChooseOperation() method: it destroys the class it belongs to, then replaces it (by using a placement new operator on "this") with a new instance of the appropriate class. So, if you have an Operation* pointer which actually points to an Add object and call ChooseOperation('*') on it, you end up with the same pointer pointing to a Mul object, which was constructed in the same memory area previously occupied by the Add object; of course, if you now call DoOperation() on it, it performs a good old multiplication :-)

    Ok, maybe it actually was too technical ;-) There were absolutely no templates involved, anyway ;-)

    As far as why they didn't make finalist, it's not that they were too technical, it's just that they weren't complete enough solutions compared to others. Other entries did ASM (like today's second article, though I think you were the only one who rewrote it) and did stuff on top of that...

    That's a whole diferent point. I really love small but crazy WTF, as opposed to overly-complicated solutions... so, since the main point of the submissions was in demostrating those two programming techniques, I thought wrapping them in even more insane projects would have defeated their purpose and made following the Real WTF (TM) more difficult :-)

  • 06-06-2007 10:27 PM In reply to

    Re: Sore losers

    I made a networked one (with separate client and server binaries) which looked "enterprisey" on the outside (sent one char at a time, each in its own packet wrapped in some XML) but actually was mostly a hard-coded hack (no XML parser, it just used strcmp to check for the different packet types, ignored the start-of-session packets because it only needed to catch the end-of-session packets, etc.) with some memory leaks, messy code, no real error checking, and a hard-coded list of test case strings on the server side (I tried to use a hash table, but GHashTable wasn't working).  Altogether it looked like it was slapped together in 10 minutes, because, well, it was.  The GUI was also supposed to be a PITA to use - you had to right-click on the display to cycle through numbers and operators and then minimize the window to insert.  I was sort of proud of it at first, but after seeing all these other much more horrible calculators, I've realized that it's only a very minor WTF, and I could have made it much, much better (worse?) if I had spent more time on it.  I mean, seriously, how can that compare to runtime-patched assembly code?  Oh well, maybe next time.
  • 06-06-2007 11:19 PM In reply to

    Re: Sore losers

    Mine were coded late at night, without much sleep. That lead to rather goofy code


     

  • 06-07-2007 9:12 AM In reply to

    Re: Sore losers

    burntfuse:
    I mean, seriously, how can that compare to runtime-patched assembly code?

    You are at least the third person to publicly state that one of my entries is great (for very peculiar values of "great"), yet none of them made it to the finals. That's amazing. Oh, well, maybe I'll be running for a People's Choice prize :-D

    I'm quite curious about what Joel, Raymond and Jeremy would have thought of them, though (yeah, that's allitteration at its best ;-)).

  • 06-07-2007 4:23 PM In reply to

    Re: Sore losers

    Looking at the ones that did make the finals I can see why mine did not make it. Not working in the IT industry I simply missed the whole general idea of what was expected. I rewrote the calcfunc.cpp file as someone who barely knew C, and definitely did not know about the CRT or STL libraries. The finalist are just so much more in depth, written by people who know what they are doing with the C++ language and libraries, but don't have a clue as to how to properly implement a simple calculator.

    Oh well, better luck next time...

Page 1 of 1 (14 items)
Powered by Community Server (Non-Commercial Edition), by Telligent Systems