• (cs)
    Excellent WTF!  Looking forward to the comments on this one, and also the very serious "alternative solutions" that will be posted.   (i.e, "It would be faster to do a binary search to determine the ASCII value")
     
    I also enjoyed the fact that is not VB.
  • (unregistered)

    <FONT style="BACKGROUND-COLOR: #efefef">Some people might suggest a switch statement, but to me this is definitely a perfect situation for a lookup table. The table would only be 256 ushorts (512 bytes) so it's faster and it doesn't use that much memory either. There can't possibly be a smaller or faster solution than that.</FONT>

    [*-)]

  • (unregistered) in reply to

    You could make the lookup table contain 8-bit values and then cast the looked up value to 16 bits before returning it. That would halve the size of the lookup table, and would potentially make it run faster on 8-bit systems.


  • (unregistered)

    duh, obviously one should use the hashtable for such kind of task. It's fast, small, and we've got perfect hash (low 8 bytes of ushort). Doing it for every ushort coming in would suck the hashtable itself to L1 cache making it blazingly fast!

  • (cs)

    I see I have not been let down by the last 3 comments so far ... keep them coming... any other good ideas on how to solve this difficult programming dilemma?  XML maybe?   

  • (unregistered)

    Is'nt there a ordinal function that will convert an ascii character to a number???

  • (unregistered) in reply to Jeff S

    right, this is retarded. the code is just taking a char and returning the same value as a short.

    The comments seem like just as much a WTF as the WTF.

    I think I'd have to use Jython to make it work right, or maybe a micture of VB and C#

  • (cs)

    Isn't it the same as,

    [code language="c#"]

    if (255 >= ch)
       return (ushort) ch;
    return 0;
    [/code]
  • (cs) in reply to seizethedave

    Okay right, joking.

    was up too late last nite.

  • (cs) in reply to seizethedave

    Geena Davis: ushort?
    Danny Devito: uchar?

    (sorry, couldn't resist)

  • (cs)

    i would have tried JavaScript

  • (cs)

    We have some WTF for a week now...

  • (unregistered)

    What the hell is wrong with you people... uchar... 8 bits... Its ALWAYS going to be less than 256... Or always going to be between 0 and 255...

    Assuming you're on an 8-bit per byte computer.

    Unless I'm wrong

  • (unregistered)

    You could have sped up GetAsciiValue() by making it a remote procedure call to a dedicated server maybe. ;)

  • (unregistered) in reply to

    What language is this with a "uchar" datatype?

    Anyways, how about 

    code language="c#" ch;[/code]
    Why would you want to convert a char (I'm assuming) to a ushort anyway though?

    Of course

    [code language="c#"](byte) ch;[/code]

    Would do the same thang with half the memory no?

  • (unregistered)

    I can't understand why no-one has yet suggested the obvious solution to the problem - a jump table, leading to highly specialzed functions dealing with each particular case, as in:

    
ushort (*ascii_converter[])()={
        convert_zero,
        convert_one,
        convert_two,
        convert_three,
        /* ... */
};  
ushort GetAsciiValue(uchar ch)
{
    return ascii_converter[ch]();
}

    This leads to a clear separation of duties between the different converter functions, and provides ample oportunity to micro-optimize their implementations.

  • (unregistered) in reply to

    It's C++.  Or I should say Visual C++.  Some Win32 #include typedefs "unsigned char" to "uchar".  Yes, it is stupid.  No, I don't know why they do that.

  • (cs) in reply to

    :
    You could have sped up GetAsciiValue() by making it a remote procedure call to a dedicated server maybe. ;)
    Better yet, turn it into a .NET Web Service!

    That way you could write it in (wait for it) JavaScript!

     

  • (unregistered)

    May I introduce myself. I am Zhong Ping and have been created a like function, GetUnicodeValue, for many weeks now. It is mighty slower than GetAsciiValue but I have not make the same bad ASCII-only mistake as this person. Now, many Chinese users are enjoying the fruits of my programmer skills. But how can I make my function faster?

    [8-|]

  • (cs) in reply to
    :

    May I introduce myself. I am Zhong Ping and have been created a like function, GetUnicodeValue, for many weeks now. It is mighty slower than GetAsciiValue but I have not make the same bad ASCII-only mistake as this person. Now, many Chinese users are enjoying the fruits of my programmer skills. But how can I make my function faster?

    [8-|]

     

    I dunno, Give the function some concrete sneakers, and dump it into the nearest body of water?

  • (cs) in reply to spooky action at a distance
    spooky action at a distance:

    [image]  wrote:
    You could have sped up GetAsciiValue() by making it a remote procedure call to a dedicated server maybe. ;)
    Better yet, turn it into a .NET Web Service!

    That way you could write it in (wait for it) JavaScript!

     

     
    Javascript to the rescue again! and, of course, we can throw some XML into the solution this way as well!  Technical perfection!  And you can tell your boss that with all of the technologies you are using, it will be "robust and expandable" and will require 6-8 months of coding + testing at $150 /hour! [:D]
  • (unregistered)

    I can't believe the insensitivity to such a complex issue. You've all clearly missed the convolution here.

    The devil is in the details. This problem can >>>only<<< be properly solved like this

    1. C# code makes interop call to a web service proxy written entirely in assembly, no framework support can be used.
    2. The assembly w/s proxy calls a Java ORB on a mainframe b/c only mainframes and java are stable enough to handle a problem of this magnitude
    3. the java program converts the data to EBCIDIC and writes a file and kicks off a COBOL program b/c only mainframe COBOL programmers have the real hardware to handle this problem.
    4. the COBOL program computes the output and dumps the output to a MQ-Series queue which in monitored by yet another java program
    5. the java program pulls it out to the MQ Series queue and sends it back to the assembly based w/s proxy

    you could have optionally transmitted the input data to voyager and have it compute the value but I didn't want to show off or anything [:$]

    Please, please, please be more sensitive to these complex issues.

     

  • (unregistered) in reply to

    <FONT style="BACKGROUND-COLOR: #efefef">I would not want to maintain your code. Everyone knows type casting is dangerous. The compiler may not do the cast the way you expect. Imagine if we just cast ClassOne to ClassTwo willy-nilly. It wouldn't make willy or nilly proud, I can tell you that buster. </FONT>

    <FONT style="BACKGROUND-COLOR: #efefef">For this case it would be much better to move the bits over one at a time and put them where you expect them to be. You could also account for future changes, such as if they re-ordered the ASCII code. It's been the same way for probably 50 years so it's high time for a re-ordering don't you think? It has always bothered me that upper case letters have a lower ASCII value than upper case letters. WTF is up with that? If it were the other way around it would be easier to remember. "Lower case, lower value." Nice and easy to remember.</FONT>

    <FONT style="BACKGROUND-COLOR: #efefef"></FONT> 

     

  • (cs)

    ... that function is so wrong in so many levels, it's disturbing. 

  • (unregistered) in reply to

    You said:

    <FONT style="BACKGROUND-COLOR: #efefef" size=1>It has always bothered me that upper case letters have a lower ASCII value than upper case letters. WTF is up with that? If it were the other way around it would be easier to remember. "Lower case, lower value." Nice and easy to remember.</FONT>

    <FONT style="BACKGROUND-COLOR: #efefef">It would be so easy to fix this too. Just change all of our binary-to-decimal conversions to use base -2 instead of base 2. This would move the lowercase values below the uppercase.</FONT>

     

  • (cs)

    Brilliant wtf . I wonder how this guy would compare strings...

  • (cs) in reply to
    Anonymus:
    It's C++.  Or I should say Visual C++.  Some Win32 #include typedefs "unsigned char" to "uchar". 
    Yes, C++. Or possibly C? How come you think to know it's Visual C++? Bloody _anybody_ can create some typedef like this; fancy, you don't even need Windows for it.
    Anonymus:
    Yes, it is stupid.  No, I don't know why they do that.
    No, it actually isn't; your not knowing it just goes to show how much you know about C/C++. My, didn't think anybody'd be even able to beat this atrocious loop in its WTFness, but such comments get you real close...
  • (unregistered)

    <FONT face=Verdana>

    <FONT face=Verdana>This could be optimized by unrolling the loop, as looping is bad for performance.</FONT>
    <FONT color=#0000ff>ushort</FONT> GetAsciiValue (<FONT color=#0000ff>uchar</FONT> ch)
{
if (ch == 0) return 0x00;
        if (ch == 1) return 0x01;
        if (ch == 2) return 0x02;
        ...
        if (ch == 255) return 0xFF;
}
<FONT face=Verdana></FONT>
    <FONT face=Verdana>also note that I used hexadecimal in the return value so the compiler will not </FONT>
    <FONT face=Verdana>have to do the decimal to hexadecimal conversion.  (Hexadecimal is the native language</FONT>
    <FONT face=Verdana>of computers, aside from binary of course).</FONT>
    <FONT face=Verdana></FONT> 
    <FONT face=Verdana>What do you think?</FONT>
    </FONT>

  • (unregistered) in reply to
    :
    <font face="Verdana">
    <font face="Verdana">This could be optimized by unrolling the loop, as looping is bad for performance.</font>
    </font>


    So is branching.  Your code would cause a pipeline flush every couple instructions.  Use a lookup table for best performance.


  • (cs)

    Got it: shoulda used stored procedures- they're always dramatically faster because they're pre-compiled.

    --

    WHERE ARE THE CODE REVIEWS?!

  • (cs)

    Maybe he/she/it should have tried Javascript
    Bwahahahahaha

  • (unregistered) in reply to

    or a switch covering all possible solutions (and also the unpossible, above 255, for the case that a bit of a register may accidently flip because of radiation). the compiler will make a jmp [reg*4+offset] and on the offsets there will be 'mov eax, n / ret' alike code.

  • (unregistered)

    Just replying to someone above who talked about comments being WTFs in themselves: Man, this is obviously sarcasm. It really doesn't take any effort to sense that.

  • (unregistered) in reply to

    :
    Just replying to someone above who talked about comments being WTFs in themselves: Man, this is obviously *sarcasm*. It really doesn't take any effort to *sense* that.

     

    unfortunately, it appears you have not been browsing this site for too long ... it is nearly impossible to distinguish between some of the real and sarcastic comments -- there have been MANY serious WTF comments.  In this thread alone, there's 3 or 4.

  • (cs) in reply to

    Oh yes? You're the guy I quoted from, are you? (I know I should sense whether you are that someone; but, then again, you already pointed out that I'm not as witty as you. So sorry.)

    To me it looked like a serious answer to the (seemingly) equally seriously asked question in which language there's an uchar-type. If that is the case, you (or that other person, possibly) obviously don't know enough about C++ to make such statements, let alone in a sarcastic way. Sure I might've been jumping to quickly, as indeed it was a comment of salient idiocy. Still, if it was an attempt at sarcasm - which you are not, by any chance, confusing with the concept of irony? - it was pretty lame, apropos of nothing.

    Anyways, if you mean those "improvements" of this method posted earlier - even I caught their drift, imagine, especially liked the function-array - you should learn to read, then come back to see what I've quoted & commented on.

    I've stumbled over this site only a few weeks ago, but still I say that many comments are even more hilarious than the actual WTF they're trying to mock/improve/justify.

    -----edit: Talking of sarcasm - this board software's truly ingenious in the context of the content. Would be nice if it leasways escaped entities correctly or allowed linebreaks, though. Or both, preferably. Anybody access to the source? ;) No offense meant. But seriously, there must be a zillion boards already, for free if needs be, why not use any of those?

  • (cs)

    I re-wrote it using assembler:

    EntryPoint: NOP

    (Jeff, You're cracking me up, man...)

  • (unregistered)

    The 1st three anonymous comments after Jeff's one are just WTFs on their own :)

  • (unregistered)

    Obviously, bitwise operations are the most efficient

    (potential typdefs replaced by actual types)

    unsigned short GetAsciiValue(unsigned char c)
    {
      unsigned short rv    = 0;
      int            i     = 0;

      do {
        rv |= ((c & 1) << i++);
      } while ((c = (c >> 1)));

      return rv;
    }

    Discuss amongest yourselves...

  • (unregistered)

    OK, here's how I see this: obviously casting from uchar to ushort does not work on this system, or the programmer would have used it. Maybe it's a compiler bug or something. Clearly, the loop is inefficient. So we have to find a way to get rid of it, without using a buggy cast. So how about this (untested):

    <font color="#0000ff">ushort</font> GetAsciiValue (<font color="#0000ff">uchar</font> ch)
    {
        <font color="#0000ff">ushort</font> i = 1;
        uchar *lo = &i;

        if(! *lo)           lo++;  // advance pointer if on big-endian hardware

        *lo = ch;
        return i;
    }

  • (unregistered) in reply to

    No, I think it could be improved further.

    You may want to translate into another language.

    After dumping it into the MQ, use UDDI to locate on-line translation services.  Get responses to how much they charge to translate and then enqueue the results in a workflow system for management to authorise the purchase.

    Once purchase order is accepted (which requires snail mail), send the text to the translation service.  Wait for their response.  Then convert back into the original text. Then return Integer.parse("0");

  • (cs) in reply to
    :

    No, I think it could be improved further.

    You may want to translate into another language.

    After dumping it into the MQ, use UDDI to locate on-line translation services.  Get responses to how much they charge to translate and then enqueue the results in a workflow system for management to authorise the purchase.

    Once purchase order is accepted (which requires snail mail), send the text to the translation service.  Wait for their response.  Then convert back into the original text. Then return Integer.parse("0");

     

    That should be:

    string zero = "0";

    (ushort)Integer.parse(zero);

    Shouldn't it? [;)]

  • (unregistered)

    You guys seem to have missed an obvious optimization... the original code was: 

    <FONT color=#0000ff>ushort</FONT> GetAsciiValue (<FONT color=#0000ff>uchar</FONT> ch)
{
    <FONT color=#0000ff>ushort</FONT> i;
    <FONT color=#0000ff>for</FONT> (i=0; i<=255; i++)
    {
        <FONT color=#0000ff>if</FONT>(ch == i)
            <FONT color=#0000ff>return</FONT> i;
    }
    <FONT color=#0000ff>return </FONT>0;
}

    If you look at how the pre- and post increment operator ++ is implemented you will understand that the following will execute faster:

    <FONT color=#0000ff>ushort</FONT> GetAsciiValue (<FONT color=#0000ff>uchar</FONT> ch)
{
    <FONT color=#0000ff>ushort</FONT> i;
    <FONT color=#0000ff>for</FONT> (i=0; i<=255; ++i)
    {
        <FONT color=#0000ff>if</FONT>(ch == i)
            <FONT color=#0000ff>return</FONT> i;
    }
    <FONT color=#0000ff>return </FONT>0;
}
  • (unregistered) in reply to

    :
    If you look at how the pre- and post increment operator ++ is implemented you will understand that the following will execute faster:

    Actually, no. Conceptually yes, but in the case of primitive types compilers are smarter than that so it makes no difference.

    I think what this function needs is some sort of binary search. [8-)]

  • (unregistered) in reply to Jeff S

    Jeff S:
    I see I have not been let down by the last 3 comments so far ... keep them coming... any other good ideas on how to solve this difficult programming dilemma?  XML maybe?   

    Have you tried JavaScript?   

  • (cs)

    Looking at the code only, it's most likely C#, where ushort and uchar are keywords.

    However, reading Telek's comment, it might very well be C, as it seems this is a custom-built device.

    In any case, it's not C++ and most certainly has nothing to do with the Win32SDK. Those typedefs are UPPERCASE.

    Here are a few facts I'd like to point out, though:

    1. Neither C nor C# requires even an explicit cast for this. The cast from integral type A to integral type B where the definition range of A is completely embedded in B's definition range is always implicit.
    2. If this code is, as I suspect, C#, then uchar will be 8 bits regardless of the machine it runs on - the VM specification requires this.
    3. Shortening typedefs aren't stupid. They're convenient if you don't feel like typing "unsigned char" out every time when "uchar" is just as clear.
    4. Visual C++ is not a language.

    And one reply:
    >Just change all of our binary-to-decimal conversions to use base -2 instead of base 2. This would move the lowercase values below the uppercase.
    Apparently you've never studied base -2. Let me tell you, it wouldn't do what you think. It would create a nice chaotic jumble out of the letters.
    The original request (reordering ASCII) is not very useful either. Who cares where in the ASCII set a particular group of characters is? Who cares whether upper-case letters have lower codes than lower-case letters? Only two groups of people:
    1) People who think they know ASCII and code stupid non-portable solutions with that character set in mind. Instead of using the correct character classification and manipulation functions that every language provides. These people have no business doing this stuff anyway.
    2) People who write the correct functions. These people have worse problems than such uninteresting details.
  • (unregistered) in reply to Bustaz Kool

    nah, that should be 'mov eax,[esp+4], ret 4'.

  • (cs)

    Everyone is acting like this is such a big WTF, but do any of you bitches have the spec?

  • (unregistered)

    This code is clearly to encourage people to use UPPER CASE LETTERS, as a message consisting only of UPPER CASE LETTERS will be processed faster than the same message in lower case letters.

     

    [:P]

  • (cs) in reply to CornedBee
    CornedBee:
    In any case, it's not C++
    It's not? I'm impressed. Could you please enlighten us and tell how you determined that? You know, before I read your post it looked like perfectly valid C++-Code to me... well, actually it still does.

    Sure, the intent of the program and the way "ushort i" is declared are indicative of it being C rather than C++, but there's no way to tell. Not unless it's your code, that is. And it isn't, now is it?

  • (cs) in reply to

    :
    <FONT style="BACKGROUND-COLOR: #efefef">It has always bothered me that upper case letters have a lower ASCII value than upper case letters. WTF is up with that?</FONT>

    HUH? Upper case is lower than upper case??? [:P]

    I know what you mean but this just sounds like another WTF to me... [H]

Leave a comment on “For-Loop Illogic”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article