• (cs) in reply to Watson
    Watson:
    "If any of you are still white, we can cure you."
    +1 for the Arthur C. Clarke reference.
  • some dude in Europa (unregistered) in reply to frits
    frits:
    Your not too smart, are you?
    Though shalt not throw stones when inside a glasshouse.

    Captcha: pecus... Reminds me of my dear friend in Rome, Pecus Decus.

  • (cs)

    Oooo...code by an old FORTRAN programmer.

    A double is 8 bytes, which is long enough for many names. A common trick in early FORTRAN was to pass such values in numeric variables, rather than in character arrays, because they were so easily read and written (because a numeric variable contained multiple bytes; 8 for double precision):

          DOUBLE PRECISION LAST, FIRST, MIDDLE
          READ (6,10) LAST, FIRST, MIDDLE
       10 FORMAT (3A8)
          WRITE (7,10) LAST, FIRST, MIDDLE
    

    Oh, and just in case you think I'm making this up: Try to follow around the original ADVENTURE program a little.

  • OccupyWallStreet (unregistered) in reply to TheSHEEEP
    TheSHEEEP:
    Storing stuff in doubles instead of strings. Finally someone did it right!

    Hey, it's a great way to properly represent the mixture.

    If one of your parents is Asian and the other is Black, you'd be 0.5 black and 0.5 asian. See? The database works great!

    Now if you married a white, your kids would be 0.25 black, 0.25 asian and 0.5 white.

    Storing in doubles makes perfect sense - you can accurately determine what race someone is, including mixed-race families. And accurately store the proportions, too. (And given the way binary floats work, it should be good for many generations)

  • Max (unregistered)
    • "For security purposes, please say the last four digits of your social security number"

    • "2051.99999999999"

  • napillo (unregistered) in reply to Race Driver
    Race Driver:
    OK, this is the first code I've ever seen that has a chance of accurately representing race. You could be 60% white, 30% asian, and 10% hispanic!

    I suppose it's quite possible. I'd like to see someone who fits that bill though and ask how their family tree is... Genetics are base2. So going one level up - parents - you can have 50% of each. Assuming parents and grandparents can only have 100% of one, you could be at max, 50% white, 50% asian. Going back further, you have 4 grandparents, each potentially 100%, you could have 50% white, 25% asian, 25% hispanic, that's assuming that each person gets 50% of their genetics from both parents. It's usually closer to 49.9%... Going up one more level, great grand parents, you'd have 16, so now you can have 10 of them be White, 5 asian, and 1 hispanic, which would get you 62.5% white, 31.25% asian, 6.25% hispanic. So, I suppose you could round it up a bit on the hispanic side, round white and asian down a bit, and you got yourself the mythical 60 30 10.

    In any case, I doubt anyone is going to trace their family history back so far enough to be able to tell with any scientific certainty which percentages of ethnicity their ancestors were. And how would you count people such as Tajiks who may be Mid-Eastern or Asian depending on where you consider them to be. Perhaps you could consider them as 50% asian, but then you have people in your database who don't add up to 100% of a person.

  • Norman Diamond (unregistered) in reply to Coyne
    Coyne:
    Oooo...code by an old FORTRAN programmer.

    A double is 8 bytes, which is long enough for many names. A common trick in early FORTRAN was to pass such values in numeric variables, rather than in character arrays, because they were so easily read and written (because a numeric variable contained multiple bytes; 8 for double precision):

    Yes, but no one would ever do arithmetic calculations on those variables. The only things they would ever do are read and write them. If a programmer wanted to compare them then the programmer had better use INTEGER instead of DOUBLE PRECISION.

    Coyne:
          DOUBLE PRECISION LAST, FIRST, MIDDLE
          READ (6,10) LAST, FIRST, MIDDLE
       10 FORMAT (3A8)
          WRITE (7,10) LAST, FIRST, MIDDLE
    
    [Community Server fodder] This garbage is not part of the quote. Close the code tag before this and close the quote tag after this. Do not delete this garbage. Tell readers not to read this garbage. [/Community Server fodder]
    Now I doubt it though. Fortran II didn't let you specify that you wanted to read from the printer and write to the card puncher; it had separate VERBS to read and write separate devices. Fortran IV had this syntax of READ and WRITE statements, but it also had CHARACTER*8 (and CHARACTER*20 etc.) so no one would need to use numeric types for these any more.
    Coyne:
    Oh, and just in case you think I'm making this up: Try to follow around the original ADVENTURE program a little.
    Right, that game compared the first 5 characters of each input string, so it could not use DOUBLE PRECISION. Either it was written for a machine where INTEGER could store 5 characters, or the programmer used CHARACTER*5. When I first saw the source code someone had already translated it to PL/I so I couldn't narrow down the original architecture any further.

    TRWTF was that the command PLOVER would send you from the Plover room to Y2. From any other room next to Y2, the command Y2 would move you to Y2. In a few other places you could also name the room you wanted to move to, if it was adjacent to your present location. The command Y2 should have worked from the Plover room. The reason Plugh was spoken by a hollow voice instead of being engraved in stone was so that it would be a hint, if you came from the Plover room then you'd know you were at Y2. If you were at Y2 then the PLOVER command worked correctly. So I think the use of the PLOVER command instead of Y2 command to move from the Plover room to Y2 was a typo by some programmer, unfairly causing injury and game losses to millions of innocent adventurers.

  • Prof Foop (unregistered)

    This reminds me of the method for finding the average Joe: you all them all up and divide by the number of Joes.

  • (cs) in reply to Larry
    Larry:
    "...I don't even know where to start with the WTFs!" writes Rachel.
    Wait, what? Someone who knows the owner of a website I frequent got an email from a girl?!!! We must develop a new crowdsourced peer-to-peer data harvesting system to glean all available info about this specimen.
    And just as I thought this community grew up... *sigh*
  • Who Needs to know race (unregistered) in reply to Mike Dimmick

    In that case, the WTF here, is that, based on that call statement, everyone is assumed White... eff the data.

    Captcha: tego (of my eggo)?

  • TZ (unregistered)

    I don't think you people realize the genius behind this!

    They are using white, hispanic, asian, and indian similar to RGBA values but only for PEOPLE!

    So while I might be a 1.0, 0.0, 0.0, 0.0

    My buddy a few desks over can be described as a 0.4, 0.25, 0.25, 0.1

    But watch out for the 0.5, 0.5, 0.5, 0.5 guys!!!

  • Thomas (unregistered) in reply to Coyne
    Oooo...code by an old FORTRAN programmer.

    A double is 8 bytes, which is long enough for many names. A common trick in early FORTRAN was to pass such values in numeric variables, rather than in character arrays, because they were so easily read and written (because a numeric variable contained multiple bytes; 8 for double precision):

    I've used this very trick to sign friends birthday cards before. Divide the chunks of the message into, for example, 64-bit integers (8 bytes) and pad with 0 bytes. Then write the birthday message using the string equivalent of those numbers so that you end up with a list of numbers. Sadly, I think it will take them a few birthdays to figure out.

  • (cs)

    You would say, why would races not be an enum? You would say, why would races be separate values, so you could combine them?

    Well, now that we have our first white-Hispanic, the method is more useful now isn't it?

Leave a comment on “The Race Case”

Log In or post as a guest

Replying to comment #:

« Return to Article