karamazov

The underlying formulas are mathematically equivalent to the ones Excel uses.

They may not match Excel precisely when it comes to numerical issues (things like roundoff error may come out differently, for example).

You're right, but people in that situation don't always have the luxury of rewriting the models or moving to a different tool. Hopefully we can help in those cases.

The calculations run locally, so your data is secure since it doesn't go anywhere.

The easiest way to check correctness is to compare what Excel returns to what our engine returns. If there's no discrepancy, you can rely on our calculations from then on.

(If there is one, let us know and we'll fix it! We've tested it internally, and part of the goal of the beta is to make sure things hold up in wider use.)

We just turn off Excel's computations and then run our own.

Most people who do heavy analytics in Excel don't have the option of importing something into a DB and using SQL, either because they aren't familiar with SQL or because they have to send the spreadsheet (and not just the result of the calculation) to someone who does.

Right now we're focusing on building the software over monetization - the beta is free and will be for a while. Our target market is Excel-based analysts. They're found in a lot of sectors, finance and ad-tech being two major ones.

We got the speed increase primarily by dropping to low-level code (numpy, and sometimes C) in functions that cause bottlenecks. Multi-threading helps too.

The largest gains are in the scenario you mentioned - big spreadsheets with a lot of computation. Excel tends to choke on these.

Actually, they're the same thing: both are computed as (number of shares outstanding) * (price per share).

The difference is that market cap is used for companies that have IPO'd (and therefore have a broad market for their shares with continuous price adjustments) versus companies that have raised money through private markets (and therefore have infrequent price adjustments).

One can reasonably argue that valuations are less precise than market caps as a result, but both are dictated by sophisticated investors and should be more or less correct on average.

(In fact, valuations are less precise, but this has a lot more to do with the amount of uncertainty inherent in any early-stage company than it does with the availability of shares on a public market; Wall St. has its ups and downs just like Silicon Valley.)

Dealing with frequent machine failure is one major issue, for example.

The original GFS and MapReduce papers (http://static.googleusercontent.com/media/research.google.co... and http://research.google.com/archive/mapreduce.html) go into detail.

This is what I would expect from the underlying mathematics. NaN roughly means the output of a function is undefined, and it does not make sense to say functions are equal at some value just because they are both undefined for that value.

For example, it's probably more sensible to say that 2x/x != 3x/x for all values of x, rather than 2x/x != 3x/x for all x except 0, wherein both functions are undefined and therefore equal to each other.

A four-stone handicap is not small: a beginning professional player could give any top Go player (there are several major championships) a run for his money with 4 stones.

Is the policy of dropping numbers from this sort of title still in effect?

Off topic, but if your son has the chance to go Harvard/MIT/Stanford, he absolutely should. The difference is primarily in the caliber of the other students, and it makes a world of difference to have such a concentration of talent in one place.

(Note that I'm not saying there isn't talent elsewhere, just that there's an incredible concentration of it in the top n schools.)

This is an incredibly broad question. Can you give some details on what happened, specifically?

I'm a big fan of SICP. I'd describe it as "hard-core": requiring hard work, but extremely rewarding for the people who take the time and effort to go through it.

I'd recommend the following three books to similarly cover the three main areas of higher mathematics (analysis, algebra, and topology):

1. Principles of Mathematical Analysis by Rudin (http://www.amazon.com/Principles-Mathematical-Analysis-Inter...)

2. Algebra by Artin (http://www.amazon.com/Algebra-2nd-Featured-Titles-Abstract/d...)

3. Topology by Munkres (http://www.amazon.com/Topology-2nd-James-Munkres/dp/01318162...)

Working through all three (including the exercises!) will give you a solid understanding of the basis of modern mathematics. If you don't have experience with proofwriting, you might find them difficult at first - the activity is very different from performing calculations or solving equations. It's also best to have someone trained in mathematics talk to you about the proofs, until you develop a feel for the needed level of logical rigor.

Rudin, in particular, leaves a lot of work to the reader; going through that book is the most intellectually difficult work I've ever done. If you find it hard-going (which is completely natural), you might want to try Artin first, especially since you have some background in algebra.

(Incidentally, these are the three books used to teach analysis, algebra, and topology to MIT mathematics majors. You can look up the assignments and exams for the three courses - 18.100B, 18.701, and 18.901 - for a good list of exercises to work through.)

We can help with both of those. Send me an email (ben@datanitro.com) and I'll get you set up.

No, only what's needed to update their model. We also don't use the data in any way other than to send updates - we don't even store it on our servers.

Prototype Day is a chance to practice your pitch in front of your peers. For most people, it's also the first chance to see what impacts an audience, especially after they've just sat through 20 presentations. (This is helpful both for pitching investors in general, and for demo day specifically.)

You can replicate a lot of the value by getting a group of serious founders together and having them spend a day or half a day pitching to each other, with feedback. If you can get a mentor experienced with the process to give you feedback, even better.

I'll start worrying when we get past "monkeykingjasmine".

Congratulations!

Take a look at this: https://voyager.datanitro.com/

A user is someone that you send data to (probably one of your customers or employees).

This site is actually for a new product: an API that lets developers push data (from any language, over REST) to the spreadsheets of end-users.

Not directly related to VBA or Python =)

Yes, that's one way to look at it. In practice most people send CSV's now, so it's a simpler, streamlined way to do that.

A big advantage of Voyager over both of those options is the ability to send custom data per-user without building an ad-hoc web UI for it.

This is primarily for analytics and other data companies with non-technical customers. They get requests for data in spreadsheets, and they usually manage that by generating and sending over one-off CSV's.

Voyager is an interface that's easier to use for the devs, and much easier for the end-users.

Hi, I'm one of the developers. Let me know if you have any questions.

We'd like to get as much feedback as possible, and we have a special offer going on towards that end: free service with unlimited users until April. We'll also build out your integration for you if you'd like us to.

If you think this'd be helpful for your company, leave a message here or email me at ben@datanitro.com.

This takes that into account - you don't spend all of your money until you have no chance of living another year.

(In this case, the assumption is that you might make it to 111 but will not make it to 112, which is not completely true but very accurate.)

If you assume that you always have a decent chance of living one more year, and you're not bringing in additional income, you essentially need to maintain a floor of savings and just live off the interest.

However (and unfortunately), this is a bad assumption. You can show that by calculating the distribution of ages for a human population that has nontrivial survival rates; they don't look anything like the actual human population.

(Explicitly: the survival rate falls off exponentially or faster. In other words, if you don't like 112 as a maximum age, you can assume 125 - that's 2 years older than the longest-lived human being.)

It's strange that it converges to a number we can describe succinctly, as opposed to a random number that has no relation to anything else.

That's exactly how survivorship bias, in particular, works:

"Survivorship bias is the logical error of concentrating on the people or things that 'survived' some process and inadvertently overlooking those that did not because of their lack of visibility." [Wiki]

Sam's saying that very successful companies tend to hit all of these points, in contrast to less successful or unsuccessful companies, which will miss one or more of them.

You don't need to take the post at face value, but if you're claiming this is a result of survivorship bias, then you're arguing that successful companies just happen to have these traits, and they don't actually help the companies succeed. I don't think that's true.

Sam has seen enough companies that have made it, and enough that have failed, to talk about this without survivorship bias.

"relentless" might be a better word.