Why these original FORTRAN quirks?
in [Fortran]
|
From: Brian Inglis on 26 Oct 2006 00:30 On Wed, 25 Oct 2006 11:07:40 +0200 in alt.folklore.computers, Jan Vorbr?ggen <jvorbrueggen(a)not-mediasec.de> wrote: >> In the extreme case, suppose N=2, which with 8bit chars allows >> up to ~32000 unique external names. With the F90 liberal rules >> some F90 Fortran program might exceed the system design constraints >> and become impossible to do. :) > >A bug was filed against DEC's Fortran compiler - IIRC, it even was the one for >the VAX - because the compiler failed with an internal error on a program >unit. This happened because the compiler uses 16-bit indices into its symbol >table, and this program unit defined more than 65535 names. VMS had a number of these boneheaded mini-computer heritages of one and two byte hardcoded limits, including a limit of 255 spool queues for all purposes: kind of limiting when even moderate sized companies have more than 255 printers scattered around the LAN. MVS/zOS/JES(2) also has/had a similar limit on spool devices per system; don't know about JES3. What would have been so wrong with using machine words on these virtual memory systems? Weren't they meant to free us from all these arbitrary limits? -- Thanks. Take care, Brian Inglis Calgary, Alberta, Canada Brian.Inglis(a)CSi.com (Brian[dot]Inglis{at}SystematicSW[dot]ab[dot]ca) fake address use address above to reply
From: glen herrmannsfeldt on 26 Oct 2006 00:57 Brian Inglis wrote: (snip) > VMS had a number of these boneheaded mini-computer heritages of one > and two byte hardcoded limits, including a limit of 255 spool queues > for all purposes: kind of limiting when even moderate sized companies > have more than 255 printers scattered around the LAN. MVS/zOS/JES(2) > also has/had a similar limit on spool devices per system; don't know > about JES3. What would have been so wrong with using machine words on > these virtual memory systems? Weren't they meant to free us from all > these arbitrary limits? Excel through 2003 still has a limit of 256 columns and 65536 rows, no matter how much memory, real or virtual, you have. I understand this will be increases in 2007. -- glen
From: Brian Inglis on 26 Oct 2006 04:09 On Wed, 25 Oct 2006 21:57:00 -0700 in alt.folklore.computers, glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote: >Brian Inglis wrote: > >(snip) > >> VMS had a number of these boneheaded mini-computer heritages of one >> and two byte hardcoded limits, including a limit of 255 spool queues >> for all purposes: kind of limiting when even moderate sized companies >> have more than 255 printers scattered around the LAN. MVS/zOS/JES(2) >> also has/had a similar limit on spool devices per system; don't know >> about JES3. What would have been so wrong with using machine words on >> these virtual memory systems? Weren't they meant to free us from all >> these arbitrary limits? > >Excel through 2003 still has a limit of 256 columns and 65536 rows, >no matter how much memory, real or virtual, you have. > >I understand this will be increases in 2007. They went up from 32K to 64K rows did they? Gave up on Excel years ago for high volume data. Still use it for lots of other things. And to think in the early 1980s accountants were loading their monthly transactions into spreadsheets (inc. 3D page col row e.g. 5F9) in *16MB* VMs, as 1-2-3 only supported a single sheet in a few MB expanded: look how far we've progressed! -- Thanks. Take care, Brian Inglis Calgary, Alberta, Canada Brian.Inglis(a)CSi.com (Brian[dot]Inglis{at}SystematicSW[dot]ab[dot]ca) fake address use address above to reply
From: glen herrmannsfeldt on 26 Oct 2006 04:40 Brian Inglis wrote: (snip on limits in VAX compilers) >>Excel through 2003 still has a limit of 256 columns and 65536 rows, >>no matter how much memory, real or virtual, you have. >>I understand this will be increases in 2007. > They went up from 32K to 64K rows did they? Not official, but it looks like 1M rows and 16K columns. > Gave up on Excel years ago for high volume data. I used it for a project that required it, but mostly I don't use it. I would say that most problems that require that much data (more than 256 columns or 64K rows) are better done by processing data while reading it, not first reading it all in. No matter how big main memory gets, data sources will always be larger. (When I was working on DNA sequence data I once calculate that the exponential growth in DNA data was faster than Moore's law. It has been a consistent 1%/week for some years now.) There is no visual advantage to 1M rows and 16K columns. There is no possible way to view it. -- glen
From: Gary Scott on 26 Oct 2006 07:51
glen herrmannsfeldt wrote: > Brian Inglis wrote: > > (snip) > >> VMS had a number of these boneheaded mini-computer heritages of one >> and two byte hardcoded limits, including a limit of 255 spool queues >> for all purposes: kind of limiting when even moderate sized companies >> have more than 255 printers scattered around the LAN. MVS/zOS/JES(2) >> also has/had a similar limit on spool devices per system; don't know >> about JES3. What would have been so wrong with using machine words on >> these virtual memory systems? Weren't they meant to free us from all >> these arbitrary limits? > > > Excel through 2003 still has a limit of 256 columns and 65536 rows, > no matter how much memory, real or virtual, you have. > > I understand this will be increases in 2007. > > -- glen > I've never had problem with the row limit myself, but that column limit has been a PITA forever. -- Gary Scott mailto:garylscott(a)sbcglobal dot net Fortran Library: http://www.fortranlib.com Support the Original G95 Project: http://www.g95.org -OR- Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html Why are there two? God only knows. If you want to do the impossible, don't hire an expert because he knows it can't be done. -- Henry Ford |