* Re: Fortran vs C++ vs. etc (has little to do with realtime anymore) @ 1997-09-13 0:00 Dr. Krishnan Chittur 1997-09-15 0:00 ` Area Industrial y Electromec�nica ` (2 more replies) 0 siblings, 3 replies; 19+ messages in thread From: Dr. Krishnan Chittur @ 1997-09-13 0:00 UTC (permalink / raw) Joseph M. O'Leary (NOSPAMjmoleary@earthlink.net) wrote: : Jeffrey Templon <templon@studbolt.physast.uga.edu> wrote in article : > The fact remains (and will for some time) that many scientific : programmers : > are scientists FIRST and programmers SECOND. ........ : > So one of my reasons for Fortran still being around: you can write : > a reasonable program which runs reasonably efficiently just by more : > or less typing in an expression of a simple algorithm. Fortran's "mental : > model" of the computer is very simple. Well said! ... I still have to find an environment that will allow me to develop a GUI as simply as I can write Fortran Code to do calculations ... if there is one, please let me know. There is this debate in the Chemical Engineering Community about whether we should teach Fortran at all ... We are currently on the side that says "yes" we should. More than Fortran itself, what we are trying to do is to teach the elements of programming ... the idea that you should plan the project, have an idea of what you want the program to do, design the "structure" ... and then write the code ... when you want to say "calculate the square root" ... find out if you need to write the program or use something that is supplied by compiler or perhaps a set of callable routines written by someone else ... In a programming course, students also learn how to develop a "set of routines" .. one problem is that at the time they are learning to program, often they do not have the background in math ... for example it is difficult at the freshman level to have students attempt to write Fortran Code to solve say linear algebraic problems ... Anyway ... Fortran is still around, will be around for a while ... students MUST know how to deal with it's many strange properties ... 4 to 6 weeks exposing them to elements of fortran 77 is worth the time ... Fortran 90 and F are I think a step in the right direction, let's see how it develops ... ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Fortran vs C++ vs. etc (has little to do with realtime anymore) 1997-09-13 0:00 Fortran vs C++ vs. etc (has little to do with realtime anymore) Dr. Krishnan Chittur @ 1997-09-15 0:00 ` Area Industrial y Electromec�nica 1997-09-16 0:00 ` Vanesch P. 1997-09-16 0:00 ` Rick Hawkins 2 siblings, 0 replies; 19+ messages in thread From: Area Industrial y Electromec�nica @ 1997-09-15 0:00 UTC (permalink / raw) To: chitturk I agree with you completely Jose Jimenez, msme ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Fortran vs C++ vs. etc (has little to do with realtime anymore) 1997-09-13 0:00 Fortran vs C++ vs. etc (has little to do with realtime anymore) Dr. Krishnan Chittur 1997-09-15 0:00 ` Area Industrial y Electromec�nica @ 1997-09-16 0:00 ` Vanesch P. 1997-09-16 0:00 ` Jeffrey Templon 1997-09-16 0:00 ` Rick Hawkins 2 siblings, 1 reply; 19+ messages in thread From: Vanesch P. @ 1997-09-16 0:00 UTC (permalink / raw) Dr. Krishnan Chittur (chitturk@email.uah.edu) wrote: : Joseph M. O'Leary (NOSPAMjmoleary@earthlink.net) wrote: : : Jeffrey Templon <templon@studbolt.physast.uga.edu> wrote in article : : > The fact remains (and will for some time) that many scientific : : programmers : : > are scientists FIRST and programmers SECOND. : ........ : : > So one of my reasons for Fortran still being around: you can write : : > a reasonable program which runs reasonably efficiently just by more : : > or less typing in an expression of a simple algorithm. Fortran's "mental : : > model" of the computer is very simple. : Well said! ... I still have to find an environment that will allow : me to develop a GUI as simply as I can write Fortran Code to : do calculations ... if there is one, please let me know. I think this is an essential point. FORTRAN is well-suited to do calculations and hard-core scientific computation. But more complex structures (a GUI is program-wise a lot more complicated than a scientific calculation) are not dealt too well with in fortran I think. I've seen this in the high-energy community. Both elements are present there: complex software systems and hard-core scientific computing. Well, I've seen quite a mess in the FORTRAN implementation (rather ad hoc) of the complicated datastructures that had to be manipulated. It would have been much better done (and the tendency now is - finally - to switch to things like C++) in a language suited for the task. On the other hand, I've also seen the opposite. A collegue of mine wrote a MONSTER program in C++ to do some straightforward matrix manipulations. The graphical user interface launches tens and tens of windows in which one can manipulate parameters, look at graphs etc... He worked for almost a year on the thing. He is a computer scientist, btw, I'm not. I'm an engineer and physicist. It takes about 10 minutes to even start up the thing, getting your X-terminal cluttered with all those windows. I've done the same thing in F77, but with an ASCII steering file, in about a month... and guess what ? my program tackles systems he can't even dream of handling in just a few hours (his can't do it, it just runs out of 1 GB swap space !!) I get a nice ASCII file with my results. For smaller systems, my program is about 20 times faster, with less memory, than his, on the same system. I think every language has its uses. FORTRAN is old and very elementary on the conceptual level. For most modern computing applications (graphics, process steering, multi-user things etc) it is simply too elementary. But for applications where these elementary concepts are sufficient (such as scientific computing - which is usually advanced on the scientific level and very simple on the computational level) it allows indeed to write a reasonably simple program that behaves resonably well by someone who has some reasonable knowledge of computers but is not a computer scientist, without involving a lot of abstract computer-think. But if the project is too ambitious, and the abstract computer think is really needed, well... I don't think it is a good idea to do it in FORTRAN. cheers, Patrick. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Fortran vs C++ vs. etc (has little to do with realtime anymore) 1997-09-16 0:00 ` Vanesch P. @ 1997-09-16 0:00 ` Jeffrey Templon 1997-09-16 0:00 ` Gary L. Scott 0 siblings, 1 reply; 19+ messages in thread From: Jeffrey Templon @ 1997-09-16 0:00 UTC (permalink / raw) pvanesch@vub.ac.be (Vanesch P.) writes: > I think this is an essential point. FORTRAN is well-suited to do > calculations and hard-core scientific computation. But more > complex structures (a GUI is program-wise a lot more complicated > than a scientific calculation) are not dealt too well with in > fortran I think. I've seen this in the high-energy community. > Both elements are present there: complex software systems and > hard-core scientific computing. Well, I've seen quite a mess > in the FORTRAN implementation (rather ad hoc) of the complicated > datastructures that had to be manipulated. It would have been > much better done (and the tendency now is - finally - to switch > to things like C++) in a language suited for the task. I agree that there are problems that get too complex for Fortran, at least for Fortran-77. I'm not sure these limitations apply to Fortran-90, given the appearance of derived types and allocatable arrays. Perhaps F90 is not enough, but I think C++ is not the answer for people who aren't professional programmers. Ada looks like it might be easier for a normal human to work with and read, but I haven't spent much time playing with it. JAT ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Fortran vs C++ vs. etc (has little to do with realtime anymore) 1997-09-16 0:00 ` Jeffrey Templon @ 1997-09-16 0:00 ` Gary L. Scott 1997-09-17 0:00 ` Jenn-Ching Luo 0 siblings, 1 reply; 19+ messages in thread From: Gary L. Scott @ 1997-09-16 0:00 UTC (permalink / raw) The problem of developing a GUI in Fortran is one of designing an appropriate API for Fortran. This used to be done quite commonly (language-specific API bindings). I have developed "graphical user interfaces" in Fortran that were highly functional (a little slow, it was 10 years ago) and very easy to develop because the API was designed "appropriately". The problem is really one of UNIX/Windows APIs being "low-level" C-oriented APIs. It is great that Fortran is being extended in ways which allow it to be able to call other languages and APIs designed for other languages, however, I shouldn't have to. OS or compiler vendors should supply language tailored API bindings. It's more work for them, but a lot less work for me, as an application developer who just wants to produce a useful product without the hassle of inter language communication which requires me to essentially know two (or more) languages, usually one of which has an appalling syntax that makes me cringe). I vote for a reduction in complexity (the K.I.S.S. principle) in the area of OS API calls from Fortran (or PASCAL or COBOL or PL/1 or <insert legacy language here>. Is anybody listening? Come on, there's only 1500 or so WIN API calls, how much work could that be...). Jeffrey Templon wrote: > pvanesch@vub.ac.be (Vanesch P.) writes: > > > I think this is an essential point. FORTRAN is well-suited to do > > calculations and hard-core scientific computation. But more > > complex structures (a GUI is program-wise a lot more complicated > > than a scientific calculation) are not dealt too well with in > > fortran I think. I've seen this in the high-energy community. > > Both elements are present there: complex software systems and > > hard-core scientific computing. Well, I've seen quite a mess > > in the FORTRAN implementation (rather ad hoc) of the complicated > > datastructures that had to be manipulated. It would have been > > much better done (and the tendency now is - finally - to switch > > to things like C++) in a language suited for the task. > > I agree that there are problems that get too complex for Fortran, at > least for Fortran-77. I'm not sure these limitations apply to > Fortran-90, given the appearance of derived types and allocatable > arrays. > Perhaps F90 is not enough, but I think C++ is not the answer for > people who aren't professional programmers. Ada looks like it might > be easier for a normal human to work with and read, but I haven't > spent > much time playing with it. > > JAT ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Fortran vs C++ vs. etc (has little to do with realtime anymore) 1997-09-16 0:00 ` Gary L. Scott @ 1997-09-17 0:00 ` Jenn-Ching Luo 1997-09-17 0:00 ` Gary L. Scott 0 siblings, 1 reply; 19+ messages in thread From: Jenn-Ching Luo @ 1997-09-17 0:00 UTC (permalink / raw) Gary L. Scott <scottg@flash.net> wrote in article <341F22C2.C46CE5F4@flash.net>... > The problem of developing a GUI in Fortran is one of designing an > appropriate API for Fortran. ..... > .................................................. > however, I shouldn't have to. OS or > compiler vendors should supply language tailored API bindings. It's > more work for them, but a lot less work for me, as an application > developer who just wants to produce a useful product without the hassle > of inter language > Just like most of developers, I started programming Windows Applications in C++ for a short period. I personal like to use Fortran, and I gave up C++ for Windows programming. There is no trouble and problem to call WIN API from Fortran. If compiler (i.e. Fortran) vendors can provide more info, examples, or documents for programming Windows applications (not quick win) in Fortran, that certainly may help Fortran programmers. Jenn-Ching Luo http://www.Equation.com/People/Luo.htm ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Fortran vs C++ vs. etc (has little to do with realtime anymore) 1997-09-17 0:00 ` Jenn-Ching Luo @ 1997-09-17 0:00 ` Gary L. Scott 0 siblings, 0 replies; 19+ messages in thread From: Gary L. Scott @ 1997-09-17 0:00 UTC (permalink / raw) Jenn-Ching Luo wrote: > Gary L. Scott <scottg@flash.net> wrote in article > <341F22C2.C46CE5F4@flash.net>... > > The problem of developing a GUI in Fortran is one of designing an > > appropriate API for Fortran. ..... > > .................................................. > > however, I shouldn't have to. > OS > or > > compiler vendors should supply language tailored API bindings. It's > > > more work for them, but a lot less work for me, as an application > > developer who just wants to produce a useful product without the > hassle > > of inter language > > > > Just like most of developers, I started programming Windows > Applications in > C++ for a short period. I personal like to use Fortran, and I gave up > C++ > for Windows programming. There is no trouble and problem to call WIN > API > from Fortran. > > If compiler (i.e. Fortran) vendors can provide more info, examples, or > > documents for programming Windows applications (not quick win) in > Fortran, > that certainly may help Fortran programmers. > > Jenn-Ching Luo > http://www.Equation.com/People/Luo.htm This is highly dependent upon your compiler's support for extensions to the standard call syntax. If you're calling Windows APIs, you're probably not programming in "standard compliant" Fortran (when you use these extensions). Some people don't mind or require this. I prefer the simpler call syntax of "standard" Fortran. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Fortran vs C++ vs. etc (has little to do with realtime anymore) 1997-09-13 0:00 Fortran vs C++ vs. etc (has little to do with realtime anymore) Dr. Krishnan Chittur 1997-09-15 0:00 ` Area Industrial y Electromec�nica 1997-09-16 0:00 ` Vanesch P. @ 1997-09-16 0:00 ` Rick Hawkins 1997-09-18 0:00 ` Oleg Krivosheev 2 siblings, 1 reply; 19+ messages in thread From: Rick Hawkins @ 1997-09-16 0:00 UTC (permalink / raw) In article <5ve7c6$f4m$1@info.uah.edu>, Dr. Krishnan Chittur <chitturk@email.uah.edu> wrote: >Joseph M. O'Leary (NOSPAMjmoleary@earthlink.net) wrote: > >: Jeffrey Templon <templon@studbolt.physast.uga.edu> wrote in article >: > The fact remains (and will for some time) that many scientific >: programmers >: > are scientists FIRST and programmers SECOND. >........ >: > So one of my reasons for Fortran still being around: you can write >: > a reasonable program which runs reasonably efficiently just by more >: > or less typing in an expression of a simple algorithm. Fortran's "mental >: > model" of the computer is very simple. >Well said! ... I still have to find an environment that will allow >me to develop a GUI as simply as I can write Fortran Code to >do calculations ... if there is one, please let me know. yes!!! learning c++ after not using c for ten years took some work. Fortran after 12 years didn't; I could sit back donw and code. I'm not going to knock c++; it's wonderful for where it belongs. But for my fairly simple models that just need numbers pounded into submission, and which won't be reused, Fortran is *much* easier, if for no other reason than high-level I/O. I was spending 2/3 of my time in c++ either writing pieces builit into fortran, or looking for libraries with the pieces. I think I switched when i couldn't find a max(), and couldn't figure out the single example of writing a function with variable number of arguments (actually, i used smalltalk for a while in between, but that's another story). Also, the bit on needing to define new classes for array bounds checking, rather than a compiler switch, was maddening . . . rick -- R E HAWKINS rhawkins@iastate.edu These opinions will not be those of ISU until they pay my retainer. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Fortran vs C++ vs. etc (has little to do with realtime anymore) 1997-09-16 0:00 ` Rick Hawkins @ 1997-09-18 0:00 ` Oleg Krivosheev 1997-09-19 0:00 ` Rick Hawkins 0 siblings, 1 reply; 19+ messages in thread From: Oleg Krivosheev @ 1997-09-18 0:00 UTC (permalink / raw) Hi, rhawkins@iastate.edu (Rick Hawkins) writes: > > In article <5ve7c6$f4m$1@info.uah.edu>, > Dr. Krishnan Chittur <chitturk@email.uah.edu> wrote: > > >Joseph M. O'Leary (NOSPAMjmoleary@earthlink.net) wrote: > > > >: Jeffrey Templon <templon@studbolt.physast.uga.edu> wrote in article > >: > The fact remains (and will for some time) that many scientific > >: programmers > >: > are scientists FIRST and programmers SECOND. > >........ > >: > So one of my reasons for Fortran still being around: you can write > >: > a reasonable program which runs reasonably efficiently just by more > >: > or less typing in an expression of a simple algorithm. Fortran's "mental > >: > model" of the computer is very simple. > > >Well said! ... I still have to find an environment that will allow > >me to develop a GUI as simply as I can write Fortran Code to > >do calculations ... if there is one, please let me know. > > yes!!! learning c++ after not using c for ten years took some work. > Fortran after 12 years didn't; I could sit back donw and code. well, if you're talking about F77, yes. FYI, there are already F90 and F95 here. I doubt you can program in F95 without learning - just as you did with C++. > I'm not going to knock c++; it's wonderful for where it belongs. But > for my fairly simple models that just need numbers pounded into > submission, and which won't be reused, Fortran is *much* easier, if for > no other reason than high-level I/O. I was spending 2/3 of my time in > c++ either writing pieces builit into fortran, or looking for libraries > with the pieces. I think I switched when i couldn't find a max(), and > couldn't figure out the single example of writing a function with > variable number of arguments (actually, i used smalltalk for a while in > between, but that's another story). hmm... cannot find max() in c++? couldn't figure how to write function with variable numbers of arguments? there is something wrong with your C++ installation or with your C/C++ book. OK ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Fortran vs C++ vs. etc (has little to do with realtime anymore) 1997-09-18 0:00 ` Oleg Krivosheev @ 1997-09-19 0:00 ` Rick Hawkins 1997-09-23 0:00 ` Oleg Krivosheev 0 siblings, 1 reply; 19+ messages in thread From: Rick Hawkins @ 1997-09-19 0:00 UTC (permalink / raw) In article <vi8k9ge42bw.fsf@drabble.fnal.gov>, Oleg Krivosheev <kriol@fnal.gov> wrote: >rhawkins@iastate.edu (Rick Hawkins) writes: >> yes!!! learning c++ after not using c for ten years took some work. >> Fortran after 12 years didn't; I could sit back donw and code. >well, if you're talking about F77, yes. FYI, there are already >F90 and F95 here. I doubt you can program in F95 without >learning - just as you did with C++. I'm using F90; It was Fortran IV on a pr1me and almost-f77 on tops 20 back then. >> I'm not going to knock c++; it's wonderful for where it belongs. But >> for my fairly simple models that just need numbers pounded into >> submission, and which won't be reused, Fortran is *much* easier, if for >> no other reason than high-level I/O. I was spending 2/3 of my time in >> c++ either writing pieces builit into fortran, or looking for libraries >> with the pieces. I think I switched when i couldn't find a max(), and >> couldn't figure out the single example of writing a function with >> variable number of arguments (actually, i used smalltalk for a while in >> between, but that's another story). >cannot find max() in c++? I tried. I looked. I'm convinced it must be there, but . . . >couldn't figure how to write function with variable numbers >of arguments? In the two books that I had, there was a single example, whihc managed not to explain. I wasn't just the issue of variable number of arguments, but of arbitrarily large variable numbers (i wanted my max()! :) >there is something wrong with your C++ installation >or with your C/C++ book. I assume it's the books; the compiler was either DEC cc or gcc; i forget now. rick -- R E HAWKINS rhawkins@iastate.edu These opinions will not be those of ISU until they pay my retainer. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Fortran vs C++ vs. etc (has little to do with realtime anymore) 1997-09-19 0:00 ` Rick Hawkins @ 1997-09-23 0:00 ` Oleg Krivosheev 1997-09-23 0:00 ` Gary L. Scott ` (2 more replies) 0 siblings, 3 replies; 19+ messages in thread From: Oleg Krivosheev @ 1997-09-23 0:00 UTC (permalink / raw) To: rhawkins Hi, Rick rhawkins@iastate.edu (Rick Hawkins) writes: > > > In article <vi8k9ge42bw.fsf@drabble.fnal.gov>, > Oleg Krivosheev <kriol@fnal.gov> wrote: > > >rhawkins@iastate.edu (Rick Hawkins) writes: > > >> yes!!! learning c++ after not using c for ten years took some work. > >> Fortran after 12 years didn't; I could sit back donw and code. > > >well, if you're talking about F77, yes. FYI, there are already > >F90 and F95 here. I doubt you can program in F95 without > >learning - just as you did with C++. > > I'm using F90; It was Fortran IV on a pr1me and almost-f77 on tops 20 > back then. well, that's exactly what i was asking about - there were NO F90/F95 twelve years ago ! If you're using F90 now, you learned it somehow. Either i misunderstood something or our claim "> >> Fortran after 12 years didn't; I could sit back donw and code." is wrong. > >cannot find max() in c++? > > I tried. I looked. I'm convinced it must be there, but . . . > > >couldn't figure how to write function with variable numbers > >of arguments? > > In the two books that I had, there was a single example, whihc managed > not to explain. I wasn't just the issue of variable number of > arguments, but of arbitrarily large variable numbers > (i wanted my max()! :) sorry, i have only min ;) well, try example below for min with arbitrary larger number of arguments. Hope it can help #include <assert.h> #include <stdio.h> #include <stdarg.h> double dmin( int nofargs, ... ) { double res = 1.0e+38, arg; int j; va_list ap; assert( nofargs > 1 ); va_start(ap, nofargs ); for( j = 0; j < nofargs; ++j ) { arg=va_arg( ap, double ); if ( arg < res ) { res = arg; } } va_end(ap); return res; } int main( void ) { printf( "%e\n", dmin( 2, 1.0, 2.0 ) ); printf( "%e\n", dmin( 3, 0.0, 1.0, 2.0 ) ); printf( "%e\n", dmin( 5, 0.0, 1.0, 2.0, 7.0, -0.2 ) ); return 0; } > >there is something wrong with your C++ installation > >or with your C/C++ book. > > I assume it's the books; the compiler was either DEC cc or gcc; i forget > now. code above works fine with gcc on Sparc/Solaris 2.5 box regards OK ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Fortran vs C++ vs. etc (has little to do with realtime anymore) 1997-09-23 0:00 ` Oleg Krivosheev @ 1997-09-23 0:00 ` Gary L. Scott 1997-09-24 0:00 ` Rick Hawkins 1997-09-25 0:00 ` const 2 siblings, 0 replies; 19+ messages in thread From: Gary L. Scott @ 1997-09-23 0:00 UTC (permalink / raw) Oleg Krivosheev wrote: > Hi, Rick > > rhawkins@iastate.edu (Rick Hawkins) writes: > > > > > > > In article <vi8k9ge42bw.fsf@drabble.fnal.gov>, > > Oleg Krivosheev <kriol@fnal.gov> wrote: > > > > >rhawkins@iastate.edu (Rick Hawkins) writes: > > > > >> yes!!! learning c++ after not using c for ten years took some > work. > > >> Fortran after 12 years didn't; I could sit back donw and code. > > > > >well, if you're talking about F77, yes. FYI, there are already > > >F90 and F95 here. I doubt you can program in F95 without > > >learning - just as you did with C++. > > > > I'm using F90; It was Fortran IV on a pr1me and almost-f77 on tops > 20 > > back then. > > well, that's exactly what i was asking about - there were NO > F90/F95 twelve years ago ! If you're using F90 now, you learned > it somehow. Either i misunderstood something or our claim > > "> >> Fortran after 12 years didn't; I could sit back donw and code." > > is wrong. However, a very large percentage of Fortran 90 features (even some of the new intrinsics) have been in some FORTRAN 77 compilers for minicomputers as extensions since the late 70's/early 80's. The main exceptions being array syntax and "non-sequence" derived types. So some of us have had a long time to learn them. I've used the following since around 1981: block do/end do (also for/end for, loop/end loop) ! comment free form source (almost identical to the current standard) variable # calling arguments (not F90/not keyword arguments/kinda messy) "Purdue" bit manipulation intrinsics direct physical memory address access ("Cray pointer" substitute?/not F90) ; record separator I'm sure others that I can't recall right now... That's why I have such a hard time believing how long it took to get some of them standardized and why some of them are still not in the standard (but are rumored). > > > > >cannot find max() in c++? > > > > I tried. I looked. I'm convinced it must be there, but . . . > > > > >couldn't figure how to write function with variable numbers > > >of arguments? > > > > In the two books that I had, there was a single example, whihc > managed > > not to explain. I wasn't just the issue of variable number of > > arguments, but of arbitrarily large variable numbers > > (i wanted my max()! :) > > sorry, i have only min ;) > > well, try example below for min with > arbitrary larger number of arguments. Hope it can help > > #include <assert.h> > #include <stdio.h> > #include <stdarg.h> > > double > dmin( int nofargs, ... ) { > > double res = 1.0e+38, arg; > int j; > va_list ap; > > assert( nofargs > 1 ); > > va_start(ap, nofargs ); > > for( j = 0; j < nofargs; ++j ) { > arg=va_arg( ap, double ); > if ( arg < res ) { > res = arg; > } > } > va_end(ap); > return res; > } > > int > main( void ) { > > printf( "%e\n", dmin( 2, 1.0, 2.0 ) ); > > printf( "%e\n", dmin( 3, 0.0, 1.0, 2.0 ) ); > > printf( "%e\n", dmin( 5, 0.0, 1.0, 2.0, 7.0, -0.2 ) ); > > return 0; > } > > > >there is something wrong with your C++ installation > > >or with your C/C++ book. > > > > I assume it's the books; the compiler was either DEC cc or gcc; i > forget > > now. > > code above works fine with gcc on Sparc/Solaris 2.5 box > > regards > > OK ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Fortran vs C++ vs. etc (has little to do with realtime anymore) 1997-09-23 0:00 ` Oleg Krivosheev 1997-09-23 0:00 ` Gary L. Scott @ 1997-09-24 0:00 ` Rick Hawkins 1997-09-24 0:00 ` Xingzeng Liu 1997-09-25 0:00 ` const 2 siblings, 1 reply; 19+ messages in thread From: Rick Hawkins @ 1997-09-24 0:00 UTC (permalink / raw) In article <vi8oh5keyy1.fsf@drabble.fnal.gov>, Oleg Krivosheev <kriol@fnal.gov> wrote: >Hi, Rick hi >rhawkins@iastate.edu (Rick Hawkins) writes: >> In article <vi8k9ge42bw.fsf@drabble.fnal.gov>, >> Oleg Krivosheev <kriol@fnal.gov> wrote: >> >rhawkins@iastate.edu (Rick Hawkins) writes: >> >> yes!!! learning c++ after not using c for ten years took some work. >> >> Fortran after 12 years didn't; I could sit back donw and code. >> >well, if you're talking about F77, yes. FYI, there are already >> >F90 and F95 here. I doubt you can program in F95 without >> >learning - just as you did with C++. >> I'm using F90; It was Fortran IV on a pr1me and almost-f77 on tops 20 >> back then. >well, that's exactly what i was asking about - there were NO >F90/F95 twelve years ago ! If you're using F90 now, you learned >it somehow. Either i misunderstood something or our claim Back then I used F77 and almost F77 (seems to me that DEC FORTRAN on TOPS 20 was somewhere between 66 and 77. But hey, we had a preproccessor fof this c++ thing :). That was about 83-84. I used some c back then, too. Rolling ahead to 95, learing c++ took work. I recoded a summer's worth of c++ and smalltalk to fortran 77 in a day and a half, not having looked at fortran since 84. Roll ahead to a couple of weeks ago, i picked up a F90 book, read a couple of chapters, and am happily using lots of it. >sorry, i have only min ;) > >well, try example below for min with >arbitrary larger number of arguments. Hope it can help I'm definitely saving this one. Thanks. There's a coupel of future pojects that will need objects, which will probably mean some c++. -- R E HAWKINS rhawkins@iastate.edu These opinions will not be those of ISU until they pay my retainer. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Fortran vs C++ vs. etc (has little to do with realtime anymore) 1997-09-24 0:00 ` Rick Hawkins @ 1997-09-24 0:00 ` Xingzeng Liu 0 siblings, 0 replies; 19+ messages in thread From: Xingzeng Liu @ 1997-09-24 0:00 UTC (permalink / raw) It should be known that C++ and C are totally different languages. I think for every one, to learn C++ is much more difficult than to learn others. If you can learn C, FORTRAN, or PASCAL with 2 weeks, then I think to learn C++ at least needs you 1 month. And you still need more than 1 month to practice it, to know the real style of C++. I use C++ for 5 years. I think C++ is a very good language. It is much suitable to do large complex simulations. It is reported in CERN that their large C++ simulation software (transfered from their original FORTRAN code) is faster than FORTRAN code. But for some small problem, C++ is not so good. And the depency of the non-standard library is also a big problem for C++. The super point in C++ is their ability to reuse. And there are so many different library of the basic object library. You may find you loss yourself when work in another platform. It is also very weak in numerical computation. So now I try to use FORTRAN 90. In my point of view, the new features such as Module, type etc. much improve the convenice in writing programs. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Fortran vs C++ vs. etc (has little to do with realtime anymore) 1997-09-23 0:00 ` Oleg Krivosheev 1997-09-23 0:00 ` Gary L. Scott 1997-09-24 0:00 ` Rick Hawkins @ 1997-09-25 0:00 ` const 1997-09-25 0:00 ` Oleg Krivosheev 2 siblings, 1 reply; 19+ messages in thread From: const @ 1997-09-25 0:00 UTC (permalink / raw) Oleg Krivosheev wrote: > > [skipped] > > sorry, i have only min ;) > > well, try example below for min with > arbitrary larger number of arguments. Hope it can help > > #include <assert.h> > #include <stdio.h> > #include <stdarg.h> > > double > dmin( int nofargs, ... ) { > > double res = 1.0e+38, arg; > int j; > va_list ap; > > assert( nofargs > 1 ); > > va_start(ap, nofargs ); > > for( j = 0; j < nofargs; ++j ) { > arg=va_arg( ap, double ); > if ( arg < res ) { > res = arg; > } > } > va_end(ap); > return res; > } > > int > main( void ) { > > printf( "%e\n", dmin( 2, 1.0, 2.0 ) ); > > printf( "%e\n", dmin( 3, 0.0, 1.0, 2.0 ) ); > > printf( "%e\n", dmin( 5, 0.0, 1.0, 2.0, 7.0, -0.2 ) ); > > return 0; > } > > [skipped] > OK, just to be pedantic, the previous example shows very fine the difference between fortran and C in computations. Since min/max are standard fortran functions, it can be supposed they are maximally optimized with no regards to number of their arguments (just because the compiler takes care of them). In the contrary, in the example, we have overhead of the arguments number evaluation and overhead of implementation (not necessarily this one, generally almost any non-trivial non-built-in operation has some overhead - there has been some reason to add into C libraries memcpy, memcmp and so on functions). Moreover the idea of such an implementation contains two great places to make bugs and definitely any user of such an implementation will be doing the bugs endlessly. Firstly, it is the programmer who should worry about conformity of the declared number of arguments to the actual one. In such cases, generally, adding or removing actual arguments, people tend to forget to correct the declared number. Secondly, there is no way for type checking and for type conversions, usage of 1 instead of 1.0 in the arguments list will cause very nasty problems. Using C++ and not C, most probably, I would try to implement the min function in the following way: inline double min(double v1, double v2) { return v1<v2 ? v1 : v2; } inline double min(double v1, double v2, double v3) { double v=min(v1,v2); return v<v3 ? v : v3; } inline double min(double v1, double v2, double v3, double v4) { double v=min(v1,v2,v3); return v<v4 ? v : v4; } inline double min(double v1, double v2, double v3, double v4, double v5) { double v=min(v1,v2,v3,v4); return v<v5 ? v : v5; } // and so on Such a way doesn't seem elegant enough and it only emulates arbitrary number of min-function arguments but it solves the types and the number-conformity problems. Trying to use non-defined min(huge-arguments-number), a programmer just gets compilation error and can easily extend the set of his min-functions. And the last but not least: the following example compiled with -O3 option with Sparc C++ 4.2 patch 104631-03 and started on SunOS 5.5.1 SUNW,Ultra-2 produces dmin: 3.04 seconds overloaded min: 1.11 seconds started on SunOS 5.5.1 SUNW,SPARCstation-4 produces: dmin: 9.32 seconds overloaded min: 4.89 seconds and compiled with -O option with HP C++ A.03.72; and started on HP-UX A.09.05 9000/715 produces: dmin: 4.63 seconds overloaded min: 1.58 seconds #include <sys/times.h> #include <limits.h> #include <iostream.h> extern double dmin(int, double, ...); //------------------------------------------------------ inline double min(double v1, double v2) { return v1<v2 ? v1 : v2; } inline double min(double v1, double v2, double v3) { double v=min(v1,v2); return v<v3 ? v : v3; } inline double min(double v1, double v2, double v3, double v4) { double v=min(v1,v2,v3); return v<v4 ? v : v4; } inline double min(double v1, double v2, double v3, double v4, double v5) { double v=min(v1,v2,v3,v4); return v<v5 ? v : v5; } //------------------------------------------------------ int main(void) { struct tms ts; clock_t clk, start; unsigned loop_len=6000000; unsigned loop; double dummy=0; start=times(&ts); loop=loop_len; while (loop--) dummy=dmin(5,1.0,2.0,3.0,dummy,(double)loop); clk=times(&ts)-start; cout << " dmin: " << double(clk)/CLK_TCK << " seconds" << endl; start=times(&ts); loop=loop_len; while (loop--) dummy=min(1.0,2.0,3.0,dummy,loop); clk=times(&ts)-start; cout << " overloaded min: " << double(clk)/CLK_TCK << " seconds" << endl; return 0; } //------------------------------------------------------ #include <stdarg.h> double dmin(int nofargs, double d, ...) { va_list ap; va_start(ap,d); while (--nofargs) { double v=va_arg(ap,double); if (v<d) d=v; } va_end(ap); return d; } //----------------------------------------------------- // End of File //----------------------------------------------------- //------------------------------------------------------------------ // Opinions expressed here are my own only // // Constantine Antonovich, Tel. : ++972-8-942-3819 // software engineer, Fax : ++972-8-942-3955 // Orbotech Ltd., P.O.Box 215, Email: const@orbotech.co.il // Yavne 81102, Israel //------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Fortran vs C++ vs. etc (has little to do with realtime anymore) 1997-09-25 0:00 ` const @ 1997-09-25 0:00 ` Oleg Krivosheev 0 siblings, 0 replies; 19+ messages in thread From: Oleg Krivosheev @ 1997-09-25 0:00 UTC (permalink / raw) To: const Hi, Constantine Antonovich: <const@orbotech.co.il> writes: > > Oleg Krivosheev wrote: > > > > [skipped] > > > > sorry, i have only min ;) > > > > well, try example below for min with > > arbitrary larger number of arguments. Hope it can help > > > > #include <assert.h> > > #include <stdio.h> > > #include <stdarg.h> > > > > double > > dmin( int nofargs, ... ) { > > > > double res = 1.0e+38, arg; > > int j; > > va_list ap; > > > > assert( nofargs > 1 ); > > > > va_start(ap, nofargs ); > > > > for( j = 0; j < nofargs; ++j ) { > > arg=va_arg( ap, double ); > > if ( arg < res ) { > > res = arg; > > } > > } > > va_end(ap); > > return res; > > } > > > > int > > main( void ) { > > > > printf( "%e\n", dmin( 2, 1.0, 2.0 ) ); > > > > printf( "%e\n", dmin( 3, 0.0, 1.0, 2.0 ) ); > > > > printf( "%e\n", dmin( 5, 0.0, 1.0, 2.0, 7.0, -0.2 ) ); > > > > return 0; > > } > > > > [skipped] > > > OK, just to be pedantic, the previous example shows very fine > the difference between fortran and C in computations. Since gu ? > min/max are standard fortran functions, it can be supposed they > are maximally optimized with no regards to number of their > arguments (just because the compiler takes care of them). well, FYI, being standard means only that - being standard. Compiler is free to optimize or to insert 5min loop into min/max function. > In the contrary, in the example, we have overhead of the > arguments number evaluation sure... if you know how do not evaluate number of arguments for functions (not min/max in particular) with arbitrary number of arguments, please share your knowledge with us. > and overhead of implementation (not > necessarily this one, generally almost any non-trivial > non-built-in operation has some overhead - there has been some > reason to add into C libraries memcpy, memcmp and so on > functions). what do you mean "overhead"? Can you clarify ? > Using C++ and not C, most probably, I would try to implement > the min function in the following way: > > inline double min(double v1, double v2) { > return v1<v2 ? v1 : v2; > } > inline double min(double v1, double v2, double v3) { > double v=min(v1,v2); return v<v3 ? v : v3; > } > inline double min(double v1, double v2, double v3, double v4) { > double v=min(v1,v2,v3); return v<v4 ? v : v4; > } > inline double min(double v1, double v2, double v3, double v4, double v5) > { > double v=min(v1,v2,v3,v4); return v<v5 ? v : v5; > } please, don't change the nature of the problem - Rick was asking about min/max function with ARBITRARY number of arguments. > Such a way doesn't seem elegant enough and it only emulates > arbitrary number nope. it's not. If the problem is to provide function which can handle arbitrary number of arguments, it cannot be solved by providing function(s) which can handle limited number of arguments. Try to reread logic textbook next time. > started on SunOS 5.5.1 SUNW,Ultra-2 produces > dmin: 3.04 seconds > overloaded min: 1.11 seconds > started on SunOS 5.5.1 SUNW,SPARCstation-4 produces: > dmin: 9.32 seconds > overloaded min: 4.89 seconds > and compiled with -O option with HP C++ A.03.72; and started on > HP-UX A.09.05 9000/715 produces: > dmin: 4.63 seconds > overloaded min: 1.58 seconds well, you compare apples and oranges. You provided solution for related but another problem than Rick was asking for. still, you know better way to handle functions with arbitrary number of arguments (using C++, templates, exceptions whatever), please, share it with us. OK ^ permalink raw reply [flat|nested] 19+ messages in thread
[parent not found: <199709070005.TAA23336@manifold.algebra.com>]
[parent not found: <5utbth$rdi@snews2.zippo.com>]
[parent not found: <34131554.73F2310E@roda.roc.servtech.com>]
[parent not found: <34157696.16620299@nntp.interaccess.com>]
[parent not found: <JTV2J.97Sep9170655@cobra.cs.virginia.edu>]
[parent not found: <3415CE44.3BD531@calfp.co.uk>]
[parent not found: <341644F2.763D@BZZvnet.ibm.com>]
* Fortran vs C++ vs. etc (has little to do with realtime anymore) [not found] ` <341644F2.763D@BZZvnet.ibm.com> @ 1997-09-12 0:00 ` Jeffrey Templon 1997-09-13 0:00 ` Joseph M. O'Leary 0 siblings, 1 reply; 19+ messages in thread From: Jeffrey Templon @ 1997-09-12 0:00 UTC (permalink / raw) "Igor Chudov @ home" <ichudov@algebra.com> writes: > Brian Thomson <thomson@vnet.ibm.com> wrote: > * a FORTRAN optimizer knows that A and B cannot be modified by the [ ... ] > * In C++ there is no such guarantee (unless you supply one > * outside the language via a #pragma), and it makes a noticeable > * difference in these matrix algorithms that are a big part of > * scientific programming. > > Well, the programmer of a Matrix class has to know what he is doing. > Making C++ code efficient may be harder than writing efficient fortran > code, but it is not impossible. This is a good point, but perhaps not in the way that Igor intended. One of the main reasons I tend to push Fortran (or something similar, like Ada or Python ... although maybe not everyone would see what I mean by "similar" here ;-) is that with stuff like C++, you *do* have to know what you are doing, or you will make a mess of it. The fact remains (and will for some time) that many scientific programmers are scientists FIRST and programmers SECOND. Turning the average physicist/programmer (at least in my field) loose with a C++ compiler is like giving your car keys to your eight-year-old. A few of them would actually be able to drive, but most of them would cause big damage trying. So one of my reasons for Fortran still being around: you can write a reasonable program which runs reasonably efficiently just by more or less typing in an expression of a simple algorithm. Fortran's "mental model" of the computer is very simple. JAT ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Fortran vs C++ vs. etc (has little to do with realtime anymore) 1997-09-12 0:00 ` Jeffrey Templon @ 1997-09-13 0:00 ` Joseph M. O'Leary 1997-09-16 0:00 ` James F Cornwall 0 siblings, 1 reply; 19+ messages in thread From: Joseph M. O'Leary @ 1997-09-13 0:00 UTC (permalink / raw) Jeffrey Templon <templon@studbolt.physast.uga.edu> wrote in article <m34t7q3bcc.fsf_-_@studbolt.physast.uga.edu>... > One of the main reasons I tend to push Fortran (or something similar, > like Ada or Python ... although maybe not everyone would see what > I mean by "similar" here ;-) is that with stuff like C++, you *do* > have to know what you are doing, or you will make a mess of it. > The fact remains (and will for some time) that many scientific programmers > are scientists FIRST and programmers SECOND. Turning the average > physicist/programmer (at least in my field) loose with a C++ compiler > is like giving your car keys to your eight-year-old. A few of > them would actually be able to drive, but most of them would cause > big damage trying. > > So one of my reasons for Fortran still being around: you can write > a reasonable program which runs reasonably efficiently just by more > or less typing in an expression of a simple algorithm. Fortran's "mental > model" of the computer is very simple. I agree with you. I spent the first 4 years of my professional career working a large scale VAX/VMS Over-the-Horizon Radar project that was written almost totally in FORTRAN. When I say large scale, I'm talking about something that required 2 VAX 6000/430 mainframes and, employed about 70 or 80 concurrent processes Then I spent about a year and a half working on a Visual C++/Windows NT project that replaced a large portion of the older project -- mainly the UI code. The difference between the 2 software development styles was like night and day. In the old system, you had to know beforehand exactly how much memory your app (or process) required. It was all allocated when the process started. If you data outgrew that size, the process crashed. Also, since it was in FORTRAN, the code read like...well like BASIC. It was very easy to pick up and very straightforward. All code paths were very structured, hierarchical, and BIG. (Huge). I think we documented very well what we did and wrote some very clean code. We didn't try to force old, procedural programming techniquest on to an object-oriented langauge. We accomplished the same task with probably less than one-third as many lines of code as the FORTRAN. Still, I don't envy the long-time FORTRAN programmer who has to switch from maintaining the old code base to maintaining the new one, even if it is much less code to look at. It requires quite a philosophical shift. Joe O' ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Fortran vs C++ vs. etc (has little to do with realtime anymore) 1997-09-13 0:00 ` Joseph M. O'Leary @ 1997-09-16 0:00 ` James F Cornwall 0 siblings, 0 replies; 19+ messages in thread From: James F Cornwall @ 1997-09-16 0:00 UTC (permalink / raw) Joseph M. O'Leary (NOSPAMjmoleary@earthlink.net) wrote: : Jeffrey Templon <templon@studbolt.physast.uga.edu> wrote in article : <m34t7q3bcc.fsf_-_@studbolt.physast.uga.edu>... : > One of the main reasons I tend to push Fortran (or something similar, : > like Ada or Python ... although maybe not everyone would see what : > I mean by "similar" here ;-) is that with stuff like C++, you *do* : > have to know what you are doing, or you will make a mess of it. : > The fact remains (and will for some time) that many scientific : programmers : > are scientists FIRST and programmers SECOND. Turning the average : > physicist/programmer (at least in my field) loose with a C++ compiler : > is like giving your car keys to your eight-year-old. A few of : > them would actually be able to drive, but most of them would cause : > big damage trying. : > : > So one of my reasons for Fortran still being around: you can write : > a reasonable program which runs reasonably efficiently just by more : > or less typing in an expression of a simple algorithm. Fortran's "mental : > model" of the computer is very simple. : I agree with you. I spent the first 4 years of my professional career : working a large scale VAX/VMS Over-the-Horizon Radar project that was : written almost totally in FORTRAN. When I say large scale, I'm talking : about something that required 2 VAX 6000/430 mainframes and, employed about : 70 or 80 concurrent processes Oh, God - I spent more time than I care to remember working on the OTH-B project, too. My aspect was sending the ionospheric "weather" forecasts to your system (using an ancient Univac terminal protocol <U200> bastardized to talk to a VAX...). Our code was a hodgepodge of Fortrans (IV, V, & 77) and assmbler code, much of it created by scientist/programmers as described above. Given a choice between any flavor Fortran and any flavor of C, FORTRAN wins hands down for me and my style of thinking. The language does what it needs to do and still keeps things simple enough to be usable for those of us below the stratosphere..... Just my $0.02 worth, YMMV. :-) Jim Cornwall (ex-USAF, now working on groundwater modeling...Using Fortran!) : Then I spent about a year and a half working on a Visual C++/Windows NT : project that replaced a large portion of the older project -- mainly the UI : code. The difference between the 2 software development styles was like : night and day. In the old system, you had to know beforehand exactly how : much memory your app (or process) required. It was all allocated when the : process started. If you data outgrew that size, the process crashed. : Also, since it was in FORTRAN, the code read like...well like BASIC. It : was very easy to pick up and very straightforward. All code paths were : very structured, hierarchical, and BIG. (Huge). I think we documented : very well what we did and wrote some very clean code. We didn't try to : force old, procedural programming techniquest on to an object-oriented : langauge. We accomplished the same task with probably less than one-third : as many lines of code as the FORTRAN. : Still, I don't envy the long-time FORTRAN programmer who has to switch from : maintaining the old code base to maintaining the new one, even if it is : much less code to look at. It requires quite a philosophical shift. : Joe O' ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~1997-09-25 0:00 UTC | newest] Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1997-09-13 0:00 Fortran vs C++ vs. etc (has little to do with realtime anymore) Dr. Krishnan Chittur 1997-09-15 0:00 ` Area Industrial y Electromec�nica 1997-09-16 0:00 ` Vanesch P. 1997-09-16 0:00 ` Jeffrey Templon 1997-09-16 0:00 ` Gary L. Scott 1997-09-17 0:00 ` Jenn-Ching Luo 1997-09-17 0:00 ` Gary L. Scott 1997-09-16 0:00 ` Rick Hawkins 1997-09-18 0:00 ` Oleg Krivosheev 1997-09-19 0:00 ` Rick Hawkins 1997-09-23 0:00 ` Oleg Krivosheev 1997-09-23 0:00 ` Gary L. Scott 1997-09-24 0:00 ` Rick Hawkins 1997-09-24 0:00 ` Xingzeng Liu 1997-09-25 0:00 ` const 1997-09-25 0:00 ` Oleg Krivosheev [not found] <199709070005.TAA23336@manifold.algebra.com> [not found] ` <5utbth$rdi@snews2.zippo.com> [not found] ` <34131554.73F2310E@roda.roc.servtech.com> [not found] ` <34157696.16620299@nntp.interaccess.com> [not found] ` <JTV2J.97Sep9170655@cobra.cs.virginia.edu> [not found] ` <3415CE44.3BD531@calfp.co.uk> [not found] ` <341644F2.763D@BZZvnet.ibm.com> 1997-09-12 0:00 ` Jeffrey Templon 1997-09-13 0:00 ` Joseph M. O'Leary 1997-09-16 0:00 ` James F Cornwall
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox