• LCrawford (unregistered)

    At least they were unique Ids, for a given session.

  • P (unregistered)

    Isn't the bigger WTF it is TypeScript apparently and is doing implicit string conversion?

  • (nodebb)

    We need to demand truth in advertising. (And function names)

  • Little Bobby Tables (unregistered)

    Unless the task involves monte carlo simulation, or creating "random" one-use passwords, I've always been sceptical of the need to generate random numbers. As it is not a straightforward task to generate truly random numbers, it's often worth taking a step back to find out what the need is for the randomicity.

  • bvs23bkv33 (unregistered)

    commentid5

  • (nodebb) in reply to Little Bobby Tables

    What about AI? To simulate a human thinking process, an element of randomness needs to be in the mix.

  • (nodebb)

    The title made me think of ...

    hi every1 im new!!!!!!! holds up spork my name is katy but u can call me t3h PeNgU1N oF d00m!!!!!!!! lol…as u can see im very random!!!! thats why i came here, 2 meet random ppl like me ^^… im 13 years old (im mature 4 my age tho!!) i like 2 watch invader zim w/ my girlfreind (im bi if u dont like it deal w/it) its our favorite tv show!!! bcuz its SOOOO random!!!! shes random 2 of course but i want 2 meet more random ppl =) like they say the more the merrier!!!! lol…neways i hope 2 make alot of freinds here so give me lots of commentses!!!! DOOOOOMMMM!!!!!!!!!!!!!!!! <--- me bein random again ^^ hehe…toodles!!!!!

    love and waffles,

    t3h PeNgU1N oF d00m

  • P (unregistered) in reply to Little Bobby Tables

    Except that this looks like JavaScript (assuming it's TypeScript), and this code breaks when counter reaches Number.MAX_SAFE_INTEGER (or 2^53) because 2^53 + 1 === 2^53.

  • Mr Bits (unregistered)

    That downstream code should just lower its expectations.

  • (nodebb) in reply to P

    All numbers are in double-precision floating point in this language?

  • DrPepper (unregistered)

    It all depends on what context this code is running in. I use code like this in my unit tests. When I'm populating an object to be used as fake data (for example, when I'm faking out a call to an API), the actual contents of the object don't really matter. In that case, I use code like the above to generate a unique number to fill in values:

    obj.orderNumber = testHelper.random(); obj.customerNumber = testHelper.random();

    So that for a particular unit test, the objects being used in that test have unique values different than any in any other test.

  • (nodebb)

    [Insert Dilbert strip with "9... 9... 9..." random number generator here]

  • (nodebb) in reply to Steve_The_Cynic

    By coincidence, this whole text is my password for thedailywtf.com

  • (nodebb)

    xkcd 1210

  • (nodebb) in reply to Medinoc

    When using the exponent operation, pretty much. The exponent function is defined using exp(x) and log(x), which are floating-point functions. The lower operators are defined for integers, but for exponents, integers are converted to floating-point, use the exp and log floating-point functions, then only converted back to integer if the next operation requires it. The loop through multiplying integers is not defined for this language.

    a^b = exp(b*log(a))

    Math proof available on request.

  • RLB (unregistered) in reply to Little Bobby Tables

    I've written code to generate random-enough IDs for items. The reason was that if the IDs are subsequent, people get them mixed up, but if they're random enough that items produced in the same day have different-looking codes, they don't get confused nearly as often. (And yes, we really did have that problem with earlier versions of that software; and yes, this change really did ameliorate, though not eradicate, the problem.)

  • WTFGuy (unregistered)

    @RLB: Me too.

    If serial number-like data has to be rekeyed and each unit of work gets a sequential number, many common typos are still valid serial numbers. Just not the correct serial number. Check digits are one common mitigation, but issuing non-sequential (more properly non-local) IDs is another mitigation. And often the latter technique has a smaller impact on downstream code & data plus better statistical performance. IOW, better all around. At a small, but completely local, increase in code complexity.

    At least until you discover some fundamental step waaay downstream in the processing pipeline that not only assumes sequential IDs, but demands them. Then you're hosed. Been there, done that too. Ouch!

  • PotatoEngineer (unregistered)

    My team wrote code almost exactly like this, to replace Kendo's random-GUID function. That random-GUID code was called ~10,000 times per page load, and switching to an incremental counter greatly improved page performance.

    (We later ended up replacing Kendo with in-house options, to cut down on load time. I'm not completely certain it was necessary, but we're definitely downloading less code now.)

  • (nodebb)

    I rather suspect this was debug code that didn't get removed.

  • Olivier (unregistered) in reply to RLB

    I remember reading somewhere about some cryptography function that was returning an hexadecimal string in the form of a few proper English words.

    That function was perfectly reversible too. The idea being that a human could remember and enter some words better than they could remember a string of 30 or 50 hexadecimal numbers. But internally, it would mean the same.

  • (nodebb) in reply to DrPepper
    obj.orderNumber = testHelper.random(); obj.customerNumber = testHelper.random();

    So that for a particular unit test, the objects being used in that test have unique values different than any in any other test.

    Nope.

    A random number generator will give you random numbers. Not unique numbers. Some day, randomly, your tests will fail if they depend on the uniqueness of these numbers. Depending on the range of the random numbers and freuency of tests, it may or may not happen while you are on the same job.

    If you want unique numbers, use a unique number generator. Such as presented in the main article here. Make sure to change the name though.

    Let us say it all together and remember it for life: Random numbers are not unique numbers.

    Addendum 2019-08-20 22:37: On a second reading of your comment, I realized that you are exactly doing the same thing that the coder of the main post did: generating serial numbers by incrementing and calling them random. Now I don't know which is worse.

  • Chris (unregistered)

    I would like to assume that the original code did something random. Then they realised they wanted uniqueness, and that randomness wasn't important, so they changed how it worked without changing the name of the function. Someone else used the same function, expecting it to do what it says on the label, and were bitterly disappointed when they discovered they were lied to.

  • (nodebb) in reply to DrOptableUser

    Personally, when I want a bunch of IDs that are both unique and non-predictable, I generate them by concatenating a counter and a random part (e.g "3654-42", "8574-43", etc;) (plus a location, if the counter isn't global) As long as you don't do something stupid downstream like comparing both parts separately, it will work well enough.

  • linepro (unregistered) in reply to Little Bobby Tables

    https://www.random.org/

  • (nodebb) in reply to Olivier

    I remember reading somewhere about some cryptography function that was returning an hexadecimal string in the form of a few proper English words.

    That function was perfectly reversible too. The idea being that a human could remember and enter some words better than they could remember a string of 30 or 50 hexadecimal numbers. But internally, it would mean the same.

    What 3 Words uses a similar concept for geolocation: https://what3words.com/

  • Ulysses (unregistered)

    I submitted a good WTF article ages ago, but flavorless crud like this continues to get posted instead. Sigh.

  • owlstead (unregistered)

    Let us say it all together and remember it for life: Random numbers are not unique numbers.

    Ugh, that's stupid. If the number is large enough then the chance of collision is negligibly small. There is nothing wrong with random GUID's. Actually, in operation they may be more likely to be unique than a counter, as the counter may be reset for some reason or other, and you need tricks to make the counter work for multiple threads / processes. Note that I am a cryptographer.

  • (nodebb) in reply to owlstead
    Ugh, that's stupid.

    Hmmm. Let us see.

    If the number is large enough then the chance of collision is negligibly small.

    Senseless. What "number"? One can write a "random number generator" which returns the same number which is "large enough" again and again. Being large alone does not decide the chance of collision.

    There is nothing wrong with random GUID's.

    Do you know what the U in GUID stands for? That U is the key to the design of GUIDs, not R, though some implementations may have an element of randomness in them. In fact quoting from wikipedia on version 4 of UUIDs in the "Universally unique identifier" page, In practice, collisions are reported. Such incidents are considered software bugs. Negligibly small?

    Actually, in operation they may be more likely to be unique than a counter, as the counter may be reset for some reason or other, and you need tricks to make the counter work for multiple threads / processes.

    I never said pure counters are the best solution for every need of uniqueness. Neither did I say one should use bounded integers if counters are used. All I said was random numbers are not unique. And if simple tricks ensure absolute uniqueness (of counters or otherwise generated ids) across threads, processes, or even persistently, why not implement them (or better when possible, use a well known solution implementing them)?

    Note that I am a cryptographer.

    Duly noted.

  • Andrew A. Gill (unregistered) in reply to P

    Assuming one ID generated per microsecond, you're looking at keeping that javascript session open for 285 years.

    I don't even want to imagine what keeping a browser open that long does to your swap.

  • BernieTheBernie (unregistered) in reply to Ulysses

    @Ulysses Why don't you post your articles in the sidebar at what.thedailywtf.com? Let's have more fun there!

  • SomeGuy (unregistered) in reply to Chris

    This is why I love the "Refactor" features in modern IDEs. It removes the laziness barrier for renaming things properly.

Leave a comment on “I'm Sooooooo Random, LOL”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article