I believe we're talking past each other. Big O has nothing to do with "actual run time*. It doesn't care what about the number of inputs you have - just that you have them.
Mathematically, if n=1000 then log n is 10. 10 operations vs. 1000 is, theoretically and time complexity wise, faster.
Our disconnect is "actual" vs. "theoretical" and I want to stress again that Big O is purely theoretical. It's a technical adjective.
The Big O of an algorithm does not change based on data size. Even if your set had precisely 1 record in it - the code you write, if it loops over every item in the set (even if it's only one item) - is still O(n).
OP here. Agree that thinking about code is better than using a rule of thumb, but we need to start somewhere don't we? I tried to make it clear in the post that looping over n items within an n loop is n * n.
OP here - Big O notation is simply shorthand math. When you're discussing things in this way, time complexity and performance are the same thing. When you care about resource usage (memory etc) that's space complexity, which is different. Either way, they're good things to understand.
>So no I don't think you should use an O(log n) operation in place of an O(n) operation just because of Big O, what matters is which one is faster.
Mathematically the log n is always faster :). Realistically... well that would be a tough one to prove, even with caching, but I say go for it.
OP here. Big O is indeed "worst case scenario" always, the size of the data set doesn't matter. An O(n) operation doesn't care if the data is sorted - even if it's the first item as you suggest. When you discuss Big O it's always worst case.
OP here - as a matter of fact I try to do just this, starting with the database. I'm mostly a data person so I try to think through, as deeply as I can, what I should expect in every table - there has to be a sensible default and if I can't find one then I rethink my design. You'll probably disagree with me and grunt out another single sentence missive, which is fine, but I think it's worth taking some extra time and using Null as a bit of a warning. It's a crutch! A way to stop thinking and say "whatever I don't know what this value is supposed to be so... it's null. Let's go shopping!"
OP here - OP has checked out (and lived with) trinary logic. Just because you appreciate null doesn't mean it should be kept in programming languages and existing programs.
That there is a logical truism, isn't this fun?
Also: false means not true, zero is a number and null doesn't exist, by definition. We can model true/false/zero easily as they exist. Null is made up, so every language gets to think about what it means in an abstract made up way. Thus the pain, thus the post.
OP here - Yes that's the operation the question wasn't supposed to be a literal one, rather a consistency issue, which illustrates the larger point that different languages deal with null differently because it's not logical and therefore confusing and a pain in the ass :)
>it's not true to say they don't exist in other languages
Sounds good, waiting for an example to support this...
>It's also wrong to suggest that Null has no place in "logic". Boolean logic is one type of logic, but it's not the only type.
What other types did you have in mind? Given that we work as programmers in a world defined by true/false 1/0 logic, I think you might want to reconsider this blanket dismissal.
OP here - I was going to go into that - it's an interesting story. There are null references, as you say, but there's also the null object pattern and the null type. I decided to just focus on the idea of null, which all three of those things represent. A pointer points to a null space, a type represents a value that can optionally be null, and the object pattern allows you to deal with null in your program directly (like Ruby's nil).
So... yeah I dig it man :) I just left some things out to keep on a pace.
There are a lot debates about this and from my experience the biggest issue with running PostgreSQL on Windows is the “Windows Tax”: background processes and services you don’t need on a DB server soaking up resources. Windows Update comes to mind.
Thanks for the thoughts. As with many others I'll offer to you that my entire post is not about piracy. I've lived with piracy of my stuff for the last 7 years. Part of doing business.
The point of my post was a business profiting from pirates. The people who make the choice to forego bittorrent and just post the pirated stuff for a profit. THAT... is my point.
It's a little different than the simple theft of a TV, although yes you raise a decent point. As I've been saying to people: just a reasonable effort is all I ask.
There is a watermark on the entire video, and you can quite easily tell the voice changes from the intro to the main body (where I also mention Pluralsight a few times). A very, very simple review process would catch this.
Every video I submit to Pluralsight goes through a 3-step review (Peer, A/V, tech) and they catch any possibility of copyright infringement (though yes, things do get through).
Udemy is not doing anything this way, and have admitted it publicly (see the post, I updated it at the bottom). They flatly say that they rely on their users to tell them if something has a copyright problem.
Yes, I did. As did Troy. No reponse (now as then).
You entirely miss the point of the article - it's not about piracy, it's about a marketplace for pirated goods. That's what Udemy does. Sorry if I'm not nice about it.
Define "dangerous". Listen mate, if you make money on something and that something is stolen - you are responsible. Udemy created this marketplace for stolen things; people steal things and sell them there.
> the correct course of action is to sue
Nope. That's what people do in a dispute to solve the dispute. The correct course of action is something else entirely as we're talking about copyright law, not pissing on your neighbors orchids.
It's fractionally slower, true, because of the serialization hit (string to binary). The real juice comes from the GIN index - and if you apply it to specific columns instead of a complete document, you have a rocket ship on read.
The first function matches any call to it with an error - this is how (apparently) you pass error information on to the result. There's no graceful exit with an error.
The keyword list is pointless with an error function.
OP here - I wanted to offer a comparison of the SQL vs. the ReQL query. Indeed if ACID is something you need, then yes a horizontally-scaling DB is probably something that deserves longer thought.
This is a broader discussion to be sure, and it's been had. Given that PG now supports jsonb, it does mean that yes, we get to have these discussions more.
Mathematically, if n=1000 then log n is 10. 10 operations vs. 1000 is, theoretically and time complexity wise, faster.
Our disconnect is "actual" vs. "theoretical" and I want to stress again that Big O is purely theoretical. It's a technical adjective.