Comment On The Ingenious DBox with the Double Trim

Perhaps he was being tongue-in-cheek with the "ingenious" comment....



Then again, we don't give people the benefit of the doubt here.  :-)

  Hey, those uppercase spaces can get you in a lot of trouble.     

Would uppercase whitespace be the written equivalent of deafening silence?

He's a genius! Especially because the title of his message box is "Message". Just, you know, in case there was some confusion from the user about whether or not they're looking at a message.

 

Slightly off topic but I'm just curious, let's say you need to trim and convert to lowercase, in what order should you implement? Trim first and then convert, or backwards? Or does it matter?  I mean if we're talking milliseconds of speed saved it might be worth it...my theory is better to trim first, then the ToLower() function would have fewer characters to scan and figure out how to turn to lower case.

DBox("The value of m_ingenious_module_variable is " + m_ingenious_module_variable + ".  Note: Be sure to _always_ set this to nothing.")

Dude shoulda used a different delimiter token.  Perhaps something as ingenious as the two-character token "\n", for example?

What an 'ingenious' way to spell Text -- Tekst

:

Trim first and then convert, or backwards?

I think you're probably right that it is faster to trim first and then lowercase.



To be sure, you would want to do a real benchmark test.  Just
write two small functions and time how long it takes to run each one,
in a loop for a million times.



I did this using Perl and found it is faster to trim first, by a small
fraction.  It depends on the amount of whitespace you have. 
If the string is 1 character and 50 spaces, then you get a big
boost.  If it's 50 characters and 1 space, it's a small boost.



If you really wanted the fastest way, you would really want to do both
the trim and lowercase at the same time.  Loop over each
character, making each one lowercase, then when you see a space, check
if that is the last space in the string, and trim the spaces off. 
If you use two separate functions, it is going to take about twice as
long.

RyGuy:

What an 'ingenious' way to spell Text -- Tekst

I honestly thought it was some strange Hungarian notation or something that I just hadn't seen before.

I also love the fact that by using the function he's effectively reduced his button options for textboxen to "Ok", and that's it.

Tekst is dutch for text. Maybe he's dutch. We're not known for our leet programming skillzzz...

Ah, crap, I totally have to check all of my code... I've never accounted for lowercase spaces before.

The real WTF is that it is not even a function, it is a sub and can not return the modified text.

PETASCII (The character code from the Commodore PET,VIC, C64) had an
uppercase space (character 160) typed as Shift-Space.  It looked
the same, but was a different character.



Maybe the coder was assuming the program would be ported to obsolete machines?

:

The real WTF is that it is not even a function, it is a sub and can not return the modified text.

I don't really agree with that, but:  An often overlooked fact that has probably caused lots of havoc over the years with VB6 programmers is that the default way to pass arguments to a function is by reference.  So if you call DBox(someVar) and then examine SomeVar when it returns, its value will have changed to reflect the substitution.

 

I'm surprised no one has commented on the silly pattern of

if condition {
    valid = true;
}
else {
    valid = false;
}

which obviously can be expressed more succinctly as

valid = condition;

err. some anonymouse guy said: maybe it would be faster to trim first then tolower second, hmmmmm. dont both those functions scan chars anyway, u not talking sense son.

Tekst does also mean text in Danish and Norwegian.

:

:

Trim first and then convert, or backwards?

If you really wanted the fastest way, you would really want to do both
the trim and lowercase at the same time.  Loop over each
character, making each one lowercase, then when you see a space, check
if that is the last space in the string, and trim the spaces off. 
If you use two separate functions, it is going to take about twice as
long.

uh, i bet you didn't time that one, huh?

I caught that too.  With a little more effort, he could have
created a list of parameters mirroring those of the MsgBox function and
passed them along with the edited text.

:

Tekst does also mean text in Danish and Norwegian.

Maybe "ingenious" means something else in those languges? [:)]

AndrewVos:

err. some anonymouse guy said: maybe it would be faster to trim first then tolower second, hmmmmm. dont both those functions scan chars anyway, u not talking sense son.

Yeah, but if the first scan removes characters, then the second scan will scan fewer characters, and will hence be faster. If you do it in the reverse order, you are guaranteed a full scan each time.

GWheeler:

I'm surprised no one has commented on the silly pattern of

if condition {
    valid = true;
}
else {
    valid = false;
}

which obviously can be expressed more succinctly as

valid = condition;

You beat me to it.  This is a WTF that I see ALL THE TIME.

You want to know what I see all the time...



if (string1.ToLower().Compare(string2.ToLower()) == 0)



This is BOGUS. You are doing 2 allocations for every compare, which is
insane. For the LOVE OF GOD, use string.Compare! (static method)



if (string.Compare(string1, string2, true) == 0)



The third parameter means "Case Insensitive". USE IT!!

:

You want to know what I see all the time...



if (string1.ToLower().Compare(string2.ToLower()) == 0)



This is BOGUS. You are doing 2 allocations for every compare, which is
insane. For the LOVE OF GOD, use string.Compare! (static method)



if (string.Compare(string1, string2, true) == 0)



The third parameter means "Case Insensitive". USE IT!!

Or, assuming this is Java, use the String.compareToIgnoreCase() method.

Cthulhon:

wrote:

You want to know what I see all the time... if (string1.ToLower().Compare(string2.ToLower()) == 0) This is BOGUS. You are doing 2 allocations for every compare, which is insane. For the LOVE OF GOD, use string.Compare! (static method) if (string.Compare(string1, string2, true) == 0) The third parameter means "Case Insensitive". USE IT!!

Or, assuming this is Java, use the String.compareToIgnoreCase() method.

Assuming there's a lower and uppercase space, and trim just works with the
uppercase one, won't the double trimming just choke on this:


"[lowercase space][uppercase space][lowercase space]Some text"?

Z

BradC:

AndrewVos wrote:

err. some anonymouse guy said: maybe it would be faster to trim first then tolower second, hmmmmm. dont both those functions scan chars anyway, u not talking sense son.

Yeah, but if the first scan removes characters, then the second scan will scan fewer characters, and will hence be faster. If you do it in the reverse order, you are guaranteed a full scan each time.

ok, well in some cases. but how u gonna know if there is more white space, otherwise its worthless.

AndrewVos:

BradC wrote:

AndrewVos wrote: err. some anonymouse guy said: maybe it would be faster to trim first then tolower second, hmmmmm. dont both those functions scan chars anyway, u not talking sense son. Yeah, but if the first scan removes characters, then the second scan will scan fewer characters, and will hence be faster. If you do it in the reverse order, you are guaranteed a full scan each time.

ok, well in some cases. but how u gonna know if there is more white space, otherwise its worthless.

hey andrew -- r u a cool hacker? 

Yes, but one day you'll probably want to breakpoint one of the
conditions but not the other, and it always turns out to be the case
that adding a conditional breakpoint makes the program run like a dog,
so you'll change it to look like this anyway.



Or, just as likely, you'll end up needing something to happen in one
case but not the other, so again you'll have to change it to the
longhand form.



And once one or both of these has happened a few times, you end up writing it like that to start with out of habit.

Gordon bloody bennett, what happened to the quote? And why can't I edit
it? And why do the adverts keep blowing themselves up to the entire
screen, disabling the back button in the process? Presumably this is
some Firefox "problem"... IE-only sites, eh, how very 2001.



Anyway, I'll try that one again.

GWheeler:

I'm surprised no one has commented on the silly pattern of

if condition {
    valid = true;
}
else {
    valid = false;
}

which obviously can be expressed more succinctly as

valid = condition;

Yes, but one day you'll probably want to breakpoint one of the
conditions but not the other, and it always turns out to be the case
that adding a conditional breakpoint makes the program run like a dog,
so you'll change it to look like this anyway.





Or, just as likely, you'll end up needing something to happen in one
case but not the other, so again you'll have to change it to the
longhand form.





And once one or both of these has happened a few times, you end up writing it like that to start with out of habit.

AndrewVos:

ok, well in some cases. but how u gonna know if there is more white space, otherwise its worthless.

The code would have to look for all the white space, of course.  But this can be done by scanning the string only once.  Doing a trim and then a lowercase would be two full scans in many languages.

Here is some Perl code (this is not the way I would normally write Perl):

sub trimAndLowercase
{
   $_ = "UPPERCASE   WHITESPACE   ";

   my @str = split //;
   my $lastSpace = @str;   # This will be the index of the last space counted backwards from the end

   for(my $i = 0; $i < @str; $i++) {
      $str[$i] = lc $str[$i];   # convert to lowercase

      if($str[$i] eq ' ') {
         if($lastSpace == @str) {
            $lastSpace = $i;   # this is the first space we have seen so far, remember this spot
         }
      }
      else {
         $lastSpace = @str;   # we saw a non-space, forget the index
      }
   }

   for(my $i = $lastSpace; $i < @str; $i++) {
      $str[$i] = undef;  # wipe out all the spaces
   }

   return join '', @str;
}

print trimAndLowercase(), "|\n";

ftumph:

GWheeler wrote:

I'm surprised no one has commented on the silly pattern of if condition {     valid = true; } else {     valid = false; } which obviously can be expressed more succinctly as valid = condition;

You beat me to it.  This is a WTF that I see ALL THE TIME.

valid =  (as_tableName.Trim().ToLower().Trim().Equals(ms_srcTable.Trim().ToLower().Trim()));

Ugh.

The WTF with the condition isn't the assignment of a true if a complex condition is true, its the fact that the Explaining Variable "valid" is meaningless.

if (String.Compare(table,source,true)==0)
{
  tableMatchesSource = true;
}
else
{
  tableMatchesSource = false;
}

after reducing the condition to something sane, it starts to seem more sensible to just put it on one line.

tableMatchesSource = (String.Compare(table,source,true)==0);

This is one of those cases where:



* If you think you can do it in a semi-compiled language faster than
the language's compiled runtime, you're wrong. If you think you can do
it by calling C functions faster than an OS that uses well-tuned
lowest-level code, you're wrong.

* Your cleanest, most intuitive algorithm is probably an order of
magnitude slower than code optimized for a cpu architecture at the
machine code level. You must think messily and with a frightful
proclivity to madness to truly understand instruction pipelining.
Because much smarter people than you made your OS, runtime, or
interpreter, it will probably be much closer to this native ideal.
[That said, several consumer-level compilers have become much more
advanced in recent years.]

* The first fetch will take an age in cpu cycles, the second should be L1/L2 cached and execute in relatively little time.

* If it matters in any way what order you do the toLower and trim,
you're using the wrong algorithm and possibly the wrong language.

* If you have to run 1000+ executions in a tight loop to register a
slight difference, it doesn't matter in any way, the real work of the
program will more than mask any percieved savings.

* You need a profiler and a deep understanding of all the running code
you never see, much more than a little high-level intuition.



This is a great example of code monkeys who think they know a little
about optimization waste too much time hacking at tiny problems and
leave glaring ones that take real . Sit down with Knuth's Art of
Programming, books on your OS and framework by the creators of each,
and several advanced OS, server, and database design books, and then
you will be competent to discuss optimization.



Yay, you've stumbled on to another one of my pet peeves. Ja ne! ^_^

>	What an 'ingenious' way to spell Text -- Tekst

It is Dutch for text. I'd guess the author is Dutch or Flemish.

ftumph:

GWheeler wrote:

I'm surprised no one has commented on the silly pattern of if condition {     valid = true; } else {     valid = false; } which obviously can be expressed more succinctly as valid = condition;

You beat me to it.  This is a WTF that I see ALL THE TIME.

How is this a WTF? It's more explicit, and therefore, easier to understand and maintain. Using the original WTF as an example, compare the following:

if (as_tableName.Trim().ToLower().Trim().Equals(ms_srcTable.Trim().ToLower().Trim()))
{
  valid = true;
}
else
{
  valid = false;
}

versus...

 

valid = (as_tableName.Trim().ToLower().Trim().Equals(ms_srcTable.Trim().ToLower().Trim()))

If you're unfamiliar with the code, which is the easier to understand and maintain? Obviously, the former is easier to make sense out of. 

I see this all the time. Programmers who consider themselves brilliant for being able to compact code into as few lines as possible. But sometimes, the stuff that's spread across multiple lines is much easier for others to read and maintain. The performance hit of the if..else block versus the valid = condition block is neglible, so why not do it in the most readable way possible?

Personally, 90% of what I've done as a programmer is maintaining and fixing the stuff written by other people. I'm more than happy to give up tiny performance gains in the service of having code that's readable.

 

spooky action at a distance:

If you're unfamiliar with the code, which is the easier to understand and maintain? Obviously, the former is easier to make sense out of. 

I see this all the time. Programmers who consider themselves brilliant for being able to compact code into as few lines as possible. But sometimes, the stuff that's spread across multiple lines is much easier for others to read and maintain. The performance hit of the if..else block versus the valid = condition block is neglible, so why not do it in the most readable way possible?

Personally, 90% of what I've done as a programmer is maintaining and fixing the stuff written by other people. I'm more than happy to give up tiny performance gains in the service of having code that's readable.

 

Hmm. I'll admit I've used both constructs. I'll use the single statement form if the condition is simple or easily understood. If the condition is complex, sometimes I'll break it up into multiple if... else if... branches to improve readability/debugging. In this case, I thought the condition was more than simple enough to qualify.

BTW: I don't think there's any significant performance difference between the two forms. A competent compiler could optimize the if... form into the simple assignment.

Surely

(as_tableName.Trim().ToLower().Trim().ToUpper().Trim()).Trim();

would be more efficient?

Sarcasm to full power, Mr. Sulu...



As I am sure Bat will point out, if you were to write this in Scheme so
that it reads the input as a series of symbols which you could
accumulate into a list, then convert the list of symbols to a string,
you would avoid the whitespace problem completely at no added cost
(except for a few trivial things like punctuation and formatting...).
Hey, if you've got a built-in parser just sorta sitting around like
that, you might as well use it, right? [:D]



I have
to
admit that I don't know how serious Bat is. He certainly comes across
as the sort of rabid Lisper who scares a lot of people away from the
beauty that is lambda calculus, but around here I suspect trolling as a
matter of course. Much as as genuinely love Scheme, I know that the
chances of actually getting to work in it professionally are somewhat
less than my chances of breaking the sound barrier on foot. 
Fortunately, I'm a passable coder in  most major languages, even
if I do
tend to get turned around once in a while (it's a hazard for us
Jack-of-all-trades types) and occasionally miss some crucial subtlety
that a more specialized programmer would consider obvious (ditto).
Also,  now that Python seems to be gaining popularity, I
may have a chance of doing real work in a language that doesn't
make me want to gouge my eyes out.  Wish me luck, folks.

Heh heh heh... I'm not as rabid as all that. 
I'm actually a language junkie -- I work regularly in PHP, Perl, XSLT,
HTML, Delphi, elisp, DOS batch, bash shell script, C, and Lua, and less
regularly in Prolog, C++, Scheme, JavaScript, and a bunch of little
languages of my own devising.  I've seen C# and Python and
wouldn't mind using them if  I had reason to; I've seen Java and
consider it to be the COBOL of the noughties.  Like any fan, I'm
half bigot and half evangelist (but I repeat myself...).  Sorry if
I'm scaring anyone away from LISP, but it is pretty clearly the most
powerful language in terms of its inherent language capabilities, and
that kind of power is inherently scary, whatever I or anyone else might
say.  Perl has the same problem in a different way -- and both
LISP and Perl gain a lot of their power from their idiosyncratic
syntax, which is also what scares people...



All of which means: he should have done it in LISP, dammit!  Or JavaScript!  Or -- no, wait! -- Intercal!

Fair enough. It's always good to hear from another Lisp fan - it can seem awfully lonely at times.

Hello everybody, here's the author of the 'ingenious' piece of code. The ingenious part was indeed tongue-in-cheek. [:)]



The problem was, I was making an Access Database for some company and
Access just kills me with its limitations. So I wanted to make
everything as fast for me as possible. I needed a lot of messageboxes
with only OK buttons, so I made this. I never needed the _ character
for the end user so it was a good choice.

:

Assuming there's a lower and uppercase space, and trim just works with the
uppercase one, won't the double trimming just choke on this:<br>

"[lowercase space][uppercase space][lowercase space]Some text"?

Z

Nope, because the original code is myString.Trim().ToLower().Trim() it would remove the first space, convert the [uppercase space] to a [lowercase space] and then trim all the remaining space before Some text!

A brilliant bit of coding there!  Full marks for redundancy.

:

wrote:

Assuming there's a lower and uppercase space, and trim just works with the uppercase one, won't the double trimming just choke on this:<br> "[lowercase space][uppercase space][lowercase space]Some text"? Z

Nope, because the original code is myString.Trim().ToLower().Trim() it would remove the first space, convert the [uppercase space] to a [lowercase space] and then trim all the remaining space before Some text!

A brilliant bit of coding there!  Full marks for redundancy.

Actually, if Trim() only worked with uppercase spaces, the first space would never get trimmed and so neither would the ones after it! To trim a pattern like: [lowercase space][uppercase space][lowercase space][uppercase space]... (repeat n times) using this theoretical case sensitive Trim() function would require a loop :D

:

Actually, if Trim() only worked with uppercase spaces, the first space would never get trimmed and so neither would the ones after it! To trim a pattern like: [lowercase space][uppercase space][lowercase space][uppercase space]... (repeat n times) using this theoretical case sensitive Trim() function would require a loop :D

Hello, my name is Anonymous and I just wrote a WTF. One case conversion, followed by one trim would suffice. No loop.

Hi, My name is Anon E Mouse, and I just wrote a WTF.  <loud prolonged clapping>

I didn't read the original post which said that trim only worked on Upper case spaces (which is a WTF all in itself)  So converting all upper case spaces to lower case spaces using the lower function would make it even worse, because now ALL the spaces would be left behind!

That loop solution sounds good, but I can think of a better way.

You need a recursive function which tests if the first character is a space (either upper or lower case).  If it IS a space, you call the function recursively, after first removing the leading space.  That removes all spaces from the front, but what about the end?

To remove all the spaces at the end, you then reverse the string, and call that handy little recursive function again.  You take the result of that function, reverse it, and that is your trimmed String!  Ingenious eh?

[8-)]

Hey, u dont know Java man. The method is equalsIgnoreCase(). Don't try to post comments about languages you are not familiar with.

What do you think about this then. Which is the right way to do it?

//1
if (condition)
{
    //do some stuff
    valid = true;
}
else
{
    valid = false;
}

//2
if (condition)
{
    //do some stuff
}
valid = condition;

//3
valid = condition;
if (valid)
{
    //do some stuff
}

/Erik

foxyshadis:

This is one of those cases where:

* If you think you can do it in a semi-compiled language faster than
the language's compiled runtime, you're wrong. If you think you can do
it by calling C functions faster than an OS that uses well-tuned
lowest-level code, you're wrong.
* Your cleanest, most intuitive algorithm is probably an order of
magnitude slower than code optimized for a cpu architecture at the
machine code level. You must think messily and with a frightful
proclivity to madness to truly understand instruction pipelining.
Because much smarter people than you made your OS, runtime, or
interpreter, it will probably be much closer to this native ideal.
[That said, several consumer-level compilers have become much more
advanced in recent years.]
* The first fetch will take an age in cpu cycles, the second should be L1/L2 cached and execute in relatively little time.
* If it matters in any way what order you do the toLower and trim,
you're using the wrong algorithm and possibly the wrong language.
* If you have to run 1000+ executions in a tight loop to register a
slight difference, it doesn't matter in any way, the real work of the
program will more than mask any percieved savings.
* You need a profiler and a deep understanding of all the running code
you never see, much more than a little high-level intuition.

This is a great example of code monkeys who think they know a little
about optimization waste too much time hacking at tiny problems and
leave glaring ones that take real . Sit down with Knuth's Art of
Programming, books on your OS and framework by the creators of each,
and several advanced OS, server, and database design books, and then
you will be competent to discuss optimization.

Yay, you've stumbled on to another one of my pet peeves. Ja ne! ^_^

I have to agree mostly, but on your first point, you would be amazed what some JIT's manage to get out of certain situations - in some (very limited) cases (synthetic math benches), interpreted languages which are executed by an interpreter with a builtin JIT can be a lot faster. Startup times are a lot slower, but once it's running it can be amazing (didn't believe it myself the first time I saw it). Anyway, currently the performance hit is usually IO-operations (network/disk/...) or a database engine. It's rare that it's CPU limited in real-world applications, memory limit is still a possibility, but CPU? Only if you do extremely stupid things. And if they would be CPU-limited and required to run in real-time, a good analisys shows that it will be, and that should not be written in an interpreted language. If it's some batch-processing afterwards, who cares that it will take 10 mins longer, if that makes the code more maintainable, when i.e. the rest of the project is also written in that same interpreted language.

Anyway, the Java or C# piece of *crap* that was posted here is the other way around. It's just making execution slower with no reason, while nog making the code more maintainable or readable, which is _BAD_. This piece of code creates 6 objects for a stupid compare, which are left for the garbage collector afterwards. If such practices are used all over a project - you will certainly feel the performance impact.

The other part, about the newlines, well - long live '\n' - how ingenious [:D]

Surely this is the best way to deal with conditions?

[code language="c#"]boolean valid;
if (condition)
{
    valid = true;
}
else
{
    valid = false;
}

if (!valid)
{
    return false;
}
else
{
    return true;
}[/code]

And what's wrong with this bloody forum software?

:

What do you think about this then. Which is the right way to do it?

//1
if (condition)
{
    //do some stuff
    valid = true;
}
else
{
    valid = false;
}

//2
if (condition)
{
    //do some stuff
}
valid = condition;

//3
valid = condition;
if (valid)
{
    //do some stuff
}

/Erik

You left one out -

if(valid=condition)

{

//do some stuff (and please ignore the double spacing)

}

That will work in most languages, but it's best to avoid doing an assignment in a conditional for readability reasons.  The one time I use that structure is when I'm looping through a result set from a database query in PHP.

I said most languages, because I believe Microsoft has made it impossible to do an assignment inside a conditional in C# to avoid those annoying, difficult to track down bugs where you use = instead of ==.