We have problems proved to be in classes P, NP, co-NP, NP-Complete, and NP-Hard. These problems have their time complexities deduced too. I am wondering if I am missing any key information on the topic.
One of the standard tricks for solving this sort of problem is what's called using an "oracle". Suppose we could ask the oracle a question about a specific class of problems, and in one step it would answer "yes" or "no". It becomes reasonable to ask "What sort of problems are in P for a machine with this oracle"? "What sort of problems are in NP for a machine with this Oracle.
It has been shown that there are oracles for which P=NP. It has been shown that there are oracles for which P≠NP. Most of the techniques we know for proving hardness should give the same result, no. matter what oracle is used.
Related
I was reading some interesting questions about the topic "Can we make a program that, given a particular sequence, produces the next terms", like this one, and I really like the detailed answer of this one. I understand that the answer is "That's impossible without more restrictions", and that given some restrictions (polynomials, rational function or boolean map) we know some good algorithms, as the second answer I linked explains.
Now, a natural question is how much can we solve, trying our best even if we can't always solve it, to answer the original, general question. What I usually do when facing a hard sequence is trying to see if it's in OEIS, and if it seems to be there, seeing if there is any formula or algorithm to produce it in there. You can download a small version of OEIS with the first terms of each sequence, and you can make queries to find formulas or maple algorithms for a particular sequence. My question is, do you think it's feasible to download a small version of OEIS that includes, with the first terms, a little algorithm to produce it?
The natural problem here is that I haven't seen any link to download the entire database of OEIS with all the details, which maybe deserves its own question. Even if we had this, you need to read the formulas/algorithms (that can be written in different languages, from what I've seen) and interpret them correctly. But I thought maybe someone here knows how to solve this, in any case thanks in advance.
You could, as you note, download the sequences and their A-numbers from the link mentioned here: https://oeis.org/wiki/Welcome#Compressed_Versions
After searching that and finding one sequence (or a small number of sequences) of interest, you could scrape the respective page(s) for formulas. There are specific fields for Maple and Mathematica, which may be helpful, and otherwise, an entry in the PROGRAM field should include identifying information when it is not one of the standard languages with its own field in the database. See: http://oeis.org/wiki/Style_Sheet
Unofficially, but with the interests of the OEIS in mind, I would not recommend trying to download or scrape the OEIS in its entirety. Whether it's one person, or a whole host of people, we would certainly recommend using the compressed version of the database to identify sequences of interest by A-number first, then pulling their entire entry by scraping the site or querying the OEIS using methods that you have already mentioned: Programmatic access to On-Line Encyclopedia of Integer Sequences
If this sounds laborious, perhaps an alternative is the Wolfram Cloud, which actives this through other means. For example, you can navigate to the cloud (you may have to register just to get access) at: https://www.wolframcloud.com/
Typing in something like FindSequenceFunction[{1, 2, 3, 5, 17, 305, 34865}] will give you a formula, if Wolfram/Mathematica can find one. The documentation for FindSequenceFunction can be found here: https://reference.wolfram.com/language/ref/FindSequenceFunction.html
Wolfram/Mathematica can also invoke the OEIS using packages like the one described here: https://mathematica.stackexchange.com/questions/40/is-it-possible-to-invoke-the-oeis-from-mathematica
From day 1 of my programming career I have always been told hard-coding/magic numbers or literals are bad. One should avoid it. I followed this principle even in Stored Procedures in SQL Server.
Recently I came across this article by Ian Jose and it came as a rude shock to me. He has nicely explained the problem with this practice in SQL Server Stored Procedures with evidence. Ian has demonstrated that the performance takes a big hit with this approach.
See this article by Chris Hedgate to know what my reaction was when I read Ian's blog.
I understand if it is a smaller code snippet and the hard coded value is not used more than once, then some people take the liberty keeping them instead of declaring them as variables or constants and using the variables or constants instead. But it seems hard coding should be encouraged in Stored Procedures?
I did find a similar discussion on SO but that thread isn't evaluating the performance hit, rather it is talking about how to avoid hard-coding, something that even I used to consider myself very good at. But now after reading Ian's blog, I feel I am adding more problem there than solving it.
I would like to request the other experts to share their experience on this topic as this seems to be a violation of fundamental programming guidelines. Could this be because of the way SQL Server is designed? Is this not an issue in Oracle or MySQL? Oracle in fact suggest these 3 nice approaches to avoid hard coding.
Edit: Thank you all for your valuable comments. I would like to request for some more statistics, to constructively challenge Ian's numbers. Just to conclude that avoiding hard coding does not have that bad an impact on performance, which is what Ian has demonstrated. I am sorry if I am asking for too much and eagerly look forward to your responses.
I had also opened a thread on LinkedIn as I didn't get many responses here at first. For people who have the same confusion as me can refer to that for some more info.
Here's how I understand the problem:
Hard coded literals in a DBMS (SQL / Oracle) do improve performance.
However, the second time you execute the query, where the hard coded literal changes, it must be recompiled, which fills up the cache.
This means that the cache can't be used efficiently for the rest of the DB.
So, whilst:
SELECT * FROM X WHERE Y = '123'
Might be slightly faster than:
SELECT * FROM X WHERE Y = #myVar
If you then want to do:
SELECT * FROM X WHERE Y = '234'
The DBMS sees that as a different query. This then fills up the cache, meaning that the next time you issue a query that should be cached, it will be slower.
Parameters are better, since the same plan can be used for multiple parameter values. An SP in SQL Server is a contract with the app writer that one plan can be used for multiple invocations. It has been eight years since I worked in SQL Server, and much may have changed. However, the optimizer will "sniff" the parm value for optimization purposes. It is nice if that value is "typical". Unfortunately, recompile can happen at any time, and hence with any parameter value. Plan guides are one technique to make an application immune to this danger. There are likely other techniques as well.
This is something that has always bothered me. Wouldnt it make more sense to have the FROM clause come before the SELECT? Whenever Im writing sql, especially with joins, I always figure out the FROM clause first and then write the SELECT.
Plus, putting the FROM first would allow for better intellisense inside the editor.
Does anyone know what the reasoning was to have SELECT come first? Am I only one who is bothered by this?
Yes it is strange and counterintuitive. Hugh Darwen theorises about how this state of affairs came about:
Do you take SELECT-FROM-WHERE for
granted, or do you, like me, find it
rather curious that the System R team
should have spurned the normal way of
writing expressions of arbitrary
complexity in favour of something
utterly idiosyncratic and, one might
say, rather dictatorial...?
The fact is that in the 1960s various
scripting languages (as we tend to
call such things these days) had come
about for the purposes of report
generation, especially ad hoc report
generation. We had one such language
in the prerelational DBMS called
Terminal Business System (TBS) that I
worked on for IBM from 1969-77. Our
language required the user to specify
the required report in a series of
steps that had to be given in the
prescribed order...
A somewhat similar but much more
sophisticated report generator was
later developed by IBM in the US, as
part of a product called (prosaically,
as was IBM's style in those days)
Generalized Information System
(GIS)... when I first looked at SQL,
my immediate reaction was "Oh no!
Son of GIS? Please not that!" I
might have been quite wrong about
this. The similarity I perceived
might have been illusory and even if
it was not, I have no firm evidence
that anybody in the System R team was
familiar with GIS. The fact remains
that the general style of a fixed
order of actions was the order of the
day at the time. I postulate that
SQL's SELECT-FROM-WHERE arose out of
this fashion.
From HAVING a Blunderful Time
The syntax was to resemble English.
I've been working in Sql server jobs since 2 years now. Although I like it, sometimes I get the feeling that at certain times, I stall too much on some tasks, and I seem to be discouraged easily from things that involve relatively simple logic. It's like, at some point I must repeat a logical condition inside my head more than 2 or 3 times in order to understand it completely.
I have the feeling that this might be of my lack of math knowledge. Can anyone please let me know what area of mathematics I can study, that would improve my Sql server coding skills?
Thank you.
The field of maths most likely to be useful to you is Boolean logic
Set Theory is good for second place however it will often go into more detail that you are likely to need/use in understanding most sql queries.
A quick cheat that you may find useful is if you feed a boolean expression into wolfram alpha it will spit out a truth table for you which some find a much easier way of visualising the expression.
http://www.wolframalpha.com/input/?i=a+or+not+b
I recommend you study symbolic logic.
I'd suggest reading up on Set based Math.
See this link: http://weblogs.sqlteam.com/jeffs/archive/2007/04/30/thinking-set-based-or-not.aspx
Set theory helped me somewhat. Studied it in college years before I got into SQL, but being able to think of a bunch of numbers as a semi-amorphous blob of data and not as an ordered list of items really helps.
Get a copy of this book. It should prove to be most useful: The Art of SQL, by Stephane Faroult.
This is a dangerous question, so let me try to phrase it correctly. Premature optimization is the root of all evil, but if you know you need it, there is a basic set of rules that should be considered. This set is what I'm wondering about.
For instance, imagine you got a list of a few thousand items. How do you look up an item with a specific, unique ID? Of course, you simply use a Dictionary to map the ID to the item.
And if you know that there is a setting stored in a database that is required all the time, you simply cache it instead of issuing a database request hundred times a second.
Or even something as simple as using a release instead of a debug build in prod.
I guess there are a few even more basic ideas.
I am specifically not looking for "don't do it, for experts: don't do it yet" or "use a profiler" answers, but for really simple, general hints. If you feel this is an argumentative question, you probably misunderstood my intention.
I am also not looking for concrete advice in any of my projects nor any sophisticated low level tricks. Think of it as an overview of how to avoid the most important performance mistakes you made as a very beginner.
Edit: This might be a good description of what I am looking for: Create a presentation (not a practical example) of common optimization rules for people who have a basic technical understanding (let's say they got a CS degree) but for some reason never wrote a single line of code. Point out the most important aspects. Pseudocode is fine. Do not assume specific languages or even architectures.
Two rules:
Use the right data structures.
Use the right algorithms.
I think that covers it.
Minimize the number of network roundtrips
Minimize the number of harddisk seeks
These are several orders of magnitude slower than anything else your program is likely to do, so avoiding them can be very important indeed. Typical methods to achieve this are:
Caching
Increasing the granularity of network and HD accesses
For example, B-Trees are absolutely ubiquitous in DB systems because the reduce the granularity of HD access for on-disk index lookups.
I think something extremely important is to be very carefully on all code that is frequently executed. This is normally the code in critical inner loops.
Rule 1: Know this code
For this code avoid all overhead. Small differences in runtime can make a big impact on the overall performance. E.g. if you implement an image filter a difference of 0.001ms per pixel will make a difference in 1s in the filter runtime on a image with size 1000x1000 (which is not big).
Things to avoid/do in inner loops are:
don't go through interfaces (e.g DB queries, RPC calls etc)
don't jump around in the RAM, try to access it linearly
if you have to read from disk then read large chunks outside the inner loop (paging)
avoid virtual function calls
avoid function calls / use inline functions
use float instead of double if possible
avoid numerical casts if possible
use ++a instead of a++ in C++
iterate directly on pointers if possible
The second general advice: Each layer/interface costs, try to avoid large stacks of different technologies, the system will spend more time in data transformation then in doing the actual job, keep things simple.
And as the others said, use the right algorithm, try to optimize the algorithm complexity first before you optimize the algorithm implementation.
I know you're looking for specific coding hints, but those are easy to find: cacheing, loop unrolling, code hoisting, data & code locality, blah, blah...
The biggest hint of all is don't use them.
Would it help to make this point if I said "This is the secret that the almighty Powers That Be don't want you to know!!"? Pick your Powers: Microsoft, Google, Sun, etc. etc.
Don't Use Them
Until you know, with dead certainty, what the problems are, and then the coding hints are obvious.
Here's an example where many coding tricks were used, but the heart and soul of the exercise is not the coding techniques, but the diagnostic technique.
Are your algorithms correct for the situation or are there better ones available?