Slashdot Mirror
Gnumeric Now Supports All Excel Worksheet Functions
unmadindu writes "The latest beta release of Gnumeric has been released. According the the developers, it is now ready and stable enough for general use and deployment, and the final 1.2.0 release will be made on September 8th. This release also marks the realization of a major milestone -- all of the worksheet functions in the U.S. version of MS Excel are now supported. I have been using 1.1.19 for quite some time now, and it is incredibly fast, and hugely improved compared to Gnumeric 1.0."
it could be very cool to support the sxc (openoffice) format. what about this ?
Ploum.net.
So how long before Microsoft chanages Excel to be totally incompatable with their old file format and/or functionality, just to screw the open source community yet again?
It damn well will happen... It's just a matter of how long.
---
Programming is like sex... Make one mistake and support it the rest of your life.
...does it support the flight simulator too?
If not, then I'm not interested, thank you!
All functions, as defined by their list of functions, is somewhat different than Gnumeric working the same as Excell. For example, I would be amazed if the graphs embedded in spreadsheets and generated from the data look anything like they do in Excell; they certainly were not ever readable in the versions of Gnumeric I've used. Sure, they have a function that calls something that supposedly makes graphs, but the graphs just ain't right. And A.F.A.I.K. this function was on their "already working" list the last time I checked.
I also want to see memos that I've attached to cells in my spreadsheet not vanish when imported into Gnumeric, as well as graphics embedded in a cell. Does anyone know if these now supposedly work?
I'm an American. I love this country and the freedoms that we used to have.
The functions to calculate integrals (need that to calculatr bond rates,) sucked big time in Excell. Insufficient precision.
If you're working on a multi-million dollar, long-term bond that comes to quite a bit of change dropped betwen the cracks.
MSBPodcast.com The opinions expressed here are my own. If you don't like 'em... Think up your own stuff.
Actually I use the Open-Office spreadsheet quite a bit at work, and can't see any reason to change to be honest. Part of my job involves perl scripts that generate .xls spreadsheet reports at night for users to view the next day and my tests with OO render them exactly the same as the users see them with Excel.
;-)
BTW, the reason we switched to doing this was due to the old system; where Access was running on PCs, and generating reports was so damned slow! It may seem unbelievable, but changing from Access+MySQL (we replicate from our Oracle server for reports and other stuff) to Perl+MySQL on Linux resulted in a staggering increase in speed. Reports that were taking an hour are now completed in under 2 minutes! The method I use to convert from Access->perl is, firstly take the Pseudo-SQL Access generates, then customise it a bit for MySQL, then use the Spreadsheet::WriteExcel module for perl. It's great!
I've never used Access myself BTW, and don't really understand what the hell it's doing to use all the CPU cycles. We watched it's activity one day - it ran a query on the Linux box, which took 12 seconds (monitored it with "top"), it then pegged the Windows PC - a P4 2.4ghz - running Access at 100% load for a good 20 minutes generating a spreadsheet!! WTF?!
So, to anyone else suffering with slow Access reports, learn some perl
Code, Hardware, stuff like that.
One way to make things go a little faster when using Access to drive Excel is to set an Excel.Range object equal to the upper left corner cell where you want data, and then CopyFromRecordset.
That assumes you've got things the way you want them in your SQL SELECT clause. If you need to tap every Recordset field prior to writing to a cell, one hopes your data are few.
Keeping this remotely on topic, are the various GNUmeric programming interfaces comparable to that beloved language, VBA?
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
The awful truth is that some very large corporations are run on cobbled together Excel worksheets.
The situation is this: Take some very intelligent people, and provide them with a braindead tool that can, in the end, get the job done. Very few of them will have enough time to find something better, or even to know that there is something better. They will use the tool, and inadvertantly create a nightmare for whoever has to clean up after them.
A multidimensional array of variant, often executable data, with links to a broken-by-design half-object-oriented crudfest of a language, and a horrific hack of the C++ type system, is clearly not the route to computing nirvana.
The world would be a nicer place if these people knew about Python, Haskell, and Prolog, for example, which would accomplish their goals in a cleaner, more efficient and maintainable but ultimately less approachable way.
How do we get this to happen? Education. Only when computing (not "How to use some applications"), and multiple models of computing (procedural/OO, functional, and logical), are taught in schools at a young age ( 11 upwards), as a basic subject as fundamental as other sciences and humanities, will people do things "right" from the beginning.
Will it happen? Doubtful. All we can hope for is that someone comes up with something that strikes a balance, and lets people do their work easily, without creating a horrific mess. Also doubtful.
From the graphing functions to its statistical capabilities, I consider Gnumeric to be on part with Gimp itself as an example of the quality that the Open Source model can create.
Any idea whether there is a windows version? Now that would be a good idea. I don't know why there isn't more work Open Source development being done for windows. How about giving Microsoft their own taste of "embrace and extend" by using Open Source on Windows as a means of reaching those who aren't likely or able to move over to Linux? I for one was VERY glad to see that Gimp had been ported to windows. I kept getting asked by windows users if there was a good alternative to Photoshop and now I can finally say yes without qualifying my answer with "but it only runs on Unix."
Microsoft isn't nearly as afraid of Linux as it is of the Open Source / Free Software movement/model itself. The technical quality of Microsoft's products is often lackluster, but when it comes to business strategy its leaders are grand-masters. They'll bankrupt you using an inferior product nine times out of ten. So far open source products like Linux have frustrated their ambitions to move up into the enterprise server arena but that isn't the same as going after them in their own backyard. Linux CAN be every bit as useful as a desktop OS as anything Microsoft or Apple has to offer, but it isn't quite there yet. Soccer moms and secretaries simply aren't going to move over to Linux because it isn't what their computers ship with and it isn't what everyone else is using. It also requires a degree of technical acumen that almost no-one posesses. The same is true of Windows of course, but that doesn't work against it since it's already in the dominant position. Those of use who do posess skill and talent with computers often forget just how mysterious the things that seem obvious to us are to most people. That is why Linux is stuck in the server room and will be for the forseeable future. If we can't displace Windows on the desktop, why not use it against its masters? Imagine if all the open-source application work that has been done for Unix was targeted at windows as well? Everyone who owned a computer would be using open source software in some capacity, and many would be aware of it. This would make it much easier to move people off of windows onto something better.
Before this movement to something better can occur however Linux needs to be made more luser friendly. Before you can sell something to someone you have to show how it is better than what they are already using and how what they are using is detrimental to them in some way that the replacement is not. Just making a better mousetrap isn't good enough when your potential customers have already invested in another model. Your mousetrap has to kill more mice AND include a feature whereby human fingers will never be smashed by it accidentally. Right now Linux is comparable to Windows as a desktop os in most ways. It needs to be better than windows and not plagued by the problems that windows is burdened with, or at least those problems that end-user clueless types consider to be important. Creating end-user apps for the platform where our end-users are is the very best way I can think of to gain insight into what they consider to be important. By ignoring windows as a platform for open-source development we're only helping Microsoft keep the barrier to use of Open-Source products artificially high.
Lee
Muslim community leaders warn of backlash from tomorrow morning's terrorist attack.
For christ's sake, slashdot, GNOME has had a new logo forever. Can you please update it?
I just tried out a copy of Office 2003.
At work I use Office 2000, and use Excel a lot, etc.
I was previously using XP (2002) at home, and I noticed that there wasn't anything added on to Excel, or really to anything, just made it more "prettier".
The same is true with 2003, save Outlook which has been revamped.
It seems as MS is insisiting on keeping the same things. I know there are things here ad there that are updated, but nothing that would make you want to upgrade over 2000, and that's pretty sad.
GeekWares - Buy and Download Today!
Its a question of resource allocation. For any time we spend polishing our xls import export we get access to the installed base of MS Office. Whereas time spent on OOo's formats yields a much smaller number. Given more resources we'd spend more time on it, but for now I threw together an importer in a couple of weekends, and have only received one bug report in 6 months. given the documentation for the OOo format, and more importantly the existance of readable code that impliments it, it would be a simple project for someone to improve our support.
It varies. We have a fairly extensive test suite that tries to keep us compatible with MS Excel for the most part. When a discrepancy appears there are 3 possibilities
1) Gnumeric bug which we fix.
2) Better precision in Gnumeric. This is fine. People tend to prefer the right answers when they can be convinced that XL was being silly. eg our VAR, HYPERGEOM, and various financial routines.
3) There is a bug in XL. This is a royal pain in the butt.
We end up with 2 functions. The XL 'FOO' that attempts to be bug compatibile, and a fixed G_FOO. We don't get a choice here. People tend to freak out if their imported spreadsheet starts to produce different results. Hopefully in time they can be convinced to use the G_ variants by default.
However, this is definitely an area we take very seriously. The Gnumeric project has received a grant to produce a test suite for open source spreadsheets. I'll announce more details shortly.
We support wk1, and wk2. There are some specs available for newer versions but I haven't had time to do more work on it. This sort of development is very parallizable. The i/o plugins are completely modular, so if anyone is interested in a new or esoteric format its not at all difficult to get something in place.
If anyone is interested please contact me.
And we can read their encrypted files too, _the horror_.
:-)
Thankfully there's not much to worry about here. A few years ago MS published a series of 'MS Excel developer's kit' books. There wasn't much in the way of useful material so for actaully developing extensions to MS Excel available. So, as far as I can tell, Microsoft tried to pad the book with what it figured was some marginally interesting filler, a full set of docs for the xls file format
When I bought the book I was quite irrate at the lack of useful content. It warms my heart all these years later to actually be able to put it to good use.
PS
They also included the full content of the book in various MSDN discs, and on their web site for several years. Then mysteriously pulled it a few years back.
True, this has been a sticking point for our scripting support. We have not wanted to commmit to a scripting interface that would not allow VBA to be used out of the box. There are several issues with that
1) security.
There is absolutely no way in hell that we'll allow vba to run without some sort of sandbox and user intervention to explicitly enable the macros. This will definitely make life more difficult, but perpetuating the nightmare of vba viruses in office docs seems like a terrible idea.
2) Reading and writing the macros. Unlike xls, the vba streams have no public documentation as far as I know. The anti-virus folk appear to have some under various NDAs but I have not seen enough to get a good handle on things. OO and gnumeric can both extract the compressed source code out of the vba streams, but neither of us has a good way of ensuring that will work.
3) In an ideal world we'd be able to extract the p-code rather than the vba source code. That will enable a simple mapping from vba to a more more opensource friendly language like python. The precompiled p-code would remove the need to parse actual vba.
4) If we're actually forced to use VBA, I'm hoping the mono's vb support will be viable as a fall back.
However, even if we find the file format, and we have an interpretter. Supporting it will require a gnumeric scripting api that supports the entire XL api. A large and daunting task. We'll do something smaller and cleaner first, likely based on our experiments in python. To date we've avoided blessing any scripting api because we don't want to offer one api then pull the rug out from under people and change it. An API needs to be stable to be useful. This is high on our list of projects for 1.3.
I made the claim as clear as possible, and belive it is true.
We can accurately reproduce results from every function in the US version of MS Excel.
We'd don't do quite as well comparing evalation techniques, although we're well ahead of OOo in that regard. 1.0.x had support for
- iterative evaluation
- implicit intersection
- and implicit type conversion
In 1.1.x we've added
- dynamic dependencies (eg OFFSET, or INDEX)
- constructed ranges (A1:INDEX(...))
- and support for implicit iteration for function arguments
That last one is the sole remaining issue as far as I know. I need to finish off support for implicit iteration for operators. Hard to say if it will go in for 1.2.0, probably not (although I've got it partially done), so it will likely wait until 1.3
This question has come up before, and I'll give you the same answer.
While we'd all like to 'innovate' (god I hate that word now that MS has abused it) and improve things no one is going to care unless the cost of transition is fairl y low. Before Gnumeric could implement some of its neat new features like dynamic dependencies we had to first implement enough of MS Excel's semantics that people could move their existing data over. That is the key to the real monopoly in Redmond. _They_ control your data. Their products have the content needed to do your work locked up in their semantics, and their binary formats. Before we can start creating a bold new world, we've got to free the hostage content.
It should also be noted that MS has lavished vast resources onto its flagship products. Ignoring all of their work 'because we know better' seems like a fools bet. Over the years I've cursed them frequently, but have also built up a grudging respect for the depth of Excel. It drives me nuts at times, but at least it is a consistent nuts, for some of the murkier corner cases.
Now that Gnumeric has paid the piper, and spent five years understanding what it means to be a spreadsheet we've got more leeway. Which is why we've been able to move so far past XL in terms of quantity and quality of analytics. Hopefully, that tend will continue.