The Daily WTF: Curious Perversions in Information Technology

ixvedeusi · 2016-02-23 Reply Admin

accalia:
fun fact, if you are assigning that to an integer type variable, it ~~works~~ generates a warning "Implicit conversion from float to int".

FTFC++

Might be considered "works", but only if you ignore or disable warnings :doing_it_wrong:

accalia · 2016-02-23 Reply Admin

ixvedeusi:
I don't have a "power" operator for literals in C++, so it would be (1<<63)-1 for me.

so you don't have the ability to use the expression i used (which does become a compile time constant) except you have the ability to use the expression i used..... oooookay then.

ixvedeusi:
12_004_624_821_123

Also :moving_goal_post:, you just claimed to work in C++ that's not a valid numeric in C++

still if i must.

1.200462e13 if some loss of precision is acceptable (depending on the use case it may very well be acceptable)

or

12004624821123; //A bit over 12 thousand billion, limit for quibble grutzing the florble wobblers if not.

accalia · 2016-02-23 Reply Admin

ixvedeusi:
but only if you ignore or disable warnings :doing_it_wrong:

or put the explicit cast in like i suggested

ixvedeusi · 2016-02-23 Reply Admin

accalia:
Also :moving_goal_post:, you just claimed to work in C++ that's not a valid numeric in C++

See above:

ixvedeusi:
I wish python and C++ supported it :cry:

I was defending why I consider this a very useful feature, which you seemed to disagree on:

accalia:
the answer is: 1e9

Steve_The_Cynic · 2016-02-23 Reply Admin

MikeWoodhouse:
Simples: which is easier to read and understand, 1000000000 or 1_000_000_000?
Ruby just has slightly enhanced numeric constant parsing, which is occasionally useful.

That's OK, Fortran beat Ruby to it a by a long margin.

      INTEGER*4 I
      I = 1 000 000 000

See, aside from the first six columns, the Fortran compiler removes all spaces outside string literals. So you might say that Fortran's parsing is dis-hanced, but anyway.

      IF I = J THEN

The above looks like an IF statement, right? Well, no. It's an assignment, of whatever is in JTHEN to IFI. The IF statement would be:

      IFI.EQ.JTHEN

accalia · 2016-02-23 Reply Admin

ixvedeusi:
I was defending why I consider this a very useful feature, which you seemed to disagree on:

i do disagree with it, because there are perfectly good alternatives, Scientific notation and expressions take care of the vast majority and show the why of a number.

for example

432000000

can also be written

4.32e8

or it can be written

5 * 24 * 60 * 60 * 1000

which while longer better represents the derivation of the number (the number of milliseconds in five standard days)

and for numbers that cannot be represented effectively in scientific notation or by expressions there are these things called "comments" which developers these days seem loathe to use despite the utility and necessity of comments for building long term maintainable software.

adding literal formatting may be convenient, but it also leads to confusion as developers from different countries with different separator patterns

anotherusername · 2016-02-23 Reply Admin

ixvedeusi:
For my part, I find Peri's solution preferable in every way except performance.

So... the only way that probably matters, is the only way that it's preferable; in a bunch of ways that don't matter, you prefer Peri's inefficient code.

ixvedeusi:
In contrast, the "improved" version says "generate a random number between 0 and 999'999'999 (or is it 1'000'000'000? Who knows? Time to check the docs!)

You forgot to ask "Does it matter?" (it doesn't)

ixvedeusi:
But wait, for an ID we need a *string*

Why should you need a string? For an HTML element, yes, ID is a string. But for significantly many applications, ID is always a number. And again: "Does it matter?" (it doesn't)

ixvedeusi:
so why did we generate a *number*? How do we map that number to a string? Will leading zeros be included? what length will that string have? ...

"Does it matter?" (it doesn't)

ixvedeusi:
I find the IDs generated by Peri's code much more convenient. I find series of letters of fixed length much more easily recognizable and memorable than arbitrary very large numbers.

"Does it matter to a computer?" (it doesn't)

ixvedeusi · 2016-02-23 Reply Admin

accalia:
"comments"

Yeah sure, comments like: 13265436 // thirteen million two hundred fifty-fife thousand four hundred and thirty six or 10000000000 // one billion

anotherusername · 2016-02-23 Reply Admin

dkf:

anotherusername:
Or, heck, you could even use base-256.

That's fine internally, but can't be used as an ID string in an interface; many of those characters are not happy when passed through a GUI or URL.

That is true. I don't know what type of ID is required or how it'll be used, so I'm spitballing. Not everything will stick, depending on the requirements.

accalia · 2016-02-23 Reply Admin

ixvedeusi:

accalia:
"comments"

Yeah sure, comments like: 13265436 // thirteen million two hundred fifty-fife thousand four hundred and thirty six or 10000000000 // one billion

i'm sorry, was that supposed to be agreement or a counterpoint? i'm not sure what you're getting at there.

boomzilla · 2016-02-23 Reply Admin

anotherusername:
in a bunch of ways that don't matter,Peri's inefficient code

In what way that matters is the code inefficient?

ixvedeusi · 2016-02-23 Reply Admin

anotherusername:
only way that probably matters [citation needed]

Have you ever heard the term "premature optimization"?

The first and foremost thing that matters is always readability and maintainability. In both of these, Peri's solution is superior than the "embettered" version. If you can show that this code (which I'd expect consumes a small fraction of the whole processing time for the page, no matter which implementation is used) has a significant performance impact, then you may consider replacing it with the new, "clever" solution.

ixvedeusi · 2016-02-23 Reply Admin

accalia:
agreement or a counterpoint?

I thought that would be clear once you counted the zeros on that "billion"...

dkf · 2016-02-23 Reply Admin

accalia:
the number of milliseconds in five standard days

And if you mean 5 days, there's not much to beat 5 days or some object that captures that notion. The advantage with that is that you can handle DST changes in ways that people expect…

giammin · 2016-02-23 Reply Admin

asp.net sessionid is generated with RNGCryptoServiceProvider as seed for random

Steve_The_Cynic · 2016-02-23 Reply Admin

ixvedeusi:

accalia:
agreement or a counterpoint?

I thought that would be clear once you counted the zeros on that "billion"...

Yeah, there aren't enough.

accalia · 2016-02-23 Reply Admin

dkf:
And if you mean 5 days,

i mean five STANDARD days.

no DST BS, no timezones BS, just five lots of twenty four lots of sixty lots of sixty lots of one thousand milliseconds

dkf · 2016-02-23 Reply Admin

accalia:
no DST BS, no timezones BS, just five lots of twenty four lots of sixty lots of sixty lots of one thousand milliseconds

Ah. You mean exactly 120 hours. That's Different. It's also a pretty rare requirement; most people when they ask for that sort of length of time actually want the one based on the civil time adjustment.

I know you know this, but this is an area where saying what you actually mean is important.

anotherusername · 2016-02-23 Reply Admin

boomzilla:

anotherusername:
in a bunch of ways that don't matter,Peri's inefficient code

In what way that matters is the code inefficient?

Efficiency is the way that matters, and the code isn't efficient. Since the article wasn't strong in the way of design requirements, but indicates that any kind of string or number could be used equally well, that leaves efficiency and readability as the only two requirements.

Both ways are equally readable. I'll give that to even Peri; her code is easy to read. It's just not clear why it should do what it does, when obviously a big random number would work just as well. So that leaves efficiency, and shuffle is a really poor design choice when all you want is a big random number.

ixvedeusi:
The first and foremost thing that matters is *always* readability and maintainability. In both of these, Peri's solution is superior than the "embettered" version.

No, it's not. It is ridiculously obvious what rand does, aside from your nail-biting about the endpoints (hint: rand(n) generates a random integer from 0 to n-1, exactly like you should expect it to... not that it even matters for this application).

ixvedeusi:
**If** you can show that this code (which I'd expect consumes a small fraction of the whole processing time for the page, no matter which implementation is used) has a significant performance impact, **then** you may consider replacing it with the new, "clever" solution.

You've got that exactly backward. There's nothing "clever" about creating a big random number and using it as an ID when you do it in the most obvious way; Peri's code is a "clever", and less efficient, way to generate a big random number.

Even if you need to generate a string, as I said, you could use hex, or base-36, depending on whether you want 64 bits to fit into an exact number of digits; you could even pad it to an exact number of digits, if that matters. Based on the information in the article, it didn't appear to matter, but even if it does matter you could still do that with rand more simply and more efficiently than Peri's code.

boomzilla · 2016-02-23 Reply Admin

anotherusername:
Efficiency is the way that matters, and the code isn't efficient.

How are you measuring efficiency? How is her's deficient? You're dodging the question, unless you mean that you're not satisfied except with the ultimate fastest smallest footprint code.

anotherusername:
So that leaves efficiency, and shuffle is a really poor design choice when all you want is a big random number.

You're begging the question that this is all that's desired. And you're still worshiping the false god of premature optimization.

PleegWat · 2016-02-23 Reply Admin

Both 86400 and 24 * 60 * 60 occur multiple times in our codebase. Also this, which I swear made sense at the time, and is used as a tag in debug logs:

        $nRand    = 362797; // 36^6/6000, never more than 6 characters
        $nReqID   = date( "is" ) * $nRand + rand( 0, $nRand );
        $strReqID = base_convert( $nReqID, 10, 36 );

        return $strReqID;

anotherusername · 2016-02-23 Reply Admin

boomzilla:
How are you measuring efficiency?

Seriously? How do you usually measure code efficiency? Memory or CPU; take your pick, because in this case, it's less efficient with regards to both.

boomzilla:
How is her's deficient?

It's over-complicated. The requirement was for a random ID; a large random number would have been perfectly adequate. Not her Rube Goldberg 5-step machine to generate one.

boomzilla:
You're begging the question that this is all that's desired. And you're still worshiping the false god of premature optimization.

You're saying that any time there are two ways to do something and both yield equally good results, then you must by definition favor the more complex way or else you're premature optimizing.

Also, why did you just type that and press Reply? I see no Wordpad documents, no faxes, no printed digital photos, no wooden table.

boomzilla · 2016-02-23 Reply Admin

anotherusername:
Seriously? How do you usually measure code efficiency? Memory or CPU; take your pick, because in this case, it's less efficient with regards to both.

And why should I care?

anotherusername:
You're saying that any time there are two ways to do something and both yield equally good results, then you must by definition favor the more complex way or else you're premature optimizing.

No, but the way you keep going on about efficiency is throwing up all sorts of red flags.

Steve_The_Cynic · 2016-02-23 Reply Admin

PleegWat:
Both `86400` and `24 * 60 * 60` occur multiple times in our codebase.

I've worked in environments where those two weren't equivalent. That is, where ```86400 == 24*60*60``` was FALSE.

In C, that is. On a 16-bit system, where unadorned integer-valued constants are int if possible (normal rule of C). So 86400 is of type long because it is too big to be an int, but the three numbers multiplied together are of type int because they are small enough in magnitude. The result of the multiplication is also an int by the normal rules of the language, but one that has the value 20864 instead of the naively-expected 86400.

As a result, my fingers itch every time I type 24*60*60 instead of 24L*60*60...

anotherusername · 2016-02-23 Reply Admin

boomzilla:
And why should I care?

Because it's the only significant difference between the two functions.

boomzilla:
No, but the way you keep going on about efficiency is throwing up all sorts of red flags.

Well, I'm comparing two bits of code that are exactly equal in every way that mattered except that one of them is flat simple and the other is way more complex, takes multiple steps, and throws away most of its work in the end. If there's a reason why the simple code using rand won't work, I haven't heard it yet.

Choosing the simpler code is not premature optimization; it's common sense.

boomzilla · 2016-02-23 Reply Admin

anotherusername:
Because it's the only significant difference between the two functions.

But what makes it significant? Different? Sure. Significant? Doubtful.

anotherusername · 2016-02-23 Reply Admin

It's the most significant difference between them.

boomzilla · 2016-02-23 Reply Admin

anotherusername:
It's the most significant difference between them.

If you really think so, then there's no good reason to change back to rand().

accalia · 2016-02-23 Reply Admin

dkf:
That's Different.

.... what does a standard day mean if not 24 hours?

dkf · 2016-02-23 Reply Admin

The O!M!G! Date And Time Handling Is Hard Thread thread must be around here somewhere…

anotherusername · 2016-02-23 Reply Admin

boomzilla:

anotherusername:
It's the most significant difference between them.

If you really think so, then there's no good reason to change back to rand().

No good reason? I just named one.

Complexity requires reason. Simpler is generally better. If no reason exists to require complexity, then unnecessary complexity is bad.

anotherusername:
exactly equal in every way that mattered except that one of them is flat simple and the other is way more complex, takes multiple steps, and throws away most of its work in the end

Given that, I will always say that the flat simple code is better, unless there's a good reason to not choose it.

boomzilla · 2016-02-23 Reply Admin

anotherusername:
Complexity requires reason. Simpler is generally better. If no reason exists to require complexity, then unnecessary complexity is bad.

Well, now, this is a different story. I'm not convinced that the level of complexity here is very significant (though reasonable people can certainly disagree about this), but this is a very different reason than efficiency. Now that you've backed away from efficiency being the only significant difference, I'm happy.

anotherusername · 2016-02-23 Reply Admin

boomzilla:
complexity ... is a very different reason than efficiency

Do you not agree that a process which is overly complex is usually less efficient as a result?

I don't see them as being very different.

boomzilla · 2016-02-23 Reply Admin

anotherusername:
Do you not agree that a process which is overly complex is usually less efficient as a result?

It seems likely, but then searching a list is a less complex than using a hash map. And the efficiency in that case depends on other things, too. And both may be efficient enough that the choice doesn't matter.

Matt_Westwood · 2016-02-23 Reply Admin

ixvedeusi:
Yeah sure, comments like:13265436 // thirteen million two hundred fifty-fife thousand four hundred and thirty sixor10000000000 // one billion

Nobody's really addressed the elephant in the room here: the fact that the original 1 billion we are wetting our knickers over is nothing more and nothing less than a number that someone pulled out of their arse.

anotherusername · 2016-02-23 Reply Admin

Yes... well, that's what I was trying to point out originally, when I said:

anotherusername:
if a larger space of values is needed, then the number can simply be increased.

and:

anotherusername:
Yes, the overcomplicated version gives around 6.3×10¹⁰ possibilities, but that's really irrelevant. If you need the larger value space, just change the `rand` argument from `10**9` to `6.3*10**10`... now they're mathematically equivalent, and the `rand` version is still a lot simpler and less complex.

Basically, if ten hundred million isn't a big enough ass-number for anyone, just make it bigger. Done. Next.

Captain · 2016-02-23 Reply Admin

How are you measuring efficiency? How is her's deficient? You're dodging the question, unless you mean that you're not satisfied except with the ultimate fastest smallest footprint code.

Her code consumes (at least) 63 bits of entropy to produce like 24. The rest of the entropy is lost as heat.

A random number generator would use 64 bits of entropy to produce an Int64. It's also probably easier to read rand(MAX_INT) than to read and understand an algorithm (regardless of how simple it is).

Neither would make me say "WTF," but real improvements could be made at very low cost.

blakeyrat · 2016-02-23 Reply Admin

anotherusername:
Do you not agree that a process which is overly complex is usually less efficient as a result?

QuickSort is a lot more complex than BubbleSort.

boomzilla · 2016-02-23 Reply Admin

Captain:
Neither would make me say "WTF," but real improvements could be made at very low cost.

And no one would ever notice. The time refactoring would be better spent on writing TDWTF comments.

Captain · 2016-02-23 Reply Admin

It is? I just write it like

quicksort [] = []
quicksort (p:xs) = (quicksort less) ++ [p] ++ (quicksort more)
  where less = filter (< p) xs
        more = filter (>= p) xs

anotherusername · 2016-02-23 Reply Admin

blakeyrat:

anotherusername:
Do you not agree that a process which is overly complex is usually less efficient as a result?

QuickSort is a lot more complex than BubbleSort.

Not in terms of big-O it's not. And it's really not that hard conceptually, either, once you know how to do it.

blakeyrat · 2016-02-23 Reply Admin

anotherusername:
Not in terms of big-O it's not.

Big-O isn't a measure of complexity.

anotherusername:
And it's really not that hard conceptually, either, once you know how to do it.

You could just say, "oh yes, Blakeyrat, that is a good counter-example to my point. Well-played!" instead of making up shit in an attempt to save face.

More examples: ZIP compression is more complex than RLE compression. PNG compression is more complex than TIFF compression. Microsoft Office's UI is a lot more complex than TeX's. Probably a million others examples if I took a few minutes to think about it.

Captain · 2016-02-23 Reply Admin

Except it's not a good counter-example, since it's trivially easy to describe the algorithm:

put the stuff that's smaller than the variable in front of the variable, and sort it, put the variable down, and put the stuff that's larger than the variable and sort it.

anotherusername · 2016-02-23 Reply Admin

blakeyrat:

anotherusername:
Not in terms of big-O it's not.

Big-O isn't a measure of complexity.

:wtf:?

https://en.wikipedia.org/wiki/Computational_complexity_theory#Complexity_measures:

The complexity of an algorithm is often expressed using big O notation.

blakeyrat:
You could just say, "oh yes, Blakeyrat, that is a good counter-example to my point. Well-played!" instead of making up shit in an attempt to save face.
More examples: ZIP compression is more complex than RLE compression. PNG compression is more complex than TIFF compression. Microsoft Office's UI is a lot more complex than TeX's. Probably a million others examples if I took a few minutes to think about it.

Yes Blakeyrat, very good counter-example. I will concede that you've proved once and for all that

anotherusername:
*usually*

does not mean "always".

[image]

blakeyrat · 2016-02-23 Reply Admin

Whatever, I guess I'm just a stupid moron idiot as always.

Tsaukpaetra · 2016-02-23 Reply Admin

blakeyrat:
I guess I'm just a stupid moron idiot

Don't call yourself an idiot! That's not funny!

anotherusername · 2016-02-23 Reply Admin

blakeyrat:
Whatever, I guess I'm just a stupid moron idiot as always.

I think you're confusing me with some other people. I only disagree with you when I'm pretty sure you're wrong, and it's not just to piss you off. I promise.

FrostCat · 2016-02-24 Reply Admin

Zemm:
Is it just me or does anyone else keep reading this name as Perl?

No, I keep thinking of Perpugilliam.

The_Bytemaster · 2016-02-24 Reply Admin

In this case, though, it is a matter of performance and the general rule of not making the computer do more work than required. Simply lowering the number of calls to RAND from 25 to 1 will be much more efficient, aside from all of the other memory allocations.

Though, from reading you post, it appears sarcastic. It is not a "which is right" scenario... it is a "teaching moment". Of course, if they actually required 100% uniqueness, they both need to be taught.

another_sam · 2016-02-24 Reply Admin

Zemm:

PaulaBean:
Peri

Is it just me or does anyone else keep reading this name as Perl?

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.

Random Ruby

Leave a comment on “Random Ruby”