• (disco) in reply to kupfernigk
    kupfernigk:
    What I'm not sure about is this; do PHP developers have shares in server companies, and write code guaranteed to keep companies buying ever bigger servers? Or are they just useful idiots for the server vendors?

    Most PHP programmers simply don't know enough to write performant code. If they did they probably wouldn't be working in PHP.

    Some of us can write performant code in PHP and in other languages but for reasons continue to use PHP.

  • (disco) in reply to Arantor

    Because we don't have to throw a bunch of shit onto our servers to get it running?


    Filed under: We throw a bunch of shit into our code instead

  • (disco) in reply to Onyx

    No, we have to throw a bunch of shit onto our servers to get it running first - Apache (or nginx), MySQL (or Postgres) and our bestest buddy PHP of course.

  • (disco) in reply to Arantor

    Good. Now set up RoR. See you in... two weeks?

  • (disco) in reply to Onyx

    Hang on, I have a WampServer to install first...

  • (disco) in reply to kupfernigk
    kupfernigk:
    Since I have just shown that aleph-null * aleph-null is still aleph-null, I have also shown that aleph-null divided by aleph-null is aleph- null, by simple algebra.

    That doesn't follow. Consider splitting the set of all integers (cardinality ℵ0) into two covering, non-intersecting subsets: the set of all odd integers and the set of all even integers. Those subsets both have cardinality ℵ0, so ℵ0 ÷ ℵ0 = 2, by simple algebra!

    In reality, transfinite numbers don't work nicely with simple algebra. They work with some parts of simple algebra, but not others (and division is one of the parts that doesn't work so well; you need a different approach to finding the average).

  • (disco) in reply to dkf

    The triangle proof of the countability of the rationals is also a way of showing that ℵ0 x ℵ0 = ℵ0

    [image]
  • (disco) in reply to Jaloopa
    Jaloopa:
    The triangle proof of the countability of the rationals

    Yeah, you have to go to things like powers (ℵ00) to make the jump to ℵ1.

    Formally, ℵ1 is the cardinality of the set of all subsets of a set of cardinality ℵ0, and the continuum hypothesis is that that is equivalent to the cardinality of the set of all real numbers. IIRC, that's actually a hypothesis that (as far as anyone knows) leads to a consistent system whether it is assumed to be true or false. Which makes it (or its complement) an interesting candidate for being taken as axiomatic…

  • (disco) in reply to dkf
    dkf:
    Formally, ℵ1 is the cardinality of the set of all subsets of a set of cardinality ℵ0, and the continuum hypothesis is that that is equivalent to the cardinality of the set of all real numbers.
    That's incorrect. 20 is the cardinality of the set of subsets you describe, and also the cardinality of the real numbers. The continuum hypothesis states that this is equal to ℵ1, which is the next largest cardinality after ℵ0. In other words, it says that there's no cardinal number between ℵ0 and 20.
    IIRC, that's actually a hypothesis that (as far as anyone knows) leads to a consistent system whether it is assumed to be true or false.
    Not merely as far as anyone knows; it's been proven that the continuum hypothesis (and indeed the generalised continuum hypothesis, which says that for any infinite cardinal k there is no cardinal number between k and 2k) is independent of ZFC1, so you can construct consistent models obeying ZFC + (G)CH and you can construct consistent models obeying ZFC + (¬CH).

    However, it does turn out that ZF + GCH implies the Axiom of Choice. So you can't have ZF + ¬AC + GCH. For what that's worth.

    1Zermelo-Fraenkel set theory together with the Axiom of Choice

  • (disco) in reply to Scarlet_Manuka
    Scarlet_Manuka:
    it does turn out that ZF + GCH implies the Axiom of Choice.

    Ah, I've not been keeping up with the field.

  • (disco) in reply to dkf

    Me either, I found that out from Wikipedia when I was checking that I wasn't about to assert something false :)

    (Though I don't recall whether we ever covered that particular point when I was learning it. I did remember the independence of GCH from ZFC, but I'm not sure if we went over (G)CH and ZF or not.)

  • (disco) in reply to Scarlet_Manuka

    To be fair, I work in a field where denial of the Axiom of Choice is relatively common, which leads to constructive and intuitionistic logics IIRC. The statements that you can make in such things tend to be a lot more restricted, but on the other hand you can say them more certainly (i.e., you're not left saying “pick a number, and you might be able to use that to do something useful in this proof”).

    That it doesn't work with the GCH (and ZF) is interesting. Unfortunately, I don't really like the AoC yet I do like the GCH… :worried:

  • (disco) in reply to dkf

    Reminds me of the joke:

    Jerry Bona:
    "The Axiom of Choice is obviously true, the well-ordering principle obviously false, and who can tell about Zorn's lemma?"
    (for the non-mathematicians: all three are logically equivalent)

    @dkf, I'm wondering whether you use weaker choice axioms, e.g. dependent choice?

  • (disco) in reply to Scarlet_Manuka
    Scarlet_Manuka:
    I'm wondering whether you use weaker choice axioms, e.g. dependent choice?

    Personally? Not sure. :stuck_out_tongue:

    As far as I can remember, the constructivist/intuituionistic approach ends up being the foundation for modal logics, which have their whole own reasoning systems that are different to the usual things like first order logic. I believe they can push the computability limits in some areas a bit further by giving up on them in others. Multi-modal K is a particularly useful one for the field I'm in at the moment, as it's at the core of being able to reason about ontologies and that's critical for certain types of searching in metadata-rich environments.

    The lack of the AoC isn't a pressing problem in that domain, because people aren't usually all that interested in finding things that might potentially exist in a platonic sense, but which haven't actually been created and described yet. ;)

  • (disco)

    To be fair, most people probably aren't that interested in the question of "hey if you have an infinite set of things, is there some other infinite set with more things than the first one but less things than the number of subsets of the first one?" either.

  • (disco) in reply to Scarlet_Manuka
    Scarlet_Manuka:
    most people probably aren't that interested in the question of "hey if you have an infinite set of things, is there some other infinite set with more things than the first one but less things than the number of subsets of the first one?"

    Most people don't know what they're missing, man

  • (disco)
    redwizard:
    //compact the job number to two digits by adding digits 1+2 and appending to the sum of digits 3+4

    TRWTF is the code appends the other way around to the comment

  • (disco) in reply to AwesomeRick
    RaceProUK:
    AwesomeRick:
    If the values are always increasing incrementally, then a malicious user could craft an electronic or social engineering attack.
    In that scenario, the sequential 'exploit' is merely a symptom of a bad security model :stuck_out_tongue:

    Disagree. Sequential descriptors are a built-in security problem.

    The main problem is that many "off-by-one" mistakes yield valid order (or confirmation) numbers. I'll grant you that the web site should lock people out of anything but their own orders. But if a customer writes the wrong number down, their only recourse is to call customer service. If the number is completely bogus, support is forced to work toward a valid number from a different route. If the wrong number is valid, a new path of least resistance is available, even though that path is more costly for the company.

    Furthermore, any predictable pattern makes it possible to "count" the number of orders, thereby leaking coarse information about the financial condition of a company.

    AwesomeRick:
    Jerome_Grimbert:
    What happen once the table has been filled with one million confirmation ?

    The confirmation number is at least 7 digits, and up to 10 digits, depending on the original value of the order number

    ...

    the order number isn't shortened to two digits in all cases. Instead it can still be 2, 3 or 4 digits. For example 1234 becomes 37, 3456 becomes 711, and 6789 becomes 1317.

    You've analyzed the range of the $c_jobno value, which few noticed, but I think the confirmation number can be as short as 1 digit long, meaning the result is between 3 and 10 digits.

    I really don't believe $c_jobno is used elsewhere in the code. At one point the code chops off the first 4 digits to get at confirmation numbers -- this won't work unless jobno is exactly 4 digits.

    But, of course, you can't tell for sure, because the :wtf: is so strong in this codesod. Marcus and Remy chose well.

  • (disco) in reply to Crunger
    Crunger:
    But if a customer writes the wrong number down, their only recourse is to call customer service. If the number is completely bogus, support is forced to work toward a valid number from a different route.

    Check out error-correcting codes. Put sufficient extra digits in and use an ECC and you'll be able to automatically undo minor errors. And it will stop the numbers from appearing to be sequential.

  • (disco) in reply to dkf

    Like credit card numbers.

    I still don't understand why bank account numbers don't do the same.

  • (disco) in reply to dkf

    For every ECC, there's a dumbass who's gonna mistype just one digit too many.

  • (disco) in reply to Maciejasjmj

    Can't most error correcting codes detect at least one more wrong digit than they can correct? So even if it couldn't switch it back it could still call the user a moron

  • (disco) in reply to Maciejasjmj
    Maciejasjmj:
    For every ECC, there's a dumbass who's gonna mistype just one digit too many.

    Sure, but that's unavoidable whatever you do because that's just how data entry is. Using an ECC would at least keep the error rate down (and allow detection of much of what remains).

  • (disco) in reply to dkf
    dkf:
    Check out error-correcting codes. Put sufficient extra digits in and use an ECC and you'll be able to automatically undo minor errors. And it will stop the numbers from appearing to be sequential.
    lightsoff:
    Like credit card numbers.

    The Luhn algorithm isn't really an ECC since technically it does no correction. It will however

    • Always detect a single wrong digit
    • Mostly detect a single tranposition (it fails on 09<->90)
    • Fail on 3/10 twin errors (22<->55, 33<->66 or 44<->77)
    • Be useless if the number of zeros at the start of the number is significant since the algorithm treats them as insignificant (then again since you presumably know the length of the number if it's a CC, this isn't an issue here.)
  • (disco) in reply to PJH
    PJH:
    Be useless if the number of zeros at the start of the number is significant since the algorithm treats them as insignificant
    How many credit/debit card numbers start with a string of zeroes anyway? :stuck_out_tongue:
  • (disco) in reply to RaceProUK
    RaceProUK:
    How many credit/debit card numbers start with a string of zeroes anyway?
    PJH:
    (then again since you presumably know the length of the number if it's a CC, this isn't an issue here.)

    It's just if you're using Luhn elsewhere with variable length numbers, like they do with ICCIDs that this may be an issue.

  • (disco) in reply to PJH

    Ohh - bug found.

    PJH:
    with ICCIDs that

    Note the difference between the tooltip text and the raw.

    CBA reporting that one tho.

  • (disco) in reply to PJH
    PJH:
    CBA reporting that one tho.
    I would report it instead, but it's not really worth the bother. Plus, it's trivial to work around.

Leave a comment on “One In a Million”

Log In or post as a guest

Replying to comment #:

« Return to Article