AuburnMathTutor 37 Junior Poster

Just write your own code, using a stack like it's meant to be used.
You have your search stack. Empty it into a temp stack until you find what you want or hit the end.
Then take your temp stack contents and empty into the search stack. Voila! O(n) search algorithm for a stack.

You probably should do the same for a queue. It's kind of weird to be (mis)using data structures like this. You only need the search queue and a reference to the first thing.

Make a record of the first thing in the queue in the beginning.
Dequeue and enqueue every element until you get back to the very first thing initially in the queue.
If you happened to come across your search thing, excellent. Make a note of this.

O(n) search algorithm for a queue.

Note that O(n) is as good as you can hope to do on an unsorted collection of things anyway, and since stacks and queues aren't sorted according to the data but according to the order they are inserted, the find() thing can only do better by a constant factor. Don't worry about it.

AuburnMathTutor 37 Junior Poster

Hey,

I am pretty sure some software is pretty portable like you're asking, but I really don't know. You might have more luck in the "Hardware and Software" subforum... Probably a Linux area there. (This isn't a great place for the question.) Good luck.

AuburnMathTutor 37 Junior Poster

For me, it has nothing to do with society. Screw society. If I want to go buy a gun tomorrow to shoot holes in a tree in my backyard, that should be my right. A few maniacs running around blowing each others' heads off doesn't invalidate that right.

There's already gun regulation for convicts and other similarly dangerous elements of society. Better they have the means to show themselves for what they really are. Some Milton perhaps to convince the Brits:

"None can love freedom heartily, but good men; the rest love not freedom, but licence."
"I made [man] just and right, Sufficient to have stood, though free to fall."

Let's not go playing God, shall we gentlemen?

AuburnMathTutor 37 Junior Poster

Uh, I think it's normally customary for the node class and the linked-list class to be made into separate entities. Without looking too hard at your code, this could be part of the problem. In any event, it's dangerous and - frankly - weird that every node contains a reference to the front, as well as the length of the list... since all nodes do.

In other words, if you are trying to learn about linked lists for an interview, this is in the danger zone. Are you familiar with the "standard" definition of a linked list structure? I'm very serious.

Looking at your code in somewhat more detail, the problem seems to be that there are several "fronts" and there's no clear indication you're ever using the correct one, or that the correct front is ever being established. This problem is corrected by correctly separating the ideas of "node" and "list". Please let me or others know if reference material on constructing and manipulating linked lists is required.

AuburnMathTutor 37 Junior Poster
#include <iostream>
using namespace std;
int main(int argc, char* argv[])
{
   char Ans;

   cout << "Keep Going? ";
   cin >> Ans;
   if(Ans=='y' || Ans=='y') main(argc, argv);
}

An idea, anyway. Otherwise, a do-while will work fine.

#include <iostream>
using namespace std;
int main(int argc, char* argv[])
{
   char Ans;

   do
   {
   cout << "Keep Going? ";
   cin >> Ans;
   } while (Ans=='y' || Ans=='y');
}
AuburnMathTutor 37 Junior Poster

My question is: does the diff function above always return 0 for every floating value of x on any computer, and is there something in the implementation of the builtin round function which guarantees stability for int(round(x)) ? This does not seem to be documented in the official doc. What do you think of this ?

If it's not documented in the official documentation, use your function and forsake int+round. In fact, if you're not sure, or you think somebody reading your code later might not be sure, just go ahead and use your function. What's the harm? Performance? You're using Python.

AuburnMathTutor 37 Junior Poster

IQ tests probably contain very good examples of questions which could be used to assess the potential of a programmer. What kinds of questions you include and which you discard will be an interesting decision, but a few come to mind...

All blargs are toogs, and some toogs are larts, therefore some larts are blargs.
True? False? Neither?

A few alien transmissions are intercepted. "Bleep quor mite sto" is translated as "Take me to your leader". "Quor sin sto ted" is translated as "You leader is good". "Quor nikste sin mite" is translated as "Your goodness pleases me." What is probably the best translation of the word "sto"?

Jim is shorter than Bob, who is taller than Anne but shorter than Tom. If Tom is the tallest, what can we say about the relative heights of Jim and Anne?

Give the next number in the sequence. 1, 2, 4, 9, 23, 64, ___.

Which of the following words is least like the other?
Gold
Euros
Money
Dollars

Someone spent the following amounts of money on different drinks. Did they spend an odd number of US coins, an event number, or can it not be uniquely determined?
- 75 cents
- 89 cents
- 77 cents
...

Let a $ b = (a+b)/ab. Does (a $ b) $ c = a $ (b & c)? Does a $ b = b $ a? Is there …

AuburnMathTutor 37 Junior Poster

^ Ninja'd me.

AuburnMathTutor 37 Junior Poster

I thought C/C++ would offer a few benifits beyond pure assembler. Apparently I was wrong.

Languages that don't have this behavior make a great many common programming tasks harder, not easier.

AuburnMathTutor 37 Junior Poster

One particularly neat solution is to put the code in a function...

def getYN(prompt='> ', errormsg='This option is not available.'):
    result = raw_input(prompt)
    if result == 'y' or result == 'n':
       return result
    else:
        print errormsg
        return getYN(prompt, errormsg)

This has the added benefit of crashing the program if the user refuses to enter 'y' or 'n' about 1000 times.

AuburnMathTutor 37 Junior Poster

"A civil and thought provoking debate"
- Yes, you definitely seemed to be the type for that, judging by your previous post, with the requisite irrelevant link to Wikipedia and lack of constructive contribution to my earlier post. And it's probably for the best we don't continue, because I actually don't speak any English, except what I have typed in this discussion and this sentence explaining it. Je suis le roi de France.

AuburnMathTutor 37 Junior Poster

^ More like a slippery slope, if that, but still.

And that being said, I don't think the comparison is so fallacious; he says that there is no reason a programming language should resemble natural language, and machine language is - IMHO at least - about as far away from natural language as you can get. I'd argue that it's not such a gross misrepresentation of his opinion at all. He says "There is no reason to make programming languages look like natural languages." I pointed out that we started with a language that was much farther from natural languages, i.e. machine language, and have since developed languages that are more similar in structure to English. Of course, I didn't make explicit the reason why we moved away from machine language - that should be obvious to anybody in a CS forum - but that reasoning completes a *valid* logical argument... perhaps not a correct argument, but if you want to go after the hypotheses than feel free.

A straw man would be to say that, if what he was saying were true, then nobody should use natural languages. That's a misrepresentation of what he said because he's talking about programming languages, not all languages.

But by all means, continue to post and I will continue to educate you, Radical Edward. And thanks for your valuable contribution to the discussion.

AuburnMathTutor 37 Junior Poster

^ Then why do we use words like "for", "while", "if", "then", etc.? Might as well use "f", "w", "i", "t", etc. And why use infix notation? Why not just do everything in postfix or prefix; that makes compiling easier, and no need for parentheses. In fact, better yet, why not just write everything in freaking machine language. No ambiguity there.
So in summary I completely disagree that there is no reason to make programming languages look like natural languages; there is, and the fact that we have languages with mnemonics and high-level-languages with English/Math like constructs is a testament to this fact.
And FWIW I'm using "ambiguous" in the technical sense of the word, not the usual sense.
And if you don't think that programming languages mimic English a little bit, consider the following programs and honestly tell me that a guy off the street would understand them equally well:

Program #1
if a < b then c = a + b else c = a - b

Program #2
mov eax, a
cmp eax, b
jge noadd
add eax, b
mov c, eax
jmp done
noadd:
sub eax, b
mov c, eax
done:
(for instance)

Program #3
01101010011010100110101001101010011010100110101001101010011010100110101001101010011010100110101001101010011010100110101001101010
(for instance)

Sorry, I don't see any merit in your POV at all.

AuburnMathTutor 37 Junior Poster

There is a balance between making programming languages look like natural languages and having them be as unambiguous as possible. A lot of Lewis Carrol's work should make it obvious that slight differences in English syntax can lead to quite different semantics. In fact English is not as forgiving as most people would have you believe; can you tell me what's wrong with the following sentence?

Mary didn't yet know if he will confront Bob and I about his prior indiscretions.

Hint: There's a lot wrong with that sentence.

AuburnMathTutor 37 Junior Poster

^ Right you are, invisal. The big-Oh time complexity of (1) is in fact O(n). It would be O(nlogn) if it were the following:

m := n
while n > 0 do
   L(m);
   n := n / 2

And the answers for (2) and (3) are right on the money. Good job!