Put here all the clever ideas you got but you don't going to use.

Me :

Using float memory representation to reformulate each float in a new statement using only integers.

Making a http request on Test Cases web page and downloading answers (if you are a winsock and regex expert).

....

Your turn guys

 

I had the idea to take a picture of a calculator on a wooden table and map image locations to buttons, and display the result in the calculator's LCD display. Unfortunately I haven't anything resembling a clue about how to accomplish that, so that idea had to be trashed. Feel free to steal this idea, as I would really like to see a working calculator image.

Badr Z.:

Using float memory representation to reformulate each float in a new statement using only integers.

 I'm using this, but only in a limited manner; its a miniscule part of my gigantic codebase.  You see, this is just the basis of the WTFery.  My code is already 500 very long lines... and not even all the features are implemented yet.
 

I lack sufficient reason to expend the effort to implement anything, but:

In the name of 'extensibility', all math operations are implemented declaratively, via a table of values. For 'simplicity', the table is a set of OISC instructions - you can implement all the required math operations in less than a hundred cells. It's also allocated on the stack, and the function to perform a math operation returns void. The calling function gets the result because the OISC code overruns its working memory area (which is on the stack, you recall) and writes directly into the stack frame *above* the current one, where the calling function keeps its local variables (which have been carefully laid out in the appropriate places in every instance), so the result lands directly in the relevant variable.

Caution: I understand how gcc lays out its stack frames. If you are not familiar with the guts of your compiler, you cannot make this work correctly (so I'm not really concerned that anybody might use this idea, because I doubt anybody else here has spent time working on that stuff, it's incredibly obscure).

The best thing about this method is not its wonderfully non-portable nature, but the fact that nobody else can touch the code without also understanding how stack frames are constructed by *this* particular compiler. Removing the unused variables in the calling function will break the whole thing (so they're duly commented as "do not remove", but with no mention of why this is necessary). Using a different compiler (or a sufficiently different version) will also break it.

One of my discarded ideas was to massively over-engineer the system: arithmetic is handled by an unlimited-precision math library capable of functioning in any number base between 1 and ULONG_MAX.

Carnildo:

One of my discarded ideas was to massively over-engineer the system: arithmetic is handled by an unlimited-precision math library capable of functioning in any number base between 1 and ULONG_MAX.

That could actually become quite useful as a general-purpose library... so this contest is definitely not the right place to implement it ;-)

I had the idea to just implement the test cases with a huge switch or even if-then-else construction, on all other cases just print "Err". Then I decided to move the WTF out of the code elsewhere :-)

blindcoder:

I had the idea to just implement the test cases with a huge switch or even if-then-else construction, on all other cases just print "Err". Then I decided to move the WTF out of the code elsewhere :-)

 I guess your program will say "File Not Found" quite often, then ;-)

I implemented my code, but it's entirely too neat and I don't have the time to make it "Enterprisey" enough.  But, here's some ideas I came up with.

1) Operations may need to be added/removed/modified at any time.  Therefore, they should all be implemented in configuration files.  These files, of course, should be written in HTML (yes, I worked for a company that actually stored configuration files in HTML).

1a) (optional) Since performance is extremely important, the configuration files should implement the operations in assembly language.  Therefore, your application will need to implement an assembler.

1aa) Since MASM can't possibly assemble as fast as you can, implement your own assembler. 

2) For ease of use, all values should be stored in strings.  Any mathematical operations should parse these strings into floats or doubles-- your choice.  When writing them back to strings, keep in mind that the testcases only require 6 digits before and 1 after the decimal point.

2a) Be sure to write your own functions to convert to and from floats so you can optimize them. 

3)  Your application should provide help functionality, but the tech writer is on vacation till next month.  You can either have the intern who got a 'D' in grammar write the help or just leave it @todo.

4) Be sure to internationalize your application.  Be sure to leave all the message catalogs empty.

5) C++ exceptions can return values in a pinch.

 

billbrasky:

2) For ease of use, all values should be stored in strings.  Any mathematical operations should parse these strings into floats or doubles-- your choice.  When writing them back to strings, keep in mind that the testcases only require 6 digits before and 1 after the decimal point.

The test cases requires 0 digits after the decimal point. There even isn't such button as decimal point button in the interface specs screenshot...

Edit: oops, my bad... Test case WTF114: 1 / 2 = 0.5 ... Sorry

Yeah. Getting those decimal places was a lot of hard work. The fact that at any particular point in my submission numbers are either stored as unsigned ints or string representations of unsigned ints or char * representations of string representations of unsigned ints, it was awfully difficult to create fractional output. Luckily a recursive division function + sprintf(buffer,"%s.%s") can make decimal output without the need of fancy things like floats!

billbrasky:

I implemented my code, but it's entirely too neat and I don't have the time to make it "Enterprisey" enough.  But, here's some ideas I came up with.

1) Operations may need to be added/removed/modified at any time.  Therefore, they should all be implemented in configuration files.  These files, of course, should be written in HTML (yes, I worked for a company that actually stored configuration files in HTML).

1a) (optional) Since performance is extremely important, the configuration files should implement the operations in assembly language.  Therefore, your application will need to implement an assembler.

1aa) Since MASM can't possibly assemble as fast as you can, implement your own assembler. 

2) For ease of use, all values should be stored in strings.  Any mathematical operations should parse these strings into floats or doubles-- your choice.  When writing them back to strings, keep in mind that the testcases only require 6 digits before and 1 after the decimal point.

2a) Be sure to write your own functions to convert to and from floats so you can optimize them. 

3)  Your application should provide help functionality, but the tech writer is on vacation till next month.  You can either have the intern who got a 'D' in grammar write the help or just leave it @todo.

4) Be sure to internationalize your application.  Be sure to leave all the message catalogs empty.

5) C++ exceptions can return values in a pinch.

 

2) I tried that, but the atof's took way too long.

5) Good idea. Actual return values are overrated :D (I'm already using exceptions for that, btw)

On point 5), shit, so am I! I thought I was being original...

Massimo:

Carnildo:

One of my discarded ideas was to massively over-engineer the system: arithmetic is handled by an unlimited-precision math library capable of functioning in any number base between 1 and ULONG_MAX.

That could actually become quite useful as a general-purpose library... so this contest is definitely not the right place to implement it ;-)

Arbitrary-precision math libraries exist.  However, they don't vary their behavior based on the desired base, since they always represent it internally in base-2 and rely on separate serialization methods to convert this to strings in other bases.

Trying to inject base-specific processing into said library would be a significant WTF and might fit well into this project, depending on what the judges think represents "clever".
 

billbrasky:

5) C++ exceptions can return values in a pinch.

I had a great idea in another thread.  Print out the equation, take a digital photo of it, and submit it to Amazon Mechanical Turk to have someone figure out the answer.

 

There's been some wonderful stuff in this thread, but I agree with someone's earlier analysis that when you just throw ideas up in a thread such as this one, you might be screwing one or more people (maybe yourself) out of a laptop.  Luckily, the particular algorithms I'm using haven't popped up here yet, but I imagine I'd feel pretty crappy if they did.  Hmm... maybe this could be a strategy?  Try to guess what everyone else is doing, then post it to this thread so they'll get scared and re-write it at the last minute... >:-)

Anyways... but I am glad to see that I seem to be coming at the problem from an entirely different direction than most everybody else... my entry will be a period piece.

There seem to be two major categories of WTFs submitted to this site. I, for the most part, have only seen one of those categories discussed. Mine falls into the other.

Yeah, there's really just two places to put WTFs here.

1) in the code

2) in the UI

Personally, I'm no fan of 1) and all I ever did in 2) is console based, which makes this my very first graphical UI. Guess you are all doomed now! *MUAHAHAHA*

(Note: This'll make me look very stupid when the results are in and I'm in last place) 

No, there is two category. One based on algorithms like casting, conversion, bit operators and a lot of maths.
And the orther category, not discussed yet, the one that use web services, web 0.1 and enterprisey stuff.

Oh SNAP. Just thought of a good one.

Addition = iterating through a string of integers. Every time you hit the end of the string, start over, but start iterating through another string of integers for the 10s, 100s, 1000s, etc.

I'll leave you to figure out the other operations...

ben_:

Addition = iterating through a string of integers. Every time you hit the end of the string, start over, but start iterating through another string of integers for the 10s, 100s, 1000s, etc.

I'll leave you to figure out the other operations...

Two words: slide rule. 

asuffield:

ben_:

Addition = iterating through a string of integers. Every time you hit the end of the string, start over, but start iterating through another string of integers for the 10s, 100s, 1000s, etc.

I'll leave you to figure out the other operations...

Two words: slide rule. 

 Hahahahahahahahaha

 *breath*

hahahahahahahaha

 

Not sure how you would actually code that (without it being too easy), but I'm sure there is a dastardly WTFish answer in there somewhere.
 

I don't want to give away the punchline, but my first idea involved a class called "transistor."

The sliderule idea is great -- if I had another few weeks and OpenGL on the test machine, I might try to make a 3D sliderule simulator... (it would rest on a simulated wooden table...)

I didn't have quite enough free time to implement either of those, and what I've got going is probably even less sensible -- even if the calculator does actually *work*.

EvanED:

asuffield:

ben_:

Addition = iterating through a string of integers. Every time you hit the end of the string, start over, but start iterating through another string of integers for the 10s, 100s, 1000s, etc.

I'll leave you to figure out the other operations...

Two words: slide rule. 

Not sure how you would actually code that (without it being too easy), but I'm sure there is a dastardly WTFish answer in there somewhere.

More or less exactly the same algorithm - addition and subtraction are done on a number line, while multiplication and division are done on a slide rule. That's where the slide rule comes from, it's the next-order version of this algorithm on a number line. In a certain sense, it's a direct implementation of Peano arithmetic. 50 years ago, any engineer could have told you how to do this; nowadays, almost nobody remembers why slide rules work, so it's hopelessly arcane.

Welbog:

I had the idea to take a picture of a calculator on a wooden table and map image locations to buttons, and display the result in the calculator's LCD display. Unfortunately I haven't anything resembling a clue about how to accomplish that, so that idea had to be trashed. Feel free to steal this idea, as I would really like to see a working calculator image.

This sounds fun; if I could find my 30-year-old calculator, a digital camera, and time to learn the relevant gtk graphics programming by the time the contest ends, I might try this.