Comment On Multiplying Strings

But a 5% discount becomes a 50% discount! Probably the bug in question.

bjolling:

foo:

eek:

very punny:

but one thing was for certain - this was going to be a long<!--Get it? Long...Decimal... When was the last time you saw a data type pun?--> week.

He was going to need to use a float-ing holiday after this.

Your String of data type puns disgusts me.

Sadly, these unsigned comments always follow the same template. Let's go booling.

Shirley using the preview button can't be that hard

FTFY

foo:

HTFM.

Case-folding depends on the locale.

Hehe, just messing with you.

I've read the arguments on both sides, and I'm an ardent supporter of making my own life easier.

[quote user="uns"][quote user="Spudley"][quote user="very punny"][quote] but one thing was for certain - this was going to be a long<!--Get it? Long...Decimal... When was the last time you saw a data type pun?--> week. [\quote]

He was going to need to use a float-ing holiday after this.
[/quote]

This int what I was expecting. I object that they string me along just for a punchline like that! I'll have to double my efforts to come up with a suitable array of ripostes.
[/quote]

for real?[/quote]

Yeah, I would object.

Especially since the majority of code, whether you want it like that or not, is English:

http://msdn.microsoft.com/tr-tr/library/0x9tb07z(v=vs.80).aspx

chubertdev:

foo:

HTFM.

Case-folding depends on the locale.

Hehe, just messing with you.

I've read the arguments on both sides, and I'm an ardent supporter of making my own life easier.

Me too, and since using the same identifier with different case is very bad style to me, I'm happy that my compiler (C++) tells me when I get it wrong.

chubertdev:

Especially since the majority of code, whether you want it like that or not, is English:

http://msdn.microsoft.com/tr-tr/library/0x9tb07z(v=vs.80).aspx

Thanks for supporting my side (case-sensitivity).

Think about it: Code written in Turkish works OK in a Turkish locale (obviously). But code written in English will fail there if case-insensitive.

foo:

chubertdev:

Especially since the majority of code, whether you want it like that or not, is English:

http://msdn.microsoft.com/tr-tr/library/0x9tb07z(v=vs.80).aspx

Thanks for supporting my side (case-sensitivity).

Think about it: Code written in Turkish works OK in a Turkish locale (obviously). But code written in English will fail there if case-insensitive.

That's just semantics. And it's up to the developer to realize that. The combination of the English programming vernacular and VB both being case-insensitive make it superior. Especially when combined with how well Visual Studio manages it real-time, so you don't have to. I honestly believe that case-sensitive languages, whether it be a programming language like C#, or a language like Turkish, are extremely flawed.

alo:

The "frist" strategy is to be logged in, writing a comment as fast as you can and the edit it later to something less embarrasing.

You didn't edit this one very well

I'll take your WORD on it.

Coyne:

RRDY:

But dividing by 100 is HARD!

captcha: nobis, as in this person had nobis getting anywhere near a computer.

Inefficient, too.

Had a teacher one time that assigned us to minimize parenthesis in something like this:

 A + ((B * C) * (D * E)) / ((F * G) * H)

My response:

 A + B * C * D * E / F / G / H

Whereupon he objected lamely that division was inefficient...but he gave in when I pointed out that the whole objective of the problem was to get rid of parenthesis.

You also could have converted to postfix and really made his day.

foo:

Thanks for supporting my side (case-sensitivity).

Don't you mean:
"Please attempt some case-sensitivity: I had a compiler that was non-case-sensitive, and let me assure you it is no laughing matter."

Tasty:

I imagine a modern compiler's optimizer will reduce your code to something more efficient. It's not your father's Fortran anymore.

Problem is that replacing a / b / c with a / (b * c) for floating-point numbers will most likely change the result due to rounding errors, which makes it illegal to do in many languages (like C, C++, Java, Objective-C).

The problem is that there are a bunch of so-called programmers who learned how to do string concatenation on day 1, and then go on to apply it everywhere for the rest of their career.

Where I work, we have one guy who does string concatenation in SQL to return a HTML select, and another who does string concatenation in javascript to do date arithmetic.

chubertdev:

foo:

chubertdev:

Especially since the majority of code, whether you want it like that or not, is English:

http://msdn.microsoft.com/tr-tr/library/0x9tb07z(v=vs.80).aspx

Thanks for supporting my side (case-sensitivity).

Think about it: Code written in Turkish works OK in a Turkish locale (obviously). But code written in English will fail there if case-insensitive.

That's just semantics. And it's up to the developer to realize that. The combination of the English programming vernacular and VB both being case-insensitive make it superior. Especially when combined with how well Visual Studio manages it real-time, so you don't have to. I honestly believe that case-sensitive languages, whether it be a programming language like C#, or a language like Turkish, are extremely flawed.

Sorry, that was a little too much. Until you wrote that I considered you might not be trolling. (Though the use of VB and superior in the same sentence above should have been a give-away.)

chubertdev:

foo:

chubertdev:

Especially since the majority of code, whether you want it like that or not, is English:

http://msdn.microsoft.com/tr-tr/library/0x9tb07z(v=vs.80).aspx

Thanks for supporting my side (case-sensitivity).

Think about it: Code written in Turkish works OK in a Turkish locale (obviously). But code written in English will fail there if case-insensitive.

That's just semantics. And it's up to the developer to realize that. The combination of the English programming vernacular and VB both being case-insensitive make it superior. Especially when combined with how well Visual Studio manages it real-time, so you don't have to. I honestly believe that case-sensitive languages, whether it be a programming language like C#, or a language like Turkish, are extremely flawed.

Worse: there are programmers out there who don't realise they are working with case-sensitive language (when it is optional).

A common error in SQL Server development projects is to install SQL Server as case-insensitive, then write case-insensitive code, thereby risking that said code will not compile on systems where SQL Server is installed case-sensitive.

A major WTF: case-insensitive is the "default" SQL Server installation state, binary (case-sensitive) is the "recommended" configuration state. Most projects I have seen (including major open source projects) have programmers that have not read that part of the manual.

can anyone explain it, is there something wrong with the code? I dont get it.

leo c:

can anyone explain it, is there something wrong with the code? I dont get it.

Hint: There's a "page 1" link below. And surprisingly, this link leads to a full page of previous comments, some of which even related to the current WTF.

Maybe I'm an ignorant savage, but I have a JavaScript program that needs to truncate a (float) number to integer. There is no such JavaScript function. All JavaScript integers are floats. The only way I've figured out how to do it is to convert X to a string and parse the string up to the decimal point.
var I = parseInt( X.toFixed(3));
Argh!

C-Derb:

da Doctah:

And if O.DiscountPercentage is 100 or greater, the calculated discount will be too small.

A discount > 100% would be paying someone to take your products off your hands. At that point, you've got bigger problems than string arithmetic.

And with that, I experience yet another flashback to all those times I was told "that'll never happen, so it doesn't matter what you do for that case".

My usual response to that sort of guidance is "in that case, I'll arrange to code it so that if the thing you say will never happen does happen, it's okay to call you at your personal unlisted number any time of the day or night". They seldom agree to this. They never agree to it a second time.

AndyCanfield:

Maybe I'm an ignorant savage, but I have a JavaScript program that needs to truncate a (float) number to integer. There is no such JavaScript function. All JavaScript integers are floats. The only way I've figured out how to do it is to convert X to a string and parse the string up to the decimal point.
var I = parseInt( X.toFixed(3));
Argh!

Math.floor(X); // takes off everything beyond the decimal point.

Drak:

AndyCanfield:

Maybe I'm an ignorant savage, but I have a JavaScript program that needs to truncate a (float) number to integer. There is no such JavaScript function. All JavaScript integers are floats. The only way I've figured out how to do it is to convert X to a string and parse the string up to the decimal point.
var I = parseInt( X.toFixed(3));
Argh!

Math.floor(X); // takes off everything beyond the decimal point.

Not for negative numbers if it's like floor() in most other languages.

Ant that is TRWTF. >;->

foo:

leo c:

can anyone explain it, is there something wrong with the code? I dont get it.

Hint: There's a "page 1" link below. And surprisingly, this link leads to a full page of previous comments, some of which even related to the current WTF.

And that is TRWTF.



(Sorry for the earlier typo! WTF?!? ;-)

lunaryorn:

D-Coder:

How is it that no one had noticed a problem with discounts less than 10% for so long?

It seems to be a very generous company... which might explain the quality of the code: There seems to be not enough money left to replace the Office expert dabbling on programming with a real, appropriately paid developer.

And given that it's been wrong like that for... HOW LONG?!? What makes it such a big crisis *RIGHT NOW*?!?

[quote user="very punny"][quote] but one thing was for certain - this was going to be a long<!--Get it? Long...Decimal... When was the last time you saw a data type pun?--> week. [\quote]

He was going to need to use a float-ing holiday after this.
[/quote]

If he was union-ized, he could do all the type punning he wanted.

very punny:

but one thing was for certain - this was going to be a long<!--Get it? Long...Decimal... When was the last time you saw a data type pun?--> week.

He was going to need to use a float-ing holiday after this.

There, fixed that for you

[quote user="very punny"][quote] but one thing was for certain - this was going to be a long<!--Get it? Long...Decimal... When was the last time you saw a data type pun?--> week. [\quote]

He was going to need to use a float-ing holiday after this.
[/quote]

Hmmm, enough to drive me to drink... better make it a double!

AGray:

¯\(°_o)/¯ I DUNNO LOL:

TRWTF is that some people shouldn't be allowed near anything that requires 9th grade mathematics skills. This isn't even algebra.

VB? How am I not surprised? (It was either that or PHP.)

I digress...but, why is it most of the more horrendously stupid WTFs are written in VB? I have never really understood it.

Smart people know VB is generally not a very good choice of language, so they stay away from it as much as possible. Stupid people don't, so they will program in whatever they can.

I think I can safely assume that stupid people create more WTFs than smart people, therefore combining these two will result in the proposition that VB code will generally contain more WTFs than code written in a language such as Java or C#.

Call me arrogant or narrow minded, but the reality really is not much more complicated than that.

RRDY:

But dividing by 100 is HARD!

Yes, dividing is generally takes more time than multiplying, so instead of dividing by 100, multiply by 0.01 instead. Problem solved.

[quote user="Nutster"][quote user="RRDY"]But dividing by 100 is HARD![/quote]
Yes, dividing is generally takes more time than multiplying, so instead of dividing by 100, multiply by 0.01 instead. Problem solved.[/quote

If that would solve the problem, the compiler would do it for you.

When you write 0.01, you don't get 0.01 but a floating point number very close to but not exactly equal to 0.01. If you multiply let's say 3700 by that number, the result before rounding isn't 37 but some number close to but not exactly equal to 37. Rounding _may_ round to 37, but isn't guaranteed to. All kinds of funny things may happen as a result.

no--you're wrong

But hey! At least he should get double time overtime pay!

On the double!

Valetudo:

Herwig:

Foo Bar:

AGray:

I digress...but, why is it most of the more horrendously stupid WTFs are written in VB? I have never really understood it.

Possibly because some Peters rise up to their level of incompetence by way of:
use MS Office products -> write a macro or two -> hey, that's Visual Basic -> VB programmer.

...and then they are talking about the "Storage Procedures" they've written in "Virtual Basic" and their other programming skills in in HTML or FTP...

In the final stages, they talk about writing a gui in VB to trace an IP.

The WTF in that last statement is that you didn't realize that they purposefully f*cked it up in order to get people to talk about it and watch to try and locate more screw ups.

Pretty good marketing actually. MS would pay them for mentioning VB; meanwhile it's self serving.

A lot of people still don't realise this, but most operations, including division take just one tick. The real performance issues are caused by cache misses and page faults.
As for the case thing, case-sensitivity is bloody annoying. It says something that IDEs for case-sensitive languages almost always have a way to mitigate it and fix the case.

¯\(°_o)/¯ I DUNNO LOL:

TRWTF is that some people shouldn't be allowed near anything that requires 9th grade mathematics skills. This isn't even algebra.

VB? How am I not surprised? (It was either that or PHP.)

Being innumerate should be as socially unacceptable as being illiterate.

C-Derb:

A discount > 100% would be paying someone to take your products off your hands. At that point, you've got bigger problems than string arithmetic.

It might be services instead of products. I had a stock transaction where the commission was discounted by 200%. It surprised me, but it looked like it was intentional on the part of the broker because of their rules. Even if that happened more than once I wouldn't get rich on it though.

It might be something other than services or products too. There have been a few cases where loans had interest rates around -0.005%. Ordinarily one would expect that the lender would be better off just keeping the cash, but someone explained that keepers of cash have to pay to store and guard the cash so the loan was better.

Meep:

Being innumerate should be as socially unacceptable as being illiterate.

In some societies being numerate is socially unacceptable, ranging from nerdishness to offensiveness.

"Hey look, I had a fantastic game of golf."
"You added up the numbers wrong. Here's your real score."
"Well what do you want, a good mathematician or a good golfer?"
"You're neither."
"GTFO asshole."

AGray:

I digress...but, why is it most of the more horrendously stupid WTFs are written in VB? I have never really understood it.

Because horrendously stupid WTFs in C are uninteligable except to experts, unnoticble except to LINT, and mostly never discovered even when they cause regular crashes.

Tasty:

I imagine a modern compiler's optimizer will reduce your code to something more efficient. It's not your father's Fortran anymore.

If it was your father's FORTRAN, it wouldn't need a modern compiler's optimizer to reduce your code to something more efficient.

Modern copiler optimizers are designed to reduce your C code to something almost as efficient as your Fathers FORTRAN. And even that is possible only if you are using the C99 'restrict' keyword.

old timer:

Tasty:

I imagine a modern compiler's optimizer will reduce your code to something more efficient. It's not your father's Fortran anymore.

If it was your father's FORTRAN, it wouldn't need a modern compiler's optimizer to reduce your code to something more efficient.

Yes you would. If I recall correctly, IBM's Fortran G didn't even remove common subexpressions when accessing array elements and didn't do strength reduction in loop variables that traversed an array. Fortran H was designed to be better but it was funny when it wasted CPU time clearing unused portions of a register that were never accessed other than in clearing them.

The Fortran standard restricted some kinds of expressions in ways that appeared unnecessary. The reason for the restrictions was that compiler writers knew ways to optimize some kinds of expressions, so the executable code could be nearly as fast as assembly. If arbitrary expressions were allowed, the executable code would be 10 times slower than assembly and no one would have switched to Fortran.

He was going to need to use a float-ing holiday after this.

Oh man, I hope he solves it by converting the string to a float, multiplying by 0.01f and writing the result to string. Next week we'll have a special "I got 5.79999999999999999999999999<snip>9999999999985% discount on this" Error'd edition.

Personally, I'd take the percentage as a string in base-10, pad on the left with zeroes if needed and insert a '.' two characters before the end.

dDiscount←ot×2⊃⎕VFI'0.',¯2↑'0',⍕O.DiscountPercentage

Fixed it for you

You, sir, made my day. I wish more people were as int-elligent as you.

[quote]
[quote] but one thing was for certain - this was going to be a long<!--Get it? Long...Decimal... When was the last time you saw a data type pun?--> week. [\quote]

He was going to need to use a float-ing holiday after this. [/quote]

That was an epic... double whammy, if I may say so.

...Fifth grade? If that?