I had this in an interview (back '96). Came up with a linear time constant space solution: create a new node, push it on the front, reverse the list, check if the 1st node is the same one you pushed, if so it has a loop, otherwise it doesn't. The downside is you need to reverse again to get the original list.
Another answer is to mark nodes using the low bits of the next pointer. Also linear time, but also requiring clean up. I can see how not knowing c would cause people to think this question was somewhat unfair, but I didn't see it that way.
If your list is laid-out a contiguously in memory as structs with both next and prev ptrs, you can visit each member using ptr arith and switch the values without actually walking the list using next and prev. Ditto if there's an underlying data-structure involved such as an array.
You allocate an array of objects that contain pointers, then link them together. It does not have all of the typical benefits of a linked list (in particular, there's a hard max size and may require a fixed size, depending on just what you're doing to it here) but it does allow O(1) reordering elements for a list-order traversal, while also allowing a linear traversal through memory.
If the linked list has a loop, but you don't know it, how do you figure out the length of the list to allocate enough space for your array? How do you copy the list into the array without traversing the list? How do you traverse the list without hitting the loop and looping infinitely?
If you know that all the elements in the loop are already in the array then traversing it is easy. Of course, if you have an upper bound for the length of the list, there's an easier check...
This is a far better 'culture' document then the Airbnb don't fuck up the culture memo.
It speaks to an important and specific norm for programmers. Plus, it doesn't read like the setup for a Greek tragedy, where hubris and self fulfilling prophecy loom large.
6.002 midterm at MIT in 91 had a problem trivial to solve with a Laplace transform ... Actually it had a couple. Of course Laplace transforms would be taught in the second half. The few students who already knew the transform or somehow knew to read, ahead did well. I spent 20 minutes on one problem solving the differential equations from scratch without the damn transform. I felt sorry for those who weren't taking it as a freshman (it was pass/fail for all classes your first year at MIT).
That guy was a useless jerk. (As a teacher.) I did have professors that were useful jerks ... Difficult homework every single class with spot on directed feedback by the very next class. Unfortunately teaching well at a research university is just a mark of being eccentric. It seems to be negatively correlated with getting tenure. The 'useful jerk' already had tenure. He was mean, but an awesome teacher.
I use the mailbox iPhone app. The killer feature for me is that I can snooze an email. It's close to ideal for me. This ability to show multiple inboxes on the desktop might be an interesting tool to add visibility to something on another list.
Can't beat Mailbox. Wish they had a desktop app too. The snoozing thing is essential for moving stuff out of my headspace until I can think about it. I wish everything in life had a swipe to snooze.
I enjoy using Mailbox to the point that I rarely use desktop Gmail anymore -- a keyboard on my iPad helps. It's also easy enough to implement the filtered inbox views mentioned in the article for Mailbox folders, allowing the same sorting functionality on mobile (unlike the star-based solution).
That specific premise is false. An alternate use case does not provide a -meaningful- floor for any store of value. Tulips still have an alternate use case.
I'd claim Krugman is arguing against cryptocurrency in general rather than Bitcoin specifically.
The affordances provided cryptocurrency are new. It's a fair bet that will provide value.
How many factors currently contributing to the value of the US dollar were in place within the first decade of its existence?
I'd also claim the libertarian hopes for cryptocurrency are overblown, though they are definitely contributing to its current level interest.
It is a systems language. The competitors are c, c++, go, and D. Within Microsoft it's just c and c++. Competition with Java is irrelevant, c# already occupies that space. Microsoft has enough need and scale that a systems language that picks up internal use is justified. The use case is making platforms, not crossing them.
Go, a systems language? I would not be so sure. Stop-the-world garbage collection and dynamically typed interfaces seem like a poor fit for this niche.
Ack ... I'm largely ignorant of the details of go other than its original positioning. Do the semantics of go constrain gc implementation in such a way that it precludes low latency? Or is it just not a focus of the implementors?
Although Go has channels for civilized communication between goroutines, the language does not have a native notion of what data is owned by which goroutine, which pretty much forces garbage collection to stop the whole world.
This, together with pervasive mutability, means that communication using channels is merely a convention that can easily be circumvented.
>I'm largely ignorant of the details of go other than its original positioning
It is a faster python with a very primitive type system tacked on. I don't know how they ended up there from their original idea of a systems language, but they did.
If I understand correctly the independent third party is only needed in a dispute. If the buyer and seller are happy then completing the transaction does not require action by anyone else.
This delays payment until 2 of the three parties sign off. From the buyer's point if view that is reversibility. From the sellers point of view this is a delay in getting paid.
People complain that PayPal freezes merchants accounts. But PayPal only does that if the number of unsettled goods is too high. In this particular case it would always happen because parties would not acknowledge a transaction for a long time.
Chargebacks allow a merchant to get the money right away and still give the customer the option to reverse the charge a month (or more later) in case something happens.
PayPal does not come back later, that's the point of paypal. PayPal hedges against chargebacks and handles them itself. In case thinks you're above the average risk, it will start freezing your account temporarily. But they will never come back after 180 days and want your money.
On the other hand if you sell directly via credit cards, the credit card company can come to you after 180 days and want money back.
The top dev ladder rung is Technical Fellow (promotion from distinguished engineer.) Except for Dave Cutler, who is a 'senior technical fellow' ... which is the exact same level with a different name.
