• (disco) in reply to boomzilla

    Significance may very and can be subjective, but a single call to a function vs 25 calls to a function makes a known difference. I would say the difference in processing something a single time vs 25 times is significant. Now, since it was for the automated test team, speed significance may not matter much. If this is something that was going into a production site, it does matter - especially since it appears the function is being called for every element --- so on calls to RAND alone (aside from array creation and string operations) your additional overhead is 24 * N repeated dynamic elements per item processed.

  • (disco) in reply to The_Bytemaster
    The_Bytemaster:
    If this is something that was going into a production site, it does matter

    Sure. Context is everything. Ultimately, it's 99% made up. We know this because it's on the front page.

  • (disco) in reply to Anthony_McLin
    Anthony_McLin:
    WTF #2 - Steven replaced the code instead of using this as a learning experience for Perl, exhibiting bad team leadership
    Name's Peri with an i. I guess Steven also uses a font too small for his age and consequently got an attack of Ruby shop Perlness envy and wanted to put her down.
  • (disco) in reply to another_sam
    another_sam:
    No, I read it as:

    http://www.nandos.com.au/the-story-of-peri-peri

    ... which is much tastier than what I'm currently eating for lunch.

    Only if it's xxx hot!

  • (disco) in reply to The_Bytemaster
    The_Bytemaster:
    so on calls to RAND alone (aside from array creation and string operations) your additional overhead is 24 * N repeated dynamic elements per item processed.
    That's the funny thing about modern computers: they don't behave as you expect. I tested the two versions earlier, and the call to `shuffle` alone is only 4.6 times slower than the call the `rand()` The real killer comes just from `('a'..'z').to_a`, which takes a monstrous 76% of the whole algorithm's time. Of course, that can be refactored into a constant since shuffle returns a new array rather than shuffling in-place. Doing that, and it's about 46:8:46 time spent in shuffle vs slicing vs joining the strings, which only gets to a 10x overhead total, rather than 24+.
  • (disco) in reply to anotherusername

    There's a difference between code complexity and algorithm complexity. Selection sorts have horrible algorithm complexity (O(n^2) but they're very easy to code in any language, minimize memory use, and minimize writes.

    It should be contextually obvious exactly which meaning of "complexity" blakeyrat meant.

  • (disco) in reply to BaconBits

    Yeah, I was :moving_goal_post:. That was partly just to yank his chain; however, like I also said, my original statement was that complexity and efficiency are usually directly linked, and a few counter-examples won't disprove that.

  • (disco) in reply to blakeyrat
    blakeyrat:
    QuickSort is a lot more complex than BubbleSort.

    Quicksort isn't stable, nor is it very efficient unless done in-place (which @Captain's code doesn't do; it also doesn't guard against the evil edge cases). Bubble Sort isn't even as good as Insertion Sort, even though they're both O(n2) and similar in complexity of code.

    Sorting is pretty much a solved area now. The best is probably Timsort, but it's a bastard complex algorithm by comparison with the other common ones.

    https://en.wikipedia.org/wiki/Timsort

  • (disco) in reply to BaconBits
    BaconBits:
    It should be contextually obvious exactly which meaning of "complexity" blakeyrat meant.

    You probably have better telepathy than us. :tropical_fish:

  • (disco) in reply to Troels_Larsen
    Troels_Larsen:
    What about just:

    require 'securerandom' SecureRandom.uuid

    But... but... we're the Devs Who Say NIH!

  • (disco) in reply to boomzilla
    boomzilla:
    You probably have better telepathy than us. :tropical_fish:

    If there's two possible meanings, and one is complete nonsense and the other is entirely cogent, then -- jokes aside -- why would you ever assume the former was the intended meaning?

  • (disco) in reply to BaconBits
    BaconBits:
    boomzilla:
    You probably have better telepathy than us. :tropical_fish:

    If there's two possible meanings, and one is complete nonsense and the other is entirely cogent, then -- jokes aside -- why would you ever assume the former was the intended meaning?

    I wouldn't, but I also wouldn't be surprised when blakey later yelled at me because he meant something completely different.

  • (disco) in reply to BaconBits
    BaconBits:
    If there's two possible meanings, and one is complete nonsense and the other is entirely cogent, then -- jokes aside -- why would you ever assume the former was the intended meaning?

    Because :trollface:, of course.

  • (disco) in reply to LaoC
    LaoC:
    Anthony_McLin:
    WTF #2 - Steven replaced the code instead of using this as a learning experience for Perl, exhibiting bad team leadership
    Name's Peri with an i. I guess Steven also uses a font too small for his age and consequently got an attack of Ruby shop Perlness envy and wanted to put her down.

    Blame TDWTF for choosing a font size and weight that makes lowercase i and l indistinguishable when bolded. Looks like they chose "OpenSans" and relied on browser rendering of bold styles instead of using one of the heavier weight variants of the font like OpenSans Semi-Bold or OpenSans Bold 700

    https://www.google.com/fonts/specimen/Open+Sans

  • (disco) in reply to Anthony_McLin
    Anthony_McLin:
    Blame TDWTF for choosing a font size and weight that makes lowercase i and l indistinguishable when bolded.

    Unable to reproduce. Bolded looks just fine:

    [image]

    In fact, the gap between the body and the dot in the i is actually more pronounced in the bolded version than it is in the regular version:

    [image]

    And before you ask, yes, my browser knows how to load fonts, and did load it correctly, and that's the default rendering and default size.

    Oh, and based on the CSS, it looks like they are using heavier weight variants for bold, not just relying on the browser rendering.

  • (disco) in reply to anotherusername

    Continuing the discussion from Random Ruby:

    LaoC:
    Anthony_McLin:
    WTF #2 - Steven replaced the code instead of using this as a learning experience for Perl, exhibiting bad team leadership
    Name's Peri with an i. I guess Steven also uses a font too small for his age and consequently got an attack of Ruby shop Perlness envy and wanted to put her down.

    Continuing the discussion from Random Ruby:

    anotherusername:
    Anthony_McLin:
    Blame TDWTF for choosing a font size and weight that makes lowercase i and l indistinguishable when bolded.

    Unable to reproduce. Bolded looks just fine:

    [image]

    In fact, the gap between the body and the dot in the i is actually more pronounced in the bolded version than it is in the regular version:

    [image]

    And before you ask, yes, my browser knows how to load fonts, and did load it correctly, and that's the default rendering and default size.

    Oh, and based on the CSS, it looks like they are using heavier weight variants for bold, not just relying on the browser rendering.

    No they aren't. They're using the same font face regardless of bold or not. The font clearly is rendering differently than the 700 weight variant on the Google hosted page at the same font size.

    Oh, and OSX renders antialiasing differently than Windows. The Google provided alternate font face for 700 weight variant renders much better at the font size used.

    DWTF (15px with bold tag): [image]

    Google Fonts (700 weight adjusted to 15px): [image]

    The Google Fonts rendering (same browser, same zoom level) of the 700 weight variant is more legible than the base font face with browser bold applied. The dot on the i is more circular, whereas TDWTF rendering squashes the dot and causes the gap to be harder to perceive.

  • (disco) in reply to Anthony_McLin

    Looks fine here on FF/Linux, too.

  • (disco) in reply to Anthony_McLin
    Anthony_McLin:
    No they aren't.

    Chrome: [image] Looks the same to me.

    Firefox: [image] Looks the same to me.

    Hell, look, I'll even dig up the ol' Internet Exploder to give it a go at it: [image] Hey look, it even got it right.

    Anthony_McLin:
    Oh, and OSX renders antialiasing differently than Windowswrong.

    Ah. Well, sounds like your computer's broken.

  • SomeName (unregistered)

    I think Steven's solution is not good. Sure, it's quick and easy. However, only 37,234 iterations later (~0.0037% of whole range) you will have 50% chance for your first collision. That's just horrible.

  • yes we can (unregistered) in reply to ixvedeusi

    In C++14 you can write 1'000'000'000

Leave a comment on “Random Ruby”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article