why just 65536 rows
jorge
number? Is there some reason?
ajames54
wrote:
>Why excel let just 65536 rows by worksheet, Why this
>number? Is there some reason?
16 "bits" worth of rows ... 8 "bits" worth of columns
2^16 = 65536 and 2^8 = 256
a very old limitation placed on the program when first
constructed... seems like they can't or wont re-code to fix it.
(There are lots of limits hard coded to these values, not just
sheet size)
Phobos
database anyway.
P
"jorge" <huna...@dacafe.com> wrote in message
news:038b01c3131a$dd58fd20$2f01...@phx.gbl...
Wilson
number of rows ^)^ ??
Don Guillett
--
Don Guillett
SalesAid Software
Granite Shoals, TX
don...@281.com
"jorge" <huna...@dacafe.com> wrote in message
news:038b01c3131a$dd58fd20$2f01...@phx.gbl...
Norman Harker
This subject has been aired many times on newsgroups. Here are some of the views on the difficulties that Microsoft face taken from
postings down the road at worksheet.functions newsgroup which I've prefaced with an extract from John Walkenbach's website. These
are by no means the views of apologists but do point to both practical and commercial reasons.
John Walkenbach:
Every Excel worksheet is limited to 256 columns. Despite what must amount to thousands of requests over the years, Microsoft refuses
to increase the number of columns in a worksheet. Beginners often discover this limitation when they want to set up a spreadsheet
that contains data for each day in a year. If they store the data horizontally, they run out of column in mid-September.
So we're stuck with 256.
Why such a weird number? Why not 250? Or 365? The number of rows and columns is a by-product of the binary number system. 256 is 2,
raised to the eight power (2^8), which is the maximum value that can be stored using eight bits. The number of rows in a worksheet
is 65,536, which is 2^16. Older versions of excel contained only 16,384 rows, which is 2^14 power.
The reason for the 256-column limitation is probably due to the fact that Excel is so old, and it contains lots of code that would
be "broken" if the number of columns were increased.
J.E. McGimpsey:
I suspect it's development costs ($100M+?), and, potentially, compatibility (I always use Rows.Count, but there's lots of hard-coded
65536s out there), vs. number of additional sales (or avoidance of sales lost). Given the near monopoly of XL in the marketplace, I
can't imagine that the return on investment calculation is positive.
I further assume that the source code was hand optimized at some point for 2-byte row references, and that
subsequent code was hard-coded to suit. I'd really be surprised if the great rewrite between XL95 and XL97 took place in a way that
was anything like as scalable as gnumeric.
I also was assuming that actually changing the code would be the smallest portion of the cost. I've seen redesign in a bureaucracy
take at least twice as long as actual coding, and pre-beta testing probably 4-6 times. Granted, that's not how it *should* work...
In addition, I assumed a large fudge factor for propagating the changes through the rest of Office/VBA/IE/etc.
Chip Pearson:
Also remember that increasing the number of columns would break every XLL out in the market. The XLOper type, the currency of the
realm in XLLs, defines column as a Byte, so every XLL would need a recompile *at a minimum* for the new XLOper type. To support the
current byte reference for columns and the new integer reference for columns would require at a minimum two release versions, but
more likely two code bases, increases greatly the headaches for XLL developers.
And in the financial world especially, there are LOTS of XLLs doing mission critical analysis, so MS is right to proceed with great
caution before breaking compatibility.
Jody Goldberg (Gnumeric Maintainer):
Excel was clearly designed in an earlier era. It uses less memory than all open source alternatives. One of the ways they
accomplished this is by bit bashing piles of stuff together. Looking at the xls file format and XLL interfaces its pretty clear
they store col = 1 byte and row == 2 byte. I'm pretty sure some of the crack-like
behaviors in MS Excel derive this. eg they don't need to bounds check relative references, IV + 1 == A because the numbers wrap.
To fix this they'd need an entirely new file format, and would break all dlls.
Norman Harker:
The only realistic option appears to be one that involves breaking the backwards capability of Excel.
And to do that Microsoft really would be making an enormous gamble and you'd need more than just adding columns and rows to attract
people to an upgrade.
There's a treble problem here:
1. The regular 5%/-5% user is satisfied with what they have! They complain already that there's nothing added in between versions.
This is evidenced by lack of upgrading of many Office 97 versions. It might well be possible to allow simple / most spreadsheets to
be imported to a new version but you'd need to find the Holy Grail and give them a lot more things that they want from the product
*before* they buy.
2. For the 95%/+5% users you are making a larger and larger number of their daily applications non-compatible / not translatable and
those would have to be rebuilt in the new version.
3. And anything built in the new version that, for example, used extra rows or columns, would not be capable of being run on lower
versions. With rows and columns in particular it would be difficult / impossible to program saving "down" to a lower version. Most
new applications on Excel Turbo would be restricted to running on Excel Turbo.
The only possibility I see here is development of a new product side by side with the old one. There is a precedent here! Look how
Excel took the market from Lotus 1-2-3. There was some limited capability of converting your 1-2-3 to Excel but not much in the
opposite direction. Over time (about 10 years!) most people switched to Excel but it wasn't just Excel that dragged them in (kicking
and screaming!) There were also the other things that came with Office.
But longer term it looks like the project has to be faced. It could even be viewed as an opportunity to create a new product. But
that product would have to have wider appeal to get people to want both packages. It's an investment in the long term future without
a lot of evidence of a challenge to that future.
--
Regards
Norman Harker MVP (Excel)
Mother's Day on Sunday! Don't forget!
(USA, Australia, Belgium, Denmark, Finland, Italy, Japan, Netherlands, Turkey).
But don't forget her wherever you are!
Sydney, Australia
Excel & Word format Function Lists free to good homes by direct request to:
njha...@optusnet.com.au
"jorge" <huna...@dacafe.com> wrote in message news:038b01c3131a$dd58fd20$2f01...@phx.gbl...