C++ vs fortran
charles d. russell
identify themselves as numerical analysts. C, C++, fortran 77, fortran
95? Would you choose differently if you were limited to low-end
hardware?
@vic.bigpond.net.au Alan Miller
You left Matlab off the list.
Perhaps it should be in place of C++ ?!
I use Fortran (mainly Fortran 90 not 95).
--
Alan Miller, Retired Scientist (Statistician)
CSIRO Mathematical & Information Sciences
Alan.Miller -at- vic.cmis.csiro.au
http://www.ozemail.com.au/~milleraj
http://users.bigpond.net.au/amiller/
Kendall Atkinson
most of my work. The one addition is Matlab which I use a great deal as
well; it is convenient and its graphics tools are quite easy to use. I use
the current versions of Fortran, slowly updating my codes from older
variants, as time permits. If you look at the Netlib library, you will find
most codes are published in Fortran. Current versions are quite
well-designed as regards much NA programming.
Ken Atkinson
"charles d. russell" <crus...@uabmc.edu> wrote in message
news:39DCDACE...@uabmc.edu...
Dan Tex1
>From: "charles d. russell" crus...@uabmc.edu
>Date: 10/5/00 12:47 PM Pacific Daylight Time
>Message-id: <39DCDACE...@uabmc.edu>
>
>I am curious what language preferences would be expressed by those who
>identify themselves as numerical analysts. C, C++, fortran 77, fortran
>95? Would you choose differently if you were limited to low-end
>hardware?
>
I'm an engineer who does some numerical programming ( don't really think I'd
call myself a numerical analyst though ). I prefer Fortran 95. Simple
syntax, easy to learn, fast and as portable as you can get.
Dan :-)
jan...@netbistro.com
vic.bigpond.net.au> wrote:
I'm just a hobbyist now but I really like Delphi. If someone is on an
Intel platform the advantages of Delphi over Fortran in ease of
creating interfaces and over C++ in ease of use are pretty compelling.
It should be possible to link the Intel Math Kernel to Delphi programs
so you would have optimal BLAS routines for the heavy number
crunching for most problems.
>charles d. russell wrote in message <39DCDACE...@uabmc.edu>...
>>I am curious what language preferences would be expressed by those who
>>identify themselves as numerical analysts. C, C++, fortran 77, fortran
>>95? Would you choose differently if you were limited to low-end
>>hardware?
>>
>
Paul Schlyter
>On Thu, 05 Oct 2000 21:26:12 GMT, "Alan Miller" <amiller @
>vic.bigpond.net.au> wrote:
>
>I'm just a hobbyist now but I really like Delphi. If someone is on an
>Intel platform the advantages of Delphi over Fortran in ease of
>creating interfaces and over C++ in ease of use are pretty compelling.
Indeed true -- Fortran was never intented to be a good language for
creating GUI's. The user interface stuff, if that's important, should
preferably be done in another language than Fortran.
The bottom line is though: no single language is best for all
programming tasks. So choose the language which best suits your needs.
--
----------------------------------------------------------------
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
Paul Schlyter
charles d. russell <crus...@uabmc.edu> wrote:
> I am curious what language preferences would be expressed by those who
> identify themselves as numerical analysts. C, C++, fortran 77, fortran
> 95?
due to its superior performance and its good support for numberical
computations. Nowadays Fortran-90 or Fortran-95 is often used in
favor of the older Fortran-77, however f-9x is backwards compatible
to f-77.
> Would you choose differently if you were limited to low-end hardware?
compilers, which of course will influence your choice. If you were
to use REALLY low-end hardware (such as the PIC microcontroller),
you'd probably be forced to use assembly language.
George Russell
> I am curious what language preferences would be expressed by those who
> identify themselves as numerical analysts. C, C++, fortran 77, fortran
> hardware?
I am not a professional numerical analyst, though I know a bit about it.
I have written some numerical analysis code (for my PhD and so on) in both
Fortran 77 and C. Which I would use for what would depend on the problem
and the available compilers. If I were restricted to low-end hardware
(a 486 PC for example) and very little money I might try running Linux with lcc.
I do research into functional languages. I would like to see the numerical
analysis community eventually using functional languages, EG SISAL:
http://www.llnl.gov/sisal/SisalHomePage.html
Sadly I've heard that SISAL isn't being funded any more, and I'm not holding
my breath . . .
charles d. russell
Paul Schlyter wrote:
> choose the language which best suits your needs.
>
But this depends on what language has the best public domain math packages.
Clearly fortran 77 now, but what about the future? Contributions to TOMS now
include languages other than fortran, and fortran 77 is still being written..
Paul Schlyter
>
>> choose the language which best suits your needs.
>
> But this depends on what language has the best public domain math packages.
indeed! There's more to choosing a programming language than just
making your choice based on the properties of the langauge itself.
> Clearly fortran 77 now, but what about the future? Contributions to TOMS now
> include languages other than fortran, and fortran 77 is still being written..
the future will bring. All we can do is to make educated guesses
about the near future. And one thing is fore sure: Fortran has been
declared "dead" at many times by many people during the last 30 years
or sonow, but it's still alive and well. It won't disappear tomorrow,
or even the next few years.
Mark Vaughan
>I'm just a hobbyist now but I really like Delphi. If someone is on an
>Intel platform the advantages of Delphi over Fortran in ease of
>creating interfaces and over C++ in ease of use are pretty compelling.
the disadvantage of Delphi is the very limited number of native
numerical libraries
several fortran vendors & websites recommmend using Delphi for
the interface, and fortran for the number crunching; see
http://www.polyhedron.com/winnl.html for example
>It should be possible to link the Intel Math Kernel to Delphi programs
>so you would have optimal BLAS routines for the heavy number
>crunching for most problems.
yep...see MtxVec by Janez Makovsek and Marjan Slatinek at
http://www.dewresearch.com/
--
Mark Vaughan
____________
Visit the Numerical Methods in Pascal web page at
http://www-rab.larc.nasa.gov/nmp/fNMPhome.htm
Dan Tex1
>creating GUI's. The user interface stuff, if that's important, should
>preferably be done in another language than Fortran.
>
>The bottom line is though: no single language is best for all
>
Very true. Another thing to keep in mind also... for those who want a nice
GUI type of interface.... No matter what language you choose, you do a fancy
GUI and... you can kiss most portability goodbye. I might be wrong, but...
I'm not aware of any language that has portable graphics capabilities. For
that matter, most graphics are add ons to the languages in the first place.
Sure... Delphi and Visual Basic have built in language graphics, but those
languages are proprietary, non-standardized, constantly changing and... only
work on one system. ( I'm not saying don't use them, they can be very nice,
just be aware of portability issues )
Dan :-)
netnet
jan...@netbistro.com wrote:
> On Thu, 05 Oct 2000 21:26:12 GMT, "Alan Miller" <amiller @
> vic.bigpond.net.au> wrote:
>
>
> I'm just a hobbyist now but I really like Delphi. If someone is on an
> Intel platform the advantages of Delphi over Fortran in ease of
> creating interfaces and over C++ in ease of use are pretty compelling.
>
>
> It should be possible to link the Intel Math Kernel to Delphi programs
> so you would have optimal BLAS routines for the heavy number
> crunching for most problems.
>
You may kill both birds with one stone.
Salford Fortran compilers almost five years support
GUI builders based on the same WinAPI as Delphi.
It is infinitely more convenient than Delphi for
Fortran users. Other GUI builders also exist
for almost all Win32 Fortran compilers with
a la Matlab/Mathematica functions for an additional
cost (~$500). Interacter/Winteracter and GINO
are wildly used and people are happy with them.
So, this problem does not exist for Fortran at all.
netnet
Paul Schlyter wrote:
> In article <39dd68b...@news.netbistro.com>, <jan...@netbistro.com> wrote:
>
>> On Thu, 05 Oct 2000 21:26:12 GMT, "Alan Miller" <amiller @
>> vic.bigpond.net.au> wrote:
>>
>> I'm just a hobbyist now but I really like Delphi. If someone is on an
>> Intel platform the advantages of Delphi over Fortran in ease of
>> creating interfaces and over C++ in ease of use are pretty compelling.
>
>
> Indeed true -- Fortran was never intented to be a good language for
> creating GUI's. The user interface stuff, if that's important, should
> preferably be done in another language than Fortran.
As to 'preferably', then how about exactly opposite ?
>
> The bottom line is though: no single language is best for all
> programming tasks. So choose the language which best suits your needs.
Sorry, I hate such kind of 'wisdom'
Paul Schlyter
netnet <net...@netnetnet.net> wrote:
>
>
>Paul Schlyter wrote:
>
>> In article <39dd68b...@news.netbistro.com>, <jan...@netbistro.com> wrote:
>>
>>> vic.bigpond.net.au> wrote:
>>>
>>> I'm just a hobbyist now but I really like Delphi. If someone is on an
>>> Intel platform the advantages of Delphi over Fortran in ease of
>>> creating interfaces and over C++ in ease of use are pretty compelling.
>>
>>
>> creating GUI's. The user interface stuff, if that's important, should
>> preferably be done in another language than Fortran.
>
>
>
>
>
>As to 'preferably', then how about exactly opposite ?
You mean "not preferably" ? Please clarify what you mean.
>> The bottom line is though: no single language is best for all
>> programming tasks. So choose the language which best suits your needs.
>
>
>Sorry, I hate such kind of 'wisdom'
Well, it's not an "easy" advice like e.g. "Use language X - it is BEST!".
Is that why you dislike it?
Paul Schlyter
Dan Tex1 <dan...@aol.com> wrote:
>> Indeed true -- Fortran was never intented to be a good language for
>> creating GUI's. The user interface stuff, if that's important, should
>> preferably be done in another language than Fortran.
>>
>> programming tasks. So choose the language which best suits your needs.
>
> GUI type of interface.... No matter what language you choose, you do a
> fancy GUI and... you can kiss most portability goodbye. I might be wrong,
> but... I'm not aware of any language that has portable graphics capabilities.
likely be unportable as well.
There have been attempts at creating LIBRARIES which presents the same
API to the application in multiple GUI environments though -- check
back issues of Dr Dobb's Journal for this.
> For that matter, most graphics are add ons to the languages in the first
> place.
I know of, however LOGO is a toy language in most other respects, and
it's not available on thet many platforms.
> Sure... Delphi and Visual Basic have built in language graphics, but those
> languages are proprietary, non-standardized, constantly changing and... only
> work on one system. ( I'm not saying don't use them, they can be very nice,
> just be aware of portability issues )
gets as separate as possible from the stuff which does the actual work
though. If you succeed in separating the two in a good way, porting
your program to another environment will then mean re-writing only
the GUI module.
Ian Gay
<20001007030349...@ng-fj1.aol.com>:
>>Indeed true -- Fortran was never intented to be a good language for
>>creating GUI's. The user interface stuff, if that's important,
>>should preferably be done in another language than Fortran.
>>
>>The bottom line is though: no single language is best for all
>>programming tasks. So choose the language which best suits your
>>needs.
>>
>
>
>Very true. Another thing to keep in mind also... for those who
>want a nice GUI type of interface.... No matter what language you
>choose, you do a fancy GUI and... you can kiss most portability
>goodbye. I might be wrong, but... I'm not aware of any language
>that has portable graphics capabilities.
Tcl/Tk does a nice job across Windoze/nix platforms. I understand it's
not as well-developed on Macs. Easy to interface it to number crunchers
written in C, probably possible to do in Fortran with a bit of work.
Janez Makovsek
> You may kill both birds with one stone.
>
> Salford Fortran compilers almost five years support
> GUI builders based on the same WinAPI as Delphi.
> It is infinitely more convenient than Delphi for
> Fortran users. Other GUI builders also exist
> for almost all Win32 Fortran compilers with
> a la Matlab/Mathematica functions for an additional
> cost (~$500). Interacter/Winteracter and GINO
> are wildly used and people are happy with them.
>
> So, this problem does not exist for Fortran at all.
There is a lot more to Delphi then just GUI for buttons. Its also GUI for
Internet
Network
Database
and many other things.
The application does not end with a button placed on the form. We should be
honest: If Matlab would be running as fast as Fortran, nobody would be using
it.And if Delphi would be running Matlab-like code, nobody would be using
Matlab.
Delphi got by far closer to that ideal (speed, math code compactness,
application capable) then any other tool.
Janez.
Paul Schlyter
Janez Makovsek <Janez.M...@usa.net> wrote:
> Delphi got by far closer to that ideal (speed, math code compactness,
> application capable) then any other tool.
same about VB...) -- just too bad those environments are
single-platform only...
But Delphi and VB are probably both fine -- if you have no ambition
of porting your program, and if it's not too heavy on numerical
computations....
jane...@my-deja.com
> > Delphi got by far closer to that ideal
(speed, math code compactness,
> > application capable) then any other tool.
>
> So Delphi fans claim (and I can easily imagine
VB fans claiming the
> same about VB...) -- just too bad those
environments are
> single-platform only...
Delphi will be running on Linux in two months..
See: www.inprise.com.
So, wherever you can run Linux....
I think thats pritty cross-platform...
> But Delphi and VB are probably both fine -- if
you have no ambition
> of porting your program, and if it's not too
heavy on numerical
> computations....
The math libraries from Intel are pretty fast.
They outperform Fortran by 3x. BTW, Fortran (CVF)
outperforms C++ by 2x and Delphi also by 2x.
In some cases of tight loops Delphi is faster
then Borland C++, but I dont know why.
Therefore, if you use vector/matrix design where
appropriate taking advantage of highly optimized
code, you can become much heavier in numerical
computations then native Fortran. (for Intel at
least, or any other platform where you have good
BLAS).
The advantage of Delphi is that you are not tied
to matrix/vector design like in Matlab.
But of course, Delphi only makes most sense to
people actually building applications not just
running computations.
Janez.
Sent via Deja.com http://www.deja.com/
Before you buy.
David Wilkinson
<pau...@saafNOSPAM.se> writes
>> application capable) then any other tool.
>
>So Delphi fans claim (and I can easily imagine VB fans claiming the
>same about VB...) -- just too bad those environments are
>single-platform only...
>
>of porting your program, and if it's not too heavy on numerical
>computations....
>
>
heavy on numerical computations, being a Computational Fluid Dynamics
application on a PC. The only standard numerical parts of it are a
linear equation solver (LU Decomposition from Numerical recipes book,
typed in Delphi) for about 500 equations, which runs quite quickly and a
repeated RK45 R-K solution which takes much longer, because of the time
taken to find the dy/dx values. Would any other language be an
improvement on Delphi for this? If so, which and why?
--
David Wilkinson
jan...@netbistro.com
wrote:
>
>But Delphi and VB are probably both fine -- if you have no ambition
>of porting your program, and if it's not too heavy on numerical
>computations....
>
Porting is clearly an issue in some circumstances but almost every
computer site will have a Windows machine. My sense is that Fortran
and C or C++ are not 100% portable that there is usually a little
fine-tuning that needs to be done to get the program running. Given
the cost of programmer time it may be cheaper to simply start up the
secretary's word processing computer and run a Delphi program on it
than to spend days trying to get a C++ or Fortran program to compile.
In my experience (which is dated, but not that dated) most numerical
analysis is concerned with writing new programs to solve specific
problems. Most of the programming is done by non-professional
programmers. The cost of computer time is small compared to programmer
cost. In that sort of environment ease of use beats execution speed
almost everytime.
Intel platforms may not match a new super computer but if you look at
the Set@Home site it gives some interesting insight into the relative
performance of different platforms. The fastest machines appear to be
the latest Alphas that take about one hour to process a result but
the Intel platforms account for the vast majority of total results
because there are so many of them.
I have a Pentium 566 which takes about 10 hours to generate a result
so the Alpha is 10 (but only ten) times faster. For many problems
that difference will not be the difference between being able to solve
the problem and not solving it. For other problems the answer will be
to break the problem up and run it on several machines. I am working
on a program that will need to est about a thousand different cases
and will take a long time to test each one. When it is ready to run I
plan on taking it to my office and installing it on all of the
secretaries machines and let it run for a weekend with each machine
working on a different range of test cases.. That should give me
about the equivalent of a Pentium II running at 15 (fifteen)
gigahertz.
There will always be some problems (e.g. hydrodynamics) where there is
no alternative to big iron and compilers that will run on it..
Paul Schlyter
David Wilkinson <Da...@quarksoft.demon.co.uk> wrote:
> In article <8rq6l7$lou$1...@merope.saaf.se>, Paul Schlyter
> <pau...@saafNOSPAM.se> writes
>>In article <8rpg9d$3va$1...@strelovod.uni-mb.si>,
>>Janez Makovsek <Janez.M...@usa.net> wrote:
>>
>>> Delphi got by far closer to that ideal (speed, math code compactness,
>>> application capable) then any other tool.
>>
>> So Delphi fans claim (and I can easily imagine VB fans claiming the
>> same about VB...) -- just too bad those environments are
>> single-platform only...
>>
>> of porting your program, and if it's not too heavy on numerical
>> computations....
>
hardware, other OS, or both) and have it execute there.
> but it IS heavy on numerical computations, being a Computational Fluid
> Dynamics application on a PC.
to use a denser grid? If the answer is "yes" to either of these
questions, you would want to move your program to a more powerful
platform. But you cannot do that without rewriting it in something
else than Delphi, because Delphi is a single-platform environment.
> The only standard numerical parts of it are a linear equation solver
> (LU Decomposition from Numerical recipes book, typed in Delphi) for
> about 500 equations, which runs quite quickly and a repeated RK45
> R-K solution which takes much longer, because of the time taken to
> find the dy/dx values. Would any other language be an improvement
> on Delphi for this? If so, which and why?
1. The FORTRAN language was designed with execution efficiency as the
#1 goal, sometimes at the expense of other qualities of the language.
Back in 1957, when FORTRAN was born, this was a big issue of
high-level languages vs assmebly languages: back then the gneral
opinion was that high-level languages would be too inefficient;
FORTRAN proved that wrong, and paved the way for other high-level
languages too. Since then, FORTRAN has been #1 regarding execution
speed for numerically intensive computations.
2. There are huge amounts of numerical libraries written in FORTRAN
out there, and you would most likely be able to find a more efficient
LU decomposition routine than the one you typed in from Numerical
Recipes. A starting place to look at would be: http://www.netlib.org
Paul Schlyter
<jan...@netbistro.com> wrote:
> On 8 Oct 2000 18:16:39 +0200, pau...@saafNOSPAM.se (Paul Schlyter)
> wrote:
>
>>
>>of porting your program, and if it's not too heavy on numerical
>>computations....
>
> computer site will have a Windows machine.
> My sense is that Fortran and C or C++ are not 100% portable that
> there is usually a little fine-tuning that needs to be done to get
> the program running.
follow the language standard to 100% and avoid using any external
libraries -- such a program would in most cases not be particularly
enjoyable to use though. Therefore most real-world programs contain
non-portable parts. If badly written, the non-portable parts will
be sprinkeled all over the code, making a port a nightmare.
Fortran and C/C++ are better than most other programming languages
concering ease of porting though. No, it won't go effortlessly, but
it'll usually be much harder in other programming languages (such as
VB or Delphi).
> Given the cost of programmer time it may be cheaper to simply start
> up the secretary's word processing computer and run a Delphi program
> on it than to spend days trying to get a C++ or Fortran program to
> compile.
yes.
> In my experience (which is dated, but not that dated) most numerical
> analysis is concerned with writing new programs to solve specific
> problems. Most of the programming is done by non-professional
> programmers. The cost of computer time is small compared to programmer
> cost. In that sort of environment ease of use beats execution speed
> almost everytime.
>
> Intel platforms may not match a new super computer but if you look at
> the Set@Home site it gives some interesting insight into the relative
> performance of different platforms. The fastest machines appear to be
> the latest Alphas that take about one hour to process a result but
> the Intel platforms account for the vast majority of total results
> because there are so many of them.
those wasted CPU cycles on all those Intel CPU's out there.
> I have a Pentium 566 which takes about 10 hours to generate a result
> so the Alpha is 10 (but only ten) times faster. For many problems
> that difference will not be the difference between being able to solve
> the problem and not solving it. For other problems the answer will be
> to break the problem up and run it on several machines. I am working
> on a program that will need to est about a thousand different cases
> and will take a long time to test each one. When it is ready to run I
> plan on taking it to my office and installing it on all of the
> secretaries machines and let it run for a weekend with each machine
> working on a different range of test cases.. That should give me
> about the equivalent of a Pentium II running at 15 (fifteen)
> gigahertz.
>
> There will always be some problems (e.g. hydrodynamics) where there is
> no alternative to big iron and compilers that will run on it..
# but it IS heavy on numerical computations, being a Computational
# Fluid Dynamics application on a PC.
which IMO means it's a kind of program which definitely should have
been written in some more portable language than Delphi. Hydrodynamical
programs can easily use any amount of CPU power: make the grid 10 times
denser and you'll immediately need 1000 times more CPU power....
netnet
Janez Makovsek wrote:
>The application does not end with a button placed on the form. We should be
>honest: If Matlab would be running as fast as Fortran, nobody would be using
>it.And if Delphi would be running Matlab-like code, nobody would be using
>Matlab.
Who argues ? Delphi is great environment success of which
all others jealously following. And copying it not less successfully
than MS in their efforts elsewhere :-).
This is because of idea is easy as 2 x 2 and can not be hidden for
centuries. Basically it is MS respond to everybody: "Grab me too".
As we all see and as it usually happen, the followers even have
some advantages :-).
>
> There is a lot more to Delphi then just GUI for buttons. Its also GUI for
>
> Internet
> Network
> Database
> and many other things.
Do you need *Internet* and *Networking* with Fortran?
I do and I use it. Do you ?
At least couple of Fortran vendors working on it and
one (Salford) already offering some features. Again it is
matter of relatively short time to add the interface to MS
WinINET in any language within Windows platform.
Do you need *Databases* ? I don't. But, again,
the library of functions and subroutines that
work as an interface between your Fortran programs
and Microsoft Windows Open Database Connectivity
(ODBC) API exist and my Fortran vendor (and I am sure
others) offers it too.
Many other things which you will have staying with
Fortran do not need special announcement. And I would
disagree if someone will insist
that for general user Fortran now have something he
can not provide (let's exclude those who really need
full access to low level programming, and much more control
of every tiny aspect of programming like it often happen
in supercomputing). Yes, it is/was late in adopting
OO features, right. But wait for next Standard.
If not, Fortran Standard committee probably deserves
dismissal. But if you will insist in that, are you ready
to eat your shoes if happen new Fortran will be *much* slower ?
(initially or forever ;-).
Sorry of course if you need to move programs from platform
to platform, but what you obtained with approach of
*selling yourself* to MS is *ease* of Delphi and Matlab
plus speed of Fortran. Hence you see that I disagree with your
web site about Fortran.
As 'much more' (including OpenGL for dessert :-) consider
also terrific advantage of doing everything in Fortran.
Just imagine opposite, that you are programming in Fortran
but all your OPEN's... READ's ... WRITE's and PRINT's
you realise with multi-language programming ?
This most often is *headache* close to
absurd if your code is larger than, say, even as little as
20-50K lines.
Also, I hope I'm far from being bigot.
If Delphi has some disadvantages in execution speed now,
I believe it definitely will be tuned in future so I do
not expect any long term overwhelming advantage of Fortran over
any other language (say, more than 2-3 times from spot to spot)
in num analysis. That means there is no terrific
reason to switch to Fortran unless you do something very
special. I would definitely first looked at the
frontier inside given language (your web site, for example).
Otherwise if this is not enough and nobody offers what you
need, then combination of Fortran, C/C++ and, sorry, assembler
is anyone's route No.1.
P.S. Somebody mentioned www.polyhedron.com web site
as one which recommend Delphi as GUI. I was their customer and
like their support very much. Definitely it recommends...
But just to note, that seems to me, one (and may be the only)
person there who was using Delphi extensively in the past,
is now working entirely in Fortran (using Winteracter GUI builder,
and I predict will move to Salford Fortran Clearwin+ GUI
in future :-)
----------
Louis M. Pecora
> The math libraries from Intel are pretty fast.
> They outperform Fortran by 3x. BTW, Fortran (CVF)
> outperforms C++ by 2x and Delphi also by 2x.
> In some cases of tight loops Delphi is faster
> then Borland C++, but I dont know why.
3x ?? 2x ?? I have a very hard time believing those speed factors.
You have documentation?
Paul Victor Birke
Paul Schlyter wrote:
>>snippings<<<
Since then, FORTRAN has been #1 regarding execution
> speed for numerically intensive computations.
*********************8
I knew that.
Tuck, Paul
and I would add accurate. I like fast and accurate for NN research, it
is a must.
I am using Watcom 77 10.5. It is just soooo gooooood!!
Victor Eijkhout
> In article <8rqh3o$ebt$1...@nnrp1.deja.com>, <jane...@my-deja.com> wrote:
>
> > The math libraries from Intel are pretty fast.
> > They outperform Fortran by 3x. BTW, Fortran (CVF)
> 3x ?? 2x ?? I have a very hard time believing those speed factors.
That's probably comparing optimised libraries against a naive implementation.
Sort of comparing naive BLAS level 3 against ATLAS gemm-based BLAS.
Factor or 3 is very realistic then.
--
Victor Eijkhout
"When I was coming up, [..] we knew exactly who the they were. It was us
versus them, and it was clear who the them was were. Today, we are not
so sure who the they are, but we know they're there." [G.W. Bush]
Paul Schlyter
>> same about VB...) -- just too bad those environments are
>> single-platform only...
>
> See: www.inprise.com.
>
> So, wherever you can run Linux....
> I think thats pritty cross-platform...
getting to be pretty cross platform....
BTW will Delphi run on any Linux? Or will it run only on x86 Linux?
And we're not there yet.....
Brien Alkire
programming as one of my research fields.
I write my own codes in C++ and Matlab. However, I make calls to FORTRAN
libraries from my C++ codes (especially BLAS/Lapack).
"charles d. russell" <crus...@uabmc.edu> wrote in message
news:39DCDACE...@uabmc.edu...
David Wilkinson
>On 8 Oct 2000 18:16:39 +0200, pau...@saafNOSPAM.se (Paul Schlyter)
>wrote:
>
>>
>>But Delphi and VB are probably both fine -- if you have no ambition
>>of porting your program, and if it's not too heavy on numerical
>>computations....
>>
>
>Porting is clearly an issue in some circumstances but almost every
>and C or C++ are not 100% portable that there is usually a little
>the cost of programmer time it may be cheaper to simply start up the
>secretary's word processing computer and run a Delphi program on it
>than to spend days trying to get a C++ or Fortran program to compile.
>
>analysis is concerned with writing new programs to solve specific
>problems. Most of the programming is done by non-professional
>programmers. The cost of computer time is small compared to programmer
>cost. In that sort of environment ease of use beats execution speed
>almost everytime.
>
>Intel platforms may not match a new super computer but if you look at
>the Set@Home site it gives some interesting insight into the relative
>performance of different platforms. The fastest machines appear to be
>the latest Alphas that take about one hour to process a result but
>the Intel platforms account for the vast majority of total results
>because there are so many of them.
>
>so the Alpha is 10 (but only ten) times faster. For many problems
>that difference will not be the difference between being able to solve
>the problem and not solving it. For other problems the answer will be
>to break the problem up and run it on several machines. I am working
>on a program that will need to est about a thousand different cases
>and will take a long time to test each one. When it is ready to run I
>plan on taking it to my office and installing it on all of the
>secretaries machines and let it run for a weekend with each machine
>working on a different range of test cases.. That should give me
>about the equivalent of a Pentium II running at 15 (fifteen)
> gigahertz.
>
>There will always be some problems (e.g. hydrodynamics) where there is
>no alternative to big iron and compilers that will run on it..
>
>
hydrodynamics program I am writing in Delphi on a 266 MHz PC. Run times
are a few minutes and results quite good but I would like to use more
points and run faster. As I have to buy my own computer I am limited to
a PC. Although I could get a 1.1GHz machine now, which would be about 4
times as fast, the run time increases as the number of points to the
power 3 or 4 so I would only be able to use about 50% more points after
this expensive change, which is hardly a dramatic improvement. I have
always found improvements in numerical methods to be more effective, and
cheaper than hardware upgrades.
>
--
David Wilkinson
Richard Hughes
Dan Tex1 wrote:
>
> >
>
> Very true. Another thing to keep in mind also... for those who want a nice
> GUI type of interface.... No matter what language you choose, you do a fancy
> GUI and... you can kiss most portability goodbye. I might be wrong, but...
> I'm not aware of any language that has portable graphics capabilities. For
> that matter, most graphics are add ons to the languages in the first place.
> Sure... Delphi and Visual Basic have built in language graphics, but those
> languages are proprietary, non-standardized, constantly changing and... only
> work on one system. ( I'm not saying don't use them, they can be very nice,
> just be aware of portability issues )
>
>
> Delphi has been quite stable since Delphi 2, will be available for Linux before
> yearend and interfaces nicely with Mathematica. No complex number type though.
Richard Hughes
Paul Schlyter
David Wilkinson <Da...@quarksoft.demon.co.uk> wrote:
> In article <39e171df...@news.netbistro.com>, jan...@netbistro.com
> writes
>>There will always be some problems (e.g. hydrodynamics) where there is
>>no alternative to big iron and compilers that will run on it..
>
> It's funny you should make that last comment because it is a
> hydrodynamics program I am writing in Delphi on a 266 MHz PC. Run times
> are a few minutes and results quite good but I would like to use more
> points and run faster. As I have to buy my own computer I am limited to
> a PC. Although I could get a 1.1GHz machine now, which would be about 4
> times as fast, the run time increases as the number of points to the
> power 3 or 4 so I would only be able to use about 50% more points after
> this expensive change, which is hardly a dramatic improvement.
times are "a few minutes". If you're prepared to instead wait a few
hours or even a few days, you could use a grid 4-12 times denser with
your current 266 MHz PC.
> I have always found improvements in numerical methods to be more
> effective, and cheaper than hardware upgrades.
I have one program which now is 17 years old, and which has survived
through the years because it performs one well-defined task quite
well: it computes rise/set times for the Sun and Moon every day, and
the planets once a week, during one calendar year. The output is
divided into 12 pages, one for each month. The first version of that
program was written in 1983 in Fortran-80 and ran on a CP/M
machine with a 2 MHz Z80 - the run time was 1.5 hours. After 2 years
I upgraded to a 6 MHz Z80 - now the run time was 30 minutes.
In 1987 the program was rewritten in C and ported to a PC (4.77 MHz
8088 with an 8087). The run time didn't go down dramatically: now
the run time was 10 minutes. In 1988 I got a 16 Mhz 386+387, and
the run time went down to 1.5 minutes. In 1994 I got a 66 Mhz
486DX - the run time was now 12 seconds. In 1998 I got a 300 Mhz
P-II, and the run time went down to perhaps 2 seconds. And on
a modern P-III the run time is 1 second or less.
Thus, due to hardware upgrades, the run time of this program has
decreased from 90 minutes (= 5400 seconds) in 1983 to about 1 second
in 2000 -- i.e. a speed improvement by a factor of about 5000.
I DON'T think an optimized algorithm or better numerical method could
make this program execute in 1 second on that CP/M machine with a 2
MHz Z80....
jan...@netbistro.com
wrote:
>> Porting is clearly an issue in some circumstances but almost every
>> computer site will have a Windows machine.
>
>Today, yes -- do you expect it to remain so indefinitely?
>
In Computing indefinitely is about five years and in that sense yes.
When I started programming in 1973 Simon Fraser University where I was
going upgraded their IBM 370-155 from 640K bytes of memory to a
mega-byte of memory at a cost of several hundred thousand dollars.
>
>Fortran and C/C++ are better than most other programming languages
>concering ease of porting though.
Agreed
> No, it won't go effortlessly, but
>it'll usually be much harder in other programming languages (such as
>VB or Delphi).
Which would be impossible to port in any practical sense.
>
>For programs which run quickly, or which aren't to be run that often,
>yes.
>
Quickly being a relative concept here. If it takes a month to write
the program in Fortran and a week to write in Delph it then it doesn't
matter if the the Delphi program would run in two weeks and the fortan
program run in ten minutes.
>
>which IMO means it's a kind of program which definitely should have
>been written in some more portable language than Delphi. Hydrodynamical
>programs can easily use any amount of CPU power: make the grid 10 times
>denser and you'll immediately need 1000 times more CPU power....
>
Generally speaking I agree with you. The reason for using C or
Fortran would be to run on more powerful systems.
The other advantage of Delphi that I have not mentioned is the build
suppport for databases which may be useful in some numerical analysis
problesm.
jan...@netbistro.com
wrote:
>> I have always found improvements in numerical methods to be more
>> effective, and cheaper than hardware upgrades.
Sometimes only if you think programmer time is free. Nothing is free.
If you are programming in Delphi you want to be careful about how you
use the dynamically allocated arrays. I found that when I was
iterating along a row of the array that it was faster to pass the row
to a sub-routine and have a subroutine do the calculation along the
row. I expect that Delphi is recalculating the address from scratch
each time while when it gets passed to the subroutine Delphi assumes
that it is simply dealing with a one dimensional array and is only
concerned with the offset.
>
>Cheaper - yes, but more effective? That depends.
A good algorithm can be a hundred times faster or more than a
mediocre one (with a bad algorithm the sky's the limit) A good
implementation can be ten time faster than a bad implementation.
>
Jeffery J. Leader
<keatk...@home.com> wrote:
>I have been using Fortran for around 40 years and will continue using it for
>most of my work. The one addition is Matlab which I use a great deal
For most of my purposes development time is the issue so Matlab has
been my tool of choice. I've forced several places to get a Matlab
license so that I could use it while working there for the summer.
I think Fortran is superior to C++ for scientific computation *but* I
am one of those who feels that Fortan is nearing its end
(supercomputing may remain an exception) and generally encourage
students to look at C++ as a practical/employability matter.
Actually, I still miss APL and would be willing to learn the new
dialect of APL, J (www.jsoftware.com), if I thought it had a chance of
catching on. I don't.
Janez Makovsek
> > The math libraries from Intel are pretty fast.
> > They outperform Fortran by 3x. BTW, Fortran (CVF)
> > In some cases of tight loops Delphi is faster
> > then Borland C++, but I dont know why.
>
Yes. Go to www.dewresearch.com and download the exe demo. You have
performance comparisons there. The MKL library is running against
native Delphi. (matrix multiplication). We will be making more
benchmarks soon. C++ demo is not on the Net, because there is not much
difference except with single precision. I also made a dll from LAPACK
source code with CVF 6.1. The results are as stated, but the dll was
meant to made available only to registered users. Will change that.
There are three different builds of dlls:
MKL PIII optimized.
MKL General CPU. (included with demo)
CVF LAPACK compile.
Other libs are not inlcuded with demo because of the size.
Regards!
Janez Makovsek
programmers are writing is not ATLAS level. So compiler is important.
Will make one more ATLAS compile... CVF was run with Full Optimizations.
Janez.
In article <om1yxqj...@disco.cs.utk.edu>,
Victor Eijkhout <eijk...@disco.cs.utk.edu> wrote:
> "Louis M. Pecora" <pec...@anvil.nrl.navy.mil> writes:
>
> > In article <8rqh3o$ebt$1...@nnrp1.deja.com>, <jane...@my-deja.com>
wrote:
> >
> > > The math libraries from Intel are pretty fast.
> > > They outperform Fortran by 3x. BTW, Fortran (CVF)
>
> > 3x ?? 2x ?? I have a very hard time believing those speed
factors.
>
> That's probably comparing optimised libraries against a naive
implementation.
> Sort of comparing naive BLAS level 3 against ATLAS gemm-based BLAS.
> Factor or 3 is very realistic then.
>
> --
> Victor Eijkhout
> "When I was coming up, [..] we knew exactly who the they were. It was
us
> versus them, and it was clear who the them was were. Today, we are
not
> so sure who the they are, but we know they're there." [G.W. Bush]
>
Janez Makovsek
David Wilkinson <Da...@quarksoft.demon.co.uk> wrote:
> In article <8rq6l7$lou$1...@merope.saaf.se>, Paul Schlyter
> <pau...@saafNOSPAM.se> writes
> >In article <8rpg9d$3va$1...@strelovod.uni-mb.si>,
> >Janez Makovsek <Janez.M...@usa.net> wrote:
> >
> >> Delphi got by far closer to that ideal (speed, math code
compactness,
> >> application capable) then any other tool.
> >
> >same about VB...) -- just too bad those environments are
> >single-platform only...
> >
> >of porting your program, and if it's not too heavy on numerical
> >computations....
> >
> >
IS
> heavy on numerical computations, being a Computational Fluid Dynamics
> application on a PC. The only standard numerical parts of it are a
> linear equation solver (LU Decomposition from Numerical recipes book,
> typed in Delphi) for about 500 equations, which runs quite quickly
and a
> repeated RK45 R-K solution which takes much longer, because of the
time
> taken to find the dy/dx values. Would any other language be an
> improvement on Delphi for this? If so, which and why?
MtxVec in Delphi interfaces fortran routine in dll. It can give you a
speed up of at least 5x towards Numerical recepies LU. And automatic
symmetric multiprocessor support if you are running one more then one
CPU machine.
(further factor by 2x).
All in all, can be: 10x.
Is that worth thinking? To test that, you need 5 minutes. And people
are today paying 4x as much money to get 40% faster machines..
Janez.
Janez Makovsek
> > I have always found improvements in numerical methods to be more
> > effective, and cheaper than hardware upgrades.
> I DON'T think an optimized algorithm or better numerical method could
> make this program execute in 1 second on that CP/M machine with a 2
> MHz Z80....
Yes, but still. An improvement by factor of 10x is 2 CPU generations.
And thats about 3 to 4 years. And that's what optimized code today can
easily do if the algorithm is long enough. (Just the plain addition
operation can be speed up by 2x in ASM towards most compilers).
netnet
Jeffery J. Leader wrote:
> On Fri, 06 Oct 2000 01:03:33 GMT, "Kendall Atkinson"
> <keatk...@home.com> wrote:
>
>> I have been using Fortran for around 40 years and will continue using it for
>> most of my work. The one addition is Matlab which I use a great deal
>
>
> For most of my purposes development time is the issue so Matlab has
> been my tool of choice. I've forced several places to get a Matlab
> license so that I could use it while working there for the summer.
>
You know, I sometimes think of Matlab as missed chance
of Fortran. All that happenned in 80-th when whole decade
Fortran was as primitive as non-graphics calculator.
Hence everybody left it. Now all hard to correct. I do not know
whom to blame for this, usually all beckon on Fortran Standards
committee which seems the only who was/is happy with whole situation.
> I think Fortran is superior to C++ for scientific computation *but* I
> am one of those who feels that Fortan is nearing its end
> (supercomputing may remain an exception) and generally encourage
> students to look at C++ as a practical/employability matter.
If you saw/heard Mersedes-Benz ad, they permanently repeat
"Impression is not always reality".
Happily for Fortran, the life made many corrections.
Seems many Fortran vendors stopped playing insane
primitive game competing on which compiler is faster.
Though, still in some cases this is "impression, which
is not always reality".
Some Fortran vendors improved up to the level where
there is no reason for everybody to leave fortran
( despite of its notorious speed ) due to lack of features and
absence of ease and versatility of development.
This is already reality, not impression.
The roadmap and prototype for this exist for
years and called Salford Fortran. Time for many of you for
correctons, guys.
netnet
Jeffery J. Leader wrote:
> On Fri, 06 Oct 2000 01:03:33 GMT, "Kendall Atkinson"
> <keatk...@home.com> wrote:
>
>> I have been using Fortran for around 40 years and will continue using it for
>> most of my work. The one addition is Matlab which I use a great deal
>
>
> For most of my purposes development time is the issue so Matlab has
> been my tool of choice. I've forced several places to get a Matlab
> license so that I could use it while working there for the summer.
>
You know, I sometimes think of Matlab as missed chance
of Fortran. All that happenned in 80-th when whole decade
Fortran was as primitive as non-graphics calculator.
Hence everybody left it. Now all hard to correct. I do not know
whom to blame for this, usually all beckon on Fortran Standards
committee which seems the only who was/is happy with whole situation.
> I think Fortran is superior to C++ for scientific computation *but* I
> am one of those who feels that Fortan is nearing its end
> (supercomputing may remain an exception) and generally encourage
> students to look at C++ as a practical/employability matter.
>
If you saw/heard Mersedes-Benz ad, they permanently repeat
"Perception is not always reality".
Happily for Fortran, the life made many corrections.
Seems many Fortran vendors stopped playing insane
primitive game competing on which compiler is faster.
Though, still in some cases this is "perception, which
is not always reality".
Some Fortran vendors improved up to the level where
there is no reason for everybody to leave fortran
( despite of its notorious speed ) due to lack of features and
absence of ease and versatility of development.
This is already reality, not perception.
The roadmap and prototype for this exist for
years and called Salford Fortran. Time for many of you for
correctons, guys.
--------
Dan Tex1
>>For programs which run quickly, or which aren't to be run that often,
>>yes.
>>
>Quickly being a relative concept here. If it takes a month to write
>the program in Fortran and a week to write in Delph it then it doesn't
>matter if the the Delphi program would run in two weeks and the fortan
>program run in ten minutes.
Ah..... but it might? Suppose the program is going to be run by
lots of different people every day for many years. In other words...
maybe it's a production oriented analysis program ( design engineers
use these regularly ). In such a case... speed can be very important
even if the speed differences are only 1 minute versus 3 minutes. I
use such programs regularly in my work.
I'd say the importance of the languages ease of coding, speed and
portability issues all depend on the intended use of the application.
Dan :-)
bv
>
> I think Fortran is superior to C++ for scientific computation *but* I
> am one of those who feels that Fortan is nearing its end
Feelings can be quite detached from the reality and perhaps you're due
for the reawakening via *exploding* netlib server statistics; it
suggests that something else rather than Fortran may be nearing its
end...
http://netlib.org/utk/misc/counts.html
--
Dr.B.Voh
-----------------------------------------------
Modeling * Simulation * Analysis
http://www.sdynamix.com
-----------------------------------------------
Dann Corbit
message news:64RE5.78$Jm4....@newsread1.prod.itd.earthlink.net...
> Ok, I've seen you post this before & I'm intrigued; what the heck do you
> mean? From what the link you post, it seems to me that what else is nearing
> its end is either Rsync, Gopher, Xwindow access or email access. Is there
> more relevance than I can divine?
The numbers clearly show it. We can easily divine the following from the bar
chart:
Not only is it permanently September, but it's exponential permanent
September.
--
C-FAQ: http://www.eskimo.com/~scs/C-faq/top.html
"The C-FAQ Book" ISBN 0-201-84519-9
C.A.P. FAQ: ftp://38.168.214.175/pub/Chess%20Analysis%20Project%20FAQ.htm
Mattias Alveteg
Dan Tex1 wrote:
> >Indeed true -- Fortran was never intented to be a good language for
> >creating GUI's. The user interface stuff, if that's important, should
> >preferably be done in another language than Fortran.
> >
> >The bottom line is though: no single language is best for all
> >programming tasks. So choose the language which best suits your needs.
excatly
>
> >
>
> Very true. Another thing to keep in mind also... for those who want a nice
> GUI type of interface.... No matter what language you choose, you do a fancy
> GUI and... you can kiss most portability goodbye.
Maybe you already know this, but with MetaCard you can create userinterfaces that
work on Windows, MacOS and Unix flavours (15 OS in total) where the userinterface
also adapts to the look and feel of the target OS (e.g. buttons look and work
slightly different on MacOS, Windows and Unix). Of course, wether it will fit your
needs is a matter of what you need to do. My needs are usually pretty modest, so I
haven't explored the limitations of MetaCard, but it might be worthwhile to
download the demo…
/mattias alveteg
Matthew C Roberts
mean? From what the link you post, it seems to me that what else is nearing
its end is either Rsync, Gopher, Xwindow access or email access. Is there
more relevance than I can divine?
matt.
"bv" <bv...@sdynamix.com> wrote in message
news:39E3D055...@sdynamix.com...
> "Jeffery J. Leader" wrote:
> >
> > I think Fortran is superior to C++ for scientific computation *but* I
> > am one of those who feels that Fortan is nearing its end
>
>
> Feelings can be quite detached from the reality and perhaps you're due
> for the reawakening via *exploding* netlib server statistics; it
> suggests that something else rather than Fortran may be nearing its
> end...
>
> http://netlib.org/utk/misc/counts.html
>
> --
> Dr.B.Voh
> -----------------------------------------------
> Modeling * Simulation * Analysis
> http://www.sdynamix.com
> -----------------------------------------------
>
--
Matthew C Roberts
Graduate Student
Department of Economics
NC State University
iday_...@DIESPAMDIEhotmail.com
% TO REPLY TO THIS MESSAGE
% REMOVE ALL CAPITAL LETTERS
% FROM THE EMAIL ADDRESS
Manuel Costa
There is a big discussion about speed in this topic. Why not to test
code speed in different languages?
I'm really interested in the results!!
Here is my proposal written in Delphi 4:
procedure TForm1.Button1Click(Sender: TObject);
const K = 1024;
type
PArrInt = ^TArrInt;
TArrInt = array[0..100000] of integer;
var
Data : PArrInt;
Size,
T,
i : integer;
begin
Data := nil;
try
Size := 10*K*K;
GetMem(Data,SizeOf(Integer)*Size);
T := GetTickCount();
for i := 0 to Size-1 do
Data[i] := (i + 1)*5 div 2;
T := GetTickCount() - T;
ShowMessage(IntToStr(T) + ' Milliseconds - ' +
IntToStr(Data[Size-1]));
finally
if Data<>nil then FreeMem(Data);
end;
end;
results:
time = 491 milliseconds in a 450 Mz PIII with 256 Mb of RAM.
Sincerely
Manuel
Lynn Killingbeck
There are lots of speed benchmarks, but nothing beats working with your
own real-world problem on real hardware. Very often, a poor algorithm on
a fast machine will be faster than a good algorithm on a slow machine.
Compilers often make a difference, including different optimizations on
the same compiler. My own conclusion, after seeing lots of the "mine is
better than yours!" arguments is: "Some programmers are much better
programmers than other programmers." They understand the problem to be
solved, a selection of viable algorithms, a selection of viable
languages, the underlying hardware strengths and weakensses, how to
identify the critical areas of the program that can benefit by extra
effort on speeding up local sections of code (so they don't waste their
time getting an 80% improvement in code that takes only 1 percent of the
resources), and other things that pertain to the problem at hand.
So, do you have some description of the problem you are solving? Or is
it just another ad-hoc benchmark of some kind? What is it measuring?
Lynn Killingbeck
David Wilkinson
<man...@fct.unl.pt> writes
I tried to run this on Delphi 5 but had two problems. It gave a warning
on the line
>T := GetTickCount() - T;
about mixing signed and unsigned variables. I got round this by using T1
and T2 and showing T2-T1.
More seriously it failed with "Invalid pointer operation" on line
> if Data<>nil then FreeMem(Data);
which I was unable to overcome.
Generally, I have no real idea what this program is doing, other than
assigning some values to an integer pointer array. try..finally blocks
do not even get a mention in "Teach Yourself Delphi in 14 days" and I
never use pointers. All real engineering and scientific programs use
floating point numbers and, probably, less memory than your program. I
doubt whether this is a useful benchmark program for computational fluid
dynamics but would be very interested in a program that was in order to
see how much speed increase I could get with a better computer.
--
David Wilkinson
Manuel Costa
operations without any optimization. Just to see the compiler working
in an ordinary problem. I think that that gives an idea of the
compiler and not the developer. I think that today's compilers do very
similar jobs when they translate code to the machine.
I don't have any idea of what will happen in, for example, an ordinary
fortran compiler for windows. VB6 performs about 20/30 percent slower
doing the same thing. C++ builder performs like Delphi and i didn't
try with visual c++ since i don't have it.
Sincerely
Manuel
Mattias Alveteg
particularly useful, basically because it only uses integer arithmetics
(the speed of which is different from real arithmetics) and since
everyone that enters this comparison really has to have the exact same
hardware as you have in order for the comparison to be of any relevance.
Writing a good pseudo-coded test program that can easily be translated
to several languages and that describes real-life performance issues is
far over my capacity, so I'll just wish you good luck.
/mattias alveteg
Hankel O'Fung
> I don't consider myself a numerical analyst, but do I consider scientific
> programming as one of my research fields.
>
> I write my own codes in C++ and Matlab. However, I make calls to FORTRAN
> libraries from my C++ codes (especially BLAS/Lapack).
To detour a little, may I ask how to make such calls? Any good
web tutorials on this issue? Since I am neither a numerical
analyst nor a professional programmer, those linkage issues
are headaches to me.
It seems that many folks in this ng write programs that are really
numerically intensive (say, each runs for days or weeks), and most of
them program on Unix/Linux systems. In my case, however, the programs
shall run on Windows systems simply because my clients use Windows
systems. And I really need GUI and ODBC supports. I wonder if this
can be easily done using any current fortran development environments.
If not, it would be very expensive for me to buy both a MSVC/BCB/Delphi
compiler plus any fortran compiler that can generate optimized code.
(Intel fortran compiler, e.g., costs $349!!!)
Cheers, Hankel
Manuel Costa
Do it this way
procedure TForm1.Button1Click(Sender: TObject);
const K = 1024;
var
Data : array of integer;
Size,
T,
i : integer;
begin
Size := 10*K*K;
SetLength(Data,Size);
//Start counting
T := GetTickCount();
for i := 0 to Size-1 do
Data[i] := (i + 1)*5 div 2;
//get execution time in milliseconds
T := GetTickCount() - T;
//Show the result
ShowMessage(IntToStr(T) + ' Milliseconds - ' +
IntToStr(Data[Size-1]));
end;
this is same thing written with a different syntax. Try finally
statement is to handle exceptions. For example, if you have an error
executing code you will always destroy your allocated memory. Writing
the procedure like here, Delphi compiler will write that code for you.
sincerely
Manuel
Stephen Howe
Paul Victor Birke <nonl...@home.com> wrote in message
news:39E1D354...@home.com...
> I am using Watcom 77 10.5. It is just soooo gooooood!!
Well you might be pleased to know that Watcom Fortran is going open-sourced.
See www.openwatcom.org.
Stephen Howe
David Wilkinson
Well, it worked this time, with much rattling of the hard disc, and took
37605 milliseconds-26214400. That is 37.6 secs, much more than your 250
msecs or whatever it was. This was on a 266 MHz machine with 64 Mb RAM.
The integer array requires 41.9x10^6 bytes which is presumably too much
to fit into my RAM with whatever else is in there. Presumably if I had
more RAM it would work much faster, but it tells me nothing about speed
of manipulating floating point numbers within RAM. The biggest arrays I
use at the moment are about 500x500 of double which occupy 2x10^6 bytes.
Regards
In article <9ougrr...@forum.mathforum.com>, Manuel Costa
<man...@fct.unl.pt> writes
--
David Wilkinson
Matthew C Roberts
"Hankel O'Fung" <3....@polyu.edu.hk> wrote in message
news:39E713D7...@polyu.edu.hk...
>
> It seems that many folks in this ng write programs that are really
> numerically intensive (say, each runs for days or weeks), and most of
> them program on Unix/Linux systems. In my case, however, the programs
> shall run on Windows systems simply because my clients use Windows
> systems. And I really need GUI and ODBC supports. I wonder if this
> can be easily done using any current fortran development environments.
> If not, it would be very expensive for me to buy both a MSVC/BCB/Delphi
> compiler plus any fortran compiler that can generate optimized code.
> (Intel fortran compiler, e.g., costs $349!!!)
Hankel,
Actually, there are definitely options to build both GUIs and ODBC calls
into a Fortran program, I have written GUIs for many of mine (though simple)
and have downloaded & played with the ODBC calling libraries.
As for the GUIs, Digital Visual Fortran provides interfaces to a great
number of the relevant Win APIs. You can write quite complicated GUIs with
DVF, and now with DVF6.5 you can build COM objects for direct inclusion into
Excel, Access, etc. As for the ODBC support, http://www.canaimasoft.com
provides a product called f90sql which provides ODBC functionality to
Fortran programs. They also have a lite version that is a free download.
Other Fortran compiler vendors probably provide similar functionality,
Salford is one that I have heard many speak quite highly of.
Anyway, hope this helps. If I can help, let me know.
jan...@netbistro.com
<Da...@quarksoft.demon.co.uk> wrote:
>. I
>doubt whether this is a useful benchmark program for computational fluid
>dynamics but would be very interested in a program that was in order to
>see how much speed increase I could get with a better computer.
>
>David Wilkinson
You might look at how different computers do on Seti@Home work units.
There is a program that has been ported to numerous platforms and is
being run on hundreds of thousands of machines. My Pentium 133 takes
44 hours and the Pentium (II ?) 566 at work takes ten hours. Some of
the newest Alpha machines take only one hour. Since platforms are not
broken out (all of the Intel windows machines are lumped together)
you will have to ask around about how different peoples machines are
doing.
Jan Christiansen
Hankel O'Fung
Thanks for the information. I've visited the website you mentioned. The
f90sql looks good, but the price is scary ($249 for merely database
access --- you still need a fortran compiler separately). However,
after I visited several fortran compiler websites, I found that many
fortran compilers, as you described, are not as primitive as I thought.
It's at least a good news to have known that. Thank you.
Regards,
Hankel
Dan Tex1
>> libraries from my C++ codes (especially BLAS/Lapack).
>
>To detour a little, may I ask how to make such calls? Any good
>web tutorials on this issue? Since I am neither a numerical
>analyst nor a professional programmer, those linkage issues
>are headaches to me.
>
>numerically intensive (say, each runs for days or weeks), and most of
>them program on Unix/Linux systems. In my case, however, the programs
>shall run on Windows systems simply because my clients use Windows
>systems. And I really need GUI and ODBC supports. I wonder if this
>can be easily done using any current fortran development environments.
>If not, it would be very expensive for me to buy both a MSVC/BCB/Delphi
>compiler plus any fortran compiler that can generate optimized code.
>(Intel fortran compiler, e.g., costs $349!!!)
>
I use Lahey LF95 Fortran along with Winteracter for my GUI. They work very
well together and there is no mixed language programming required. Of
course... there are other good fortran compilers out there and a couple other
good GUI tools also. But... none of them are inexpensive ( neither is Matlab
by the way ). You're gonna have to cough up the cash if you wanna stay in the
game and be efficient at the same time.
Dan :-)
Bruce Scott TOK
Hankel O'Fung <3....@polyu.edu.hk> wrote:
>Hi Matthew,
>
>Thanks for the information. I've visited the website you mentioned. The
>f90sql looks good, but the price is scary ($249 for merely database
>access --- you still need a fortran compiler separately). However,
>after I visited several fortran compiler websites, I found that many
>fortran compilers, as you described, are not as primitive as I thought.
>It's at least a good news to have known that. Thank you.
Try the fujitsu web site www.fujitsu.com and look for their F90/F95
compiler. There is a free version for research and personal purposes.
We have the full version and it is about 200 USD. It produces very fast
code (I compiled my turbulence code with no modifications and tested it
on a Linux box ... Sony VIAO with I think a P300).
--
cu,
Bruce
drift wave turbulence: http://www.rzg.mpg.de/~bds/
Lars Gregersen
wrote:
>Brien Alkire wrote:
>
>> I don't consider myself a numerical analyst, but do I consider scientific
>> programming as one of my research fields.
>>
>> I write my own codes in C++ and Matlab. However, I make calls to FORTRAN
>> libraries from my C++ codes (especially BLAS/Lapack).
>
>To detour a little, may I ask how to make such calls? Any good
>web tutorials on this issue? Since I am neither a numerical
>analyst nor a professional programmer, those linkage issues
>are headaches to me.
>
>It seems that many folks in this ng write programs that are really
>numerically intensive (say, each runs for days or weeks), and most of
>them program on Unix/Linux systems. In my case, however, the programs
>shall run on Windows systems simply because my clients use Windows
>systems. And I really need GUI and ODBC supports. I wonder if this
>can be easily done using any current fortran development environments.
>If not, it would be very expensive for me to buy both a MSVC/BCB/Delphi
>compiler plus any fortran compiler that can generate optimized code.
>(Intel fortran compiler, e.g., costs $349!!!)
If price is a concern then go GNU: www.gcc.org
Lars
---
M.Sc. Chem. Engng. Lars Gregersen
l...@kt.dtu.dk
http://members.nbci.com/gregersenweb/
Martin Kahlert
In article <39E713D7...@polyu.edu.hk>,
Hankel O'Fung <3....@polyu.edu.hk> writes:
> It seems that many folks in this ng write programs that are really
> numerically intensive (say, each runs for days or weeks), and most of
> them program on Unix/Linux systems. In my case, however, the programs
> shall run on Windows systems simply because my clients use Windows
> systems. And I really need GUI and ODBC supports. I wonder if this
> can be easily done using any current fortran development environments.
> If not, it would be very expensive for me to buy both a MSVC/BCB/Delphi
> compiler plus any fortran compiler that can generate optimized code.
> (Intel fortran compiler, e.g., costs $349!!!)
We use MS Visual C++ (expensive) and Compaq Fortran (expensive).
They can work together and you can call Fortran Routines without
much headache. This is for a project, where MS is the only target
platform.
We have a much bigger project here, which is very cross platform,
no GUI, though. For that we use gnu's gcc and g77 (Fortran).
I would suggest to use the tools from http://www.mingw.org/
(Use the 'latest development snapshot', since that is much more stable,
than the 'stable' release!)
This is a completely free compiler system, which produces code
that is comparable in speed to MS's compilers. (O.k. it's not
that far from it).
It is better suited for you than the Cygnus tools, since these
are targetted for cross platform development from Unix to Win32.
Every application, that is generated by Cygnus's system depends
on a dll from Cygnus (it contains some Unix-only functions like fork).
The mingw toolchain produces native Windows applications.
The compiler is in both cases the same (gcc/g77).
But be warned: The mingw project is quite young and there may be some
own work needed in order to make some not so common functions of MS's
libraries work. (MS doesn't allow the free distribution/copying of there
header files)
There is no GUI included! If you want Visual Studio, you will have to
pay for it. There are free alternatives, though.
The mingw toolchain works more the Unix way: Write your app by any
Editor, produce a Makefile and call make.
The Debugger is usable for C/C++. It's a pain for Fortran!
Hope that helps,
Martin.
--
The early bird gets the worm. If you want something else for
breakfast, get up later.
Ian Gay
b...@rzg.mpg.de (Bruce Scott TOK) wrote:
[snip]
Can you post a complete URL? If I go to that site and search for 'fortran' I get
no matches.
*** To reply by e-mail, make double u single in address ***
Ivan Frohne
Bruce Scott TOK
>In article <8seqi...@subds.rzg.mpg.de>,
> b...@rzg.mpg.de (Bruce Scott TOK) wrote:
>[snip]
>>Try the fujitsu web site www.fujitsu.com and look for their F90/F95
>>compiler.
>
>Can you post a complete URL? If I go to that site and search for
>'fortran' I get no matches.
As the other guy said, Lahey now sell it. Makes me wonder... Lahey are
the big boys, and although they say they support Linux they are really
selling to Windows boxes.
Here is what I sent to someone else via email...
It looks like disaster has struck and the Fujitsu Fortran has been
bought up by Lahey, who are a Windows oriented company. Check it out
here:
There are no free versions, and there are also no Linux specific
versions as far as I can tell (altough the Express version runs there).
Mike Metcalf's FAQ file has deleted the entry for Fujitsu Linux as of
May 2000:
http://www.fortran.com/fortran/metcalf.html
For more information you can start from this link:
Information about running Fortran codes under Linux
http://studbolt.physast.uga.edu/templon/fortran.html
which contains...
06-15-2000 Fujitsu to stop selling Linux Fortran.
(*) Fujitsu Fortran Compiler --- This product lives on since it forms
the guts of Lahey's system. A newsgroup posting by Fujitsu claims
that development of this compiler continues. However, Fujitsu no
longer sells this compiler directly.
the posting:
LINUX FORTRAN & C/C++
Fujitsu Software Corp. stopped selling the Fortran and C/C++ products
for Linux on June, 1, 2000. After that, Lahey Computer Systems,
Inc. takes over the sale of Fortran product for Linux(except C/C++
product). Fujitsu Limited is continuously developing the Fortran and
C/C++ products for Linux. And also, it continues to provide the
Lahey/Fujitsu Fortran 95 compiler to Lahey Computer Systems, Inc. We
support our customers who have already purchased the support
subscription. If you have any questions about this subject, please
feel free to contact us at sup...@tools.fujitsu.com. If you are
interested in the Fortran for Linux, please visit Lahey LF95 Express.
So Lahey are supposed to be supporting Linux, but their own page is very
Windows oriented. Makes me not trust them. Also, the compiler express
version is USD 250, which is more than the complete version was from
Fujitsu.
We'll see...
Dan Tex1
stable.
It is no more or less "Windows" oriented than the other vendors making
compilers
for the PC market as far as I can see.
For those out there saying that they want a compiler that can create a nice
GUI.... it kind of seems backwards to me that you would then complain
that a compiler is TOO Windows oriented?? GUI's are in general, very non-
portable. Seems to me that you NEED a compiler that is geared heavily towards
the "non-portable" operating system you plan on using? Otherwise... you will
have to kiss your fancy looking GUI goodbye.
Dan :-)
DannyRich
both an F95 and C++ compilers, the latter is compatible with the MS Foundation
Classes and will allow direct calls. In addition, it is compatible with
Winteracter - a third party GUI design package that runs on many PC and
workstation platforms. Unfortunately, a solid cross-platform development
system will not be inexpensive. A lot of development time was invested in
getting all of those tools tested and debugged.
Bruce Scott TOK
Dan Tex1 <dan...@aol.com> wrote:
>I think you all will find the Lahey/Fujitsu Fortran 95 compiler to be fast and
>stable.
>It is no more or less "Windows" oriented than the other vendors making
>compilers
>for the PC market as far as I can see.
>
>For those out there saying that they want a compiler that can create a nice
>GUI.... it kind of seems backwards to me that you would then complain
>that a compiler is TOO Windows oriented?? GUI's are in general, very non-
>portable. Seems to me that you NEED a compiler that is geared heavily towards
>the "non-portable" operating system you plan on using? Otherwise... you will
>have to kiss your fancy looking GUI goodbye.
Screw the GUIs, I just want standard high performance and complete
compatibility with GNU Make...
...reall programmers _still_ debug via PRINT statements :-)
[the exception is if you can get TotalView]
--
cu,
Bruce
drift wave turbulence: http://www.rzg.mpg.de/~bds/
sign the Linux Driver Petiton: http://www.libranet.com/petition.html
Bruce Scott TOK
DannyRich <dann...@aol.com> wrote:
>In agreement with "smiling Dan" I recommend the Lahey system. It comes with
>both an F95 and C++ compilers, the latter is compatible with the MS Foundation
>Classes and will allow direct calls. In addition, it is compatible with
>Winteracter - a third party GUI design package that runs on many PC and
>workstation platforms. Unfortunately, a solid cross-platform development
>system will not be inexpensive. A lot of development time was invested in
>getting all of those tools tested and debugged.
That's all fair enough, but then Fujitsu did the development and they
still do the support, but when the thing was offered by Fujitsu we still
had a free version from them (useable by, e.g., high school students on
allowances). The VAST/F90 thing is nice but can't deal with allocated
arrays whose dimensions are input parameters (since it converts to F77
and not C/C++).
Bottom line: we just lost the most important free F90 compiler in the
world, due to corporate maneuvering. That sucks.
So Fujitsu built the thing, and they offered a free version. Lahey buys
it up, and they don't. End of story.
Dan Tex1
Bottom line: we just lost the most important free F90 compiler in the
world, due to corporate maneuvering. That sucks.
So Fujitsu built the thing, and they offered a free version. Lahey buys
it up, and they don't. End of story.
--
cu,
Bruce
===========================================================
Hmmm. I don't recall there being ANY free F90 compiler on the market???
Also... The Lahey compiler is more than just the product from Fujitsu.
Of course... the real bottom line might be.... "Why should anyone receive
a free compiler from anyone?" Do you think anyone OWES it to you? Also,
why all the hostility to Lahey? Fujitsu is in partnership with Lahey on this
one.
Do you think Fujitsu is so weak that Lahey muscled them into the deal?
Neither
Fujitsu or Lahey owe it to anyone to produce a free compiler. The current
compiler from Lahey is better than the prior compilers from Lahey or Fujitsu.
Cough up some money. Go out and BUY a compiler from some company ( you
get to choose the company ). It'll do the economy some good. It gets kind
of
lame hearing so many people whining about not getting enough freebies.
( Or of course... spend a truckload of your own time and money and create a
compiler yourself that is as good as the top few compilers on the market
today. Then... give it to the rest of us for free. You do that and I will
be
very impressed. )
Dan :-)
Bruce Scott TOK
Dan Tex1 <dan...@aol.com> wrote:
>===========================================================
>Bottom line: we just lost the most important free F90 compiler in the
>world, due to corporate maneuvering. That sucks.
>
>So Fujitsu built the thing, and they offered a free version. Lahey buys
>it up, and they don't. End of story.
>--
>cu,
>Bruce
>===========================================================
>
>Hmmm. I don't recall there being ANY free F90 compiler on the market???
>Also... The Lahey compiler is more than just the product from Fujitsu.
Maybe so, maybe just the windows versions.
The free version of the Fujitsu compiler was (1) good enough to use on
its own by poor people (incl students, who don't need pro optimisation
when they are learning), and (2) very effective advertisement for the
professional version, which was around USD 200, for the rest of us.
>Of course... the real bottom line might be.... "Why should anyone receive
>a free compiler from anyone?" Do you think anyone OWES it to you? Also,
>why all the hostility to Lahey? Fujitsu is in partnership with Lahey on this
>one.
>Do you think Fujitsu is so weak that Lahey muscled them into the deal?
>Neither
>Fujitsu or Lahey owe it to anyone to produce a free compiler. The current
>compiler from Lahey is better than the prior compilers from Lahey or Fujitsu.
>
>Cough up some money. Go out and BUY a compiler from some company ( you
>get to choose the company ). It'll do the economy some good. It gets kind
>of
>lame hearing so many people whining about not getting enough freebies.
Your rant is seriously misplaced. We bought it as an institute, and
several of us bought the full blown version for our own laptops.
Do you understand the reason free software even exists, or even the
sense of (in this case absolutely voluntary) community service by a
Corporation, or even the PR value of having a free product on the side?
>( Or of course... spend a truckload of your own time and money and create a
>compiler yourself that is as good as the top few compilers on the market
>today. Then... give it to the rest of us for free. You do that and I will
>be
>very impressed. )
You do not understand my position on this matter. It is of course
easier to rant at strawmen.
(1) Nobody said there _must_ be a free version, but...
(2) In fact there was a very good one, and now it is gone.
DannyRich
>>Hmmm. I don't recall there being ANY free F90 compiler on the market???
>>Also... The Lahey compiler is more than just the product from Fujitsu.
>
>Maybe so, maybe just the windows versions.
>
>
>The free version of the Fujitsu compiler was (1) good enough to use on
>its own by poor people (incl students, who don't need pro optimisation
>when they are learning), and (2) very effective advertisement for the
>professional version, which was around USD 200, for the rest of us.
>
>Do you understand the reason free software even exists, or even the
>sense of (in this case absolutely voluntary) community service by a
>Corporation, or even the PR value of having a free product on the side?
>
I seem to remember before Fujitsu there was ELF90 from Lahey which was a free
version of their F90 fortran compiler. It recieved a lot of flack because they
limited it to only one memory model and did not include the backward F77
extensions that were depricated by the Fortran 90 standard. That free compiler
disappeared at apparently the same time as the Fujitsu version when Lahey and
Fujitsu introduced the F95. I do not know why they dropped ELF90. It was
nice little compiler on which to learn F90 syntax. You could solve real
problems - just not really big ones and you had to rewrite any legacy code to
bring it up to the F90 standard. I thought it shame when they dropped it. I
used it on my home system and F90 on my system at work. I have now upgraded to
F95 but I miss being able to work on problems at home.
Olaf Michelsson
>
> >>
> >>Hmmm. I don't recall there being ANY free F90 compiler on the market???
> >>Also... The Lahey compiler is more than just the product from Fujitsu.
> >
> >Maybe so, maybe just the windows versions.
> >
.
.
>
> I seem to remember before Fujitsu there was ELF90 from Lahey which was a free
> version of their F90 fortran compiler. It recieved a lot of flack because they
> limited it to only one memory model and did not include the backward F77
> extensions that were depricated by the Fortran 90 standard. That free compiler
> disappeared at apparently the same time as the Fujitsu version when Lahey and
> Fujitsu introduced the F95. I do not know why they dropped ELF90. It was
> nice little compiler on which to learn F90 syntax. You could solve real
> problems - just not really big ones and you had to rewrite any legacy code to
> bring it up to the F90 standard. I thought it shame when they dropped it. I
> used it on my home system and F90 on my system at work. I have now upgraded to
> F95 but I miss being able to work on problems at home.
>
> Dann...@aol.com
If you would like to use an ELF90 comparable F95-compiler, which
supports
the new syntax, only, why don't you use the F-compiler from imagine1?
This compiler supports now in its last incarnation the f95-syntax and is
free
for all supported platforms (Linux, Solaris, Windows, MAC (f90 only))
Download under
ftp://web01.meltingsand.com/pub/F
Olaf
--
Olaf Michelsson mailto:miche...@e-technik.tu-ilmenau.de
Faculty E/I Dept. of Theoretical Electrical Engineering
Technical University of Ilmenau, Germany
jmfb...@aol.com
>>Bottom line: we just lost the most important free F90 compiler in the
>>world, due to corporate maneuvering. That sucks.
>>
>>So Fujitsu built the thing, and they offered a free version. Lahey buys
>>it up, and they don't. End of story.
>>--
>>cu,
>>Bruce
>>===========================================================
>>
>>Hmmm. I don't recall there being ANY free F90 compiler on the market???
>>Also... The Lahey compiler is more than just the product from Fujitsu.
>
>
>its own by poor people (incl students, who don't need pro optimisation
>when they are learning), and (2) very effective advertisement for the
>professional version, which was around USD 200, for the rest of us.
>
>>should anyone receive
>>a free compiler from anyone?" Do you think anyone
>>OWES it to you? Also,
>>why all the hostility to Lahey? Fujitsu is in
>>partnership with Lahey on this
>>one.
>>Do you think Fujitsu is so weak that Lahey muscled them into the deal?
>>Neither
>>Fujitsu or Lahey owe it to anyone to produce a free
>>compiler. The current
>>compiler from Lahey is better than the prior compilers
>>from Lahey or Fujitsu.
>>
>>Cough up some money. Go out and BUY a compiler from some company ( you
>>get to choose the company ). It'll do the economy some
>>good. It gets kind
>>of
>>lame hearing so many people whining about not getting enough freebies.
>
>several of us bought the full blown version for our own laptops.
>
>sense of (in this case absolutely voluntary) community service by a
>Corporation, or even the PR value of having a free product on the side?
I've been watching a very disturbing trend; it seems that the
attitude is to try to "control" who gets training and how
much these trainees learn. A side effect of a company
getting bought out is that most of the knowledge of that
company gets lost because the parent company places no
value on it. That is a side effect of having this
knowledge "owned" by one company. Math and science
knowledge is disseminated via your publication procedures.
Software and hardware development doesn't have an
equivalent mechanism.
<snip>
/BAH
Subtract a hundred and four for e-mail.
Bruce Scott TOK
>I've been watching a very disturbing trend; it seems that the
>attitude is to try to "control" who gets training and how
>much these trainees learn. A side effect of a company
>getting bought out is that most of the knowledge of that
>company gets lost because the parent company places no
>value on it. That is a side effect of having this
>knowledge "owned" by one company. Math and science
>knowledge is disseminated via your publication procedures.
>Software and hardware development doesn't have an
>equivalent mechanism.
Very true, and this is among the most important reasons to keep large
corporations out of the universities. You can imagine the effect had
the corporate invasion happened earlier... C and Unix, and FORTRAN, all
got to gestate a long time without much in the way of steering/spinning
by interests. Though IBM was quite successful in screwing up what it
touched (including UNIX), they didn't write all the stuff in the first
place.
Software patents and NDAs are, of course, the main impediment to a real
peer-reviewed software literature.
George Russell
[snip]
> Very true, and this is among the most important reasons to keep large
> corporations out of the universities. You can imagine the effect had
> the corporate invasion happened earlier... C and Unix, and FORTRAN, all
> got to gestate a long time without much in the way of steering/spinning
> by interests. Though IBM was quite successful in screwing up what it
> touched (including UNIX), they didn't write all the stuff in the first
> place.
first place? How far would Unix have got if AT&T hadn't backed it?
>
> Software patents and NDAs are, of course, the main impediment to a real
> peer-reviewed software literature.
everyone is lucky enough (like me) to work in a university doing pure research.
Inventing algorithms is often hard work, and if you want people to do so for
private companies, you need to find some way of paying them. Since we live in
a market econony, patents seem the most appropriate solution. I can guarantee that
valuable privately developed algorithms will either get patents or else protected by
non-disclosure; personally I think patents are the better solution. Obviously we need
patent offices to be rather more clued up about what constitutes a non-trivial advance
but that's another issue . . .
jmfb...@aol.com
George Russell <g...@informatik.uni-bremen.de> wrote:
>Bruce Scott TOK wrote:
>[snip]
>> Very true, and this is among the most important reasons to keep large
>> corporations out of the universities. You can imagine the effect had
>> the corporate invasion happened earlier... C and Unix, and FORTRAN, all
>> got to gestate a long time without much in the way of steering/spinning
>> by interests. Though IBM was quite successful in screwing up what it
>> touched (including UNIX), they didn't write all the stuff in the first
>> place.
>Er didn't IBM invent FORTRAN (the first popular non-assembler
>>language) in the
>>first place? How far would Unix have got if AT&T hadn't backed it?
>>
>> Software patents and NDAs are, of course, the main impediment to a real
>> peer-reviewed software literature.
>I'm sorry, but I regard this as pure Free Software
>Foundation propaganda. Not everyone is lucky enough
>(like me) to work in a university doing pure research.
>Inventing algorithms is often hard work, and if you want
>people to do so for private companies, you need to find
>some way of paying them.
We did. That's not the issue I'm trying to point out.
The problem is not losing the solution. Everytime you
do an upgrade of a piece of software, you are essentially
"losing" the knowledge that produced the previous version;
and that previous version could have had a piece of
somebody's code that did something really well. The next
version, however, didn't keep that code (for whatever reason).
Now, unless the company has the foresight or care to keep
the old stuff, the old knowledge is just gone.
> Since we live in
>a market econony, patents seem the most appropriate
>solution. I can guarantee that
>valuable privately developed algorithms will either
>get patents or else protected by
>non-disclosure; ...
Non-disclosure sucks. It doesn't teach anybody anything.
> ...personally I think patents are the better solution. Obviously we need
>patent offices to be rather more clued up about what
>constitutes a non-trivial advance but that's another issue . . .
The problem is that it may take man-years of development to
know that a certain piece of code should have been patented.
Software is very hard to patent. But that's an ownership
issue. I want to talk or warn about the teaching issue.
Bruce understood.
jmfb...@aol.com
>
>>I've been watching a very disturbing trend; it seems that the
>>attitude is to try to "control" who gets training and how
>>much these trainees learn. A side effect of a company
>>getting bought out is that most of the knowledge of that
>>company gets lost because the parent company places no
>>value on it. That is a side effect of having this
>>knowledge "owned" by one company. Math and science
>>knowledge is disseminated via your publication procedures.
>>Software and hardware development doesn't have an
>>equivalent mechanism.
>
>corporations out of the universities. You can imagine the effect had
>the corporate invasion happened earlier... C and Unix, and FORTRAN, all
>got to gestate a long time without much in the way of steering/spinning
>by interests. Though IBM was quite successful in screwing up what it
>touched (including UNIX), they didn't write all the stuff in the first
>place.
>
>peer-reviewed software literature.
Our solution, which had its own class of problems, was to ship
sources with the executables but that was a backdoor way
to encourage self-teaching. Believe me, they got
reveiwed [wry emoticon here].
I just wanted to warn you all about the dangers of all this
buyout business that is going on. I shall now bow out of
this august group :-).
/BAH
Bruce Scott TOK
George Russell <g...@informatik.uni-bremen.de> wrote:
>Bruce Scott TOK wrote:
>[snip]
>> corporations out of the universities. You can imagine the effect had
>> the corporate invasion happened earlier... C and Unix, and FORTRAN, all
>> got to gestate a long time without much in the way of steering/spinning
>> by interests. Though IBM was quite successful in screwing up what it
>> touched (including UNIX), they didn't write all the stuff in the first
>> place.
>first place? How far would Unix have got if AT&T hadn't backed it?
Different situation (see below). Everyone knew what was in it, and the
spectrum of people involved in development and improvement was very
wide.
But I argue UNIX would be nowhere today without that generation of CS
people steeped in it which flowed into the field in the years
1980-1990+.
>> Software patents and NDAs are, of course, the main impediment to a real
>> peer-reviewed software literature.
>I'm sorry, but I regard this as pure Free Software Foundation propaganda. Not
>everyone is lucky enough (like me) to work in a university doing pure research.
>Inventing algorithms is often hard work, and if you want people to do so for
>private companies, you need to find some way of paying them. Since we live in
>a market econony, patents seem the most appropriate solution. I can guarantee that
>valuable privately developed algorithms will either get patents or else protected by
>non-disclosure; personally I think patents are the better solution. Obviously we need
>patent offices to be rather more clued up about what constitutes a non-trivial advance
>but that's another issue . . .
I would agree if and only if a patent were a protection only for
_published_ software. There should be negative rewards for keeping
basic knowledge secret.
Part of the whole Open Society thing, of which Open Source is only a
small part...
Thomas Ruedas
>people steeped in it which flowed into the field in the years
>1980-1990+.
tradition as well. I am convinced that Open Source software in general
and Linux as a particular example are the only (or at least the most
realistic) hope to escape from the monopoly M$ managed to evolve over
the last decade; and that is because the laws of the market don't really
hold in the open software world, i.e. it is not as easy for a powerful
and unscrupulous company to crunch its competitors here. Today, we're at
a point where Linux is evolving towards an OS which can be handled by
non-specialists as well, which is not completely, but to a large part
the merit of the open source community.
--
Sign the Linux Driver petition:
http://www.libralinux.com/petition.english.html
------------------------------------------------------------------------
Thomas Ruedas
Institute of Meteorology and Geophysics, J.W.Goethe University Frankfurt
e-mail: rue...@geophysik.uni-frankfurt.de
http://www.geophysik.uni-frankfurt.de/~ruedas/
------------------------------------------------------------------------
DannyRich
>
>If you would like to use an ELF90 comparable F95-compiler, which
>supports
>the new syntax, only, why don't you use the F-compiler from imagine1?
>This compiler supports now in its last incarnation the f95-syntax and is
>free
>for all supported platforms (Linux, Solaris, Windows, MAC (f90 only))
>Download under
> ftp://web01.meltingsand.com/pub/F
>
>Olaf
>--
>
> Olaf Michelsson mailto:miche...@e-technik.tu-ilmenau.de
> Faculty E/I Dept. of Theoretical Electrical Engineering
> Technical University of Ilmenau, Germany
>
I am game to give it a try. Hope it has better documentation than g77. I
never could get that system to work. Too many pieces in too many different
directories and too many different and incompatible versions. One of the
problems with software developed at large.
Bruce Scott TOK
DannyRich <dann...@aol.com> wrote:
>I seem to remember before Fujitsu there was ELF90 from Lahey which was a free
>version of their F90 fortran compiler. It recieved a lot of flack because they
>limited it to only one memory model and did not include the backward F77
>extensions that were depricated by the Fortran 90 standard. That free compiler
>disappeared at apparently the same time as the Fujitsu version when Lahey and
>Fujitsu introduced the F95. I do not know why they dropped ELF90. It was
>nice little compiler on which to learn F90 syntax. You could solve real
>problems - just not really big ones and you had to rewrite any legacy code to
>bring it up to the F90 standard.
That's all fair enough. Nobody expects a research or production grade
compiler for nothing (even if we do have the C/C++ stuff from GNU). But
it is nice to have learning tools that you can master before deciding to
invest in stuff that you need to understand before you can know whether
it is going to bring rewards.
If the free F90 cannot do basic things like recursion, modules,
allocation, pointers, and array syntax then it wouldn't be very useful.
That's the sort of stuff you have to learn if you want to learn how to
use the language. Otherwise it is just F77 (maybe not even that) and we
have that from GNU already (and thanks to altruism by AT&T or whomever
we had it through f2c for many years).
A colleague here corrected me on the VAST/F90 thing... the only problem
it has with the allocation seems to be the namelist, with array
dimensions used as input parameters. He reads these dimensions in from
a file, and then the thing works. So maybe I'll try that.
>I thought it shame when they dropped it. I
>used it on my home system and F90 on my system at work. I have now upgraded to
>F95 but I miss being able to work on problems at home.
My guess is that they dropped it in order to incrementally maximise
profits in the local approximation where the time scale is zero,
probably because some MBA within the hierarchy told them to. I could be
wrong though. I just don't like to see private companies taking
advantage of people just because they can... even if it might just be a
side effect of something else.
Bruce Scott TOK
DannyRich <dann...@aol.com> wrote:
>I am game to give it a try. Hope it has better documentation than g77. I
>never could get that system to work. Too many pieces in too many different
>directories and too many different and incompatible versions. One of the
>problems with software developed at large.
How is f2c+gcc? I never had problems with that and still use it for
basic testing of new schemes (only thing is, it won't take namelists
because that isn't in the F77 standard).
Bruce Scott TOK
Olaf Michelsson <miche...@e-technik.tu-ilmenau.de> wrote:
>If you would like to use an ELF90 comparable F95-compiler, which
>supports
>the new syntax, only, why don't you use the F-compiler from imagine1?
>This compiler supports now in its last incarnation the f95-syntax and is
>free
>for all supported platforms (Linux, Solaris, Windows, MAC (f90 only))
>Download under
> ftp://web01.meltingsand.com/pub/F
Thanks for this tip. I'll try it.
The rap on F I've heard is that you cannot run most pre-existing code
with it, but for me and my group this is no problem, because we are
researchers who re-write from the ground up once we understand the
problem we are working on :-)
Dan Tex1
>allocation, pointers, and array syntax then it wouldn't be very useful.
>That's the sort of stuff you have to learn if you want to learn how to
>use the language. Otherwise it is just F77 (maybe not even that) and we
>have that from GNU already (and thanks to altruism by AT&T or whomever
>we had it through f2c for many years).
You'd like F or ELF90 then. Those compilers do the new stuff. It's the older
stuff that they no longer support... mainly the older things that have
historically tended to get people into trouble.
Dan :-)
Atis Luguzs
Hello!
Do you have a problem with data analysing? I can help you.
Send me e-mail with details and we could do some business with us.
BY!
Atis
John Molitor
> In article <8rpg9d$3va$1...@strelovod.uni-mb.si>,
> Janez Makovsek <Janez.M...@usa.net> wrote:
>
> > Delphi got by far closer to that ideal (speed, math code compactness,
> > application capable) then any other tool.
>
> So Delphi fans claim (and I can easily imagine VB fans claiming the
> same about VB...) -- just too bad those environments are
> single-platform only...
>
> But Delphi and VB are probably both fine -- if you have no ambition
> of porting your program, and if it's not too heavy on numerical
> computations....
>
>
However, as you may know, Borland (Imprise) has a Linux port of Delphi
that's due out soon.
John