On 03/14/12 00:29, Rob Weir wrote:
It would be great if the community would focus
some effort on academic publishing requirements such as
this. There are other aspects to this space that we can
attend to which could create some exciting value for
scholars who have crappy tools today. For example,
integration of the R statistics package http://www.r-project.org/
... just a thought. We may have some licensing challenges
but if we think about how valuable this could be...well.
there must be a solution, right?
Yes, this has been proposed in a bugzilla issue
https://issues.apache.org/ooo/show_bug.cgi?id=66589
It is an interesting idea. Some programs, like the Gnumeric project,
have added a considerable amount of more advanced statistical support
directly into their spreadsheet, more than OpenOffice, more than
Microsoft Office, more even than LibreOffice. But they obviously
still have only a fraction of what is in R. You can never beat R.
Well, R is a language for statistics with it's own graphical tools
etc. This was the approach used by major statistic packages
a decade ago but it seems like all of them have been moving to
a more spreadsheet oriented approach in recent years.
But doing fine grained interchange with R, within a spreadsheet
calculation cycle, is probably a killer for performance. But there
are some things you can do that do perform well. For example,
ODFWeave gives a way to treat an OpenOffice document (or any ODF
document) as a template that this then filled out based on R's
calculations and charting. I could see it being useful for automating
laboratory reports, for example.
http://cran.r-project.org/web/packages/odfWeave/index.html
I would like to see some day a package adds full math capabilities
to writer.. something like MathCAD. I doubt this project will head
that way but it would be a great tool to see in relation to TeX.
Also, I wonder if there is anything more we can integrate from the
COIN project? That was Eclipse license, right? They had non-linear
constraint solving, etc. Quadratic programming would be another good
one.
You should now better about the COIN license ;). The code was
originally from IBM. When it started it was strong thanks to the
Open Solver Interface that supports the top of the line
commercial solvers in the market.
CoinMP was a simple solution for the immediate problem but
we are not using the full advantages of the OSI interface.
For practical purposes though, the current CoinMP is more
than sufficient for the requirements of a basic OR course and
I suspect it will stay like that for the foreseeable future.
I see COIN-OR is starting to build some code around python
and I guess that's something we should examine in the future
since we are already carrying python.
But still, it is a trade-off. The more capability we bring to Calc,
the bigger it becomes. We need a way to grow without growing.
Modular extensions, not just at the UI level, but at the computational
level.
There is a OOo extension for non-linear programming (partially
owned by Oracle) that was brought into LibreOffice. I personally
think bringing in such functionality that few people use is a
bad idea and just make the basic office suite bloated and
eventually unmanageable.
There are some really powerful libraries out there (fftw, taucs,
mumps ... ) that can be useful to make extensions but most
of them add the requirement of fortran to the build system.
Such tools can/should live as extensions.
Another thing I hear from academics is the desire to have much
improved bibliographic support in Writer.
I would personally favor some VBA macros in the
lines of software like Minitab.
I'm not sure I understand. VBA macros in AOO that can call an
automation interface in Minitab?
No, Minitab was really innovative in offering a powerful
statistical environment with a spreadsheet interface at
a very competitive price (they raised the prices a lot
afterwards).
I guess I would mean the gnumeric approach. Keep it simple,
use existing tools.
Cheers,
Pedro.
