I am a genius.



  • Here is a brilliant example of my code.

    private void FromFile(string path)
    {
        for (int i = 0; i < 0xfa0; i++)
        {
            RgbData item = new RgbData();
            this.provinceColors.Add(item);
        }
        foreach (string str in File.ReadAndCleanLines(path))
        {
            string[] strArray = str.Split(new char[] { ';' });
            if (strArray.Length < 4)
            {
                break;
            }
            ushort num2 = ushort.Parse(strArray[0]);
            byte num3 = byte.Parse(strArray[1]);
            byte num4 = byte.Parse(strArray[2]);
            byte num5 = byte.Parse(strArray[3]);
            this.provinceColors[num2] = new RgbData(num3, num4, num5);
        }
    }

      Doesn't it make so much sense? Note that it was loaded using Reflector. That's because I lost the original source code. As well as, in fact, the source code for any working version of that project. But whatever, it's not like source code is all that important. After all, I managed to load this code using Reflector, so it's not really a problem that I don't have the original source.

     Basically, the reason for me going back to this code is that a client wanted to have a IdToColorMap with more than 4000 (0xfa0) entries. So I went into Reflector, used an addin to edit the CIL and changed 4000 to 20000. Really now, 20000 entries should be enough for anyone. In any case, changes made, and patched exes sent to the client. Problem solved, all without ever having to use a fancy IDE or compiler.

    Now that was pretty brilliant, but let me take you through my code, just to display how much of an underappreciated genius I am.

    First, the hardcoded limit of 4000 entries. Back when I wrote this, 2 or 3 years ago, the highest necessary was 2800 entries, and 4000 entries was already excessively generous. How was I supposed to predict that people would soon start demanding so many entries? It's completely unfair, how clients continually change their specifications and expect everything to just work. Furthermore, hardcoding 4000 was a very good idea. Otherwise I would have to have done something like "i < array.Length", and everyone knows that having a constant is much faster than doing member lookup.

    Note that RgbData is a struct. So I am first populating a list with 4000 empty RgbData items, and then in the next loop changing out certain ones for entries read from a file. I mean, there might hypothetically be a better way to do it, but it's not like I can take advantage of the fact that the entries are supposed to be in ascending order or any other solution. Nope, array-like population is the way to go.

    Sometimes the users might be stupid and they might enter less than the required four entries per line. In that case, I might as well give up, and silently stop parsing the file. Users should know better than to have typoes, and this will teach them to be more careful when typing or generating entries in the future. Their problem if one mistaken entry suddenly causes a large portion of the data-loading process to fail.

     Also, notice that I declare num2 as a ushort instead of an int. Essentially num2 corresponds to an ID number. Yeah, that might be a problem if IDs ever exceed 60000 or so, but considering that IDs are only in the low thousands, it's not like that will ever become a problem. But I had a very good reason for declaring it as a ushort instead of the standard int. By doing so, I manage to save two bytes on the stack. That's right, two whole bytes! When you only have about a million of them, two bytes is very significant and a very good reason for the minor potential maintainability hassle this could bring. I mean, all I'd have to do is change a few dozen declarations of ushort to int. Shouldn't be buggy at all.

    Oh, one last thing. This code is actually common to four applications that comprise part of the software suite. I could have made the common code into a DLL, but instead I linked the source files to each of the four projects. That way, I won't need to worry about missing DLLs. Sure, if I need to make changes to the common code I'll need to edit four different instances in Reflector, but the ease of not having to link to a DLL is very worthwhile.

    Hmm, I really do outdo myself with my humble ingenuity. Perhaps I should become a consultant, and spread my talents to these poor other software companies, who believe in such outdated concepts as source control.



  • @Wiguyy said:

      for (int i = 0; i < 0xfa0; i++)

    Very clever.  I don't use hex much so this didn't trigger my "hardcoded round number" detector. Or is that just caused by Reflector? It would have taken me a long time to discover the reason for the customer's "it stopped working" complaint. "What were you trying to do before it stopped working?" "Just adding a line?  How many lines are there?"



  •  Yeah, it's a Reflector thing (I think! *gulp*)

    Thankfully, people can send exception logs these days, so it was trivial to pinpoint the problem. And this isn't the first time I had to modify CIL in-place so everything was already there. Argh, at least usage should die out in a year or so.


  • Garbage Person

     10/10. Excellent creative presentation. WTF quality high. Subtlety is substantially above par. Sarcasm is very well applied and not drippy at all (well, until the last bit of the last sentence)



  • What happened to num1 ?



  • @Qwerty said:

    @Wiguyy said:

      for (int i = 0; i < 0xfa0; i++)

    Very clever.  I don't use hex much so this didn't trigger my "hardcoded round number" detector. Or is that just caused by Reflector?

    It's definitely caused by Reflector. If one were to go to Reflector's menu View > Options > Disassembler > Number Format, one can choose between Auto, Hexadecimal and Decimal.

    Also, the naming of the variables is somewhat random, also caused by Reflector. I'm assuming the 0xFA0 is recognized as num1 but not disassembled as such... or something.</p?



  • I'm more amazed that you need over 4000 configured colors for something...



  • @Daid said:

    I'm more amazed that you need over 4000 configured colors for something...

    Apparently 4000 wasn't enough... The new limit is now 20k.



  • @C-Octothorpe said:

    @Daid said:

    I'm more amazed that you need over 4000 configured colors for something...

    Apparently 4000 wasn't enough... The new limit is now 20k.

    And "over 4000" is more then 4000.


  • @Daid said:

    @C-Octothorpe said:

    @Daid said:

    I'm more amazed that you need over 4000 configured colors for something...

    Apparently 4000 wasn't enough... The new limit is now 20k.

    And "over 4000" is more then 4000.

    4000 wasn't enough, though.



  • @Sutherlands said:

    @Daid said:

    @C-Octothorpe said:

    @Daid said:

    I'm more amazed that you need over 4000 configured colors for something...

    Apparently 4000 wasn't enough... The new limit is now 20k.

    And "over 4000" is more then 4000.

    4000 wasn't enough, though.

    I really think we need one more person to nest this reading comprehension fail...  4000 isn't enough? OMGWTFLOL!

    Haven't had my coffee yet when I responded.  My bad.



  • Added WTF: whatever you do, make sure you don't use the built-in Color class. Waaay too convenient!

    So... is 4000 colors enough?



  • Actually, there was reason to use many colors. In brief, each color represented a "province" on a map, so the more "provinces", the more colors needed. Possibly not the best system, but this was reasonably flexible for its purpose.

    Actuallly, there was reason to use custom color classes, namely that of memory. The program used hundreds of megabytes, so a 25% savings (and in some cases, 75%), was actuallly worthwhile. Of course there may have been better solutions, such as looking into memory-mapped files or in-memory compression, but I think that in this context creating a custom struct was a reasonable, if not optimal, choice.



  • @Wiguyy said:

    Actually, there was reason to use many colors. In brief, each color represented a "province" on a map, so the more "provinces", the more colors needed. Possibly not the best system, but this was reasonably flexible for its purpose.

    And I thought that some mapping theory had shown us all long time ago that whatever map with areas (such as provinces) you can conjure up, you can always do it with just 5 colors. Except when you are going to draw a map on the back of yur Möbius headband, you will need no more than 6.

    So, we might ask agian, why the multitude of colors? I could have understood the need if you were doing some gridding with population density or such. But still, it would be a stretch since people would be unable to accurately distinguish the colors.

    /Me :)


  • Discourse touched me in a no-no place

    @dsckeld said:

    @Wiguyy said:

    Actually, there was reason to use many colors. In brief, each color represented a "province" on a map, so the more "provinces", the more colors needed. Possibly not the best system, but this was reasonably flexible for its purpose.

    And I thought that some mapping theory had shown us all long time ago that whatever map with areas (such as provinces) you can conjure up, you can always do it with just 5 colors.

    That's all very well if the only condition you're restricted by is that no two adjoining areas must have the same colour.


  •  The FOUR color mapping theorem says that you can color any map with only four colors. However, that only applies if the territories are connected. For example Michigan is not connected and so a map of the US might require more than four colors.

    But think about it - he's using over four thousand different colors on a map. How many people can distinguish between four thousand different colors. As in light bluish-green versus not-quite-so-light bluish-green. 

    There may be 24 million different colors to a computer, but not to a human.



  •  Because each "province" has to have a unique ID associated with it, and a Color<->ID map seemed the easiest way to implement it. Note that the colors are just used by those designing maps. End-users never see the maps, but rather the output of the map-generator (which does not depend on distinguishing shades of colors).

    Also, dsckled is right in that it was the 5-color theorem that was proved a long time ago. The 4-color theorem is much more recent, and some might even reject it due to its computer-based proof.


Log in to reply