On Tue, 13 Mar 2007, Jim Lux wrote:
I should mention that if you want to really obfuscate things, you could do
something like
IF (0) 901,902,903
because you know that only 902 will be a target. And, almost all compilers
could figure out that the argument is fixed, so it would emit a
will recognize that the cases are 1,2,3,...N and optimize
with a look up table accordingly. I checked only once, about 15
compiler writers do try hard to stay abreast of actual hardware
behavior. this is a good example: the look-up-table approach is
clearly not the fastest for some (many?) c
At 05:30 PM 3/13/2007, Robert G. Brown wrote:
On Tue, 13 Mar 2007, Jim Lux wrote:
Now that I think about it, I actually quite liked working in PL/I.
Me too.
it's easy to write without GOTOs in FORTRAN...
IF (0) 902,902,902
is the same as
GOTO 902
Again, I'm left speechless
On Tue, 13 Mar 2007, Jim Lux wrote:
At 04:03 PM 3/13/2007, Greg Lindahl wrote:
On Tue, Mar 13, 2007 at 05:58:53PM -0400, Joe Landman wrote:
> If your need for speed increases faster than Moore's law will give you
> performance for,
... clusters have been getting bigger, and thus for many apps
On Tue, 13 Mar 2007, Jim Lux wrote:
Now that I think about it, I actually quite liked working in PL/I.
Me too.
it's easy to write without GOTOs in FORTRAN...
IF (0) 902,902,902
is the same as
GOTO 902
Again, I'm left speechless. I wonder if I would have gotten credit on
al
At 04:32 PM 3/13/2007, you wrote:
On Tue, Mar 13, 2007 at 12:59:49PM -0700, Jim Lux wrote:
> Which syntax compiler writers hate, because you can't use a parser
> that always moves forward. (But compiler writers love FORTH)
Er, compiler writers (like the ones around here) know that parsing is
t
> Jim Lux <[EMAIL PROTECTED]> wrote
>
> it's easy to write without GOTOs in FORTRAN...
>
> IF (0) 902,902,902
>
Spaghetti code goto was evil, but I miss computed goto. So long as
one was careful to exit every section with a goto to the same
exit point it was well structured and it was
Wow, thanks everyone! That's exactly what I needed to hear.
Without trying to go too Off-Topic, I just want to add to the "What
Comp-Sci depts teach to students":
Here at UofWaterloo, in the Faculty of Math, it is a requirement for
all undergrads to take CS courses, which for most only means the
Greg Lindahl wrote:
On Tue, Mar 13, 2007 at 05:58:53PM -0400, Joe Landman wrote:
If your need for speed increases faster than Moore's law will give you
performance for,
... clusters have been getting bigger, and thus for many apps,
sustained performance has been growing faster than Moore's La
At 04:03 PM 3/13/2007, Greg Lindahl wrote:
On Tue, Mar 13, 2007 at 05:58:53PM -0400, Joe Landman wrote:
> If your need for speed increases faster than Moore's law will give you
> performance for,
... clusters have been getting bigger, and thus for many apps,
sustained performance has been growi
On Tue, Mar 13, 2007 at 12:59:49PM -0700, Jim Lux wrote:
> Which syntax compiler writers hate, because you can't use a parser
> that always moves forward. (But compiler writers love FORTH)
Er, compiler writers (like the ones around here) know that parsing is
the easiest part of compiling, so th
On Tue, Mar 13, 2007 at 05:58:53PM -0400, Joe Landman wrote:
> If your need for speed increases faster than Moore's law will give you
> performance for,
... clusters have been getting bigger, and thus for many apps,
sustained performance has been growing faster than Moore's Law for
quite some ti
At 02:58 PM 3/13/2007, Joe Landman wrote:
Pointers? Anathema! I'll bet you even do things like topological
sorts and other stuff out of Knuth, instead of nice clean matrix
math. If you don't know how big your arrays are and how many you
need before you start, then you don't understand your pr
At 02:18 PM 3/13/2007, Robert G. Brown wrote:
On
And really old people also remember Our Old Friend, PL/C, which never
met a line of code it didn't like.
Designed as competition(?) for Basic, really.. It was used for
introductory programming classes at UCLA in 1977 and 1978 as an
"easy" form
Jim Lux wrote:
Precisely.. the FORTRAN compiler can make use of real hot rod hardware
(think of vector processors) without you, the coder, having to be much
aware of it.
This is quite important to making things work well. Abstract the
hardware. Hide it from the user. Make the compiler "sm
I thought it was getting normal for large enough places to have multiple
departments? I expect EE to teach C, CIS to teach LISP, or whatever is
cutting edge in the theory of artificial linguistics, and the business
school to teach COBOL and VisualBASIC.
But maybe I'm spoiled by OSU. They have mor
> If you don't
> know how big your arrays are and how many you need before you start,
then you
> don't understand your problem well enough. Dynamic allocation is a sign
of
> weak will, or worse.
I just deleted so much that I've lost attribution, but y'all know who you
are :-)
Of course
On Tue, 13 Mar 2007, David Mathog wrote:
Nobody knows why CPS departments no longer teach students
to code in C (and instead teach a bizarre mix of C++, java, lisp, and
god-knows-what else first.
I know, I know! The folks who teach computer science consider
functional languages like C and For
On Tue, 13 Mar 2007, Jim Lux wrote:
Pascal was, and remains, the German of compilers. All sentences must at
the end a verb have. Declarations and definitions of all entities must
occur in strict order. Differences in passing by reference vs value,
especially for functions a la your example bel
On 3/13/07, Lombard, David N <[EMAIL PROTECTED]> wrote:
On Tue, Mar 13, 2007 at 12:33:50PM -0500, Peter St. John wrote:
> Brown Dai-Sensei-Sama,
>
[deletia]
>
> Re: FORTRAN, for awhile there we didn't really compile it, but translate
it
> to C and then invoke the C compiler. That gets you the be
>"Robert G. Brown" <[EMAIL PROTECTED]> wrote:
> Also you can do amazing things with C and actually
> understand what the computer is doing when you do them.
I'd like to add that by "understand" you could read "debug with ease".
Parallel debugging is miserable enough without having to wonder wher
At 11:55 AM 3/13/2007, Robert G. Brown wrote:
On Tue, 13 Mar 2007, Peter St. John wrote:
instead of {} is just dumb. Almost
as dumb as
DO 100 I=1,N
100 CONTINUE
Which syntax compiler writers hate, because you can't use a parser
that always moves forward. (But compiler
At 10:42 AM 3/13/2007, Jeffrey B. Layton wrote:
Glen Beane wrote:
Kyle Spaans wrote:
does that mean I
should suck it up and learn Fortran/C/C++?
Ouch this hurts! I've gotten the same rubbing from RGB. I hate to
say it, but I'm a Fortran programmer ("Hi! My name is Jeff and I'm
a Fortran
At 10:33 AM 3/13/2007, Peter St. John wrote:
Brown Dai-Sensei-Sama,
Regarding "...Nobody knows why CPS departments no longer teach
students to code in C (and instead teach a bizarre mix of C++, java,
lisp, and god-knows-what else first -- at one time they just LOVED
pascal and where is THAT n
On Tue, 13 Mar 2007, Peter St. John wrote:
Brown Dai-Sensei-Sama,
Regarding "...Nobody knows why CPS departments no longer teach students to
code in C (and instead teach a bizarre mix of C++, java, lisp, and
god-knows-what else first -- at one time they just LOVED pascal and where is
THAT now I
On Tue, Mar 13, 2007 at 12:33:50PM -0500, Peter St. John wrote:
> Brown Dai-Sensei-Sama,
>
[deletia]
>
> Re: FORTRAN, for awhile there we didn't really compile it, but translate it
> to C and then invoke the C compiler. That gets you the beauty of the IMSL
> libraries and the efficiency of very s
Jeffrey B. Layton wrote:
Ouch this hurts! I've gotten the same rubbing from RGB. I hate to
say it, but I'm a Fortran programmer ("Hi! My name is Jeff and I'm
a Fortran programmer. Hi! Jeff!"). I know C reasonably well (except
for the esoteric garbage) and I code in Python and the usual assortmen
On Tue, 13 Mar 2007 12:54:46 -0400 (EDT) "Robert G. Brown"
<[EMAIL PROTECTED]> wrote:
> On Tue, 13 Mar 2007, Kyle Spaans wrote:
>
> > Do I really need MPI/OpenMPI/OpenMP/PVM? If so, does that mean I
> > should suck it up and learn Fortran/C/C++? Or can I just devise my
> > own message passing sys
Jeffrey B. Layton wrote:
I know this will set off a language war, but I've found that anything
technical or scientific I need to code is always easier in Fortran than
anything else (well except Matlab, but I usually prototype in Matlab
and move to Fortran for extra speed). For many other tasks,
Brown Dai-Sensei-Sama,
Regarding "...Nobody knows why CPS departments no longer teach students to
code in C (and instead teach a bizarre mix of C++, java, lisp, and
god-knows-what else first -- at one time they just LOVED pascal and where is
THAT now I aske you), ..."
Pascal, C, C++, Java, and L
On Tue, 13 Mar 2007, Kyle Spaans wrote:
Do I really need MPI/OpenMPI/OpenMP/PVM? If so, does that mean I
should suck it up and learn Fortran/C/C++? Or can I just devise my own
message passing system to help me parallelize the workload? For
example, TCP sockets were mentioned. In my CS class I le
Glen Beane wrote:
Kyle Spaans wrote:
does that mean I
should suck it up and learn Fortran/C/C++?
If you really want to get into parallel programming, you really should know C
(actually I think everyone should know C). C++ isn't too much of a stretch once
you know C (if you learn the
Kyle,
I know it's easy to always say "study more"; I'm sure your professors have
plenty for you to do. However, if you want to program stuff yourself, I urge
you accept (at least) two languages. C/C++ is the only way to go for such
things as linux kernel hacking. LISP is a huge window of insight i
Kyle Spaans wrote:
does that mean I
> should suck it up and learn Fortran/C/C++?
If you really want to get into parallel programming, you really should know C
(actually I think everyone should know C). C++ isn't too much of a stretch once
you know C (if you learn the concepts of OO programming
Hello Beowulf list.
Some of you may remember me from earlier in the summer. Well, after
nearly a year of lurking, I'm back!
As a background update: I'm at the University of Waterloo, studying
math in a program called Computational Math [solving problems
computationally, sound familiar? haw haw ha
35 matches
Mail list logo