• (disco)

    Frist of the fristest! By a new approach this time!

  • (disco)

    Cc @PJH: So @PaulaBean creates a new topic. And makes it invisible. Making it invisible creates a post. Which is visible in @PaulaBean's profile. And contains a direct link to the invisible topic...

    Invisible topics are a joke. They are broken by design, and fixing them will need fiddling in many places.

  • (disco) in reply to faoileag

    Conglaturation! This topic is happy end.

    Filed under: I was here an hour ago but didn't post.

  • (disco) in reply to aliceif
    aliceif:
    Filed under: I was here an hour ago but didn't post.
    Why didn't you?
  • (disco) in reply to faoileag

    Always winning is boring. I wake up really early because I take the train to work. I should have liked @PaulaBean's post, though, just to have evidence.

  • Hannes (unregistered)

    I don't know, is this topic visible yet? I cannot see it being displayed in topic list.

  • (disco) in reply to faoileag
    faoileag:
    Cc @PJH: So @PaulaBean creates a new topic. And makes it invisible. Making it invisible creates a post. Which is visible in @PaulaBean's profile. And contains a direct link to the invisible topic...

    hmm. Sure that was sorted previously...

  • the beholder (unregistered) in reply to Hannes
    Hannes:
    I don't know, is this topic visible yet? I cannot see it being displayed in topic list.
    I'm not sure. Paula Bean might know, but she's not gonna tell us.
  • (disco) in reply to PJH
    PJH:
    hmm. Sure that was sorted previously...
    My original plan was to use the entry from the "topics created" list in @PaulaBean's profile, but there isn't one for this topic. So perhaps *that* has been fixed, but not the "making invisible creates a post" thing?
  • (disco)

    Oh, and the next bug with "invisible topics" is: as soon as anyone posts a reply to an invisible topic, that "reply" will be visible in the "replies" list of the user creating the invisible topic. Also making it more or less public.

  • (cs)

    I've heard many claims for the 51st state of the USA, including "Puerto Rico", but never have "Americas", "Europe", or "Federal" featured among them. (Nor the Canadian provinces, come to that). I'm half surprised not to see an entry for Guantánamo Bay.

  • (disco)

    Where are the remaining 24 posts?

  • (disco) in reply to aliceif
    aliceif:
    Always winning is boring. I wake up really early because I take the train to work.I should have liked @PaulaBean's post, though, just to have evidence.

    Ok, so @aliceif can quote obscure game references at a higher rate than me, and @Arantor can match me in Red Dwarf quotes at the very least...

    Hey, @PJH, if we make an "uber nerd" contest, could you make a badge for the winner? :stuck_out_tongue:

  • (disco) in reply to Anonymous
    Anonymous:
    Where are the remaining 24 posts?

    Someone found @PaulaBean's meds and she's taking them again.

    Onyx:
    Hey, @PJH, if we make an "uber nerd" contest, could you make a badge for the winner?

    I have one already. You are allowed more than one snowflake you know...

  • (disco)

    UNICODE anyone?

  • (disco) in reply to aliceif
    aliceif:
    Always winning is boring. I wake up really early because I take the train to work.

    Actually, sounds like you're always losing.

  • (disco) in reply to TheCPUWizard
    TheCPUWizard:
    UNICODE anyone?

    What sort of state names do you use?

  • (disco)

    Who mixes state names with country names? Why is there a continent in there too?

  • (disco)

    7 am waking up in the morning, gotta be fresh gotta go downstairs.

  • (disco)

    Not only strcmp is probably already optimized to compare multiple bytes simultaneously, this “optimization” may cause the program to crash and burn if it run on an architecture requiring properly aligned reads.

    This code sample also screams “hashtable” (or at least bsearch)

  • (disco) in reply to VinDuv
    VinDuv:
    This code sample also screams “hashtable” (or at least bsearch) fast enough already

    FTFY

  • (disco)

    Just me who's amused by the response to @PJH raising this on meta?

    https://meta.discourse.org/t/links-to-invisible-topics-are-visible-in-a-users-activity-history/19080/2

    filed under: Bug trackers tend to have a search

  • (disco) in reply to Jaloopa
    jaloopa:
    Just me who's amused by the response to @PJH raising this on meta?

    https://meta.discourse.org/t/links-to-invisible-topics-are-visible-in-a-users-activity-history/19080/2

    I would probably have done so eventually myself, I just wanted to keep it as a post-v1-bug.
  • (disco) in reply to delfinom
    delfinom:
    Who mixes state names with country names?
    Americans. I see that nonsense all the time on the Interwebs.
    Why is there a continent in there too?
    Whut? Surely every continent is an American state!
  • (disco) in reply to boomzilla

    The point is that for unicode, casting to a short will only compare on the first letter!

  • (disco) in reply to TheCPUWizard

    Depends on the encoding, no? Anyways, the function takes const char *StAbbr, not const wchar_t *StAbbr

  • (disco) in reply to Jaloopa
    jaloopa:
    Just me who's amused by the response to @PJH raising this on meta?

    https://meta.discourse.org/t/links-to-invisible-topics-are-visible-in-a-users-activity-history/19080/2

    Ok, [I posted a reply to Jeff][1] over on meta.d to clarify things more.
  • (disco) in reply to VinDuv

    The compiler might insert padding between the strings to provide multi-byte alignment anyway, and this code's author probably has a pretty high degree of certainty that the code will only run on x86 and maybe ARM.

    The overhead of calling strcmp() -- or just figuring out alignment so it can decide what implementation to use -- would be substantial compared to the type-punning comparison in this code. A perfect hash function (i.e. tailored for this particular array's content, so that there are no collisions for strings in the search domain) would probably be the only algorithm that is measurably faster than the provided code: Binary search would have worse cache locality, and bsearch() in particular adds huge function call overhead for such a simple search.

    If I had to put money on this, I'd be most comfortable saying that you could not reliably measure a difference in execution time between this code and a binary search, followed by this code being faster than binary search, and least comfortable claiming that binary search would be faster. Any of those would be somewhat improved by making the StAbbrs[] array an array of character arrays, rather than an array of pointers to character arrays -- that might be a bigger difference than linear vs binary search.

  • (disco) in reply to faoileag
    faoileag:
    Ok, [I posted a reply to Jeff][1] over on meta.d to clarify things more.

    Here's your post reproduced (from raw) prior to memory hole action:

    codinghorror:
    Remember that it is not *literally* invisible, just only accessible to those with a link. It's a mild form of topic suppression.
    That is understood. But the link to the invisible topic *is in the public domain*, i.e. the topic creator's post history, and thus can be seen (and used) by anyone coming across the topic creator's post history.

    If that is "by design", perhaps it would be less misleading if the text were changed from "This topic is now invisible" to "This topic does now not appear in the topic list".

  • (disco) in reply to faoileag

    https://meta.discourse.org/t/links-to-invisible-topics-are-visible-in-a-users-activity-history/19080/2

    "Would swear it is a duplicate but I can't find it."

    I see their "bug tracker" is working well. Any bug tracker that relies on Discourse search is doomed from the get-go.

  • (disco) in reply to Keith
    Keith:
    Any bug tracker that relies on Discourse search is doomed from the get-go.

    Yet another misguided optimization. And you thought you were being OT!

  • (disco) in reply to boomzilla
    boomzilla:
    Here's your post reproduced (from raw) prior to memory hole action: ...
    Oh. Thank you. I forgot...
  • (disco) in reply to boomzilla
    boomzilla:
    OT

    Just so I know what I'm being accused of, is that On or Off Topic?

  • (disco) in reply to Keith
    Keith:
    https://meta.discourse.org/t/links-to-invisible-topics-are-visible-in-a-users-activity-history/19080/2

    "Would swear it is a duplicate but I can't find it."

    I see their "bug tracker" is working well. Any bug tracker that relies on Discourse search is doomed from the get-go.

    Well it worked for cpradio, he found [this][1].
  • (disco) in reply to faoileag
    faoileag:
    Well it worked for cpradio, he found this.

    Or did googlebot find it for him?

  • (disco) in reply to Keith
    Keith:
    Just so I know what I'm being accused of, is that *On* or *Off* Topic?

    I'm not saying.

  • (disco) in reply to faoileag
    faoileag:
    Well it worked for cpradio, he found this.

    Stop undermining my Discourse dissing.

  • (disco) in reply to boomzilla
    boomzilla:
    Or did googlebot find it for him?
    Maybe, but Google is also available to Jeff.
  • (disco) in reply to faoileag
    faoileag:
    Maybe, but Google is also available to Jeff.

    Not for searching Discourse. If he's insane enough to cram Discourse into a bug-tracker dogfood can, no way he's not using his own search.

  • (disco) in reply to nerd4sale

    AA, AE, etc., (Americas and Europe) are APO/FPO codes - Army Post Office and Fleet Post Office. They're abbreviations used within the US postal service for delivery to US military addresses overseas.

  • (disco)

    Ah, but Jeff has an explanation: "It depends how you define invisible, in this case it means 'invisible from topic lists'."

    Discoverability. You just have to discover that invisible means invisible from topic lists.

  • (disco) in reply to faoileag

    Misleading labels (to anyone not smart enough to discover Jeff's cleverness) are kind of a Disco-trademark.

  • anonymous (unregistered)

    I'm pretty sure this topic is going to stay hidden. The Discourse topic is visible, though.

  • (disco) in reply to Entrope
    Entrope:
    The compiler might insert padding between the strings to provide multi-byte alignment anyway, and this code's author probably has a pretty high degree of certainty that the code will only run on x86 and maybe ARM.
    Well, it had better not run on e.g. classic Cray machines, which don't have a 16-bit type in hardware... A C short is not required to be 16 bits - the constraint is merely "at least" 16 bits. An architecture where all integer types were 137 bits would be conformant (I believe this is the right term) and logically all of them would have sizeof == 1. Of course, almost no code on the planet would work correctly on such a machine, especially as we might hypothecate that pointers are only 37 bits, but you can't have everything.

    And the alignment-padding for the strings had better be there for it to work on the align-checking ARM architecture...

    (For real fun, run almost any of the code we see on TDWTF on an x86 of the 486+ variety when some maniac has set the AC bit...)

  • (disco)

    If doing a linear search on an ordered list with only 70 or so items is the slowest part of this application, then she is a goddess among coders, and deserves not your scorn.

    Never guess where to optimize.

  • (disco)

    If you wanted a fast, well-defined way to do the compare in this linear search...

    const char *StateName(const char *StAbbr) {
  // make some assumptions about the state list
  if(StAbbr[0] == '\0')
    return "";
  if(StAbbr[0] == '.' && StAbbr[1] == '\0')
    return StateNames[0];
  if(StAbbr[1] == '\0' || StAbbr[2] != '\0')
    return "";

  for(short index = 0; index < MaxNumStates; index++)
  {		
    if(StAbbr[0] == StAbbrs[index][0] && StAbbr[1] == StAbbrs[index][1])
      return StateNames[index];
  }
  return "";
}
  • (disco) in reply to alipha

    If you really want speed and don't care about space, you want to encode the full names as pointers in a two-level trie of 256 elements each. Since the trie encodes the case of "." and all the invalid abbreviations as well, the only special case you need to check is whether or not a NULL pointer is passed in for StAbbr.

    Sure it takes 256 KB (assuming 32-bit pointers) plus the actual string storage, but I defy you to find a faster implementation.

    char const * const StateNames[256][256] = {
    /* 0x00 */ {
        /* 0x00 0x00 */ "",
        /* 0x00 0x01 */ "",
        ...
        /* 0x00 0xff */ "",
    },
    ...
    /* A */ {
        /* A 0x00 */ "",
        /* A 0x01 */ "",
        ...
        /* AA */ "Americas",
        /* AB */ "Alberta",
        /* AC */ "",
        /* AD */ "",
        /* AE */ "Europe",
        ...
        /* A 0xff */ "",
    },
    /* B */ {
        /* B 0x00 */ "",
        /* B 0x01 */ "",
        ...
    },
    ...
};

const char *StateName(const char *StAbbr) {
    if (StAbbr == NULL)
        return("");
    return(StateNames[StAbbr[0]][StAbbr[1]]);
}
  • (disco)

    About 10 years ago, the province of Newfoundland was renamed to Newfoundland and Labrador. The abbr. was changed from NF to NL. I was in the middle of a big (at least for me) database project when this happened, so I had to change the name and abbreviation, which I had used as a primary key for the "Province" table. I just had to make one change and let the UPDATE relationships convert all those NF codes to NL. I am actually glad I put the province/state information in the database, rather than hard-coding it.

    I also noticed that code for Newfoundland in the look up is still NF, even though that changed 10 years ago. This could cause bad times for your mail getting to its destination in St. John, NL. I think TRWTF is not updating your list of constants when circumstances change. That is why they are there; so you only have to update them in one place, but you still have to update them.

  • (cs)

    Now that Nagesh is here, it will get open soon.

  • (cs)

    For start, this is so much easier in Python.

    allIndia = {'MA': 'Maharashtra', 'AP': 'Andhra Pradesh', 'MP': 'Madhya Pradesh'} print allIndia['AP']

Leave a comment on “Misguided Optimization”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article