Why these original FORTRAN quirks?
in [Fortran]
|
From: James Parsly on 26 Oct 2006 10:23 For reasons that are unclear, when you are making charts in Excel, they limit the number of data points to something less than the number of rows. In earlier versions, seems like is was 4000 points (it always annoyed me because I often wanted to plot a years worth of hourly data, and had to break it up into two lines). For Excel 2003 it seems to be 32000 points. This is better, but why should it be less that the number of rows (and why 32000 instead of some "natural" computer geek number like 32767?) "Gary Scott" <garylscott(a)sbcglobal.net> wrote in message news:lj10h.23889$7I1.4570(a)newssvr27.news.prodigy.net... > 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
From: Brian Inglis on 27 Oct 2006 00:08 fOn Thu, 26 Oct 2006 01:40:05 -0700 in alt.folklore.computers, glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote: >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. Long term trend analysis charts? 15 minute samples for a year is over 32K. You'd have to put each year on a separate chart, or another line on the same chart with a good possibility of interference even on a large format plotter. Sometimes just seeing being able to see the overall trend(s) visually allows you to see factors you wouldn't otherwise spot. That's what data warehousing is all about, and major database enabled visualization packages. AutoCAD recognized that high end graphics market a couple of decades ago. -- 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: Rostyslaw J. Lewyckyj on 27 Oct 2006 02:31 glen herrmannsfeldt wrote: > 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 > I think that the idea in spread sheets is not so much viewing it, but rather in being able to manipulate interactions between rows and columns by formulas, playing what if games and such like, and then inspecting the effect on some collection of cells. So to proceed with the iterations you need to read it all in and store it etc. If it can be done in one pass through the data then it isn't a real candidate for processing with a spread sheet. That is not to say that it isn't done.
From: Jan Vorbrüggen on 27 Oct 2006 03:52 > 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. That's all nice and well from today's - or even a decade-back - perspective. However, the first VAXen came out with 256 kB of main memory, and we actually had one with 512 kB (for about a hundred users...) for some time. Hey, the boot code was enhanced to patch VMS instructions on the fly when it detected that the system had more than 65535 fluid pages (32 MB)... Jan
From: jmfbahciv on 27 Oct 2006 07:26
In article <zjTZg.31111$zF5.19849(a)bignews1.bellsouth.net>, "Rostyslaw J. Lewyckyj" <urjlew(a)bellsouth.net> wrote: >Larry__Weiss wrote: > >> Rostyslaw J. Lewyckyj wrote: >> >>> Keypunchers, unless summer interns from a technical school or such like, >>> are not expected to be the Fortran pre compiler syntax checking phase. >>> Similarly we instructed our student help staffing the input-output >>> window (i.e. accepting job decks & handing out the printed outputs) >>> not to hand out programming advice, i.e. not play at being consultants, >>> even if they were seniors with some programming courses under their >>> belts. >> >> > >> >> Plus, learning to code benefits from a "school of hard-knocks" >> experience. You don't really want to take that away from someone >> who is serious about learning the art (or is forced to become so >> because of job expectations). >> >> The proper place for such feedback is in a mentoring partnership >> or in a formal code-review. >> >> - Larry >> >> >> >Yes..., Well that's a different discussion. >Those users who came to the consulting desk with a thin printout, >which they hadn't even bothered to unwrap from around their deck, >and dropped it on the desk with the immediate question "why didn't >this run", did annoy us a lot. >Some users developed a reputation for this. >That is one instance when I'd have been glad to apply the hard >knocks methodology. But that's easy to deal with. hmmm..maybe that's why I got the job of breaking in people. /BAH |