Fortran - Good compilable langauge for math and graphics?

Author

Good compilable langauge for math and graphics?

dave.harper@gmail.com

2005-06-02, 3:58 pm

I've been using Matlab for years, but would like to find an language
that's a little faster (compilable and executable) and lower level
(i.e. more freedom). I've considered Matlab's compiler, but would like
to broaden my programming knowledge instead of buying a $500 patch
(which might not work with the older version of Matlab I use, and might
require $upgrading$ my Matlab). Ideally, I'd like a language that:

1. Has a good math foundation
2. Can compile code to a relatively fast executable file(s)
3. Good graphing/plotting capabilities (graphics in general)
4. Relatively common, cheap, and not about die out

After trying some C++ and dealing with the difficulties with graphics
and math, I've come to the conclusion that C++ probably isn't the best
language to accomplish what I'm looking for. Are there any other
suggestions?

Thanks in advance!
Dave

Jeremy Watts

2005-06-02, 3:58 pm

<dave.harper@gmail.com> wrote in message
news:1117724977.764944.196570@g43g2000cwa.googlegroups.com...
> I've been using Matlab for years, but would like to find an language
> that's a little faster (compilable and executable) and lower level
> (i.e. more freedom). I've considered Matlab's compiler, but would like
> to broaden my programming knowledge instead of buying a $500 patch
> (which might not work with the older version of Matlab I use, and might
> require $upgrading$ my Matlab). Ideally, I'd like a language that:
>
> 1. Has a good math foundation
> 2. Can compile code to a relatively fast executable file(s)
> 3. Good graphing/plotting capabilities (graphics in general)
> 4. Relatively common, cheap, and not about die out
>
> After trying some C++ and dealing with the difficulties with graphics
> and math, I've come to the conclusion that C++ probably isn't the best
> language to accomplish what I'm looking for. Are there any other
> suggestions?
>
> Thanks in advance!
> Dave

fortran is certainly the language for maths - not sure about its graphics
though. java is pretty good for both.
>

s8ngsu3@yahoo.com

2005-06-02, 3:58 pm

> 1. Has a good math foundation
> 2. Can compile code to a relatively fast executable file(s)
> 3. Good graphing/plotting capabilities (graphics in general)
> 4. Relatively common, cheap, and not about die out

I guess you can choose any compilable language, and look for additional
libraries for additional capabilities (math, graphing, plotting etc.).
I doubt if there is a _language_ that has everything built-in.

s8ngsu3@yahoo.com

2005-06-02, 3:58 pm

> fortran is certainly the language for maths - not sure about its graphics
> though.

There are some graphics libraries that can be used with Fortran -
dislin (http://www.dislin.de/), pgplot
(http://www.astro.caltech.edu/~tjp/pgplot/), plplot
(http://plplot.sourceforge.net/), but I haven't yet tried them.
[color=darkred]
> java is pretty good for both.

Isn't Java too slow for number crunching?

Rich Townsend

2005-06-02, 3:58 pm

s8ngsu3@yahoo.com wrote:
>
>
> There are some graphics libraries that can be used with Fortran -
> dislin (http://www.dislin.de/), pgplot
> (http://www.astro.caltech.edu/~tjp/pgplot/), plplot
> (http://plplot.sourceforge.net/), but I haven't yet tried them.
>
>
>
> Isn't Java too slow for number crunching?
>

Yep, it has historically been a very slow language, although native Java
compilers are beginning to match languages such as C and C++.

But, in terms of already-existing software repositories such as Netlib,
Java simply can't hold a candle to Fortran.

On the flip side, of course, graphics in Java is pretty straightforward.
The OP may want to consider having a two-language approach -- number
crunching in Fortran, data presentation and analysis in Java. That's
something I myself am exploring at the moment.

cheers,

Rich

Madhusudan Singh

2005-06-02, 3:58 pm

dave.harper@gmail.com wrote:

> I've been using Matlab for years, but would like to find an language
> that's a little faster (compilable and executable) and lower level
> (i.e. more freedom). I've considered Matlab's compiler, but would like
> to broaden my programming knowledge instead of buying a $500 patch
> (which might not work with the older version of Matlab I use, and might
> require $upgrading$ my Matlab). Ideally, I'd like a language that:
>
> 1. Has a good math foundation
> 2. Can compile code to a relatively fast executable file(s)
> 3. Good graphing/plotting capabilities (graphics in general)
> 4. Relatively common, cheap, and not about die out
>
> After trying some C++ and dealing with the difficulties with graphics
> and math, I've come to the conclusion that C++ probably isn't the best
> language to accomplish what I'm looking for. Are there any other
> suggestions?
>
> Thanks in advance!
> Dave

Fortran might be what you need.

1. Math foundation is excellent. Perhaps the richest trove of mathematical
libraries (written for any language) exists for Fortran. Since a Fortran 95
compiler can be used on any old F77 or F66 code, there are no problems
there.
2. Generated executables tend to be very fast (very compiler dependent). To
give you an example, in C++, they had to create a special library called
blitz++ to try to match Fortran speed performance.

3. Platform dependent. You can use Dislin, plplot, pgplot, etc. On
Unix/Linux like systems, you can directly use gnuplot (which is free)
through gnuplotfortran.

4. Again, Intel Fortran Compiler is free for non-commercial use, and there
are also g95 and gfortran. Its definitely not going to die out anytime
soon. F2003 standard is out and you might see brand new compilers in a few
years.

What is probably a deal clincher for you is the ability to do vector and
matrix operations natively using a syntax that is very similar to Matlab.

andy2O@hotmail.com

2005-06-02, 3:58 pm

dave.harper@gmail.com wrote:
> I've been using Matlab for years, but would like to find an language
> that's a little faster (compilable and executable) and lower level
> (i.e. more freedom). I've considered Matlab's compiler, but would like
> to broaden my programming knowledge instead of buying a $500 patch
> (which might not work with the older version of Matlab I use, and might
> require $upgrading$ my Matlab). Ideally, I'd like a language that:
>
> 1. Has a good math foundation
> 2. Can compile code to a relatively fast executable file(s)

Fortran has good fast free/cheap compilers.
It has bags of very good numerical code available for free.
It handles arrays very easily and efficiently.
It has a very helpful news group who will help you learn and fix
problems quickly.

> 3. Good graphing/plotting capabilities (graphics in general)
> 4. Relatively common, cheap, and not about die out

Two obvious options here:

a) You could look at the Winteracter library, which usually gets a good
press on comp.lang.fortran for graphics.
b) Why not just keep using Matlab for plotting? Just write a few fairly
general purpose Fortran subroutines for saving your data to disk that
you can use in all your codes (e.g. one for outputting real arrays,
etc.) then load the data in Matlab.

The advantages of option (b) would be that

- Matlab is very good at plotting
- you know how to use it already and
there's nothing new to buy/learn
- done right, this can be very effective
and easy to use,

but also, and crucially for me, when analysing/plotting your data you
have all Matlab's commands at your fingertips to *interactively*
investigate it. E.g. There's no need to recompile and re-run a code
just to plot the difference of two solutions, or to plot y(x)^2 when
your code only gave you y(x), etc. Investigating numerical results is
best done interactively and compiled languages don't make that easy on
their own - so using Matlab fills the gap nicely.

That's my $0.02.

HTH
andy

Janne Blomqvist

2005-06-02, 3:58 pm

In article <d7na9t$40h$1@scrotar.nss.udel.edu>, Rich Townsend wrote:
> s8ngsu3@yahoo.com wrote:
>
> Yep, it has historically been a very slow language, although native Java
> compilers are beginning to match languages such as C and C++.
>
> But, in terms of already-existing software repositories such as Netlib,
> Java simply can't hold a candle to Fortran.
>
> On the flip side, of course, graphics in Java is pretty straightforward.
> The OP may want to consider having a two-language approach -- number
> crunching in Fortran, data presentation and analysis in Java. That's
> something I myself am exploring at the moment.

Well, since the performance of the second (non-Fortran) language isn't
that important, you might as well go with something higher level than
Java and save yourself some typing (e.g. GUI stuff is done in native
libraries anyway). My favourite is python, but YMMV.

--
Janne Blomqvist

kia

2005-06-02, 8:58 pm

dave.harper@gmail.com wrote:
>
> I've been using Matlab for years, but would like to find an language
> that's a little faster (compilable and executable) and lower level
> (i.e. more freedom). I've considered Matlab's compiler, but would like
> to broaden my programming knowledge instead of buying a $500 patch
> (which might not work with the older version of Matlab I use, and might
> require $upgrading$ my Matlab). Ideally, I'd like a language that:
>
> 1. Has a good math foundation
> 2. Can compile code to a relatively fast executable file(s)
> 3. Good graphing/plotting capabilities (graphics in general)
> 4. Relatively common, cheap, and not about die out

Try, http://www.openwatcom.org Fortran compiler to do 1, 2 & 4.
Either choose one of plotting packages (e.g. http://www.dislin.de) or
buy a commercial graphics package (e.g. SigmaPlot) to take care of 3.

glen herrmannsfeldt

2005-06-02, 8:58 pm

s8ngsu3@yahoo.com wrote:

(snip)
[color=darkred]
[color=darkred]
> Isn't Java too slow for number crunching?

With JIT on it is probably fine. JIT is pretty good at finding
the code in loops and compiling that to native instructions.
As most number crunching has a lot of loops it should work well.

I have done string crunching in Java, and it was pretty fast.

Independent of language, object oriented programming tends to do a
lot of memory allocation and deallocation which can be slow.

For number crunching, try not to do object creation inside deeply
(or even not so deeply) nested loops.

-- glen

Rich Townsend

2005-06-02, 8:58 pm

kia wrote:
> dave.harper@gmail.com wrote:
>
>
>
>
> Try, http://www.openwatcom.org Fortran compiler to do 1, 2 & 4.
> Either choose one of plotting packages (e.g. http://www.dislin.de) or
> buy a commercial graphics package (e.g. SigmaPlot) to take care of 3.
>

Although be advised that OpenWatcom is a Fortran 77 compiler, and
therefore does not support any of the features introduced in Fortran
90/95/2003. These features include the array arithmetic syntax, which --
with the OP being a Matlab user -- will be very familiar to him.

cheers,

Rich

Bart Vandewoestyne

2005-06-02, 8:58 pm

In article <1117724977.764944.196570@g43g2000cwa.googlegroups.com>, dave.harper@gmail.com wrote:
> I've been using Matlab for years, but would like to find an language
> that's a little faster (compilable and executable) and lower level
> (i.e. more freedom). I've considered Matlab's compiler, but would like
> to broaden my programming knowledge instead of buying a $500 patch
> (which might not work with the older version of Matlab I use, and might
> require $upgrading$ my Matlab). Ideally, I'd like a language that:

I've found the combination Fortran + gnuplot very satisfying for my
needs...

> 1. Has a good math foundation

Fortran is has bean a language for numerical analysts for years.

> 2. Can compile code to a relatively fast executable file(s)

A Fortran compiler does this for you.

> 3. Good graphing/plotting capabilities (graphics in general)

Fortran by itself has no real graphing/plotting capabilities unless you
decide to use external libraries. I don't know what kind of
graphing/plotting you want to do, but if it's not the GUI-stuff and only
plotting of data, you might want to use your Fortran program to output
data to files and then plot that data with gnuplot. I've been using
this combination for a while now, and i find it very satisfying for my
needs...

> 4. Relatively common, cheap, and not about die out

There are Open Source Fortran compilers out there:

http://www.openwatcom.org/
http://www.g95.org/
....

> After trying some C++ and dealing with the difficulties with graphics
> and math, I've come to the conclusion that C++ probably isn't the best
> language to accomplish what I'm looking for. Are there any other
> suggestions?

If number-crunching is what you want to do, and you don't need GUI-stuff
but only want to do some data-plotting, i'd definitely go for the
combination Fortran+gnuplot.

Regards,
Bart

--
"Share what you know. Learn what you don't."

Michael Prager

2005-06-02, 8:58 pm

dave.harper@gmail.com wrote:

> Ideally, I'd like a language that:
>
>1. Has a good math foundation
>2. Can compile code to a relatively fast executable file(s)
>3. Good graphing/plotting capabilities (graphics in general)
>4. Relatively common, cheap, and not about die out

It's probably impossible to get all of those in one language.
As others have noted, Fortran provides 1, 2, and 4 but not 3.
Fortran is persistent, and it has excellent portability.
Compiler prices range from free (g95) to thousands.

When using Fortran, graphics can be added with add-in libraries
or by using another language for the graphics. What's more
appropriate depends on your application.

We write files from Fortran that are read by R

http://www.r-project.org/

which is open source and offers excellent graphics for what we
do. I don't know if R graphics would meet your needs.

If you choose an add-in library, there are many, some of which
can be found with the search

fortran graphics

on Google. The commercial ones tend to be expensive, as the
Fortran marketplace is smaller than the C++ or Java marketplace.

You could also look at

http://www.dmoz.org/Computers/Progr.../Fortran/Tools/

Hope that helps.

--
Mike Prager, NOAA, Beaufort, NC
Address spam-trapped; remove color to reply.
* Opinions expressed are personal and not represented otherwise.
* Any use of tradenames does not constitute a NOAA endorsement.

2005-06-02, 8:58 pm

Rich Townsend wrote:
>
> kia wrote:
>
> Although be advised that OpenWatcom is a Fortran 77 compiler, and
> therefore does not support any of the features introduced in Fortran
> 90/95/2003. These features include the array arithmetic syntax, which --
> with the OP being a Matlab user -- will be very familiar to him.

This advisory is a patentable nonsense since Watcom compiler already
contains every major extension that matters. If OP wants array syntax
he can always spend a few bucks and purchase CVF compiler (now under HP
label).

http://h21007.www2.hp.com/dspp/tech...03,6235,00.html

Richard E Maine

2005-06-02, 8:58 pm

In article <429F8BAC.8F375427@Xsdynamix.com>, bv <bvoh@Xsdynamix.com>
wrote:

> Rich Townsend wrote:

>
> This advisory is a patentable nonsense

I knew that the patent office was giving out what I consider a pretty
ludicrous patents these days, but that's a new one to me. Whoever holds
the patent on nonsense must be pulling in a lot of money. :-)

(I think you mean patent instead of patentable.)

> since Watcom compiler already
> contains every major extension that matters.

I won't to try to debate with bv (having figured out that such debates
are pointless), but the OP might benefit from realizing that the
important part of bv's statement is the qualifier "that matters", which
I would elaborate as "that matters to bv." There are lots of features
that matter to other people but aren't in Watcom.

Not to say that Watcom isn't a fine compiler. But, as Rich Townsend
notes, it isn't an f90/f95/f2003 one and thus doesn't have a lot of
features that matter to many people.

> If OP wants array syntax
> he can always spend a few bucks and purchase CVF compiler (now under HP
> label).

Yes, or any other f90/f95 compiler. That's one fine choice.

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

Jeremy Watts

2005-06-03, 3:57 am

"Rich Townsend" <rhdt@barVOIDtol.udel.edu> wrote in message
news:d7na9t$40h$1@scrotar.nss.udel.edu...
> s8ngsu3@yahoo.com wrote:
>
> Yep, it has historically been a very slow language, although native Java
> compilers are beginning to match languages such as C and C++.

yes it is certainly slower than C++ but not dramatically so. I remember
seeing a 'computer language shootout' recently, where the performance of
different computer languages were compared. i think delphi came top in
terms of speed, C++ was up there near the top, java was certainly in the top
20%, other interpreted languages like PHP then were way down.

I think the multiplication of two 300 x 300 matrices was compared over about
20 different languages, amongst other things. delphi did it in
milliseconds, C++ took about a quarter of a second, java about 0.8secs, the
interpreted languages then were taking tens of seconds.

Remember java is a 'semi' compiled language so its not going to be that slow
at anything, although the amount of memory it uses is sometimes high. But
with regards to the OPs post, fortran is the way to go, but also investigate
delphi.
>
> But, in terms of already-existing software repositories such as Netlib,
> Java simply can't hold a candle to Fortran.
>
> On the flip side, of course, graphics in Java is pretty straightforward.
> The OP may want to consider having a two-language approach -- number
> crunching in Fortran, data presentation and analysis in Java. That's
> something I myself am exploring at the moment.
>
> cheers,
>
> Rich

Tom Micevski

2005-06-03, 3:57 am

Michael Prager wrote:
> We write files from Fortran that are read by R
>
> http://www.r-project.org/
>
> which is open source and offers excellent graphics for what we
> do. I don't know if R graphics would meet your needs.
>
i've been doing the same. note that you can also call fortran (or c?)
code from within R, so you can do the serious number crunching in
fortran and the graphics in R.

Rich Townsend

2005-06-03, 3:57 am

Rich Townsend

2005-06-03, 3:57 am

Tom Micevski wrote:
> Michael Prager wrote:
>
>
> i've been doing the same. note that you can also call fortran (or c?)
> code from within R, so you can do the serious number crunching in
> fortran and the graphics in R.

Thanks for the pointer -- I've just had a quick look, and it seems that
much of what I currently do in IDL (as a Fortran frontend) can be done
in R. This of course is great, since IDL is not open source, and
therefore is a sticking point in redistributing my modelling codes.

cheers,

Rich

Rich Townsend

2005-06-03, 3:57 am

bv wrote:
> Rich Townsend wrote:
>
>
>
> This advisory is a patentable nonsense since Watcom compiler already
> contains every major extension that matters. If OP wants array syntax
> he can always spend a few bucks and purchase CVF compiler (now under HP
> label).

Which platforms does Watcom support, beyond x86 with Windows or OS/2?
What is its support for dynamic array allocation? What is its support
for derived data types? What is its support for pointers? What is its
support for free source form? How does it achieve all of these
functionalities in a platform-neutral (ie, portable and standards
compliant) manner? Does it generate code for 64-bit x86 platforms, such
as AMD64 and Intel EMT? How is its support for SSE instructions? Does it
come with a vendor-tuned BLAS?

Just a few questions to get you started...

cheers,

Rich

Jan Vorbrüggen

2005-06-03, 9:07 am

> but also, and crucially for me, when analysing/plotting your data you
> have all Matlab's commands at your fingertips to *interactively*
> investigate it. E.g. There's no need to recompile and re-run a code
> just to plot the difference of two solutions, or to plot y(x)^2 when
> your code only gave you y(x), etc. Investigating numerical results is
> best done interactively and compiled languages don't make that easy on
> their own - so using Matlab fills the gap nicely.

Very much seconded...and do your prototyping in Matlab or IDL or somesuch
- for stuff you can express as array operations, they are fast enough for
that.

Jan

Abdul Qat

2005-06-03, 9:07 am

"Bart Vandewoestyne" <MyFirstName.MyLastName@telenet.be> wrote in message
news:1117747634.807849@seven.kulnet.kuleuven.ac.be...
>
>
> Fortran is has bean a language for numerical analysts for years.
>

Not since the King died, and I don't mean Elvis. Are you living?, never
mind.

--
You're Welcome,
Gerry T.
______
"Klinger, it's my considered opinion that no one is going to believe you
are pregnant." -- Col Henry Blake, the 4077th M*A*S*H

Simon Geard

2005-06-03, 9:07 am

Jeremy Watts wrote:
> "Rich Townsend" <rhdt@barVOIDtol.udel.edu> wrote in message
> news:d7na9t$40h$1@scrotar.nss.udel.edu...
>
>
>
> yes it is certainly slower than C++ but not dramatically so. I remember
> seeing a 'computer language shootout' recently, where the performance of
> different computer languages were compared. i think delphi came top in
> terms of speed, C++ was up there near the top, java was certainly in the top
> 20%, other interpreted languages like PHP then were way down.
>
> I think the multiplication of two 300 x 300 matrices was compared over about
> 20 different languages, amongst other things. delphi did it in
> milliseconds, C++ took about a quarter of a second, java about 0.8secs, the
> interpreted languages then were taking tens of seconds.
>
[snip]

In the shootout fortran90 (Intel) is the fastest for n-body,
spectral-norm, raytracer (an alpha test in the sandbox) and harmonic; it
was also the fastest for matrix multiplication but that test has now
been removed. The shootout uses both g95 and ifort and differing results
show that if performance is really critical then the compiler (and its
switches) can make a real difference.

I've just checked the shootout page http://shootout.alioth.debian.org
and can't find any reference to Delphi so I'm not sure where you got
that info from.

Simon

Han de Bruijn

2005-06-03, 9:07 am

s8ngsu3@yahoo.com wrote:

>
> Isn't Java too slow for number crunching?

Depends, but the general answer is: yes.

Han de Bruijn

Han de Bruijn

2005-06-03, 9:07 am

dave.harper@gmail.com wrote:

> [ ... ] Ideally, I'd like a language that:
>
> 1. Has a good math foundation
> 2. Can compile code to a relatively fast executable file(s)
> 3. Good graphing/plotting capabilities (graphics in general)
> 4. Relatively common, cheap, and not about die out

A good compromise between all of these requirements is Delphi (Pascal).
Take a look at:

http://www.borland.com/
http://community.borland.com/
http://www.borland.com/delphi/index.html

Quite like Fortran, Delphi (Pascal) performs reasonably fast on number
crunching. Unlike Fortran, Delphi has a decent GUI and graphics can be
easily implemented with your application. Delphi's compiler has been
derived from Turbo Pascal: it is fast as lightning. With proper licence
conditions, the product is very much affordable (: I have always worked
with a cheap University licence). Borland company is the vendor and you
should have no doubt that this company will survive another decennium.

Furthermore, the development of your application is much faster (RAD)
with Delphi than with Fortran. This is due to Delphi's drag-and-drop
interface, decent help and good documentation. Be prepared, however,
that Borland's main interest is in administrative i.e. non-technical,
non-scientific applications: databases / web based. I think because
the big money is there ...

Another drawback is that Delphi does NOT come with extensive numerical
libraries. For me, that's no problem, because I always make my own:

http://huizen.dto.tudelft.nl/deBrui...rams/delphi.htm

If you have Fortran sources at your disposal, then translation to Pascal
is a piece of cake, most of the time, especially with numerical stuff.

Hope this helped to make up your mind.

Han de Bruijn

Jeremy Watts

2005-06-03, 4:00 pm

"Simon Geard" <simon@quintic.co.uk> wrote in message
news:42a014e5$0$1711$ed2e19e4@ptn-nntp-reader04.plus.net...
> Jeremy Watts wrote:
> [snip]
>
> In the shootout fortran90 (Intel) is the fastest for n-body,
> spectral-norm, raytracer (an alpha test in the sandbox) and harmonic; it
> was also the fastest for matrix multiplication but that test has now been
> removed. The shootout uses both g95 and ifort and differing results show
> that if performance is really critical then the compiler (and its
> switches) can make a real difference.
>
> I've just checked the shootout page http://shootout.alioth.debian.org and
> can't find any reference to Delphi so I'm not sure where you got

it was 'doug bagleys computer shootout' - may not still be running i'm not
sure, but fortran and delphi were top 2, and i think in his tests delphi
came top

> that info from.
>
>
> Simon

Steve Lionel

2005-06-03, 4:00 pm

On 2 Jun 2005 08:09:37 -0700, dave.harper@gmail.com wrote:

>I've been using Matlab for years, but would like to find an language
>that's a little faster (compilable and executable) and lower level
>(i.e. more freedom). I've considered Matlab's compiler, but would like
>to broaden my programming knowledge instead of buying a $500 patch
>(which might not work with the older version of Matlab I use, and might
>require $upgrading$ my Matlab). Ideally, I'd like a language that:
>
>1. Has a good math foundation
>2. Can compile code to a relatively fast executable file(s)
>3. Good graphing/plotting capabilities (graphics in general)
>4. Relatively common, cheap, and not about die out

Lots of good advice in this thread. If you're looking at the Windows
platform, you may want to consider Intel Visual Fortran and its Intel Array
Visualizer feature. This is a 2-D and 3-D interactive data visualization
library and tool and is quite flexible. For more information, see
http://www.intel.com/software/products/compilers/fwin/ - and the link for
Intel Array Visualizer in the right column.

Steve Lionel
Software Products Division
Intel Corporation
Nashua, NH

User communities for Intel Software Development Products
http://softwareforums.intel.com/
Intel Fortran Support
http://developer.intel.com/software/products/support/

Michael Prager

2005-06-03, 4:00 pm

Rich Townsend <rhdt@barVOIDtol.udel.edu> wrote:

>Tom Micevski wrote:
>
>Thanks for the pointer -- I've just had a quick look, and it seems that
>much of what I currently do in IDL (as a Fortran frontend) can be done
>in R. This of course is great, since IDL is not open source, and
>therefore is a sticking point in redistributing my modelling codes.

I'll add that R is one of the best software distributions I've
used at any price -- and of course it is free. Quality is
excellent, and bugs are fixed promptly. The R core team is
exceptionally dedicated and talented among software developers.
The email help list provides prompt and thoughtful -- if
sometimes caustic -- responses. Being a matrix language, it can
even be used for small numerical programs (though it lacks many
of the error-checking features of Fortran and can be markedly
slower than compiled languages). Of course R is not perfect,
but it's impressed me mightily so far.

--
Mike Prager, NOAA, Beaufort, NC
Address spam-trapped; remove color to reply.
* Opinions expressed are personal and not represented otherwise.
* Any use of tradenames does not constitute a NOAA endorsement.

Calum Grant

2005-06-03, 8:57 pm

glen herrmannsfeldt wrote:
> s8ngsu3@yahoo.com wrote:

> For number crunching, try not to do object creation inside deeply
> (or even not so deeply) nested loops.

That's the advantage of hybrid languages like C++ - you can change
approach to suit your circumstances.

Calum

> -- glen
>

Andreas Koch

2005-06-03, 8:57 pm

(f'up set to comp.lang.misc - no need to discuss this on thousands
of groups!)

Han de Bruijn wrote:

>
> A good compromise between all of these requirements is Delphi (Pascal).

I love Delphi but i'm not sure if i would call it especially good
at maths. A few of the things i am missing :

-no user definable datatypes with infix operators
-no included formula interpreter
-no complex numbers
-no included support for matrix math (that i am aware of)

I think it's pretty decent for doing "normal" maths, e.g. applying
combinations of +,-,/,* to real numbers, or doing binary logic.

And of course its great when you want to build a nice GUI for
that app :-)

Jon Harrop

2005-06-03, 8:57 pm

dave.harper@gmail.com wrote:
> I've been using Matlab for years, but would like to find an language
> that's a little faster (compilable and executable) and lower level
> (i.e. more freedom). I've considered Matlab's compiler, but would like
> to broaden my programming knowledge instead of buying a $500 patch
> (which might not work with the older version of Matlab I use, and might
> require $upgrading$ my Matlab). Ideally, I'd like a language that:
>
> 1. Has a good math foundation
> 2. Can compile code to a relatively fast executable file(s)
> 3. Good graphing/plotting capabilities (graphics in general)
> 4. Relatively common, cheap, and not about die out
>
> After trying some C++ and dealing with the difficulties with graphics
> and math, I've come to the conclusion that C++ probably isn't the best
> language to accomplish what I'm looking for. Are there any other
> suggestions?

I ditched C++ in favor of a combination of Objective CAML (OCaml):

http://caml.inria.fr/

and Mathematica:

http://www.wolfram.com/

OCaml is a very succint compiled language with free, efficient,
cross-platform compilers and a very friendly userbase. The language itself
is simple and easy to learn whilst being vastly more succinct than many
alternatives (particularly Fortran) and more capable (e.g. a functional
language). Real-time 2D and 3D visualization is easy with OCaml and OpenGL:

http://www.ffconsultancy.com/produc.../visualisation/

If you want to do general math then data structures and algorithms are
extremely important. Non-trivial data structures are essentially
intractable in Fortran and are only easy to use in C++ if they happen to be
implemented in the STL. In contrast, sophisticated and highly efficient
data structures are often available (e.g. lists, arrays, maps, sets, hash
tables, queues, stacks) or easily implemented (e.g. tries, hash sets) in
OCaml.

Mathematica is a great companion because of its symbolic math and graphics
capabilities.

However, if by "math" you mean computing huge numbers of small,
machine-precision matrix-vector multiplications and nothing more, you won't
do much better than Fortran.

--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

Richard E Maine

2005-06-03, 8:57 pm

In article <42a0b33b$0$1734$ed2e19e4@ptn-nntp-reader04.plus.net>,
Jon Harrop <usenet@jdh30.plus.com> wrote:

> Non-trivial data structures are essentially
> intractable in Fortran.

That hasn't been so for the last decade and a half. This sounds like a
reference to Fortran 77. Data structures were one of the big
improvements in Fortran 90, but that was 15 years ago.

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

Jon Harrop

2005-06-04, 4:00 am

Richard E Maine wrote:
> In article <42a0b33b$0$1734$ed2e19e4@ptn-nntp-reader04.plus.net>,
> Jon Harrop <usenet@jdh30.plus.com> wrote:
>
> That hasn't been so for the last decade and a half. This sounds like a
> reference to Fortran 77. Data structures were one of the big
> improvements in Fortran 90, but that was 15 years ago.

No, that was a reference to Fortran 95. Fortran 2003 appears to bring the
capabilities of C++, but that is still significantly behind many other
languages (and there aren't any Fortran 2003 compilers yet, AFAIK).

As a trivial example, consider computing the intersection of two ordered
sets efficiently. That is one function call in either OCaml or C++ but will
require thousands of lines of Fortran 95 and, even then, it won't be
generic. And set intersection is hardly obscure.

In relation to data structures, ML has many advantages:

1. Garbage collection.
2. Pattern matching.
3. Static typing.
4. Functional (closures can be put into data structures).
5. Polymorphism.

--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

lavigne.eric@gmail.com

2005-06-04, 8:57 am

>> Non-trivial data structures are essentially
>
>That hasn't been so for the last decade and a half. This sounds like a
>reference to Fortran 77. Data structures were one of the big
>improvements in Fortran 90, but that was 15 years ago.

As examples of "non-trivial data structures," Jon mentioned lists,
arrays, maps, sets, hash
tables, queues, stacks. As far as I know, fortran 90 has only arrays
(and types, which were not mentioned). When I tried googling for
fortran hashtables, I got a bunch of hits regarding other languages
instead (java, lisp, ocaml, scheme...) with pages that only briefly
mentioned fortran.

I spend a lot of time with fortran 90 at work, so if it has these other
data structures (or if there are fortran 90 compatible libraries
implementing them) I would be very interested in hearing about it. I am
accustomed to using exclusively arrays in my fortran 90 code, even when
other data structures would be faster or more convenient.

Jon Harrop

2005-06-04, 8:57 am

lavigne.eric@gmail.com wrote:
> As examples of "non-trivial data structures," Jon mentioned lists,
> arrays, maps, sets, hash
> tables, queues, stacks. As far as I know, fortran 90 has only arrays
> (and types, which were not mentioned). When I tried googling for
> fortran hashtables, I got a bunch of hits regarding other languages
> instead (java, lisp, ocaml, scheme...) with pages that only briefly
> mentioned fortran.

Before studying the data structures and algorithms themselves it is vital to
understand the notion of asymptotic algorithmic complexity (as taught on
computer science courses). The objective selection of efficient data
structures and algorithms can then be based upon this notion of complexity.

All of the data structures I listed are considerably more efficient (orders
of magnitude faster) on a wide variety of important problems. This even
includes several pedagogical examples which used to be used to teach
Fortran using arrays, e.g. the travelling salesman problem.

For a more thorough introduction to the use of appropriate data structures
and algorithms in the context of OCaml, read my book "Objective CAML for
Scientists":

http://www.ffconsultancy.com/produc...for_scientists/

The first chapter and code from the chapters on visualisation and examples
from scientific computing are freely available.

> I spend a lot of time with fortran 90 at work, so if it has these other
> data structures (or if there are fortran 90 compatible libraries
> implementing them) I would be very interested in hearing about it.

Such data structures and algorithms can be implemented in Fortran, of
course, but this is so difficult, tedious, error-prone and not reusable
that people rarely do so.

> I am
> accustomed to using exclusively arrays in my fortran 90 code, even when
> other data structures would be faster or more convenient.

Yes, Fortran programmers typically use arrays for everything as a
consequence. The first step in optimising any such programs is to switch to
more appropriate data structures and algorithms.

--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

Rich Townsend

2005-06-04, 3:57 pm

lavigne.eric@gmail.com wrote:
>
>
> As examples of "non-trivial data structures," Jon mentioned lists,
> arrays, maps, sets, hash
> tables, queues, stacks. As far as I know, fortran 90 has only arrays
> (and types, which were not mentioned). When I tried googling for
> fortran hashtables, I got a bunch of hits regarding other languages
> instead (java, lisp, ocaml, scheme...) with pages that only briefly
> mentioned fortran.
>
> I spend a lot of time with fortran 90 at work, so if it has these other
> data structures (or if there are fortran 90 compatible libraries
> implementing them) I would be very interested in hearing about it. I am
> accustomed to using exclusively arrays in my fortran 90 code, even when
> other data structures would be faster or more convenient.
>

Well, I've implemented a module that does hashtables via a derived type.
The type maps character strings into integers, which can then be used as
indices into an array of any data type. I find this to be a pretty
useful technique.

I don't really think there is any structure that cannot be implemented
as a Fortran derived type. Linked lists are especially trivial -- in
fact, my hashtable implementation uses an internal linked list structure
to store the key/value pairs in each bucket.

cheers,

Rich

Bob Walton

2005-06-04, 3:57 pm

Jan Vorbrüggen wrote:

>
>
> Very much seconded...and do your prototyping in Matlab or IDL or somesuch
> - for stuff you can express as array operations, they are fast enough for
> that.
>
> Jan

And I'll third that. In addition, it is easy to use Matlab's
external program interface to make Fortran-coded Matlab "mex"
files ("dll" on Windoze) that take advantage of the speed of
Fortran and the ease of use of Matlab. Very nice. I do that all
the time, using Fortran to generate Matlab executables for a
simulation language similar to ACSL, but using Matlab for all the
plotting and analysis.

Also, frequently, it is possible to "vectorize" Matlab code to
eliminate for and while loops. Matlab's implementations of
internal matrix operations are definitely world class.

--
Bob Walton
Email: http://bwalton.com/cgi-bin/emailbob.pl

Richard E Maine

2005-06-04, 3:57 pm

In article <42a160ed$0$15022$ed2619ec@ptn-nntp-reader02.plus.net>,
Jon Harrop <usenet@jdh30.plus.com> wrote:

> Yes, Fortran programmers typically use arrays for everything as a
> consequence.

That's the kind of statement that made me think that F77 was being
referred to. This was certainly the case for F77 code, there being no
other alternative to speak of. It is also the case for some programmers
who use f90, but are themselves used to f77 styles.

In my observation, as also mentioned by some others, derived types and
pointers are much more typically the base of more complicated structures
in f90 code. That is certainly what I personally use when doing lists
(which I have quite a lot of), or some of the other-mentioned
structures; I was under the impression that it was also what most people
use. Arrays also sometimes get added into the mix of things used for the
implementation, but I certainly wouldn't say that they were "used for
everything".

If your experience shows that "Fortran programmers" use arrays for
almost everything, then I would say that you have been exposed to a
different set of Fortran programmers than I have. Perhaps "Fortran
programmers" is not then a complete description of the set in question;
there appears to be a non-random subset selection involved.

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

2005-06-04, 8:57 pm

Rich Townsend wrote:
>
> What is its support for dynamic array allocation? ...

Glad you asked - will the sun rise trw? is water wet? iirc Dr. GT has
advised you on more than one occasion not to engage in polemics where
your factual basis is an empty set. Insofar as your silly question is
concerned - well, Watcom had dynamic allocation when you were still
soiling your diapers. For the rest of your Qs, see

http://www.openwatcom.org

btw, Watcom came packaged with a *nine* volume document set. Surely, you
don't think they spent it explaining F77!?

Rich Townsend

2005-06-05, 8:57 pm

bv wrote:
> Rich Townsend wrote:
>
>
>
> Glad you asked - will the sun rise trw? is water wet? iirc Dr. GT has
> advised you on more than one occasion not to engage in polemics where
> your factual basis is an empty set.

But how does it support dynamic array allocation in a *standard,
portable* manner -- as specified in my original remarks, which you've so
kindly cut to remove any context. Since Watcom is an F77 compiler with
extensions, there can be *no* standard, portable manner in which it can
support dynamic array allocation, BY DEFINITION.

> btw, Watcom came packaged with a *nine* volume document set. Surely, you
> don't think they spent it explaining F77!?

No, I'm sure they spent it explaining a non-portable language that is of
no use whatsoever to those writing portable code. Myself, I prefer not
to devote all of my time fetishizing over certain vendors'
bastardizations. By avoiding writing non-standard code, I'm not affected
when a specific compiler is discontinued, and thus don't have to march
around c.l.f making a hullabaloo about it. But I'm sure you yourself are
far too clever to tie your whole codebase to a sinking ship. Aren't you?

cheers,

Rich

PS Posted to c.l.f alone; I'm sure all of the other groups don't need to
watch you hoist on your own petard.

Robert Dede

2005-06-05, 8:57 pm

Hello,

I saw this post within Labview's newsgroup, and surprised no one mentions
Lab Windows.

A combination of LabWindows and Gigasoft ProEssentials (charting) will
provide most your charting and speed needs. More info can be found at
www.gigasoft.com

Though, I'd recommend VB6 and ProEssentials for the easiest approach. Our
charting tool allows DLL interfacing with APIs to transfer blocks of data
very quickly. If you have some functions that are intensive, code them in C
or Fortran as an external function.

best regards,

Robert Dede
Gigasoft, Inc.

<dave.harper@gmail.com> wrote in message
news:1117724977.764944.196570@g43g2000cwa.googlegroups.com...
> I've been using Matlab for years, but would like to find an language
> that's a little faster (compilable and executable) and lower level
> (i.e. more freedom). I've considered Matlab's compiler, but would like
> to broaden my programming knowledge instead of buying a $500 patch
> (which might not work with the older version of Matlab I use, and might
> require $upgrading$ my Matlab). Ideally, I'd like a language that:
>
> 1. Has a good math foundation
> 2. Can compile code to a relatively fast executable file(s)
> 3. Good graphing/plotting capabilities (graphics in general)
> 4. Relatively common, cheap, and not about die out
>
> After trying some C++ and dealing with the difficulties with graphics
> and math, I've come to the conclusion that C++ probably isn't the best
> language to accomplish what I'm looking for. Are there any other
> suggestions?
>
> Thanks in advance!
> Dave
>

Ian Chivers

2005-06-05, 8:57 pm

<lavigne.eric@gmail.com> wrote in message
news:1117867554.801238.217510@o13g2000cwo.googlegroups.com...
>
> As examples of "non-trivial data structures," Jon mentioned lists,
> arrays, maps, sets, hash
> tables, queues, stacks. As far as I know, fortran 90 has only arrays
> (and types, which were not mentioned). When I tried googling for
> fortran hashtables, I got a bunch of hits regarding other languages
> instead (

java,
lisp,
ocaml,
scheme

....)

which of these languages are subject to international standardisation?
the first fortran standard was 1966.

with pages that only briefly
> mentioned fortran.
>
> I spend a lot of time with fortran 90 at work, so if it has these other
> data structures (or if there are fortran 90 compatible libraries
> implementing them) I would be very interested in hearing about it. I am
> accustomed to using exclusively arrays in my fortran 90 code, even when
> other data structures would be faster or more convenient.
>

meek@skyway.usask.ca

2005-06-06, 3:58 am

In a previous article, bv <bvoh@Xsdynamix.com> wrote:
>Rich Townsend wrote:
>
>Glad you asked - will the sun rise trw? is water wet? iirc Dr. GT has
>advised you on more than one occasion not to engage in polemics where
>your factual basis is an empty set. Insofar as your silly question is
>concerned - well, Watcom had dynamic allocation when you were still
>soiling your diapers. For the rest of your Qs, see
>
> http://www.openwatcom.org
>
>btw, Watcom came packaged with a *nine* volume document set. Surely, you
>don't think they spent it explaining F77!?
>
Nine ? I have eight (V10.9) ... was I gypped?
Fortran 77 Lang ref.
Fortran 77 user's guide
Fortran 77 programmer's guide
Fortran 77 Tools user's guide
Graphical tools user's guide
Debugger user's guide
Linker user's guide
Fortran 77 graphics library reference

Very good manuals - glad I bought them when they were
chance .. although the help files have all the same
information (AFAICT)
I do use dynamic allocation .. works fine.

Chris

Rune Allnor

2005-06-06, 8:57 am

dave.harper@gmail.com wrote:
> I've been using Matlab for years, but would like to find an language
> that's a little faster (compilable and executable) and lower level
> (i.e. more freedom). I've considered Matlab's compiler, but would like
> to broaden my programming knowledge instead of buying a $500 patch
> (which might not work with the older version of Matlab I use, and might
> require $upgrading$ my Matlab). Ideally, I'd like a language that:
>
> 1. Has a good math foundation
> 2. Can compile code to a relatively fast executable file(s)
> 3. Good graphing/plotting capabilities (graphics in general)
> 4. Relatively common, cheap, and not about die out
>
> After trying some C++ and dealing with the difficulties with graphics
> and math, I've come to the conclusion that C++ probably isn't the best
> language to accomplish what I'm looking for. Are there any other
> suggestions?

Well, I certainly sympathize with your concerns. I've tried to base
my work on C++ and use matlab for prototyping.

I don't like fortran since there are so many system dependent
(some times even compiler dependent) quirks and idiosyncracies.
While there are tons of fortran code avaiilable for the maths,
it seems to be little support for stuff like file handling,
GUIs and some of the other stuff one would like to do.

While C++ doesn't have the large function library that exists in
the fortran world, it is certainly moving in the right direction,
as support for complex numbers recently has been included in
standardized libraries. With a bit of luck, even LAPACK/BLAS type
routines might be included in the future (well, one can hope...).

Much of the graphics/GUI problems could be handled by the Qt
library (www.trolltech.com). Again, the basic framework is there,
but the details leave a bit to be desired. Another appealing feature
with Qt is that it is portable between platforms, so apparently
(I haven't tested this myself yet), the code you wrote on your PC
also compiles and runs on both linux and on the mac, without
modifications.

Rune

David N. Williams

2005-06-06, 3:58 pm

Rune Allnor wrote:
>
> [...]
>
> While C++ doesn't have the large function library that exists in
> the fortran world, it is certainly moving in the right direction,
> as support for complex numbers recently has been included in
> standardized libraries. With a bit of luck, even LAPACK/BLAS type
> routines might be included in the future (well, one can hope...).

Are the C interfaces to LAPACK/BLAS type things all that inferior?

-- David

Jon Harrop

2005-06-06, 8:57 pm

Rich Townsend wrote:
> Well, I've implemented a module that does hashtables via a derived type.
> The type maps character strings into integers, which can then be used as
> indices into an array of any data type. I find this to be a pretty
> useful technique.

Yes, that is a very good idea. This is developed in languages like OCaml
into a polymorphic hashing function which can act on any data structure and
a built-in hash table implementation.

For example, to create a hash table "h" mapping a single element, the
2-tuple of an integer and a 3-element float list (7, [2.; 3.; 4.]), onto
the string "Ono" in OCaml you just write:

let h = Hashtbl.create 1;;
Hashtbl.add h (7, [2.; 3.; 4.]) "Ono";;

Note that the hashing function is applied to a custom data structure without
even having to explicitly specify the type.

> I don't really think there is any structure that cannot be implemented
> as a Fortran derived type. Linked lists are especially trivial -- in
> fact, my hashtable implementation uses an internal linked list structure
> to store the key/value pairs in each bucket.

AFAIK, you cannot write [2.; 3.; 4.] in Fortran, so I would not call them
"especially trivial".

--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

Jon Harrop

2005-06-06, 8:57 pm

Richard E Maine wrote:
> If your experience shows that "Fortran programmers" use arrays for
> almost everything, then I would say that you have been exposed to a
> different set of Fortran programmers than I have. Perhaps "Fortran
> programmers" is not then a complete description of the set in question;
> there appears to be a non-random subset selection involved.

Yes, perhaps. How many Fortran programmers do you know who make use of
balanced binary trees?

--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

Richard E Maine

2005-06-06, 8:57 pm

In article <42a4c9d5$0$1695$ed2e19e4@ptn-nntp-reader04.plus.net>,
Jon Harrop <usenet@jdh30.plus.com> wrote:

> Yes, perhaps. How many Fortran programmers do you know who make use of
> balanced binary trees?

Not a large number, but some. It isn't the kind of thing I keep an
actual count of.

I suspect that the number is a little larger if you include Fortran
programmers that use a library for it, but haven't bothered to custom
program their own implementation.

As so happens, I have my own balanced binary tree in f90 that I use
myself in my current applications. Nothing fancy, but it works. It has
been stable for a long enough time that I had forgotten that I did
balancing in it, but checking the comments at the top, I see

!-- 19 Aug 92, Richard Maine: Version 1.1 added balancing.
....
!-- This version uses a balanced binary tree implementation internally.

Of course, it isn't generic. As you have commented, that's a pain in
f90/f95. In fact, also in my comments from the early 90's, I see.

!-- Specific to character string keys as needed by getData/fdas;
!-- generalization to arbitrary key structures would be tricky.

My experience in this kind of thing is part of what lead me to realize
that I could actually use some object-oriented concepts in my own
applications... at least after I listened to John Cuthbertson give an
explanation of object-oriented concepts that finally made sense to me as
a Fortran programmer. John's talk (early to mid 90's - I forget the
exact date) was what convinced me to support adding some object-oriented
concepts to f2003 because I then saw that it was actually useful to
Fortran folk such as myself.

When f2003 compilers actually get out, I look forward to reworking some
of my code to take advantage of it; my balanced binary tree module is a
prime candidate.

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

glen herrmannsfeldt

2005-06-07, 3:57 am

Jon Harrop wrote:

> Yes, perhaps. How many Fortran programmers do you know who make use of
> balanced binary trees?

The IBM Fortran H compiler does. It uses six, one for each identifier
length. In one manual they suggest that for faster compilation you
distribute your variable names equally between one and six letters long.

I don't believe most people select variable names to minimize
compilation time, though.

Oh, yes, it is mostly written in Fortran 66 with a few extra extensions.

-- glen

Rich Townsend

2005-06-07, 3:57 am

Jon Harrop wrote:
> Rich Townsend wrote:
>
>
>
> Yes, that is a very good idea. This is developed in languages like OCaml
> into a polymorphic hashing function which can act on any data structure and
> a built-in hash table implementation.
>
> For example, to create a hash table "h" mapping a single element, the
> 2-tuple of an integer and a 3-element float list (7, [2.; 3.; 4.]), onto
> the string "Ono" in OCaml you just write:
>
> let h = Hashtbl.create 1;;
> Hashtbl.add h (7, [2.; 3.; 4.]) "Ono";;
>
> Note that the hashing function is applied to a custom data structure without
> even having to explicitly specify the type.

That's pretty neat. I'm currently giving serious thought to having a
good look at OCaml, since I'm hearing very positive things about it.
>
>
>
>
> AFAIK, you cannot write [2.; 3.; 4.] in Fortran, so I would not call them
> "especially trivial".
>

Sure, you cannot write [2.; 3.; 4.;] to create a linked list literal in
Fortran; but you most certainly can write (/2.,3.,4./) to create an
array literal. You can then use a unary operator (e.g., .list.) to
convert the array literal into your linked list datatype.

cheers,

Rich

Rich Townsend

2005-06-07, 3:57 am

@skyway.usask.ca wrote:
>
> Nine ? I have eight (V10.9) ... was I gypped?

Probably not, you just didn't include "Getting Started". Actually, I
didn't mean to either until you enticed me into a recount.

NuclearWizard

2005-06-07, 3:57 am

Like what everybody else said, I think Fortran is the way to go EXCEPT
for graphics. For graphics in general, what about the openGL API for
Fortran, http://math.nist.gov/f90gl/. It includes all openGL commands,
the openGL utility library (openGLU) and the GLUT library, which is
nice for menus and mouse controls, etc. For plotting of functions,
f90gl is probably too primitive---you'll have to do a lot of
programming to get a decent x-y plot. So it depends on what is more
important---I am using f90gl to visualize unstructured meshes, for
which it is great.
-Will

Jon Harrop

2005-06-07, 8:59 am

Rich Townsend wrote:
>
> That's pretty neat. I'm currently giving serious thought to having a
> good look at OCaml, since I'm hearing very positive things about it.

Yes, OCaml is an excellent complement to Fortran.

If you want to use the built-in "set" (implemented as a balanced binary
tree) then you need to give an explicit type for your elements and a
comparison function (the default one in this case, which can be applied to
any data structure):

module Elt struct =
type t = int * float list
let compare = compare
end;;

To create a new type which implements a set of these:

module MySet = Set.Make(Elt);;

Then you can add an element to the empty set:

let s = MySet.add (7, [2.; 3.; 4.]) MySet.empty;;

This data structure is great for many different things. Firstly, adding new
elements and checking to see if elements have already been added takes
O(log n) time. Secondly, the "MySet.union", ".inter" and ".diff" functions
let you compute set union intersection and difference very efficiently.
These can run as fast as constant time.

>
> Sure, you cannot write [2.; 3.; 4.;] to create a linked list literal in
> Fortran; but you most certainly can write (/2.,3.,4./) to create an
> array literal. You can then use a unary operator (e.g., .list.) to
> convert the array literal into your linked list datatype.

Higher-order functions are another useful facility in OCaml. For example,
you can accumulate a set containing a list of values by folding the
"MySet.add" function over the list:

List.fold_right MySet.add [(7, [2.; 3.; 4.]); (6, [3.; 4.; 5.]);
(5, [4.; 5.; 6.])] MySet.empty;;

The built-in ones ("iter", "map", "fold" and so on) are very useful but you
can often define your own, which greatly reduces the amount of code
required to get a job done.

--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

Rune Allnor

2005-06-07, 8:59 am

David N. Williams wrote:
> Rune Allnor wrote:
>
> Are the C interfaces to LAPACK/BLAS type things all that inferior?

A C/C++ interface to a fortran BLAS/LAPACK library is an utter
nightmare to maintain. When generating linkable object code,
the compilers make entry points by using source code function
names and add underscores in front and after. In C, this is done
pretty consistently across platforms. In fortran, some compilers
add underscores only at the back while others add underscores
both at the front and at the back:

Source Code function name: MyFunc
C object code: MyFunc_
Fortran compiler A: _MyFunc_
Fortran Compiler B: MyFunc_

While you can handle this by adding an underscore to the
function call in the source code (call the function "_MyFunc"
from the C code), it is an utter nightmare when dealing with
source code that is intended to be portable.

As for canned C/C++ interfaces, I don't know the current state.
I haven't found a C/C++ BLAS/LAPCK package around for 10 years.
I did try to install something like that on a SUN around 1995,
without much success. The code compiled, but didn't run properly.
I wasn't very interested in spending days and w

s finding out
why, so that was one of the rasons why I started to use matlab.

I just found out that Intel sells a set of math kernels that
apparently includes BLAS/LAPACK. If I can find enough $$, I might
buy one of those lisences. The fact that a major player like
Intel have invested time and $$ in making such a library might
perhaps generate some pressure from others to include the thing
in the C++ STL.

Or am I too naive? Oh well.

Rune

Abdul Qat

2005-06-07, 8:59 am

<dave.harper@gmail.com> wrote in message
news:1117724977.764944.196570@g43g2000cwa.googlegroups.com...
> I've been using Matlab for years, but would like to find an language
> that's a little faster (compilable and executable) and lower level
> (i.e. more freedom). I've considered Matlab's compiler, but would like
> to broaden my programming knowledge instead of buying a $500 patch
> (which might not work with the older version of Matlab I use, and might
> require $upgrading$ my Matlab). Ideally, I'd like a language that:
>
> 1. Has a good math foundation
> 2. Can compile code to a relatively fast executable file(s)
> 3. Good graphing/plotting capabilities (graphics in general)
> 4. Relatively common, cheap, and not about die out
>
> After trying some C++ and dealing with the difficulties with graphics
> and math, I've come to the conclusion that C++ probably isn't the best
> language to accomplish what I'm looking for. Are there any other
> suggestions?

The Matlab compiler has everything you're looking for. So what are you
waiting for? Fortran, forget it. Do dodos still fly?

--
You're Welcome,
Gerry T.
______
"Today's C++ programs will be tomorrow's unmaintainable legacy code." --Ian
Joyner, in a Critique of C++, 3rd ed., 1996.

Greg Lindahl

2005-06-07, 8:58 pm

In article <1118132998.782131.224880@g14g2000cwa.googlegroups.com>,
Rune Allnor <allnor@tele.ntnu.no> wrote:

>A C/C++ interface to a fortran BLAS/LAPACK library is an utter
>nightmare to maintain. When generating linkable object code,
>the compilers make entry points by using source code function
>names and add underscores in front and after.

There are a small number of cases, and there is lots of portable code
which manages to get it right. It's amazing what some people think
constitutes a nightmare...

-- greg

David N. Williams

2005-06-08, 4:00 pm

Rune Allnor wrote:
>
> [...]

> As for canned C/C++ interfaces, I don't know the current state.
> I haven't found a C/C++ BLAS/LAPCK package around for 10 years.
> I did try to install something like that on a SUN around 1995,
> without much success. The code compiled, but didn't run properly.
> I wasn't very interested in spending days and w

s finding out
> why, so that was one of the rasons why I started to use matlab.

I've only looked into this a little bit. I found this interesting:

http://math-atlas.sourceforge.net/

And it did compile on my Mac OS X system.

> I just found out that Intel sells a set of math kernels that
> apparently includes BLAS/LAPACK. If I can find enough $$, I might
> buy one of those lisences. The fact that a major player like
> Intel have invested time and $$ in making such a library might
> perhaps generate some pressure from others to include the thing
> in the C++ STL.

It's too bad the academic community gets little reward for doing
this porting this kind of thing...

Greg Lindahl wrote:
> In article <1118132998.782131.224880@g14g2000cwa.googlegroups.com>,
> Rune Allnor <allnor@tele.ntnu.no> wrote:
>
>
>
>
> There are a small number of cases, and there is lots of portable code
> which manages to get it right. It's amazing what some people think
> constitutes a nightmare...

I wondered about that, too. It doesn't seem as complicated as
some of the portability problems that are routinely solved by
configure/make in open source projects.

On the other hand the CBLAS interface is not trivial, due to other
issues.

I was really wondering whether one has to give up speed. The
impression I get is that probably you don't.

-- David

Rune Allnor

2005-06-09, 8:57 am

Greg Lindahl wrote:
> In article <1118132998.782131.224880@g14g2000cwa.googlegroups.com>,
> Rune Allnor <allnor@tele.ntnu.no> wrote:
>
>
> There are a small number of cases,

What do you mean by "A small number of cases"? Either you get it
right or you get it wrong whenever you try to link C and fortran
code. The relative fraction of cases is 100%, and the relative
probability of faliure is 50%.

> and there is lots of portable code which manages to get it right.

Sorry, beg to differ. It's not "the code" that gets it right.
It's whoever wrote and set up the code to become portable.
Have you any idea how much detailed knowledge about compilers
and systems it takes to get such questions right? How many
pragmas and compiler directives must be distributed in the code?
Do you know how much time and contemplation it takes to work out
a system where such portability can be achieved at all, let alone
with an acceptable added workload on whoever writes the code?

> It's amazing what some people think
> constitutes a nightmare...

I could turn that around at state my amazement over what some
people accept to put up with. My point is merely that I have no
ambition (and no interest) of being a software and computer
specialist. I am an engineer who solve applied problems where
the computer and the numerical software are the means, not the
goals. And as such I would like to write efficient code that is
portable between systems, and spend as little coding overhead
as possible in doing so.

I abandoned the PC around 1990 because the OS's were limited
to 60kByte memory segments. At the time I had a PC with 2MB RAM
(which was more than enough for what I was doing) but I could
only work inside 64k segments, or spend three times as much
work on overcoming the ridiculous memory structure, first across
the 64k data segments in primary memory, then to access whatever
memory existed above 1MB due to the MSDOS adressing modes. UNIX
was a completely different world. I could issue a MALLOC call
asking for 1MByte or 1TByte of memory (not that I ever asked
for terabytes, but I could if I wanted to); it was up to the
operating system to get me what I asked for.

As far as I know, lots of software engineers at the time were
working to solve such issues. While I am sure the engineers in
question enjoyed the income generated from such tasks, I think
it was a completely waste of time, caused by an inferior system
design.

As for the fortran/C naming conventions, I wouldn't mind if
it was done consistently across platforms. The problem is that
it takes a lot of time and effort to dig up the system and
fortran documentation needed to sort out these questions, and
incorporating them into the code. Time that would be better
spent solving the actual engineering problems.

Rune

HomerCritic

2005-06-10, 4:00 am

> Isn't Java too slow for number crunching?

Actually, no. If you do the tests properly, you will find that Java
often runs faster than C. How? bytecode to machine language
translation, which happens invisibly behind the scenes.

The propblem is that websites like the famous language shootout one do
the Java tests incorrectly. There are at least 2 fundemental problems
with their Java tests that is leaving people all over the net thinking
that Java is much slower than it really is.

For number crunching, Java is a great choice, because the bytecode gets
compiled to machine language that matches the computer you're running
on closer. For C, code is generally compiled to straight 386, or 686.

Greg Lindahl

2005-06-10, 4:00 am

In article <1118360652.736655.62930@o13g2000cwo.googlegroups.com>,
HomerCritic <homercritic@yahoo.com> wrote:

>Actually, no. If you do the tests properly, you will find that Java
>often runs faster than C. How? bytecode to machine language
>translation, which happens invisibly behind the scenes.

I see. Very convincing. So why is it that Java flopped as a language
for number crunching? A conspiracy of dunces? Do tell.

-- g

J.V.Ashby

2005-06-10, 8:57 am

Greg Lindahl wrote:

> In article <1118360652.736655.62930@o13g2000cwo.googlegroups.com>,
> HomerCritic <homercritic@yahoo.com> wrote:
>
>
> I see. Very convincing. So why is it that Java flopped as a language
> for number crunching? A conspiracy of dunces? Do tell.

As one of the dunces who's done tests that suggest Java to be
significantly slower than C & Fortran for numerically intensive
computing, I too would be interested in what I did wrong in my tests.

john

Sponsored Links