I've done some work where I've implemented some stuff in code that was originally done via excel formulas (some traders do things that way). I wrote some python to do symbolic substitution on formulas operating over many columns of data to reduce functions to single line definitions over just the data input, making my job much easier. Any programming language implementing the excel formula functions would make it super easy to automate taking prototyped multi-column excel functions to code.
It's somewhat confusing. The structure is MIT licenses but the individual implementations have different licenses (for example, many functions were copied from OpenOffice (which is under Apache2 license)
(For English-only speakers: Excel's translation to other languages goes as far as translating function names, thus rendering non-English Excel users' knowledge useless when confronted with an English Excel. E.g., IF(ROUND(A1)=1,B1,C1) in English Excel is JEŻELI(ZAOKR.DO.CAŁK(A1)=1,B1,C1) in Polish Excel -- yes, with all those funky non-ASCII letters.)
This also includes changing argument separators according to the locale. In France, for instance, where commas are used as decimal separators, function arguments must be separated by semicolons. Faithful i18n should take both into account.
Luckily this is a UI thing and the files themself normalize to English. So the project could still be useful for opening Excel files on the web (theoretically).
As far as I know it's still text, but the function names are stored in English and are only localised within the Excel UI.
Fun fact: Some old versions of Excel even had a localised VBA ... using ZeichenF instead of String and other oddities made that a very weird experience.
That's the reason I always use the English version of Office. But then it's so weird when I go help some colleague and they're using the local version, and I'm suddenly a beginner... A remainder of the old world in today's hyper-globalized world.
Not only PT, that happens in most languages where the dot is not the decimal separator. It might have been the case in English as well if they used commas.
That's the reason I always use the English version of everything. What I find most ridiculous is when hotkeys get translated, ex. Ctrl+S is Underline in Spanish (Subrayar)
It never occurred to me that other languages would have different hot-keys. Intuitively it makes sense, but damn I imagine a lot of programs don't do it so it must be a horribly inconsistent experience (I get angry when a program fails to support something like CTRL-W to close windows or CTRL-A for select all or the inconsistency between some using ctrl-shift-Z or ctrl-Y for redo).
I guess that's the advantage to the old Word Perfect approach of function-keys for everything (provided you have one of those nifty overlays that show you all the key-commands).
oh the worst part is the number formatting. In French, for instance '.' and ',' are reversed. Excel in French then thinks 10,000 is 10. So Value("10,000") is different from Valeur("10,000"). Of course strings do not get translated when changing locale...
Every time I read some comment about how people shouldn't use excel for complex calculations and should use relational databases or Python or whatever else, I'll know why it will never happen.
It's really easy to implement the easy parts of spreadsheets, getting the hard parts right is why Excel continues to dominate the space.
There is a good reason why no one has unseated excel: it's easy to build the really easy 80%, but the last 20% is incredibly difficult and time consuming.
Most spreadsheets I've dealt with don't hold relational data. Are there people who use them as such? Sure. But I don't think that's the typical use case.
I would say relational data is the dominant use case for spreadsheets. It's a natural fit given the rows and columns. What other kind of data do you see in spreadsheets? Hierarchical data is not a great fit for spreadsheets.
I've been trying to find which js file has the actual meat of the implementation, but didn't manage to find it. function.js seems the biggest candidate, but didn't contain that much. The rest are all minified other JS libraries or bootstrapping. Any hint on where the actual mapping of names to formulas, and implementation of the formulas, is? Thanks.
As for the unimplemented.js formulas, for Gamma you could use the lanczos approximation, it's easy to convert the C code of it which you can find on the internet, to JS.
This reminds me of my college days. At Statistical Computing Facility at UC Berkeley, a grad student and I (I just finished 1st year at the time) built a web-based spreadsheet for tracking students' homework and exam scores. We called it StatGrades. One feature that it had was that you could write javascript for each column for calculation/validation. I looked at the excel help docs and implemented most of the relevant/useful functions, so people could do something like:
for the final grade. We used rhino for javascript and the service was built on jsp/servlet. It also had access controls so different readers/GSIs had access to different students and columns, and students could see their own grades. Everyone hated Blackboard and loved what we built, but unfortunately they couldn't find anyone to maintain it after I graduated (I was the only person working on it shortly after I joined). The service was shutdown a couple years after I left.
I honestly admire the thought and effort that went into it.
I fear that JavaScript's use of floating point as its single numeric type is likely to create surprising results for the unwary. I have come to the suspicion that the longevity of Excel's dominance is in part due to a sophisticated system for inferring numeric types.
Excel only supports numbers that fit in an IEEE754 double, just like JavaScript.
There is some fancy logic to format numbers, however (including some mess for date codes). http://oss.sheetjs.com/ssf/ is a pretty decent implementation in JavaScript.
> I have come to the suspicion that the longevity of Excel's dominance is in part due to a sophisticated system for inferring numeric types.
Huh? Doesn't Excel just treat everything computationally as doubles and sometimes display them as integers? As far as "sophisticated systems" for dealing with numeric types go, that's fairly weak sauce (and quite easily doable in JavaScript, which already does the first part).
Excel is dominant because it runs on Windows and is supplied with MS Office.
Many people would be fine to use other spreadsheet software but why bother going through the bother of researching and downloading and learning that software when your company probably has Excel licences and you've got some entry level training that used Excel?
That dominance has other effects. There is a huge amoun of support (training courses; books; Usenet groups and forums; Magazine articles; other people in the office; etc) for Excel that don't translate immediately to Excel. There are very many third party tools to help you do stuff in Excel if you really need it to. And Excel is probably some people's first introduction to programming. (Which is perhaps a bit scary.)
I speak as someone who loves gnumeric and LibreOffice btw.
Spreadsheets are a pretty useful and powerful tool when it comes to doing ad-hoc data analysis, but it's kind of annoying to get data in and out of them from command line tools.
I'm actually working on this, although for various reasons I had to reimplement the formula parser (corner cases are a pain). Screenshot (in progress): http://i.imgur.com/snyBhYH.png
IRR is one of those things that is remarkably simple to calculate and grok, but is made difficult in the number of horrendous instructions across the web, many of them simply wrong. Until I corrected it the NPV entry on Wikipedia (NPV being a dependency of IRR) sat with incorrect input / result data.
It all makes me think that some in the financial industry think this is some sort of trade secret.
56 comments
[ 6.4 ms ] story [ 83.3 ms ] threadEDIT: someone already thought about combining those libraries: http://SheetJS.github.io
[1] https://raw.githubusercontent.com/sutoiku/formula.js/master/...
(For English-only speakers: Excel's translation to other languages goes as far as translating function names, thus rendering non-English Excel users' knowledge useless when confronted with an English Excel. E.g., IF(ROUND(A1)=1,B1,C1) in English Excel is JEŻELI(ZAOKR.DO.CAŁK(A1)=1,B1,C1) in Polish Excel -- yes, with all those funky non-ASCII letters.)
That's actually pretty neat. Power of storing your equations in a binary format instead of plain text, I guess.
Fun fact: Some old versions of Excel even had a localised VBA ... using ZeichenF instead of String and other oddities made that a very weird experience.
I guess that's the advantage to the old Word Perfect approach of function-keys for everything (provided you have one of those nifty overlays that show you all the key-commands).
It's really easy to implement the easy parts of spreadsheets, getting the hard parts right is why Excel continues to dominate the space.
http://siag.nu/siag/
Seriously, how much does doing a simple "Select Distinct" suck in Excel?
(I know you can do filter => unique only => copy somewhere) but it's stupidly slow.
As for the unimplemented.js formulas, for Gamma you could use the lanczos approximation, it's easy to convert the C code of it which you can find on the internet, to JS.
AVERAGE(homework1, homework2) * 0.2 + AVERAGE(exam1, exam2) * 0.8
for the final grade. We used rhino for javascript and the service was built on jsp/servlet. It also had access controls so different readers/GSIs had access to different students and columns, and students could see their own grades. Everyone hated Blackboard and loved what we built, but unfortunately they couldn't find anyone to maintain it after I graduated (I was the only person working on it shortly after I joined). The service was shutdown a couple years after I left.
I fear that JavaScript's use of floating point as its single numeric type is likely to create surprising results for the unwary. I have come to the suspicion that the longevity of Excel's dominance is in part due to a sophisticated system for inferring numeric types.
There is some fancy logic to format numbers, however (including some mess for date codes). http://oss.sheetjs.com/ssf/ is a pretty decent implementation in JavaScript.
http://msdn.microsoft.com/en-us/library/office/bb687869%28v=...
Huh? Doesn't Excel just treat everything computationally as doubles and sometimes display them as integers? As far as "sophisticated systems" for dealing with numeric types go, that's fairly weak sauce (and quite easily doable in JavaScript, which already does the first part).
Many people would be fine to use other spreadsheet software but why bother going through the bother of researching and downloading and learning that software when your company probably has Excel licences and you've got some entry level training that used Excel?
That dominance has other effects. There is a huge amoun of support (training courses; books; Usenet groups and forums; Magazine articles; other people in the office; etc) for Excel that don't translate immediately to Excel. There are very many third party tools to help you do stuff in Excel if you really need it to. And Excel is probably some people's first introduction to programming. (Which is perhaps a bit scary.)
I speak as someone who loves gnumeric and LibreOffice btw.
Slightly related... I reckon a command line / ncurses version of Excel would be really useful. Am I crazy?
e.g. something like http://upload.wikimedia.org/wikipedia/en/e/ec/Lotus-123-3.0-...
Spreadsheets are a pretty useful and powerful tool when it comes to doing ad-hoc data analysis, but it's kind of annoying to get data in and out of them from command line tools.
I have no idea how easy it is to pipe input into and out of it, but it certainly want designed for it.
I would love a maintained {n,}curses mode spreadsheet that can handle excel1040.com.
It all makes me think that some in the financial industry think this is some sort of trade secret.