While searching for an alternative to the limit of 2 gigabytes of Microsoft Access, I found SQLite (http://www.sqlite.org/) a small software library (350KB) in C without external dependencies that implements a SQL database engine.
The source code for SQLite is in the public domain and supports multi platform databases up to 2 terabytes.
The simplicity of SQLite is comes from acting directly on a single file (a database) on the hard disk, not requiring installation, configuration or administration. Performing a backup boils down to copy the file to another location.
Another added advantage is its direct connection to the R (http://www.r-project.org) using the RSQLite library.
Showing posts with label actuary. Show all posts
Showing posts with label actuary. Show all posts
Friday, March 23, 2012
Saturday, August 8, 2009
The Actuarial Toolkit
Traditionally, at least in Portugal, actuaries are considered as "Jack of all trades" in their working places, being asked to do all sort of «technical» tasks. Mainly because they are able to do these tasks, fast and accurately, even though, most of them lay outside their responsibility area.
There's not much that can be done about that. As such, I don't think it's efficient or wise, that Microsoft Excel, should be almost the only tool used by a great majority of the actuaries. I'm not discarding it's versatility, specially if we are considering it's macro programming facilities with Visual Basic for Applications (VBA).
But a spreadsheet, as it's name implies, was created to be used as large sheet (of paper) to do some type of calculations. All the rest are convenience functionalities. It was not designed to be used as a database or to design charts, even if it is widely used, for that, all over the world. It is a generalist rather than a specialist tool for these tasks, as such it's limitations (some have been addressed in the latest versions).
The workload increases every month and there is a pressing need to do more in the same time frame. Upgrading to faster computers isn't a viable option, it just delays the problem.
Actuaries need to use other tools that allow to work faster and do things that Excel simply can't do.
They need to build their own actuarial toolkit.
Just to finish this post, some years ago I found one tool that became fundamental to my loss reserving work. It's called R (www.r-project.org) and, in my opinion, probably the most versatile piece of software I've ever seen for mathematical type of work.
There's not much that can be done about that. As such, I don't think it's efficient or wise, that Microsoft Excel, should be almost the only tool used by a great majority of the actuaries. I'm not discarding it's versatility, specially if we are considering it's macro programming facilities with Visual Basic for Applications (VBA).
But a spreadsheet, as it's name implies, was created to be used as large sheet (of paper) to do some type of calculations. All the rest are convenience functionalities. It was not designed to be used as a database or to design charts, even if it is widely used, for that, all over the world. It is a generalist rather than a specialist tool for these tasks, as such it's limitations (some have been addressed in the latest versions).
The workload increases every month and there is a pressing need to do more in the same time frame. Upgrading to faster computers isn't a viable option, it just delays the problem.
Actuaries need to use other tools that allow to work faster and do things that Excel simply can't do.
They need to build their own actuarial toolkit.
Just to finish this post, some years ago I found one tool that became fundamental to my loss reserving work. It's called R (www.r-project.org) and, in my opinion, probably the most versatile piece of software I've ever seen for mathematical type of work.
Subscribe to:
Posts (Atom)