Jonathon Blake wrote:
Dave wrote:
1 million rows and up to 16 000 columns
A fully populated worksheet of that size would require 96 768 GB RAM,
just to load.
That comes out to 6,048 bytes per cell. I'm not arguing the point, but
I'm just curious where you got that number.
1. Assuming Calc will be able to handle M$'s perverted form of XML,
will it be able to handle sheets of this size?
The more pertinent question is if Excel will be able to handle a
sheet that is that big.
15 625 vertical sheets 63 horizontal sheets.
Total of 984 375 sheets. Calc _might_ not be able to handle it.
Do you have enough RAM? Do you have a large enough hard drive? Are
you using very fast chips?
These are requirements that were/are the purview of supercomputers,
before Beowulf clusters took center stage.
I don't think the point of it is to actually create spreadsheets that
large so much as it is to functionally remove the hard-coded limits that
currently exist. Instead your limits will be "soft" that will depend
more on your available resources and willingness to put up with sheets
that take a long time to open and work with.
The reality is that most users probably couldn't create a spreadsheet
that uses the existing limits in Calc (64000 rows, 256 cols, 256
sheets). Assuming your figure of 6K per cell that would require
something like 2.5 TB of RAM to load already.
The reality is you would *either* want/need more than 64000 rows with
only a few columns *or* more than 256 cols with only a few rows, etc.
2. If not, the users list will probably be flooded with posts
saying "in Excel I can have this many ... blah, blah, blah".
That might happen. If so, then either educate people in how to use
databases, and how to use spreadsheets, or go to Plan B
Does anyone here know if any development is under way to add this
capacity to Calc?
This might be an interesting "problem"
Write a function/plugin/macro that makes the user think that they are
using Calc, but in fact are using the dBase clone. [Circa 1994,
there was a spreadsheet for Dos, that could have an infinite number
of rows, columns, and pages. The limiting factor was the amount of
disk space on your system. ]
Plan B
Record: Cell Field zero: Cell Number Field one: Page Number Field
two: Column Number Field three: Row Number Field four: Cell Value
field five: Cell Value Type Field six: Cell Formula Field seven:
Cell Links From. Field eight: Cell Links To.
Create records as needed. Keep an index of all fields.
Whilst slower than Excel, it provides for more pages, columns, and
rows than Excel proposes. [And suffers from the same issue: How much
RAM, and disk space does your system have.]
Wondering if being able to advertise a spreadsheet that can handle 1
000 000 000 000 000 000 000 pages, with 1 000 000 000 000 000 000
000 rows, and 1 000 000 000 000 000 000 000 columns is going to win
any brownie points anywhere?
xan
jonathon -- Ethical conduct is a vice. Corrupt conduct is a virtue.
Motto of Nacarima.
I don't know if the above was meant facetiously, but it's a real
question: What is/should be the border between a spreadsheet and a
database? The reality is there are likely as many spreadsheet databases
out there as "real" databases, and for good reason. A real database,
even an "easy" one like Access, is kind of a PITA to set up.
I think anyone who could devise a hybrid between the two that really
combines the best features of both would have a real market winner.
Maybe something like a user-friendly object-oriented database. I
remember seeing a web-site a couple years ago for a product that claimed
to be such a hybrid, but I was unable to locate it again for this post.
FWIW, there *are* some interesting ideas for spreadsheets floating
around out there beyond the Excel/Calc paradigm. One I found is Abykus,
http://www.abykus.com/, which claims to be an "object-oriented"
spreadsheet. It doesn't try to have a humongous number of rows/cols, but
it does other interesting things.
--
Rod
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
