• Benjamin Smith (unregistered) in reply to kipthegreat
kipthegreat:

The "Dollars" column, despite it's name, really stored pennies.

Except for being name "Dollars", isn't this how you're supposed to do this?  That's what I was taught in like CompSci 101 anyway.  It's never been an issue for me, and avoids questions like "Why is the sum of seven \$0.01 transactions less than \$0.07" (or something like that which might be seen in the real world).

As for the date garbage, why wouldn't they just use a Unix timestamp?  Seems much easier to me...

Unix timestamps are accurate to the second.

Sometimes you need to ensure uniqueness of a date, not a second in time. Storing dates in this format YYYYMMDD is pretty straightforward, compact, and allows for easy, portable constraints to ensure the uniqueness of a specific date.

// THIS IS NOT A WTF //

The WTF is the convoluted way that the poster described the date format, as though "YYYYMMDD" wasn't somehow easier to recognize...
• Doh! (unregistered) in reply to stevekj
stevekj:
Anonymous:
kipthegreat:

Except for being name "Dollars", isn't this how you're supposed to do this?  That's what I was taught in like CompSci 101 anyway.  It's never been an issue for me, and avoids questions like "Why is the sum of seven \$0.01 transactions less than \$0.07" (or something like that which might be seen in the real world).

As long you never need to refer to less than 1cent or a fraction of a cent this method is fine. For example, what is the unit price of a washer if 100 washers cost \$2.49?

And good luck if you ever need to represent the price of a litre of gas (or a gallon in less enlightened countries), which around here is 99.9 cents today.

The whole issue of accuracy and precision in numerical computations is more complex than it appears at first glance.    Definitely don't use (binary) floating point to represent decimal (fractional) numbers if accuracy is at all important to you, which it usually is.  Either integers or decimal fractional data types are much better.  But equally important is to keep track of how many digits of precision you have in your computation, since most decimal (fractional) numbers we encounter in day-to-day usage are inexact, including prices.  (But not including dates!)

I am trying to have this discussion with some of my co-workers and it's an uphill battle.  "What do you mean by 'inexact', exactly??  Aren't all numbers exact??  I'm just going to get around the problem by arbitrarily defining all these decimal values in the database as being exact so I don't have to worry about it."

I guess nobody ever heard of a mill.

Look, I've restrained myself.    I swore I would read all the responses before posting..

there's NO WTF here.

Convert \$2.49 to pennies by stripping out the "\$", and ".".

If its \$15,249.49, yeah, strip out the  the ",".

if its 15259.5 (like data from *nix systems), parse it.

That's why they're paying you the bucks.

If the the date plus 10 overflows, parse it. Fix it.

Any C programmer could do this with both eyes and asshole closed.

The rest of you script kiddies, get a life!!!!!

• doh! (unregistered) in reply to Doh!
Anonymous:
stevekj:
Anonymous:
kipthegreat:

Except for being name "Dollars", isn't this how you're supposed to do this?  That's what I was taught in like CompSci 101 anyway.  It's never been an issue for me, and avoids questions like "Why is the sum of seven \$0.01 transactions less than \$0.07" (or something like that which might be seen in the real world).

As long you never need to refer to less than 1cent or a fraction of a cent this method is fine. For example, what is the unit price of a washer if 100 washers cost \$2.49?

And good luck if you ever need to represent the price of a litre of gas (or a gallon in less enlightened countries), which around here is 99.9 cents today.

The whole issue of accuracy and precision in numerical computations is more complex than it appears at first glance.    Definitely don't use (binary) floating point to represent decimal (fractional) numbers if accuracy is at all important to you, which it usually is.  Either integers or decimal fractional data types are much better.  But equally important is to keep track of how many digits of precision you have in your computation, since most decimal (fractional) numbers we encounter in day-to-day usage are inexact, including prices.  (But not including dates!)

I am trying to have this discussion with some of my co-workers and it's an uphill battle.  "What do you mean by 'inexact', exactly??  Aren't all numbers exact??  I'm just going to get around the problem by arbitrarily defining all these decimal values in the database as being exact so I don't have to worry about it."

I guess nobody ever heard of a mill.

Look, I've restrained myself.    I swore I would read all the responses before posting..

there's NO WTF here.

Convert \$2.49 to pennies by stripping out the "\$", and ".".

If its \$15,249.49, yeah, strip out the  the ",".

if its 15259.5 (like data from *nix systems), parse it.

That's why they're paying you the bucks.

If the the date plus 10 overflows, parse it. Fix it.

Any C programmer could do this with both eyes and asshole closed.

The rest of you script kiddies, get a life!!!!!

pennies = (pennies*115)/100

Don't make me puke!
• doh! (unregistered) in reply to me from den bosch
Anonymous:
In accounting that is a serious problem because debit and credit do not match and you cannot close your books. Doing your math is not enough, you also must look carefully at your rounding to avoid that negative numbers round the same way as positive numbers.

These difference no matter how small are a serious problem in accounting systems.

The real money is to made in jobs that don't involve "Accounting".

• Out of the Woods (unregistered) in reply to me from den bosch
Anonymous:
In accounting that is a serious problem because debit and credit do not match and you cannot close your books. Doing your math is not enough, you also must look carefully at your rounding to avoid that negative numbers round the same way as positive numbers.

These difference no matter how small are a serious problem in accounting systems.

from den Bosch:

The real WTF  is this forum software.

Of course, we've heard this many times before.

But, consider. . .

One opens the forum, somewhere past "First" post.

Possibly past the first 50 posts.

Hmmm...  Something perhaps worthy of a reply.

Captcha isn't valid.   OK.   The dinky thing on the bottom of the screen has timed out.  Fair enough (but, solveable by software).

But, when the entry IS accepted, one is kicked back to the original highest-level for that date.  Dumb, dumb, software, doesn't know to bring you back were you where when your now-interrupted train-of-thought let you to make a comment.

Not to mention that registering and/or putting in your real name leads to a lifetime supply of V*agr*a Sp*m

SSUUCCKKSS!!

• Doh! (unregistered) in reply to smbell
smbell:
Anonymous:

WHAT?!  My calculations might be off by 0.0000000001% if I use floating point numbers?!  That's a horrible, horrible tragedy!  I will use integers for everything I ever do in the future.  Thanks for setting me on the enlightened path.

This looks to me like sarcasm.  If so, in the imortal words of Napoleon Dynamite... "IDIOT!"

In any system that tracks real money you never store that money in a floating point variable.  Never, never, never!  It would be a WTF well beyond the stupid garbage that is the topic of this today's message.  Values of \$.01 (very common in most financial apps) will usually cause problems, and if you process any large transactions things can get really screwy.

Money needs to be stored in a form that is precise.  Integers work (although I'd go with longs over integers), for the most part, foreign currency can make things interesting.  Many programming languages have a Decimal type to deal with this for you.  Most DB's have a Decimal type in which the precision can be set.  Worst case you can store the values as char arrays or strings.

That being said, (unless I'm missing something about the FLOAT cast), the code in question destroys the precision we assume they were aiming for with the FLOAT cast.

The Date Integer is a lesser WTF, but most of the problems with that have been mentioned already.

Consider the Gas Companies, who charge at rates of n.nnnn per cubic meter of gas.    Conversion to (your unit of choice), in integers or longs (depending on your system, definitely not a float), makes the math much more accurate.

Certainly more accurate than an Excel spreadshit. . .   Ooops  I guess that's why they paid me to fix the problem.

• Doh! (unregistered) in reply to Gene Wirchenko
Gene Wirchenko:
Anonymous:
And tack a late fee onto that bill, and you'll really have a problem.

There apparently have been cases of people being dunned for \$0.00 with a threat to send the amount to collection if it is not paid.

We can laugh about it, but about the RW impact?  Customers can be lost over such stupid mistakes.  If I got such a bill, I would likely switch to a more clueful company.

Sincerely,

Gene Wirchenko

I'm waiting for the phone call from the guy who says I owe \$0.00

lol, comkb
• Doh! (unregistered) in reply to warmachine
warmachine:
Dates stored as encoded integers? Aah! I've inherited a database where a timestamp is stored as a presentation string in DD-MMM-YYYY HH:MM:SS.SSS format and a screen that selected records within date ranges. The SQL to do this was hideous. As you can guess, the performance sucked and an index couldn't be added. But at least the field could be displayed as is.

Oh alright, encoding a timestamp as an integer would allow range selection and working index, making it better than string. Still more painful than using DATE for no benefit.

Hello?

January, 1970 + 2^32 is sometime in 2038.

It'll make Y2K look like a tea-party.

• 08 (unregistered) in reply to Maurits
Maurits:
Otto:
"(1 + CAST(15 AS FLOAT)/100)"
Is it just me, or is this stupider than normal? What's wrong with typing "1.15" ?

It's not as bad as it looks.  The execution plan will very likely compile that to a constant anyway.

There is a slim justification in the expanded version because you can easily do a search-and-replace for "15" to "8" and the expanded version will still be correct.  1.15 on the other hand would become 1.8, which is a hike of 80% instead of 8%.

That's just plain Stupid
Anonymous:
Maurits:
Otto:
"(1 + CAST(15 AS FLOAT)/100)"
Is it just me, or is this stupider than normal? What's wrong with typing "1.15" ?

It's not as bad as it looks.  The execution plan will very likely compile that to a constant anyway.

There is a slim justification in the expanded version because you can easily do a search-and-replace for "15" to "8" and the expanded version will still be correct.  1.15 on the other hand would become 1.8, which is a hike of 80% instead of 8%.

you have two options for searhc and replace
1) replace 1.15 with 1.08 or replace 15 with '08' eitherway there is no problem keep in mind
search and replace works on stings it dosn't care that the string is a number and will not trim leading zeros.

I should have read further. . .  but, as someone once said, once the seal has been broken. . .

• 08 (unregistered) in reply to Gene Wirchenko
Gene Wirchenko:
Anonymous:
Maurits:
Otto:
"(1 + CAST(15 AS FLOAT)/100)"
Is it just me, or is this stupider than normal? What's wrong with typing "1.15" ?

It's not as bad as it looks.  The execution plan will very likely compile that to a constant anyway.

There is a slim justification in the expanded version because you can easily do a search-and-replace for "15" to "8" and the expanded version will still be correct.  1.15 on the other hand would become 1.8, which is a hike of 80% instead of 8%.

you have two options for searhc and replace
1) replace 1.15 with 1.08 or replace 15 with '08' eitherway there is no problem keep in mind
search and replace works on stings it dosn't care that the string is a number and will not trim leading zeros.

It is still possible to get in trouble.  In C, "08" is an illegal octal constant.

Sincerely,

Gene Wirchenko

Actually, "08" is a string.

Almost sincerely. . .
• Foo (unregistered)

The real wtf is that so many of the people who post on here have no clue.

I simply cannot believe today's discussion.

Most of you monkeys don't even know why today's wtf is a wtf... but you think you do - and post comments that expose you as a clumsy operator.

If you don't really understand today's wtf like so many of today's posters, you really need to go back to school.

Well done guys, keep the wtf comments coming, they always make us cringe more than the original post!

• Jesus (unregistered) in reply to Foo
Anonymous:
The real wtf is that so many of the people who post on here have no clue.

I simply cannot believe today's discussion.

Most of you monkeys don't even know why today's wtf is a wtf... but you think you do - and post comments that expose you as a clumsy operator.

If you don't really understand today's wtf like so many of today's posters, you really need to go back to school.

Well done guys, keep the wtf comments coming, they always make us cringe more than the original post!

Let's hear it for the Pope!

• John Hensley (unregistered) in reply to doh!
Anonymous:

pennies = (pennies*115)/100

Don't make me puke!

IBM has something called the "telco benchmark", where you have to add up price, tax, and tariff for a million phone calls. All results have to be correct to the cent (I suppose they did the calculations with rational arithmetic to get the exact values). If you use standard floating point arithmetic, you can be as much as \$20 off.

Major long-distance companies go through that many calls in a couple minutes.

Go puke.

• oiu8uuu88 (unregistered) in reply to John Hensley

Oh man.

I once worked somewhere where almost all money calculations were done in Excel, even by the "programmers" in my department.

One day, one of the guys had summed a column and he was puzzled as to why it didn't total up to what it was supposed to.

I told him that it was because Excel used floating-point numbers.  Of course, because he had zero formal training in CS, he had no idea what a floating point number.  Since he was supposed to be some sort of superstar dude, I left him to his own devices.

To this day, he still doesn't get it.  At the very least, he could multiply his column values by 100, sum them, and then divide the total by 100.  But he was never "superstar" enough to figure that out.

• oiu8uuu88 (unregistered) in reply to John Hensley
Anonymous:
Anonymous:

pennies = (pennies*115)/100

Don't make me puke!

IBM has something called the "telco benchmark", where you have to add up price, tax, and tariff for a million phone calls. All results have to be correct to the cent (I suppose they did the calculations with rational arithmetic to get the exact values). If you use standard floating point arithmetic, you can be as much as \$20 off.

Major long-distance companies go through that many calls in a couple minutes.

Go puke.

Good example.  There was also a situation in Canada where a bank here was calculating mortgage and credit card interest using floating point values.  They ended up giving back money to a whole schwack of people here.  I sincerely hope to God the IT people working on that were drawn and quartered.
• Nicolas Lehuen (unregistered)

If you are worried about the inaccuracy of float or double, DBMS vendors are too, and that's why they often provide a decimal or money datatype which while a little more spacey does the computations in the right way.

• mike (unregistered) in reply to Tei
Tei:
Re-post

Post found on the PHP manual.

10-Aug-2004 06:41
Beware of FLOAT weirdness!

Floats have a mind of their own, and what may look like an integer stored in a float isn't.

Here's a baffling example of how floor can be tripped up by this:

<snip>

THe moral of this story - never use float for anything that needs to be accurate! If you're doing prices for products or a shopping cart, then always use an integer and store prices as a number of pence, you'll thank me for this later :)

This is a WTF as well. The whole floats have a mind of their own blah, and tripping up floats bullsh*t... It's a programming language, it works the way it was designed to, you can't trip it up, and it doesn't have a mind.

This person first explains how floats work, and then says never to use them because floor() might lead to unexpected results. Yeah, and dividing an int by 0 will lead to strange results as well, so best not use ints, they can be 'tripped up'. If you can't cook, stay out of the kitchen...

• DavidK (unregistered) in reply to Brian Kemp
Anonymous:
A 15% fee on a dollar amount is still the same as a 15% fee on a cent amount. That's the real WTF right there

I'm almost crying with laughter at this. The guy is spot on.
• (cs) in reply to John Bigboote

My #1 WTF sofar... Unbelievable.....

• (cs)

[N]

Is the word "consultant" somewhat abused here?

Consultant: "one who gives professional advice or services". If your company hires non-consultant problematic would-be code hackers, go see your boss and convince him he was wrong. He should hire more employees who clean messy systems!

More questions I have when reading susch stuff:

Are consultants just out there to assure jobs for employees by creating messy systems?

Would employees on their own be able to even start creating such a mess?

[B]

• (cs) in reply to RJTECH
RJTECH:

[N]

Is the word "consultant" somewhat abused here?

Consultant: "one who gives professional advice or services". If your company hires non-consultant problematic would-be code hackers, go see your boss and convince him he was wrong. He should hire more employees who clean messy systems!

More questions I have when reading susch stuff:

Are consultants just out there to assure jobs for employees by creating messy systems?

Would employees on their own be able to even start creating such a mess?

[B]

There are always pros and cons.
• (cs) in reply to andrew queisser
Anonymous:

The "pennies as ints" approach isn't so bad but what really puzzles me is

What's wrong with using the stored datatypes that come with your database.
You ca't avoid rounding problems, of fractional numbers in a computer system. Never! (within reason)
Not even when you try to reimplement a solution for it using only ints. It's bullshit and while you're solving one problem, you're introducing tons of other problems.
• Anthony (unregistered) in reply to Doh!
Anonymous:

There apparently have been cases of people being dunned for \$0.00 with a threat to send the amount to collection if it is not paid.

In that circumstance, I would send the payment immediately. In cash.

• (cs) in reply to ammoQ
ammoQ:
RJTECH:

[N]

Is the word "consultant" somewhat abused here?

Consultant: "one who gives professional advice or services". If your company hires non-consultant problematic would-be code hackers, go see your boss and convince him he was wrong. He should hire more employees who clean messy systems!

More questions I have when reading susch stuff:

Are consultants just out there to assure jobs for employees by creating messy systems?

Would employees on their own be able to even start creating such a mess?

[B]

There are always pros and cons.

Cons are usually brought in as wearing double cuffs and cuff links adds more weight to your coding.

Seriously tho, just use money data types and use a decent machine to serve from.
• Eq (unregistered) in reply to ParkinT
ParkinT:

Edgar Plonk:
"Cliché" is not an adjective. It is a noun. The adjective is "clichéd", if you really feel compelled.

That would be "if you ARE compelled" [:)]

He's wrong, anyway. "Cliche" is quite acceptable as an adjective in English, and it's obvious why if you know the French. I wish people wouldn't bitch about grammar when they are clueless.

• Anonymoose (unregistered) in reply to Justin
Anonymous:

Um... 12.2386 rounded = 12.24

61.19 + 12.24 = 73.43

Um, not programatically (IME anyway). The extra's just get trimmed.
• Anonymoose (unregistered) in reply to Anonymoose

Just like that apostrophe that sneaked in to my post should be trimmed.

• CelkoFan (unregistered) in reply to Anonymoose

Joe Celko has a nice line on developers and floats:

The moron that declared columns to be FLOAT in a commercial system is probably a C programmer who does not understand rounding errors.

http://www.intelligententerprise.com/000626/celko.jhtml

• One (unregistered) in reply to The Anonymous Coward

First, that is false. I work in assembly language. It's not "more resource-intensive".

On the second, Epsilon value is used not to minimize, but to eliminate completely errors. As it's been pointed out, putting 0.1 * 0.1 in the explorer direction bar returns a value of 0.0100000......00000020 That would fail to test against 0.01 but it's enough close. That's Epsilon for. If you know the limits of your floating point unit, no problem. And that leads me to say, how can 0.00000000000000000000000000000x prevent a 2 decimal number from being calculated with correctness? (And don't tell there are a zillion values of that form in bank transactions as that would be the necessary distinct values needed to fool the calculation)

And actually, the precission that a float can give (remember, no doubles in 3d engines) is enough for all purposes.

• MarkUK (unregistered)

Non-portable to countries that don't use the dollar - think of the amount of work required for each country 1,\$s/DOLLAR/EURO/g etc.

However, if it had been called CENTS, at least it could be used in the Euro zone, or call it PENNIES and you can use it in the UK. :)

Or CENTS_OR_PENNIES_OR_SIMILAR and you can use it anywhere. :)

And you may tip 15%, but this side of the pond we are too mean, make that 15percent_or_5percent_if_british

• (cs) in reply to Foo
FooDude:
The real wtf is that so many of the people who post on here have no clue. I simply cannot believe today's discussion. Most of you monkeys don't even know why today's wtf is a wtf... but you think you do - and post comments that expose you as a clumsy operator. If you don't really understand today's wtf like so many of today's posters, you really need to go back to school. Well done guys, keep the wtf comments coming, they always make us cringe more than the original post!

Heh, you're just trying to trick people to tell you exactly why this WTF _is_ a WTF, 'cause you just have no clue ;)

(Smiley should be enough, shouldn't it... Right? RIGHT??? WTF...)
• (cs) in reply to CelkoFan
CelkoFanDude:

Joe Celko has a nice line on developers and floats:

The moron that declared columns to be FLOAT in a commercial system is probably a C programmer who does not understand rounding errors.

http://www.intelligententerprise.com/000626/celko.jhtml

Just seeing his name makes stuff like 'fields are not columns' going through my head...
• Jalf (unregistered) in reply to One
Anonymous:

The precission that a float can give (remember, no doubles in 3d engines) is enough for all purposes.

So it doesn't bother you if your bank is unable to represent the amount \$0.1?

On the second, Epsilon value is used not to minimize, but to eliminate completely errors

Never ever write code fort me. Please!
You use epsilon to provide a range within which you assume "it's good enough". It might be, or it might not be. You have no guarantee, and moreover, it only helps you with comparisons.

It does not magically allow you to represent numbers that can't be represented as floats (such as 0.1). It does not allow you to multiply 0.0001 with 0.0001 and get a nonzero value. It does not, in fact, solve the problems with floating point numbers!

You ca't avoid rounding problems, of fractional numbers in a computer system. Never! (within reason)

Yes you can. If you know what you're doing.
Rounding errors *only* occur with floating point datatypes. Integer datatypes have limited precision, yes, but that's something entirely different. For one thing, they're predictable. You usually know how many decimals you need for the operations you need to perform on the data you're operating with. And then you can easily choose a fixed point that suits your needs.
Or you could just make your own datatype with dynamic lenght, to make sure you can represent any number at any precision.

But for representing money, a simple integer datatype works fine. You only have a set number of decimals, no matter what you do. And the final result is always rounded to a fixed (and small) number of decimals, so it's pretty easy to guarantee precision.

This thread has scared the life out of me. If the people reading *this* site of all things, can't tell the difference between a float and an int, the world is a scary place.
The "real" WTF is that so many people here would prefer to use floating point datatypes for money, or that they're arguing that "You can't avoid precision loss", or "It doesn't matter with a few small rounding errors".
That is just scary. Really really scary. Please tell me if any of you get any contracts in my part of the world. If you do, I'm moving.
• dumba's's (unregistered)
The "Dollars" column, despite it's name, really stored pennies

The real WTF is that IT'S A CONTRACTION!

• (cs) in reply to Benjamin Smith
Anonymous:
kipthegreat:

The "Dollars" column, despite it's name, really stored pennies.

Except for being name "Dollars", isn't this how you're supposed to do this?  That's what I was taught in like CompSci 101 anyway.  It's never been an issue for me, and avoids questions like "Why is the sum of seven \$0.01 transactions less than \$0.07" (or something like that which might be seen in the real world).

As for the date garbage, why wouldn't they just use a Unix timestamp?  Seems much easier to me...

Unix timestamps are accurate to the second.

Sometimes you need to ensure uniqueness of a date, not a second in time. Storing dates in this format YYYYMMDD is pretty straightforward, compact, and allows for easy, portable constraints to ensure the uniqueness of a specific date.

// THIS IS NOT A WTF //

The WTF is the convoluted way that the poster described the date format, as though "YYYYMMDD" wasn't somehow easier to recognize...

While I agree that SQL Server *should* have a "date only" datatype, that is no reason to do something like this.  It is extremely easy to add a simple constraint to a table to be sure that dates only are stored (i.e., the time is always 12:00:00 AM).  Then you have not reinvented the wheel, you are guaranteed that your data is valid, and you can perform date math and formatting on the data without conversions, and so on.

Your data has absolutely no integrity if you use a hacked solution like this.  The only conceivable way you might get away with this and still have valid data would be to create a table of all Dates you need to cover and reference it is a FK.  Then, that table will ensure that your dates are valid, and you can add entries in that table to provide "date math" features (i.e., day, month, year, dateTime equivalent, etc).  But that would not be too smart since now your dates become *entities* as opposed to attributes, and I doubt they need to be.
• (cs) in reply to dumba's's

unrelated comment:

I hate gettext on php por no purpose.

related comment:

If you really care about money as float. Maybe can be a working solution to make a "BCD class" to work with money as strings of decimal numbers. This can be a good idea if you work with a strong type lang. I will love to see one for Javascript, because Math on javascript live somewhere on Mondo Bizarro

cheat card for webmasters:
Float (a lossy format) = JPG
Integer (lossless) = GIF

• duckets (unregistered) in reply to Tei

http://www2.hursley.ibm.com/decimal/decifaq.html

• (cs)
<rambling>

Needs to be put in the KITCHEN:

K Knowledge
I Inside
T Totally
C Cleansed
H Holistic
E Enterprise
N Namespace

[:S]

The HEN (Holistic Enterprise Namespace) can be created by using EGGs:

E Enterprise
G Gathered
G Gidget

[*-)]

Just don't let the "firefox" in the hen house.

[+o(]

</rambling>
• JCmay (unregistered) in reply to Otto

Would not "0.0115 AS INT" equate to zero?

• JCmay (unregistered) in reply to Otto
Otto:
"(1 + CAST(15 AS FLOAT)/100)"

Is it just me, or is this stupider than normal? What's wrong with typing "1.15" ?

This is not to mention the fact that you could replace the entire function with this:
SET @retvalue = CAST(CAST(@amount AS FLOAT) * 0.0115 AS INT)
RETURN @retvalue

Would not the @retvalue always be zero?  0.0115 AS INT should evaluate to zero, right?
• Terry (unregistered) in reply to Dooku
Anonymous:

Of course, an especially cool way would be to store all money values as strings in the DB: "\$15.99", and then write routines in code to convert those to money objects.  Or maybe save values as gifs (in BLOBS) and use OCR to convert back from GIF to numeric values in code.

Word,

Dooku

Or better yer, store a picture of the item in the DB as a gif, and use steganography to embed the price right into the image, thus saving valuable disk space.

Now if only I can find a way to obfuscate the encryption function ...

... if only ....

Terry
• Feanor (unregistered)

What on earth were the consultants thinking.I can not figure a single instance where something like this is useful :|

• software bear (unregistered)

What if the %age rate changes ... ? [8-|]

• (cs) in reply to software bear
Anonymous:

What if the %age rate changes ... ? [8-|]

A team of cheap programmers in Outsourcelandia will write functions or all percentage rates from 0 to 100.
The border cases 0% and 100% will make it to the front page of  TDWTF, because they follow the same pattern like the other functions, which looks even dumber for 0%.
• (cs) in reply to kipthegreat

How does the HP-12C does its calculations? I'm surprised no one mentioned the 12C yet; in two of my previous jobs the "customer" would always consult the 12C to verify if the result of any monetary calculation was "correct".

• Anonymous Cow (unregistered)

Hmm. I read how they did the date (leads to the number 20060426) and thought, "Hey! Cool idea!" ... Is that a bad sign? Really, is that so bad, for storing an 8 digits of a date value?

• (cs) in reply to ammoQ
ammoQ:

A team of cheap programmers in Outsourcelandia will write functions for all percentage rates from 0 to 100.
The border cases 0% and 100% will make it to the front page of  TDWTF, because they follow the same pattern like the other functions, which looks even dumber for 0%.
• anonymous (unregistered) in reply to Anonymous Cow

Really, is that so bad, for storing an 8 digits of a date value?

---

20060231

--Tei

• naterkane (unregistered) in reply to Bailey
Anonymous:
kipthegreat:

Didn't that happen in Superman III?

:)

Didn't that happen in Office Space? ;)

what happened in office space was different than superman 3.
those stories have nothing to do with one another.