ajayshah@aludra.usc.edu (Ajay Shah) (11/09/89)
Pascal is the prettiest language in the universe, but declaring five
matrix inversion routines is a little tedious. Any ideas on how to
get around this?
Does OOP (still a buzzword to me...) and TP5.5 help us any?
--
_______________________________________________________________________________
Ajay Shah, (213)747-9991, ajayshah@usc.edu
The more things change, the more they stay insane.
_______________________________________________________________________________dmurdoch@watstat.waterloo.edu (Duncan Murdoch) (11/09/89)
In article <6354@merlin.usc.edu> ajayshah@aludra.usc.edu () writes: > >Pascal is the prettiest language in the universe, but declaring five >matrix inversion routines is a little tedious. Any ideas on how to >get around this? I haven't actually done this, but it looks as though it shouldn't be too onerous to declare all your arrays as big one dimensional ones, and do the indexing yourself. For example, to pass an n by m array to a routine, pass a vector of the data, and pass n and m. Then when you want to access element x[i,j], instead access x[e(i,j)], where "e" is defined to be a little function to do the indexing. It'll be a little tedious because you'll either need a separate "e" function for each value of m, or you'll have to pass m to the routine, but that's not so bad. Most linear algebra routines only need one or two column sizes anyways. If you're using TP and you take the time to code e as an inline assembler routine there won't even be much of a speed penalty. You could also do something like x(i,j), but I think that would incur more overhead, or at least make for more complicated inlines. Duncan Murdoch
bam@bnlux0.bnl.gov (Bruce Martin) (11/10/89)
In article <6354@merlin.usc.edu> you write: > >Pascal is the prettiest language in the universe, ... You've got to be kidding! Pascal is just about the ugliest, but never mind. >...but declaring five matrix inversion routines is a little tedious. >Any ideas on how to get around this? Yes. Use a modern language that has *generics* (like Ada or Fortran-88), rather than one whose designer confused the notion of "data type" with various other attributes (like aggregation) and expected all programmers to put up with dependent compilation (or no separate compilation at all). Seriously, Pascal is a very useful pedagogical toy that some people have unjustifiably tried to use as a real, general-purpose programming language. It was never designed to be one. Most of the things I don't like about Ada are leftovers from Pascal, but at least it was designed as a general-purpose language -- and it lets you create processing abstractions (i.e. procedures) that are *allowed* to be independent of any attributes (like dimension of arrays or precision) that just may happen to be irrelevant to the algorithm. -/s/- BAM Bruce A. Martin Grumman Aircraft Systems [Address given for identification only.] (Mailstop B02-106) [Every conceivable disclaimer applies!!] Bethpage, NY 11714 [Opinions are mine only, & will change,] (516) 577-1426 [without notice, whenever appropriate!!]
LUKRW@vax1.cc.lehigh.edu (11/11/89)
"Full standard Pascal" permits variable dimensions via the conformant array construct. This is, however, a level 1 (optional) feature, not supported by Turbo Pascal. (In the ANSI compatibility section, non-support of optional features is not mentioned.) Since late binding is supported by the TP 5.5 OOP extensions, that would be one alternative. I do wish Borland would "get with the program" and stop ignoring the standard. Extensions are nice, but compatibility beats that any day of the week. There's no good excuse for an incomplete implementation in such a widely used product. Kevin Weiner Lehigh University Computing Center
dmurdoch@watstat.waterloo.edu (Duncan Murdoch) (11/12/89)
In article <9686@vax1.cc.lehigh.edu> LUKRW@vax1.cc.lehigh.edu writes: > I do wish Borland would "get with the program" and stop >ignoring the standard. Extensions are nice, but compatibility beats >that any day of the week. There's no good excuse for an incomplete >implementation in such a widely used product. I think you gave the excuse in your last 5 words - TP is selling well enough without compatibility, so why should they bother with the standard? I doubt very much it would increase sales detectably. Duncan Murdoch
ajayshah@aludra.usc.edu (Ajay Shah) (11/12/89)
>In article <9686@vax1.cc.lehigh.edu> LUKRW@vax1.cc.lehigh.edu writes: > I do wish Borland would "get with the program" and stop >ignoring the standard. Extensions are nice, but compatibility beats On this issue, I'm squarely on the side of Borland. Standard Pascal is a reasonably crippled creature: no hooks for seperate compilation, no breakouts from strong typing, stupid file handling, etc. Borland has enabled some of the most satisfying programming of my life by crafting a language which combines the basic beauty of Pascal with the minimal extensions needed to bring it closer to real-world programming. Turbo Pascal might have slowed the advent of Modula, but it sure made the life of millions of users a lot happier. The most important single aspect where i might have differed from Borland is that i'd have taken more trouble to create TP implementations for a coupla other standard machines (Sun, Mac, etc.). That way, a user has more portability. I've often got stranded when trying to move from the PC to a Sun. -- _______________________________________________________________________________ Ajay Shah, (213)747-9991, ajayshah@usc.edu The more things change, the more they stay insane. _______________________________________________________________________________
schwartz@psuvax1.cs.psu.edu (Scott Schwartz) (11/12/89)
In article <6422@merlin.usc.edu> ajayshah@aludra.usc.edu (Ajay Shah) writes: >In article <9686@vax1.cc.lehigh.edu> LUKRW@vax1.cc.lehigh.edu writes: > I do wish Borland would "get with the program" and stop >ignoring the standard. Extensions are nice, but compatibility beats On this issue, I'm squarely on the side of Borland. Standard Pascal is a reasonably crippled creature: no hooks for seperate compilation, no breakouts from strong typing, stupid file handling, etc. The fact of the matter is that the ISO standard specifies that language extensions are permitted. In other words, the seperate compilation stuff, breakouts from strong typing, etc, etc, are all ok. The problem is that Borland, for no sensible reason, omitted lots of required functionality. If you are so excited by features, then ask yourself why Borland omitted conformant arrays, procedure parameters, and the elegant i/o model that the standard requires. In my humble opinion, the reason they left these things out is pretty clear to anyone who read the documentation that came with the early versions of the compiler: they wanted a quick and easy implementation for the CP/M systems that were popular at the time. Anything the compiler writer didn't understand, didn't want to spend time on, or didn't feel like using simply got left out. -- Scott Schwartz <schwartz@shire.cs.psu.edu> "More mips; cheaper mips; never too many." -- John Mashey
dmurdoch@watstat.waterloo.edu (Duncan Murdoch) (11/13/89)
In article <1989Nov12.040036.10887@psuvax1.cs.psu.edu> schwartz@psuvax1.cs.psu.edu (Scott Schwartz) writes: >The problem is that Borland, for no sensible reason, omitted lots of >required functionality. If you are so excited by features, then ask >yourself why Borland omitted conformant arrays, procedure parameters, >and the elegant i/o model that the standard requires. You're right about conformant arrays, but Borland has included procedure parameters, and the elegance of standard Pascal I/O is debatable when you hear about the compromises that have to be made to deal with interactive I/O. >In my humble >opinion, the reason they left these things out is pretty clear to >anyone who read the documentation that came with the early versions of >the compiler: they wanted a quick and easy implementation for the CP/M >systems that were popular at the time. Anything the compiler writer >didn't understand, didn't want to spend time on, or didn't feel like >using simply got left out. That's a reasonable explanation for the early releases, but TP is a mature compiler now. Borland has had lots of time to program conformant arrays and Pascal style I/O, but has chosen not to. Why don't we all agree that TP is not Pascal, and forget the standard? Let's change the name of this group to comp.lang.tp, and drop comp.lang.pascal, because it deals with an old, irrelevant language (1/2 :-). Duncan Murdoch
amull@Morgan.COM (Andrew P. Mullhaupt) (11/13/89)
Turbo Pascal supports procedure and function parameters in all
versions >= 5.0. The useful extension procedure and function
types is also supported.
The failure to support ISO level 1 extensions (conformant array
parameters) cannot, strictly speaking be considered a failure
to conform to the ISO standard. ANSI only supports ISO level 0,
so level 1 support is strictly speaking, and ANSI extension.
Borland and Microsoft (following Borland's lead) are off on some
tangent to Pascal: Object extensions. While what we probably need
are extensible arrays and removal of segmentation restrictions
(and no stupid 'huge' keyword nonsense, either!) the big two
Pascal vendors seem to be preoccupied with marketing.
As far as the dreaded file I/O goes, get real guys. Pascal clearly
intends this operating system dependent stuff to be ingored by
the standard, and handled by extensions, for the most part. Thus
you need to write a collection of primitives for I/O that are
implemented for each OS you need. If you write all your code
in terms of ISO standrard invocations of your I/O routines, then
you can port anything to any OS where you have implemented your
primitives. Anyone who has a great stake in multiple machine
ports of software should be willing to invest the time to write
a few I/O routines and then paste up the appropriate source@c{" in
an automated way. I have found that this approach actually can
result in efficiency gains, and I've yet to lose anywhere near
the time porting Pascal as I have lost porting C.
Later,
Andrew MullhauptLUKRW@vax1.cc.lehigh.edu (11/13/89)
In article <6422@merlin.usc.edu>, ajayshah@aludra.usc.edu (Ajay Shah) writes: > > On this issue, I'm squarely on the side of Borland. Standard Pascal > is a reasonably crippled creature: no hooks for seperate compilation, > no breakouts from strong typing, stupid file handling, etc. ..... There's no doubt that TP is a fine product. The original question was how to handle arrays of different sizes. Bottom line is that if you're using the "crippled" standard Pascal, it's no problem; in TP, you do some sort of work-around. Conformant arrays were established as part of the ANSI/ISO draft standard long before Borland released their first CP/M compiler. You'd think they'd have caught up by now. It's a constant problem for programmers, and conformant arrays aren't even that difficult to implement. On the other hand, TP 5.5's object extensions are so cumbersome that maybe it is just a case of lazy programming. Kevin Weiner Lehigh University Computing Center