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.
It has many more functions that are not found in Excel, but ALSO having support for everying Excel supports means that any Excel sheet can be opened and used in Gnumeric.
Gnumeric is compatible. It is faster. It does more. That seems better to me, even when ignoring the price tag and lack of Evil(tm) technology.
You can't judge a book by the way it wears its hair.
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!
Oh, and by the way, there's only so many ways to make a usable spreadsheet program. If a standard spreadsheet application exists, and a way of doing things already exists, why reinvent the wheel? This is just so people can be free from the Microsoft grind of upgrading every couple of years to a new, more bloated version of office.
There's still a long way to go though, just because we have all the functions of Excel doesn't mean that it's Excel, or that people won't have functions in Windows (i.e. Macros in VBA) that they need (Like in accounting).
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.
Worksheet functions are great, but a lot of Excel's draw comes from its embedded VBA. Companies that rely on workbooks with embedded VBA probably wont be willing to switch to Gnumeric until it has support for VBA, or something very similar.
"Open the pod by doors, Hal" > "I'm afraid I can't do that, Dave" sudo "Open the pod bay doors, Hal" > alright
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.
i can see a Microsoft ad right below the news :)
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
And even on technical merit, Gnumeric is behind in some important aspects, Excel file compatibility the most dire one.
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.
What happens if some of these functions don't quite work identically to Excel's in 0.1% of cases, be it for a bug in Excel or Gnumeric? I don't see much rush for converting existing work to Gnumeric, just because of this risk factor.
Linux started with GNU gcc version 1.37. Wow, does that seem like a long time ago. There was not even a working curses library at the beginning. Only stuff which relied on the standard C libary could be made to work, and not even all of that.
So while this Gnumeric milestone deserves a "hats off" to all the wizards on the Gnumeric team, let's not forget all those who over the years toiled away at improving the GNU toolchain -- compilers, linkers, libraries, debuggers, and all those who worked to make XFree86 as stable as it is today. They layed the groundwork for Gnumeric and all the great software to come.
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?
Once you define yourself as a competitor, then you can start adding the cool stuff that differentiates your product.
MS knows this as well. Excel just didn't materialize from thin air. Spreadsheets started with Visicalc on the Apple ][. It was a truly innovative program that, to the people who understood it, justified the purchase of the machine. In much the same way that the graphics capabilities justified the purchase of a Macintosh, even if it had barely enough memory. The one truly imaginative thing MS has ever done is was combine the spreadsheet concept with the Macintosh concept. The original Excel was a truly beautiful and a deserving successor to Visicalc. But Excel was only a successor, not an original. And since them MS has lost the beauty in a bunch of extraneous crap.
I cannot say the same thing about word, as MacWrite was a superior product for many years.
"She's a scientist and a lesbian. She's not going to let it slide." Orphan Black
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.
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.
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
Actually that capability was one of the first things that went into Gnumeric. Its an area we trounce MS Excel on several levels. - Adding a plugin to gnumeric is trivial. Indeed the vast majority of the functions are in plugins that are demand loaded. - plugin functions can be written in C (like an XLL but with a much cleaner interface), python, perl, or guile Docs for python here
Our stated goal in the Gnumeric project is to produce the best spreadsheet available. After some consideration we decided that Gnumeric seems likely to produce that sooner than OpenCalc. OO is an important project, but as a spreadsheet user I have little interest in an office suite. There are quite a few users out there that seem to have similar views.
This is not a winner take all situation. OOo is the right solution for some users. However, Gnumeric is better is several areas already and with some work, we'll move past Excel in more places too.
If you want an Office Suite, by all means use OO. If you want the best possible spreadsheet I'm guessing that people will end up using Gnumeric.
We have tests for accuracy. Speed tends to be more of a 'hmm this is too slow for my taste lets see why' sort of operation. Gnumeric-1.2 is damn fast compared to 1.0, and is easily faster than OOo.
However, I'm not clear on what you're looking for in the context of the solver.
1.1.x has goal seek, and several different optimization algorithms curtesy of various other projects (linear, integer, and non-linear). We're less concerned with XL compatility here (they suck badly). Nor is speed of paramount concern. It seems more important to produce accurate and stable results.
Dunno what else to say. Try it out and bugzilla a report if you see a problem.
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.
Interesting.
Can you forward a copy of the file with the miss imported fonts ?
Please file a bug about 'replace by'. This is still a beta there is time to polish things before 1.2.0
Yah, it would be nice to have image preview in there. Its a simple project hopefully someone will tackle it.
How is the zoom dialog worse ? bugzilla your complaints please. They'll be easier to track/debate there.
IIRC, pivot tables are "functionality", not a "function". Functions are those things that look like: =foo(a,b,c)