I've recently had occasion to use 'MATLAB' (tm The Math Works, Inc.), which
is a little language that gives access to some linear algebra and other
numerical analysis routines. Apparently, it is used in undergraduate
university courses in linear algebra, numerical analysis, linear systems
theory and signal processing, and perhaps some statistical analysis courses.
Although the MATLAB language leaves a _lot_ to be desired in terms of its
elegance and clarity -- especially when compared with some of its
competitors -- e.g., APL -- it does have some interesting features which
make it easier to use.
(I haven't studied the MATLAB language thoroughly, nor do I know any of
the details of how it is implemented, so some of the items below are
educated guessing on my part.)
1. There seems to be a 1-1 relationship between functions and files. While
this leads to extremely small files, it also allows for the file system itself
to be part of the language 'name space'. Apparently, when MATLAB is started
up, it searches the appropriate directories and _automagically_ builds the
appropriate 'autoload' capabilities, so that when a function is referenced,
it knows where to find it.
For those who have had to keep 'autoload' properties in Lisp systems
consistent with the locations of files, this greatly reduces that work.
This function=file relationship gives MATLAB more of a feeling of a
Unix 'shell' language, because the programmer does not have to go to any
trouble keeping the file system and the internal name space consistent.
MATLAB itself seems to go to a lot of trouble to keep the file & the function
consistent. Although MATLAB provides its own function editor, one is
also allowed to use another editor -- e.g., Emacs -- and MATLAB apparently
notices when one of its files gets updated.
2. MATLAB provides a 'named' scheme for multiple returned values. If a
function produces multiple values -- e.g., the singular value decomposition
for matrices, which produces U, S, V, where U,V are unitary/orthogonal
matrices, and S is a diagonal matrix -- then one defines the function like so:
function [U,S,V] = svd(M)
and then references U,S,V by name within the function. This is almost
a return to the yesteryear of Fortran 1, where one assigned the function
name itself with a value to be returned.
Those in the prolog/logic community will find this old hat. Those from
the Pascal/Ada community will probably be confused, since it appears
that the returned values are all constructed within the function and
passed out; these apparently are _not_ 'var'/'inout' parameters.
I'm not sure how this is implemented in MATLAB. In particular, I'm not
completely sure what happens when a multi-valued function is used
'functionally' -- I think that perhaps only the first value is then used.
(This is one of the big problems with MATLAB -- the documentation is
woefully inadequate at explaining the intricacies of name binding,
semantics of parameter passing and value returning, etc. For a language
that is aimed somewhat at _mathematicians_, such ambiguities and sloppiness
are unforgiveable.)
3. MATLAB does go to substantial effort to try to get the 'right'
semantics for 'NaN's' ("Not-a-Numbers"). It may be the first language
since the Lisp Machines that really put in an effort to do this right.
4. MATLAB shows that if the underlying subroutines are high quality, people
will put up with a lot of inelegancies in the 'scripting' language. Some
would say that the graphing/plotting capabilities alone are worth the price of
admission.
-------
On the negative side, MATLAB's integration with the Maple symbolic
algebra package is a bad joke. Although the Maple system itself is actually
quite good, one would have a difficult time coming to that conclusion after
trying to use Maple within MATLAB. Apparently, the only communication
between MATLAB and Maple is in the form of character strings, so there's
a _lot_ of parsing and unparsing going on!
Also, Maple uses an entirely different set of names for operations than
does MATLAB -- e.g., MATLAB uses the single quote "'" for the transpose
(conjugated), while Maple uses the 'transpose()' function.
MATLAB understands complex numbers very well, but Maple (at least as
incorporated into MATLAB) doesn't seem to understand complex numbers
at all.
--------
In summary, MATLAB is a useful tool because of its high quality library of
built-in functions and graphing/plotting capabilities, and because it allows
a relatively simple programming model which hides many of the
problems of the internal v. file-system issues.
It is a shame, however, that 'scripting languages' like MATLAB didn't
learn a bit more from languages like APL in the areas of generalized
arrays and array-indexing, and from languages like Lisp/etc. in the
areas of data structures more sophisticated than arrays for symbolic
algebra.
I'm somewhat concerned that non-CS undergraduate students will come to
the conclusion that MATLAB is 'state of the art' in terms of computer
language design, and that misconception would be a real shame. Perhaps the
company could at least include a disclaimer regarding the MATLAB/Maple
interface, and tell the students that they realize that it is kludgey, and
that they will attempt to improve this in the future.
--
www/ftp directory:
ftp://ftp.netcom.com/pub/hb/hbaker/home.html
······@netcom.com (Henry Baker) wrote:
<an interesting review of MATLAB followed by this paragraph>
>I'm somewhat concerned that non-CS undergraduate students will come to
>the conclusion that MATLAB is 'state of the art' in terms of computer
>language design, and that misconception would be a real shame. Perhaps the
>company could at least include a disclaimer regarding the MATLAB/Maple
>interface, and tell the students that they realize that it is kludgey, and
>that they will attempt to improve this in the future.
>--
>www/ftp directory:
>ftp://ftp.netcom.com/pub/hb/hbaker/home.html
I'd be more concerned that CS-undergrads will create languages that
mimic this kind of kludgery and attempt to ``extend it with object-
oriented capabilites''
The latter statement should be taken as a challenge to any computer
company producing software that they *know* is a kludge. Has any
done this?
Janet Bell wrote:
>
> ······@netcom.com (Henry Baker) wrote:
>
> The latter statement should be taken as a challenge to any computer
> company producing software that they *know* is a kludge. Has any
> done this?
Microsoft: Windows 95
--
Todd Spindler Div. of Meteorology & Physical Oceanography
·········@rsmas.miami.edu Rosenstiel School of Marine & Atmos. Science
Eagles soar, but weasels never get sucked into jet engines. -Elf
In article <·······················@10.0.2.15> ······@netcom.com (Henry Baker) writes:
1. There seems to be a 1-1 relationship between functions and files. While
this leads to extremely small files, it also allows for the file
system itself to be part of the language 'name space'. Apparently,
when MATLAB is started up, it searches the appropriate directories
and _automagically_ builds the appropriate 'autoload' capabilities,
so that when a function is referenced, it knows where to find it.
For those who have had to keep 'autoload' properties in Lisp systems
consistent with the locations of files, this greatly reduces that work.
This function=file relationship gives MATLAB more of a feeling of a
Unix 'shell' language, because the programmer does not have to go to any
trouble keeping the file system and the internal name space consistent.
To me this is actually a painful feature of Matlab. In most serious
use of Matlab you would want to define many functions. But it simply
takes too much time to handle this hurd of functions, and you quickly
start using silly names in order to avoid name clashes.
I find myself writing scripts in situations where I would have divided
the problem into functions if I were using a real language, like
Scheme. I also miss Scheme's excellent support for higher order
functions. In Matlab you have to pass functions as function name
strings, and use a special syntax when you use them:
feval(fname, arg1, arg2 ... argN);
Also, it's silly not being able to define local functions. There is
virtually no support for mudularization of your problem in Matlab.
You want to be able to put several functions in one file, and being
able to have control over which are visible globally. Yesterday I
was talking to an experienced Matlab user (a professor of numerical
analysis) who solves the problem by putting several functions in one
file and uses an extra argument in the file-function to select the
subfunction actually evaluated... Of course this is ugly but, given
Matlab's limitations, I find it a smart hack around the problem.
/mdj
RE: Matlab "programming":
I had the unfortune to have to use Matlab in a linear algebra course.
Programming the darn thing was absolutely painful -- no local variables
no local functions, no case, no scooping, no nothing to make the language
even reminiscient of civilized languages.
Matlab has an im[pressive array of features, but fora CS-student with a t
least a little (10 years+) experience of "real" languages, Matlab just
is something I will try to avoid for the rest of my life.
Why can't more people use functional languages for maths? Much simpler to
implement and extend that hacked-togehter languages. Matlab STINKS of being
hacked and cobbled together, feature for feature without systematics.
/jakob
----------------------------------------------------------------------------
Jakob Engblom. Computer Science Student @ Uppsala University, Sweden
presently an ERASMUS exchange student in Stuttgart, Germany
email Uppsala: ·····@docs.uu.se
email Stuttgart: ········@tick.informatik.uni-stuttgart.de
homepage: http://www.csd.uu.se/~jakob
In article <············@tick.infomatik.uni-stuttgart.de>, Jakob Engblom
<········@tick.infomatik.uni-stuttgart.de> wrote:
RE: Matlab "programming":
I had the unfortune to have to use Matlab in a linear algebra course.
Programming the darn thing was absolutely painful -- no local variables
no local functions, no case, no scooping, no nothing to make the language
even reminiscient of civilized languages.
Matlab has an im[pressive array of features, but fora CS-student with a t
least a little (10 years+) experience of "real" languages, Matlab just
is something I will try to avoid for the rest of my life.
Why can't more people use functional languages for maths? Much simpler to
implement and extend that hacked-togehter languages. Matlab STINKS of being
hacked and cobbled together, feature for feature without systematics.
/jakob
----------------------------------------------------------------------------
Jakob Engblom. Computer Science Student @ Uppsala University, Sweden
presently an ERASMUS exchange student in Stuttgart, Germany
email Uppsala: ·····@docs.uu.se
email Stuttgart: ········@tick.informatik.uni-stuttgart.de
homepage: http://www.csd.uu.se/~jakob
This is the reason that I wish TMW would copy a few features from
"civilized scripting languages", e.g. Tcl. Acceptance by the CS bigots
would do a lot to move MATLAB into the software mainstream. As it is,
MATLAB is just about perfect for systems engineers. But the CS folks turn
up their noses because it shares more attributes with English than with
Latin. Of course, we all know what happened to Latin.
Surely, static local variables, for instance, can't be that hard.
Tom
In article <······················@pppsb37.itg.ti.com>,
Tom L. Davis <·····@adrs1.dseg.ti.com> wrote:
>In article <············@tick.infomatik.uni-stuttgart.de>, Jakob Engblom
><········@tick.infomatik.uni-stuttgart.de> wrote:
>
> RE: Matlab "programming":
>
> I had the unfortune to have to use Matlab in a linear algebra course.
> Programming the darn thing was absolutely painful -- no local variables
> no local functions, no case, no scooping, no nothing to make the language
> even reminiscient of civilized languages.
>
> Matlab has an im[pressive array of features, but fora CS-student with a t
> least a little (10 years+) experience of "real" languages, Matlab just
> is something I will try to avoid for the rest of my life.
>
> Why can't more people use functional languages for maths? Much simpler to
> implement and extend that hacked-togehter languages. Matlab STINKS of being
> hacked and cobbled together, feature for feature without systematics.
>
> /jakob
>
> ----------------------------------------------------------------------------
> Jakob Engblom. Computer Science Student @ Uppsala University, Sweden
> presently an ERASMUS exchange student in Stuttgart, Germany
> email Uppsala: ·····@docs.uu.se
> email Stuttgart: ········@tick.informatik.uni-stuttgart.de
> homepage: http://www.csd.uu.se/~jakob
>
>This is the reason that I wish TMW would copy a few features from
>"civilized scripting languages", e.g. Tcl. Acceptance by the CS bigots
>would do a lot to move MATLAB into the software mainstream. As it is,
>MATLAB is just about perfect for systems engineers. But the CS folks turn
>up their noses because it shares more attributes with English than with
>Latin. Of course, we all know what happened to Latin.
>
>Surely, static local variables, for instance, can't be that hard.
>
>Tom
--
············@cl.cam.ac.uk http://www.cl.cam.ac.uk/users/rwab1
In article <······················@pppsb37.itg.ti.com>,
Tom L. Davis <·····@adrs1.dseg.ti.com> wrote:
>In article <············@tick.infomatik.uni-stuttgart.de>, Jakob Engblom
><········@tick.infomatik.uni-stuttgart.de> wrote:
>>
>> RE: Matlab "programming":
>>
>> [paraphrasing, "Matlab employs an horrible scripting language"]
>>
>> /jakob
>>
>This is the reason that I wish TMW would copy a few features from
>"civilized scripting languages", e.g. Tcl. Acceptance by the CS bigots
>would do a lot to move MATLAB into the software mainstream. As it is,
>MATLAB is just about perfect for systems engineers. But the CS folks turn
>up their noses because it shares more attributes with English than with
>Latin. Of course, we all know what happened to Latin.
>
>Surely, static local variables, for instance, can't be that hard.
>
>Tom
No No No No No! I can't believe somebody said this. Time for a few
home truths:
1 . there is no such thing as the tooth fairy;
2 . for `CS bigots' read `those who value cleanliness, consistency and
simplicity without sacrificing efficiency';
3 . TCL is *not* a civilised scripting language (see 2) - nor is
Perl;
4 . there is no reason why a clean yet powerful language should be
hard to learn (try Python).
MATLAB's value is in the functionality it provides. Tcl/Tk's value
lies almost purely in the Tk functionality. If you are only going to
use these things for brief, one-off hacks, then they're fine (apart
from having to waste time getting your head round yet another heap of
semantic spaghetti). On the other hand, if you are going to develop
largish bodies of code which you would like to reuse, adapt and
maintain over long periods or which other people are going to have to
use at all, then one could really use some half-decent abstraction
mechanisms such as local variables & functions, modules (separate name
spaces), types and objects (amongst other things). None of these are
especially hard concepts to grasp or apply. Indeed, many more
civilised languages have acquired libraries providing sane interfaces
to tools such as Tk. Of course, the alternative is to assume that
everyone is a capable and disciplined programmer, but that would be to
assume that everyone is a `CS bigot'.
I appreciate that the `English' speaking hack-it-and-die fraternity
probably consider such `Latin'esque considerations as just so much
theoretical hand-waving, but God help you if you have to use/maintain
their code.
Ralph
--
············@cl.cam.ac.uk http://www.cl.cam.ac.uk/users/rwab1
In article <··········@lyra.csx.cam.ac.uk>, ·····@cl.cam.ac.uk (Ralph
Becket) wrote:
In article <······················@pppsb37.itg.ti.com>,
Tom L. Davis <·····@adrs1.dseg.ti.com> wrote:
>In article <············@tick.infomatik.uni-stuttgart.de>, Jakob Engblom
><········@tick.infomatik.uni-stuttgart.de> wrote:
>>
>> RE: Matlab "programming":
>>
>> [paraphrasing, "Matlab employs an horrible scripting language"]
>>
>> /jakob
>>
>This is the reason that I wish TMW would copy a few features from
>"civilized scripting languages", e.g. Tcl. Acceptance by the CS bigots
>would do a lot to move MATLAB into the software mainstream. As it is,
>MATLAB is just about perfect for systems engineers. But the CS folks turn
>up their noses because it shares more attributes with English than with
>Latin. Of course, we all know what happened to Latin.
>
>Surely, static local variables, for instance, can't be that hard.
>
>Tom
No No No No No! I can't believe somebody said this. Time for a few
home truths:
1 . there is no such thing as the tooth fairy;
2 . for `CS bigots' read `those who value cleanliness, consistency and
simplicity without sacrificing efficiency';
3 . TCL is *not* a civilised scripting language (see 2) - nor is
Perl;
4 . there is no reason why a clean yet powerful language should be
hard to learn (try Python).
MATLAB's value is in the functionality it provides. Tcl/Tk's value
lies almost purely in the Tk functionality. If you are only going to
use these things for brief, one-off hacks, then they're fine (apart
from having to waste time getting your head round yet another heap of
semantic spaghetti). On the other hand, if you are going to develop
largish bodies of code which you would like to reuse, adapt and
maintain over long periods or which other people are going to have to
use at all, then one could really use some half-decent abstraction
mechanisms such as local variables & functions, modules (separate name
spaces), types and objects (amongst other things). None of these are
especially hard concepts to grasp or apply. Indeed, many more
civilised languages have acquired libraries providing sane interfaces
to tools such as Tk. Of course, the alternative is to assume that
everyone is a capable and disciplined programmer, but that would be to
assume that everyone is a `CS bigot'.
I appreciate that the `English' speaking hack-it-and-die fraternity
probably consider such `Latin'esque considerations as just so much
theoretical hand-waving, but God help you if you have to use/maintain
their code.
Ralph
--
············@cl.cam.ac.uk http://www.cl.cam.ac.uk/users/rwab1
Sorry, I shouldn't have used the phrase 'CS bigot' but, as Apple might
say, we need a programming language for the rest of us.
If the CS community would just invent and promote a language that was
truely "clean, consistant and, most of all, simple" then I would have
kinder and gentler thoughts. As it is, we get C, Ada, Unix, Lisp, etc.
As to the relative merits of Tcl, Perl and Python, I would point out that
this is a much debated topic in the newsgroups. And again I must ask a
practical question, if Python is so much better, why isn't it more popular
than Tcl? My guess is that it is a more complex language than Tcl. It may
indeed be better for writing and maintaining programs that are more than
10K lines long. But is it a good choice for small hacks?
Somebody needs to invent a language that scales well. One that will appeal
to both the "hack-it-and-die fraternity" and the "CS bigots". Kinda like
"Huckleberry Finn" appeals to both kids and English professors.
Tom
Tom L. Davis wrote:
>
> If the CS community would just invent and promote a language that was
> truely "clean, consistant and, most of all, simple" then I would have
> kinder and gentler thoughts. As it is, we get C, Ada, Unix, Lisp, etc.
>
[...]
Ada is a pretty nice little language. LISP is a model of conceptual simplicity.
It's just that the concepts are not the one that you learn in high school...
>
> Somebody needs to invent a language that scales well. One that will appeal
> to both the "hack-it-and-die fraternity" and the "CS bigots". Kinda like
> "Huckleberry Finn" appeals to both kids and English professors.
>
In my humble experience, the BIG difference between languages like Ada, C,
ML etc... ("real" programming languages) and the lanugages used for scripting
Basic, Macrolanguaguages, MATLAB, Hypertalk, etc... is the power of the individual
commands. The macro languages are tailored to one or a few application domains,
usually involving processings strings of characters (or matrixes or functions
or whatever).
This tailoring means that macro langugages are emminently writable within their
domain. Usually not as readable. And definitely not infinitely extendable or
maintainable.
The only solution that I can find to this dichotomy is something like Common Lisp...
a good simple language at heart, with a HUGE set of good utilities thrown in.
Most macro langugages are just the utilities...
When I have to do a quick and dirty hack for something, Common Lisp ranks pretty
high, because it's simple to program and has this wonderful library of routines
available.
/jakob
> Tom
--
----------------------------------------------------------------------------
Jakob Engblom. Computer Science Student @ Uppsala University, Sweden
presently an ERASMUS exchange student in Stuttgart, Germany
email Uppsala: ·····@docs.uu.se
email Stuttgart: ········@tick.informatik.uni-stuttgart.de
homepage: http://www.csd.uu.se/~jakob
In article <·············@tick.infomatik.uni-stuttgart.de>,
Jakob Engblom <········@tick.infomatik.uni-stuttgart.de> wrote:
>Tom L. Davis wrote:
>> If the CS community would just invent and promote a language that was
>> truly "clean, consistant and, most of all, simple" then I would have
>> kinder and gentler thoughts. As it is, we get C, Ada, Unix, Lisp, etc.
Whilst I'm trying not to be an evangelist, I strongly suggest you
have a look at Python. If anything, it's even better than Tcl at
string handling (if that's what you want), you don't have to
call `expr' to evaluate expressions, and it isn't based on an inefficient
and confusing string-substitution model. Apart from being clean and
simple, it really is pretty similar to most other imperative
languages. Take a peek at http://www.cwi.nl/www.python.org/
Re: the prevalence of Tcl over Python, I strongly suspect that is due
to the ease with which Tcl/Tk lets one throw up GUIs (or at least, the
front ends of 'em) and this leads people to believe they should
develop the rest of the application in the same language. These days,
just about everything has a Tk interface, so there's really no excuse.
>In my humble experience, the BIG difference between languages like Ada, C,
>ML etc... ("real" programming languages) and the lanugages used for scripting
>Basic, Macrolanguaguages, MATLAB, Hypertalk, etc... is the power of the individual
>commands. The macro languages are tailored to one or a few application domains,
>usually involving processings strings of characters (or matrixes or functions
>or whatever).
>
>This tailoring means that macro langugages are emminently writable within their
>domain. Usually not as readable. And definitely not infinitely extendable or
>maintainable.
But this is what libraries are for.
>The only solution that I can find to this dichotomy is something like Common Lisp...
>a good simple language at heart, with a HUGE set of good utilities thrown in.
>Most macro langugages are just the utilities...
>
>When I have to do a quick and dirty hack for something, Common Lisp ranks pretty
>high, because it's simple to program and has this wonderful library of routines
>available.
I am being fractious today. Common Lisp falls down because it doesn't
put all this functionality in libaries where it belongs. Instead,
when you fire up the binary, you also get N MBytes of mostly useless
image. Tcl is bad in this respect too. It really doesn't cost much
to add a line saying something like `import strings, regsub, tk' to a
shell script.
'Nuff said by me.
Ralph
--
············@cl.cam.ac.uk http://www.cl.cam.ac.uk/users/rwab1
Tom L. Davis (·····@adrs1.dseg.ti.com) wrote:
: If the CS community would just invent and promote a language that was
: truely "clean, consistant and, most of all, simple" then I would have
: kinder and gentler thoughts. As it is, we get C, Ada, Unix, Lisp, etc.
None of those came from the "CS community", except possibly Lisp.
Scheme, a lisp variant, is "clean consistent and, most of all, simple."
: Somebody needs to invent a language that scales well. One that will appeal
: to both the "hack-it-and-die fraternity" and the "CS bigots". Kinda like
: "Huckleberry Finn" appeals to both kids and English professors.
: Tom
--
Matthew B. ··········@caffeine.engr.utk.edu/I do not speak for ORNL, DOE or UT
Oak Ridge National Laboratory/University of Tennessee, Knoxville, TN USA/
*NO MASS EMAIL SPAM* It's an abuse of Federal Government computer resources
and an affront to common civility. On account of egregiously vile spamation,
my software terminates all email from "interramp.com" and "cris.com" without
human intervention.
In article <············@tick.infomatik.uni-stuttgart.de> Jakob Engblom <········@tick.infomatik.uni-stuttgart.de> writes:
RE: Matlab "programming":
I had the unfortune to have to use Matlab in a linear algebra course.
Programming the darn thing was absolutely painful -- no local
variables
Sure there are!
no local functions, no case, no scooping, no nothing to make the language
even reminiscient of civilized languages.
Local functions are just really not all that useful for numerical
linear algebra. Not to say that they don't have their place, but...
All matlab really seems designed for is numerical analysis, in
particular numerical linear algebra. For this it works well. That's
all I use it for, so that's all it needs to do.
--Mike Gertz
Mike Gertz wrote:
>
>
> All matlab really seems designed for is numerical analysis, in
> particular numerical linear algebra. For this it works well. That's
> all I use it for, so that's all it needs to do.
>
> --Mike Gertz
I agreee. I guessx my problem is that I had to throw together an interactive
application in MATLAB, and being used to a reasonably structured style of
programming, using Matlab for that work turned out to be (almost) as primitive
as my old days of Z-80/BASIC hacks for the now extinct ZX Spectrum..
--
----------------------------------------------------------------------------
Jakob Engblom. Computer Science Student @ Uppsala University, Sweden
presently an ERASMUS exchange student in Stuttgart, Germany
email Uppsala: ·····@docs.uu.se
email Stuttgart: ········@tick.informatik.uni-stuttgart.de
homepage: http://www.csd.uu.se/~jakob
> Why can't more people use functional languages for maths? Much simpler to
> implement and extend that hacked-togehter languages. Matlab STINKS of being
> hacked and cobbled together, feature for feature without systematics.
1) As far as I know, nobody have yet hooked a set of really high
quality numerical subroutines to a functional language and
packaged it like a sellable product.
2) If you hold your nose it _is_ possible to do high quality _work_
in MATLAB, even if the _code_ you produce probably will not be
very pretty (at least according to CS-standards for such things ;-)
It would be nice if someone hooked a set of routines like Matlab's to
a really portable ML or Scheme implementation, but today the most
likely candidate for such a venture is probably Java.
--
(Rmz)
Bj\o rn Remseth !Institutt for Informatikk !Net: ···@ifi.uio.no
Phone:+47 22855802!Universitetet i Oslo, Norway !ICBM: N595625E104337
···@ifi.uio.no (Bj�rn Remseth) wrote:
> 1) As far as I know, nobody have yet hooked a set of really high
> quality numerical subroutines to a functional language and
> packaged it like a sellable product.
Of course one can do "functional-style" programming in Wolfram's
Mathematica--see Chpt. 6 of John W. Gray's "Mastering Mathematica:
Programming Methods and Applications"--though the Mathematica language is
fundamentally rule-based. It would probably not be very difficult to
implement a scheme interpreter in Mathematica either.
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
·····@mo�s_/mo�s chicken & ribs_/
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
(······@anet-chi.com)
In article <·······················@ppp45.anet-chi.com>,
······@anet-chi.com (Jason Voigt) wrote:
···@ifi.uio.no (Bj�rn Remseth) wrote:
> 1) As far as I know, nobody have yet hooked a set of really high
> quality numerical subroutines to a functional language and
> packaged it like a sellable product.
Of course one can do "functional-style" programming in Wolfram's
Mathematica--see Chpt. 6 of John W. Gray's "Mastering Mathematica:
Programming Methods and Applications"--though the Mathematica language is
fundamentally rule-based. It would probably not be very difficult to
implement a scheme interpreter in Mathematica either.
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
·····@mo�s_/mo�s chicken & ribs_/
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
(······@anet-chi.com)
For what it does best, MATLAB is probably unbeatable. In the numerical
analysis domain, I seriously doubt that any other existing language can
compete in ease of use, breadth of tools, accuracy, speed of execution or
speed of results.
For example, the Mathematica language, while elegant, is too hard to learn
and doesn't have as broad a selection of tools. Its syntax, while
consistent, is overly busy. Plus, its documentation and tutorial aren't as
well done as MATLAB's.
Tom
···@ifi.uio.no (Bj�rn Remseth) wrote:
> 1) As far as I know, nobody have yet hooked a set of really high
> quality numerical subroutines to a functional language and
> packaged it like a sellable product.
Jason Voigt wrote:
> Of course one can do "functional-style" programming in Wolfram's
> Mathematica--see Chpt. 6 of John W. Gray's "Mastering Mathematica:
> Programming Methods and Applications"--though the Mathematica
> language is fundamentally rule-based. It would probably not be very
> difficult to implement a scheme interpreter in Mathematica either.
Unfortunately in terms of performance (especially on parallel
computers) there is a yawning chasm between functional programming
and "function style" programming. People don't seem to realise
the strong ties that exist between semantics and oractical
considerations like performance. These ties make that yawning
chasm.
graham
--
we howled into Berlin
tore the smoking buildings down
raised the red flag high
burnt the Reichstag brown
In article <··············@solva.ifi.uio.no>,
Bj�rn Remseth <···@ifi.uio.no> wrote:
>
>> Why can't more people use functional languages for maths? Much simpler to
>> implement and extend that hacked-togehter languages. Matlab STINKS of being
>> hacked and cobbled together, feature for feature without systematics.
>
>1) As far as I know, nobody have yet hooked a set of really high
> quality numerical subroutines to a functional language and
> packaged it like a sellable product.
>
>2) If you hold your nose it _is_ possible to do high quality _work_
> in MATLAB, even if the _code_ you produce probably will not be
> very pretty (at least according to CS-standards for such things ;-)
>
>It would be nice if someone hooked a set of routines like Matlab's to
>a really portable ML or Scheme implementation, but today the most
>likely candidate for such a venture is probably Java.
>
What looks VERY promising is an OpenDoc environment where one can
have multiple windows with intercommunication between applications.
For example, MatLab (or its descendant) could have a window for input
data (vectors/matrices/etc) and the ability to list these in one window
and view them in another.
Then the nature of one window could change to present a list of operators.
Selecting an input data item and a "method" from the list of operators
would present the result (list/graphics/3-D) in another window. The entire
process could be recordable so that once the process is done, it could
be repeated. There could be optional spreadsheet style windows for input
and output, permitting cut & paste in & out.
Given the source codes available for various matrix method packages,
it should not be long before such an application is here --- I hope!
Cheers,
Rob Lake
Environmental Modeling Inc.
···@po.cwru.edu
>>>>> "Jakob" == Jakob Engblom <········@tick.infomatik.uni-stuttgart.de> writes:
> Why can't more people use functional languages for maths?
Because people who want to use things like matlab aren't generally
familiar with functional languages. What they want is an interactive
language similar to Fortran/BASIC/C with lots of well-tested routines
for doing mathematical things; they (we, even!) want something that
doesn't involve much learning. The last time I looked, pure
functional languages (and in general, languages without assignment)
had problems with arrays, and in any case often the goal of using
matlab is to develop an algorithm which then gets hacked in Fortran or
C.
> Much simpler to implement and extend that hacked-togehter languages.
You say that as if it's a bad thing to be hacked together! It would
be interesting to look at octave, designed to be a free alternative to
parts of matlab, so it's supposed to be more-or-less compatible, but
may well be cleaner in parts.
> Matlab STINKS of being hacked and cobbled together, feature for
> feature without systematics.
I think that's a bit unfair. Mostly it hangs together quite nicely.
I think there's a real chance for an alternative to succeed, however.
If Guile (the FSF's Scheme-like language) goes well, and gets lots of
matrix operations and nice interfaces to gnuplot thrown in, together
with a less Lispy optional syntax, then that might do well.
--
Bruce Stephens | email: ··········@math.ruu.nl
Utrecht University | telephone: +31 30 2534630
Department of Mathematics | telefax: +31 30 2518394
P.O. Box 80010, 3508 TA Utrecht |
The Netherlands |
In article <··············@solva.ifi.uio.no> ···@ifi.uio.no (Bj�rn Remseth) writes:
> Why can't more people use functional languages for maths? Much simpler to
> implement and extend that hacked-togehter languages. Matlab STINKS of being
> hacked and cobbled together, feature for feature without systematics.
1) As far as I know, nobody have yet hooked a set of really high
quality numerical subroutines to a functional language and
packaged it like a sellable product.
2) If you hold your nose it _is_ possible to do high quality _work_
in MATLAB, even if the _code_ you produce probably will not be
very pretty (at least according to CS-standards for such things ;-)
It would be nice if someone hooked a set of routines like Matlab's to
a really portable ML or Scheme implementation, but today the most
likely candidate for such a venture is probably Java.
--
(Rmz)
Bj\o rn Remseth !Institutt for Informatikk !Net: ···@ifi.uio.no
Phone:+47 22855802!Universitetet i Oslo, Norway !ICBM: N595625E104337
Check out
http://nis-www.lanl.gov/~rosalia/gnudl-doc/gnudl_toc.html
It an effort to implement some useful numerical routines in
Guile (dialect of Scheme). I personally think that Common Lisp
would be much nicer to use for this, especially because there
exists Maxima ported to GNU CL at ftp.ma.utexas.edu.
But Matlab has too many useful for numerical analysis features
--- it can easily save data in binary files, it has good
graphics, etc... In short, it is incredibly ugly but quite
useful. There are a lot of "MATLAB"-like languages around, my
favorite right now is Yorick. It has more data structures (even
lists and arbitrary structures), binary I/O is very good,
graphics is decent, it is very fast and free.
Numerical people tend to stay away from Lisp, ML, etc. because
they believe that these languages are very slow compared to
C/Fortran and very difficult to learn (both statements are wrong
for those who does not know, BTW), so there is not enough good
quality numerical algorithms for them.
If someone hacked together interface to NetCDF binary data
format library to LAPACK and to some decent graphical library
for GNU CL and began to shout about it very loudly at each
corner, situation could certainly change.
Followups are trimmed a bit.
In article <··············@spot.uchicago.edu>,
Alexey Goldin <······@oddjob.uchicago.edu> wrote:
>In article <··············@solva.ifi.uio.no> ···@ifi.uio.no (Bj�rn Remseth) writes:
>
>
> > Why can't more people use functional languages for maths? Much simpler to
> > implement and extend that hacked-togehter languages. Matlab STINKS of being
> > hacked and cobbled together, feature for feature without systematics.
It is possible to compile fortran code into lisp. Two packages (at
least) exist. Symbolics did one, but where it is now I don't know.
A simpler one, f2cl was done by Kevin Broughan at Univ. Waikato (New Zealand).
f2cl does not solve one problematical construction that is used rarely,
but when used it tends to be deep inside some fortran code
(e.g. in BLAS in LAPACK).
This is a construction which requires that one be able to pass a PIECE
of an array by reference into a routine. That is
CALL FOO(a(14)...)
SUBROUTINE FOO (b ...)
dimension b(100)
....
b(2)=0.0
C the line above changes a(15) to zero.
I believe Symbolics solves this problem abandoning all semblance of
functional programming, using a Fortran execution model, stacking
arguments itself, etc.
As for Matlab being ugly, this is a tough call. Ease of interaction
vs. declarative structure raises different esthetic questions.
In 1980 or so at Berkeley we loaded the original (fortran based)
Matlab into VAX Macsyma, and provided interface routines so you
could ship matrices back and forth (really, just the names were
needed .. VAX "franz lisp" had identical matrix and float types
to Fortran). You could also start/exit from the Matlab parser
at will. This was not picked up and used by anyone, so far as
I know. Now the VAX is dead, Common Lisp usually doesn't have the
same structures for matrices as fortran. Matlab has gone commercial
and is in the driver's seat more often than computer algebra systems.
Even so, in an attempt to gain the upper hand, Macsyma Inc now claims
that Macsyma supports Matlab syntax and much of its semantics,
extended to symbolic entries.
Macsyma's underlying implementation language is Lisp, and thus
there is some possible connection there to a functional language.
--
Richard J. Fateman
·······@cs.berkeley.edu http://http.cs.berkeley.edu/~fateman/
Richard J. Fateman wrote:
> As for Matlab being ugly, this is a tough call. Ease of interaction
> vs. declarative structure raises different esthetic questions.
Such as?
graham
--
we howled into Berlin
tore the smoking buildings down
raised the red flag high
burnt the Reichstag brown
······@spot.uchicago.edu (Alexey Goldin) writes:
>
> In article <··············@solva.ifi.uio.no> ···@ifi.uio.no (Bj=F8rn Rems=
eth) writes:
>
>
> Check out
>
> http://nis-www.lanl.gov/~rosalia/gnudl-doc/gnudl_toc.html
>
> It an effort to implement some useful numerical routines in
> Guile (dialect of Scheme). I personally think that Common Lisp
> would be much nicer to use for this, especially because there
> exists Maxima ported to GNU CL at ftp.ma.utexas.edu.
>
Along these same lines, I also prefer Common Lisp, because scheme is
too sparse: not enough data types and no standard object system.
Thus, I decided a short while ago to hook up LAPACK to CMU Lisp via
its foreign function (alien) interface. I've added hooks to some
parts of BLAS and a very few parts of LAPACK and combined them with a
simple matrix class via CLOS.
The results are encouraging. A 200x200 matrix multiply in Matlab
takes about 0.7 seconds on my machine. The equivalent CMU Lisp with
BLAS takes 0.63 seconds. This is rather surprising because my
implementation requires making 3 complete copies of the matrix. I
need to copy the two Lisp arrays into an alien object and then copy
the result back to a Lisp array. My only guess is that the matrix
multiply in LAPACK is far superior to Matlab, either because the
implementation is better or because my Fortran compiler is better.
Unfortunately, this advantage does not hold for smaller matrices. For
sufficiently small matrices, Matlab has at least a 2 to 1 advantage.
Curiously, a large matrix add runs faster in CMU Lisp than calling the
LAPACK equivalent. However, this is not so surprising because I have
to copy the Lisp vector into a alien object, operate on it, and then
copy it out.
Anyone know how to get CMU Lisp to operate on (simple-array
double-float (*)) without having to copy the whole object to an alien
array? That could really speed things up by not having to do the
copies.
Alternatively, how can I get the garbage collector to clean up an
alien array embedded in a CLOS object? Something like weak vectors or
finalization, I think. (I'm pretty much a Lisp novice).
I think a Lisp vender could clean up if they had something like this.
With a decent graphing package, I'd certainly consider it as an
alternative to Matlab. It would be far superior in all ways.
Ray
In article <··············@rtp.ericsson.se> Raymond Toy <···@rcur18.rtp.ericsson.se> writes:
Along these same lines, I also prefer Common Lisp, because scheme is
too sparse: not enough data types and no standard object system.
Thus, I decided a short while ago to hook up LAPACK to CMU Lisp via
its foreign function (alien) interface. I've added hooks to some
parts of BLAS and a very few parts of LAPACK and combined them with a
simple matrix class via CLOS.
Hmm, can I look at it? I am just learning Common Lisp and would
like to see example how could I use it for something real ;-)
In article <·············@maths.anu.edu.au> Graham Matthews
<···············@maths.anu.edu.au> writes:
>> It would be nice if someone hooked a set of routines like Matlab's
>> to a really portable ML or Scheme implementation, but today the
>> most likely candidate for such a venture is probably Java.
g> The one problem with this idea is Java's lack of performance and
g> parallelism.
"Java's lack of performance" is at least a little of a myth.
- JIT compilers currently give acceptable performance for many
application domains.
- With use of appropriate storage and garbage collection models, there
is no need to box primitive types.
- As far as parallelism is concerned, Java explicitly supports a
multithreaded programming model (although current implementations do
not yet map threads to OS-level LWPs).
- There is nothing to stop a smart compiler from performing the same
kind of automatic loop parallelisation as can be done for
carefully-written numerical C code.
In short, while a lot of work remains to be done to make use of Java
acceptable for efficient numeric crunching tasks, there is nothing
intrinsic to the language that makes it a worse candidate for such
tasks than are, say, C or C++ for such tasks. It would take some work
on the language definition in order to make the kinds of optimisations
that Fortran compilers can get away with safe in Java, though.
<b
--
Let us pray:
What a Great System. ···@eng.sun.com
Please Do Not Crash. ···@serpentine.com
·····@P6 http://www.serpentine.com/~bos
In article <······················@pppsb37.itg.ti.com>
·····@adrs1.dseg.ti.com (Tom L. Davis) writes:
t> This is the reason that I wish TMW would copy a few features from
t> "civilized scripting languages", e.g. Tcl. Acceptance by the CS
t> bigots would do a lot to move MATLAB into the software mainstream.
This is an interesting perspective on how to get acceptance. As a "CS
bigot", I would run even farther from a Matlab that incorporated
Tcl-esque features than I am likely to from its current incarnation.
t> But the CS folks turn up their noses because it shares more
t> attributes with English than with Latin. Of course, we all know
t> what happened to Latin.
Insults tend to be somewhat more effective when they don't display
quite such ignorance of their intended targets.
<b
--
Let us pray:
What a Great System. ···@eng.sun.com
Please Do Not Crash. ···@serpentine.com
·····@P6 http://www.serpentine.com/~bos
In article <····················@jade.cs.brandeis.edu> ·······@jade.cs.brandeis.edu (Jordan Pollack) writes:
Certainly matlab could be fixed, but not at the cost of backward
compatibility. But maybe there is a niche for a new programming
language? I'd be interested in any effort at defining and building a
public standard pedagogical language for computational
science/engineering which overcomes some of the ignorant elements of
matlab. Maybe one of the existing freeware kernels could be used as
Well, there's xlispstat. It is Xlisp with statistical extensions
including (from what I understand) faster matrix operations, various
built-in algorithms (from statistical to singular value
decomposition), and dynamic loading if desired. It can be found
somewhere on statlib. Hardcopy plotting is rather primitive, but
interactive is pretty good. A web pointer:
http://stat.umn.edu/~luke/xls/xlsinfo/xlsinfo.html
A similar language, which xlispstat seems partially based on, is
S. This is not freeware, though. It comes in source code from some
part of AT&T which has probably been spun off, and also some other
company, which calls it Splus. It uses a C-like syntax rather than a
Lisp-like one. It really is a language rather than a hacked-together
thing.
I've used both where other people use such things as Matlab.
--
Raj Manandhar (205) 544-3965 ···@msfc.nasa.gov
NASA/George C. Marshall Space Flight Center I'm not affiliated with
Code ES84 NASA.
Huntsville, AL 35812
My URL is http://xanth.msfc.nasa.gov/~raj/home.html
> A similar language, which xlispstat seems partially based on, is
> S. This is not freeware, though. It comes in source code from some
> part of AT&T which has probably been spun off, and also some other
> company, which calls it Splus. It uses a C-like syntax rather than a
> Lisp-like one. It really is a language rather than a hacked-together
> thing.
There is a freeware clone of S called R. I use it a lot. The language
is for me surprisingly easy to learn. I would not call it C-like (I use
C a lot). Much easier for me to learn than lisp, used in xlisp-stat.
Versions are available for Mac, Windows, unix.
ftp://stat.auckland.ac.nz/pub/R/
http://www.stat.auckland.ac.nz/rproj.html
Bill Simpson
>>>>> "JP" == Jordan Pollack <·······@jade.cs.brandeis.edu> writes:
In article <····················@jade.cs.brandeis.edu>
·······@jade.cs.brandeis.edu (Jordan Pollack) writes:
[snip]
JP> Also, the development environment works against larger scale
JP> applications by not supporting any kind of name space model
JP> beyond directories, or organized revision controls. A single
JP> programming language? I'd be interested in any effort at
JP> defining and building a public standard pedagogical language
JP> for computational science/engineering which overcomes some of
JP> the ignorant elements of matlab. Maybe one of the existing
JP> freeware kernels could be used as the basis for its libraries.
Have you seen the Numeric extension to Python? Nice stuff.
For up to date information, you can look at:
http://www.python.org/sigs/matrix-sig/
For a specific answer to the question "Yet Another Numeric Language?",
see the paper "Extending Python for Numerical Computation" by Jim
Hugunin <·······@mit.edu> at:
http://www.python.org/workshops/1995-12/papers/hugunin.html
-Perry
Bj�rn Remseth wrote:
Someone:
> Why can't more people use functional languages for maths? Much simpler to
> implement and extend that hacked-togehter languages. Matlab STINKS of being
> hacked and cobbled together, feature for feature without systematics.
Bj�rn Remseth wrote:
> 1) As far as I know, nobody have yet hooked a set of really high
> quality numerical subroutines to a functional language and
> packaged it like a sellable product.
How about Sisal. It would come pretty close to this description. When the
development environment is released (which is supposed to be soon) it will
come even closer ..
> It would be nice if someone hooked a set of routines like Matlab's to
> a really portable ML or Scheme implementation, but today the most
> likely candidate for such a venture is probably Java.
The one problem with this idea is Java's lack of performance and parallelism.
graham
--
we howled into Berlin
tore the smoking buildings down
raised the red flag high
burnt the Reichstag brown
Jakob Engblom <········@tick.infomatik.uni-stuttgart.de> writes:
> > Why can't more people use functional languages for maths?
Bruce Stephens wrote:
> Because people who want to use things like matlab aren't generally
> familiar with functional languages.
This is nonsense. People who use things like Matlab are generally
mathematicians or physicists. These sorts of people know what a
function is in mathematics, and hence they know what a function
is in a functional language. The familiarity with mathematical
functions translates directly into familiarity with functions in
a functional programming language.
Bruce Stephens wrote:
>What they want is an interactive
> language similar to Fortran/BASIC/C with lots of well-tested routines
> for doing mathematical things; they (we, even!) want something that
> doesn't involve much learning. The last time I looked, pure
> functional languages (and in general, languages without assignment)
> had problems with arrays,
Then I suggest you look again! Try the following http address,
http://www.llnl.gov/sisal/SisalHomePage.html
> and in any case often the goal of
> matlab is to develop an algorithm which then gets hacked in Fortran or
> C.
Isn't that somewhat wasteful of effort?
graham
--
we howled into Berlin
tore the smoking buildings down
raised the red flag high
burnt the Reichstag brown
Graham Matthews (···············@maths.anu.edu.au) wrote:
: Jakob Engblom <········@tick.infomatik.uni-stuttgart.de> writes:
: > > Why can't more people use functional languages for maths?
: Bruce Stephens wrote:
: > Because people who want to use things like matlab aren't generally
: > familiar with functional languages.
: This is nonsense. People who use things like Matlab are generally
: mathematicians or physicists. These sorts of people know what a
: function is in mathematics, and hence they know what a function
: is in a functional language. The familiarity with mathematical
: functions translates directly into familiarity with functions in
: a functional programming language.
Sure, but the experience of trying to create an efficient algorithm
without using any directly mutable state is going to feel a little weird.
In real live 'data analysis' of the sort practiced in Matlab there is
a whole bunch of massaging this and plotting that and extracting pieces
and loading and saving in various formats.
One very important ability is the net time from data file to graphical
plot on screen. I.e. start in Unix shell with foobar.dat. How long
does it take to get a decent plot out?
: Bruce Stephens wrote:
: >What they want is an interactive
: > language similar to Fortran/BASIC/C with lots of well-tested routines
: > for doing mathematical things; they (we, even!) want something that
: > doesn't involve much learning. The last time I looked, pure
: > functional languages (and in general, languages without assignment)
: > had problems with arrays,
: Then I suggest you look again! Try the following http address,
: http://www.llnl.gov/sisal/SisalHomePage.html
: > and in any case often the goal of
: > matlab is to develop an algorithm which then gets hacked in Fortran or
: > C.
: Isn't that somewhat wasteful of effort?
No, because in science you didn't even know what algorithm to use.
The purpose is not to write programs but to do science, and there
is often a large stage of prospective exploration first to find the
things that are worth doing.
And sometime the MATLAB version did exactly what you needed. Why
bother writing a Fortran program to massage 20 data sets? If you
have a capable and idiomatic interpreted language it is often more
productive to do it by hand, especially as you can easily stop in the
middle and plot what you have in the middle of the process.
MATLAB is for numerical data what perl is for strings combined with what
a debugger is for regular programs: graphical debugging means plotting graphs!
: graham
--
Matthew B. ··········@caffeine.engr.utk.edu/I do not speak for ORNL, DOE or UT
Oak Ridge National Laboratory/University of Tennessee, Knoxville, TN USA/
*NO MASS EMAIL SPAM* It's an abuse of Federal Government computer resources
and an affront to common civility. On account of egregiously vile spamation,
my software terminates all email from "interramp.com" and "cris.com" without
human intervention.
Jakob Engblom <········@tick.infomatik.uni-stuttgart.de> writes:
> : > > Why can't more people use functional languages for maths?
Bruce Stephens wrote:
> Because people who want to use things like matlab aren't generally
> familiar with functional languages.
Graham Matthews (···············@maths.anu.edu.au) wrote:
> : This is nonsense. People who use things like Matlab are generally
> : mathematicians or physicists. These sorts of people know what a
> : function is in mathematics, and hence they know what a function
> : is in a functional language. The familiarity with mathematical
> : functions translates directly into familiarity with functions in
> : a functional programming language.
Matt Kennel wrote:
> Sure, but the experience of trying to create an efficient algorithm
> without using any directly mutable state is going to feel a little > weird.
How do you figure this Matt? If you are suggesting that you have
to contort your functional code to get high performance, then you
are wrong (cf. Sisal). If not then I am not sure I understand
your point.
Matt Kennel wrote:
> In real live 'data analysis' of the sort practiced in Matlab there is
> a whole bunch of massaging this and plotting that and extracting pieces
> and loading and saving in various formats.
>
> One very important ability is the net time from data file to graphical
> plot on screen. I.e. start in Unix shell with foobar.dat. How long
> does it take to get a decent plot out?
Again you seem to be suggesting that its hard to do this kind of thing
in a functional language. I don't see why. The only conceptual change
is instead of mutating existing things you must create new things from
old things. But for a mathematician/physicist this is not an issue since
you never "mutate" things in either discipline. Its only for those already
using imperative languages like Matlab that this change may seem a little
wierd at first.
Bruce Stephens wrote:
> The last time I looked, pure
> functional languages (and in general, languages without assignment)
> had problems with arrays,
Graham Matthews (···············@maths.anu.edu.au) wrote:
> : Then I suggest you look again! Try the following http address,
>
> : http://www.llnl.gov/sisal/SisalHomePage.html
Bruce Stephens wrote:
> : > and in any case often the goal of
> : > matlab is to develop an algorithm which then gets hacked in Fortran or
> : > C.
>
> : Isn't that somewhat wasteful of effort?
Matt Kennel wrote:
> No, because in science you didn't even know what algorithm to use.
>
> The purpose is not to write programs but to do science, and there
> is often a large stage of prospective exploration first to find the
> things that are worth doing.
Agreed entirely, but thats not the issue here. The issue is why do that
exploring in Matlab. The reasons for not doing it in Matlab are that as
soon as you want to do some more serious exploring you are going to
need to change language. And that wastes some of your initial exploring.
Matt Kennel wrote:
> And sometime the MATLAB version did exactly what you needed. Why
> bother writing a Fortran program to massage 20 data sets? If you
> have a capable and idiomatic interpreted language it is often more
> productive to do it by hand, especially as you can easily stop in the
> middle and plot what you have in the middle of the process.
This is not an argument for Matlab. Its simply an argument for any
well implemented language with graphics.
graham
--
well alas we've seen it all before
knights in armour, days of yore
the same old fears and the same old crimes
we haven't changed since ancient times
Matt Kennel wrote:
>
> Graham Matthews (···············@maths.anu.edu.au) wrote:
> : Jakob Engblom <········@tick.infomatik.uni-stuttgart.de> writes:
> : > > Why can't more people use functional languages for maths?
>
> : Bruce Stephens wrote:
> : >What they want is an interactive
> : > language similar to Fortran/BASIC/C with lots of well-tested routines
> : > for doing mathematical things; they (we, even!) want something that
> : > doesn't involve much learning. The last time I looked, pure
> : > functional languages (and in general, languages without assignment)
> : > had problems with arrays,
>
> And sometime the MATLAB version did exactly what you needed. Why
> bother writing a Fortran program to massage 20 data sets? If you
> have a capable and idiomatic interpreted language it is often more
> productive to do it by hand, especially as you can easily stop in the
> middle and plot what you have in the middle of the process.
>
I quite agree. For trying out formulas and only (interactively) using the built-in
functions, MATLAB is super! The problem comes when you have to write programs using
the so-called language...
My ideal would be a package with the power of something like MATLAB, but where, when
you have to write programs, you could do so in a fashion at least a littel resembling
real programming. A structured language in the Algol-family would do nicely (perhaps
a pure Algol-68, with its extreme orthogonality would fit right in), or a modern functional
dynamic language (like an ML-clone or (requiring a gigabyte or so of memory) Common Lisp).
And do I have to remind everybudy that the first interactive environment was LISP...?
--
----------------------------------------------------------------------------
Jakob Engblom. Computer Science Student @ Uppsala University, Sweden
presently an ERASMUS exchange student in Stuttgart, Germany
email Uppsala: ·····@docs.uu.se
email Stuttgart: ········@tick.informatik.uni-stuttgart.de
homepage: http://www.csd.uu.se/~jakob
Jakob Engblom <········@tick.infomatik.uni-stuttgart.de> writes:
>And do I have to remind everybudy that the first interactive environment was LISP...?
I'm a little surprised that no-one has mentioned IDL.
IDL stood for "Interactive Data-analysis Language".
It was a statistics library written in Interlisp.
Combine that with a Dandetiger, and good stuff happened.
These days, I have both MATLAB and Xlisp-Stat. Since my MATLAB
copy cost real money and runs only on mac (yes, that isn't a restriction
of MATLAB, it's a restriction of my copy; I would have to pay _more_
money to lift it) while Xlisp-Stat runs on Wintels, UNIX, _and_ Macs,
all for the price of an FTP and recompile, guess what I use?
--
Fifty years of programming language research, and we end up with C++ ???
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.
In article <·············@maths.anu.edu.au>, Graham Matthews
<···············@maths.anu.edu.au> wrote:
> [...] The familiarity with mathematical
> functions translates directly into familiarity with functions in
> a functional programming language. [...]
You're assuming they haven't already been forced to learn Fortran.
For me, it would have been much easier to learn Scheme had I not
already known C.
-thant
······@spot.uchicago.edu (Alexey Goldin) writes:
> I believe there is an effort underway to add MATLAB-like functionality
> to Python; take a look at the projects on http://www.python.org/
>
> (Python is a little less powerful than Scheme--no call/cc, some
> limitations on closures--but it has dynamic typing, a highly dynamic
> object system, exceptions, threads, lots of OS integration, a good
> FFI, and it's embeddable.)
And its slow! No disrespect meant to Python -- I use it all the
time, just not for numerical analysis! :-)
graham
--
we howled into Berlin
tore the smoking buildings down
raised the red flag high
burnt the Reichstag brown
>>>>> "Graham" == Graham Matthews <···············@maths.anu.edu.au> writes:
> Bruce Stephens wrote:
>> Because people who want to use things like matlab aren't generally
>> familiar with functional languages.
> This is nonsense. People who use things like Matlab are generally
> mathematicians or physicists. These sorts of people know what a
> function is in mathematics, and hence they know what a function is
> in a functional language. The familiarity with mathematical
> functions translates directly into familiarity with functions in a
> functional programming language.
I'm not entirely convinced of this, but perhaps my objection is only
because of the way that mathematicians and physicists are taught about
programming, which tends to be using a traditional imperative
programming language (because such languages are what are used in the
real world, and because such languages tend to have better support for
arrays and complex numbers).
> Bruce Stephens wrote:
>> What they want is an interactive language similar to
>> Fortran/BASIC/C with lots of well-tested routines for doing
>> mathematical things; they (we, even!) want something that doesn't
>> involve much learning. The last time I looked, pure functional
>> languages (and in general, languages without assignment) had
>> problems with arrays,
> Then I suggest you look again! Try the following http address,
> http://www.llnl.gov/sisal/SisalHomePage.html
That's interesting. My comment is a general one: when you allow
arrays, you either allow updates to the array (so I can say
a[1,1]:=a[1,1]+1) which is unclean, or you require me to construct a
new array (Sisal seems to have the syntax a[1,1] := old a[1,1]+1).
You can amortize that by giving me good features for constructing new
arrays from old ones (as Sisal does), and of course the compiler
should be able to recognise when copies don't need to be made, most of
the time, but how can I be convinced the system is always going to be
sufficiently efficient?
>> and in any case often the goal of matlab is to develop an algorithm
>> which then gets hacked in Fortran or C.
> Isn't that somewhat wasteful of effort?
Of course. The hope is that developing the algorithm in matlab will
save effort in developing it in whatever follows (which may well be
run on a parallel system). Some people develop only in matlab, which
makes excellent sense when it's possible, but for the work I've been
involved in for the last 5 or 6 years, that's not possible: the
problems must be run on parallel machines (both because of size and
computational cost), and matlab doesn't.
--
Bruce Stephens | email: ··········@math.ruu.nl
Utrecht University | telephone: +31 30 2534630
Department of Mathematics | telefax: +31 30 2518394
P.O. Box 80010, 3508 TA Utrecht |
The Netherlands |
In article <···············@bommel.math.ruu.nl>, ········@math.ruu.nl
(Bruce Stephens) wrote:
> That's interesting. My comment is a general one: when you allow
> arrays, you either allow updates to the array (so I can say
> a[1,1]:=a[1,1]+1) which is unclean, or you require me to construct a
> new array (Sisal seems to have the syntax a[1,1] := old a[1,1]+1).
>
> You can amortize that by giving me good features for constructing new
> arrays from old ones (as Sisal does), and of course the compiler
> should be able to recognise when copies don't need to be made, most of
> the time, but how can I be convinced the system is always going to be
> sufficiently efficient?
There are 'functional' languages -- e.g., 'Clean' -- in which certain
objects are typed as 'unique' (reference count = 1), and this property
is preserved by the primitives of the language. Therefore, there is no
uncertainty in either the programmer's mind or the compiler's mind about
when it is legal/possible to 'update in place'.
This idea has been used by programming system _implementors_ since the
dawn of computers, but for some reason, it has only recently made it into
the quiver of the computer language designer. (Probably because there is
now an official semantics for it -- 'linear logic'.)
Instead of making a language more complicated, it actually makes it simpler,
since you can have your 'update in place' semantics and your 'functional'
semantics at the same time!
--
www/ftp directory:
ftp://ftp.netcom.com/pub/hb/hbaker/home.html
In article <···············@bommel.math.ruu.nl>, ········@math.ruu.nl
(Bruce Stephens) wrote:
[snip]
Of course. The hope is that developing the algorithm in matlab will
save effort in developing it in whatever follows (which may well be
run on a parallel system). Some people develop only in matlab, which
makes excellent sense when it's possible, but for the work I've been
involved in for the last 5 or 6 years, that's not possible: the
problems must be run on parallel machines (both because of size and
computational cost), and matlab doesn't.
--
Bruce Stephens | email: ··········@math.ruu.nl
Utrecht University | telephone: +31 30 2534630
Department of Mathematics | telefax: +31 30 2518394
P.O. Box 80010, 3508 TA Utrecht |
The Netherlands |
Maybe you would be interested in the Falcon project:
http://www.csrd.uiuc.edu/falcon/falcon.html
Tom
In article <··············@spot.uchicago.edu> ······@spot.uchicago.edu (Alexey Goldin) writes:
From: ······@spot.uchicago.edu (Alexey Goldin)
Newsgroups: comp.lang.scheme,comp.lang.lisp,comp.soft-sys.matlab
Date: Mon, 1 Jul 1996 17:00:16 GMT
Organization: University of Chicago
Reply-To: ······@oddjob.uchicago.edu
X-Nntp-Posting-Host: spot.uchicago.edu
Lines: 13
Sender: ····@midway.uchicago.edu (News Administrator)
X-Newsreader: Gnus v5.1
References: <·······················@10.0.2.15>
<···············@sans06.nada.kth.se>
<············@tick.infomatik.uni-stuttgart.de>
<··············@solva.ifi.uio.no> <··············@spot.uchicago.edu>
<··············@rtp.ericsson.se>
Xref: agate comp.lang.scheme:16157 comp.lang.lisp:21971 comp.soft-sys.matlab:23051
In article <··············@rtp.ericsson.se> Raymond Toy <···@rcur18.rtp.ericsson.se> writes:
Along these same lines, I also prefer Common Lisp, because scheme is
too sparse: not enough data types and no standard object system.
Thus, I decided a short while ago to hook up LAPACK to CMU Lisp via
its foreign function (alien) interface. I've added hooks to some
parts of BLAS and a very few parts of LAPACK and combined them with a
simple matrix class via CLOS.
Hmm, can I look at it? I am just learning Common Lisp and would
like to see example how could I use it for something real ;-)
Yes. It would be a good thing to see how you do these things. Of
course if you can show us.
Cheers
--
Marco Antoniotti - Resistente Umano
===============================================================================
International Computer Science Institute | ·······@icsi.berkeley.edu
1947 Center STR, Suite 600 | tel. +1 (510) 643 9153
Berkeley, CA, 94704-1198, USA | +1 (510) 642 4274 x149
===============================================================================
...it is simplicity that is difficult to make.
...e` la semplicita` che e` difficile a farsi.
Bertholdt Brecht
Matlab is not used anywhere as far as I can tell for intro computer
science instruction, but in science and engineering courses which
don't have to pass through cs curriculum committees arguing between
the value of pascal, C++, and Ada versus scheme.
I agree with most of your commentary, but you missed several other
kluges in matlab:
funargs as strings
global/local name space conflicts
64 bit storage for strings and "fl-ints"
Binary types used only for movies
Also, the development environment works against larger scale applications by
not supporting any kind of name space model beyond directories, or
organized revision controls. A single matlab directory starts to get
clogged up with competing names very quickly.
However, because of its c-like appearance, high-efficiency numerics,
and modern universal windows interface, matlab far surpassed APL in
customer acceptance. the company has no interest in being considered
as a programming language by the computer science field, merely the
best engineering computing tool. Because of its interpretive
environment and rapid user feedback and rapid prototyping speed, it
does have a pedagogical role NOT filled by computer science proramming
languages - teaching science/engineering students how to hack up
computational models for their own immediate purposes, a growing
constituency.
Certainly matlab could be fixed, but not at the cost of backward
compatibility. But maybe there is a niche for a new programming
language? I'd be interested in any effort at defining and building a
public standard pedagogical language for computational
science/engineering which overcomes some of the ignorant elements of
matlab. Maybe one of the existing freeware kernels could be used as
the basis for its libraries. After all, APL was first built by
interfacing Iverson's language concept to the existing fortran
libraries, and Matlab was first built as an interface to a Linear
algebra library...
--
Professor Jordan B. Pollack DEMO Laboratory, Volen Center for Complex Systems
Computer Science Department Phone (617) 736-2713/Lab x3366/Fax x2741
Brandeis University website: http://www.demo.cs.brandeis.edu
Waltham, MA 02254 email: ·······@cs.brandeis.edu
······@spot.uchicago.edu (Alexey Goldin) writes:
> > I believe there is an effort underway to add MATLAB-like functionality
> > to Python; take a look at the projects on http://www.python.org/
<···············@maths.anu.edu.au> writes:
> And its slow! No disrespect meant to Python -- I use it all the
> time, just not for numerical analysis! :-)
Thomas<···@best.com> replied:
> Well, sure, it doesn't run as fast as natively compiled code, but for
> gluing together a bunch of highly optimized native code routines, as
> in MATLAB, it's perfectly good.
Thomas
I am not sure I agree with this statement. The implication you are making
here is that even if a language L is slow if all you use it for is to tie
together a collection of optimised (and therefore fast) routines, then
the code written in L will be fast. My experience with such languages
suggests that this implication is wrong. How many interpreters have I
used which espoused this philosophy and yet ran terribly slow.
graham
--
well alas we've seen it all before
knights in armour, days of yore
the same old fears and the same old crimes
we haven't changed since ancient times
In article <··········@news.ox.ac.uk> ·····@maths.ox.ac.uk (James Lawry) writes:
From: ·····@maths.ox.ac.uk (James Lawry)
Date: 3 Jul 1996 20:27:44 GMT
Organization: Oxford Centre for Industrial & Applied Mathematics
Lines: 26
X-No-Archive: Yes
Carlos A. Felippa <······@mars.Colorado.EDU> wrote:
>········@math.ruu.nl (Bruce Stephens) writes:
>>true of Mathematica. Anyway, I refuse to use a system that requires
>>me to say "Sin[x]" or whatever its syntax is rather than "sin(x)".
>>(I'll put up with "(sin x)" for the sake of using Lisp, though.)
>
...
[example snipped]
But the reason that [...] had to be used for functions was so that *
could be omitted in multiplication of symbols (so what should
a(b+c)
be interpreted as?). What you gain on the roundabouts you lose on the
swings.
Apart from the Mathematica bashing I would like to reiterate that a
very good package for Infix Notation for math in Common Lisp is
available.
You can write (eg. to the lisp listener)
* (defvar x 4.0)
X
* (defvar y 3.66)
Y
* #I ( sin(x * pi) / cos(y) )
5.639574442249689d-16
Cheers
--
Marco Antoniotti - Resistente Umano
===============================================================================
International Computer Science Institute | ·······@icsi.berkeley.edu
1947 Center STR, Suite 600 | tel. +1 (510) 643 9153
Berkeley, CA, 94704-1198, USA | +1 (510) 642 4274 x149
===============================================================================
...it is simplicity that is difficult to make.
...e` la semplicita` che e` difficile a farsi.
Bertholdt Brecht
>>>>> "Graham" == Graham Matthews <···············@maths.anu.edu.au> writes:
> I am not sure I agree with this statement. The implication you are
> making here is that even if a language L is slow if all you use it
> for is to tie together a collection of optimised (and therefore
> fast) routines, then the code written in L will be fast. My
> experience with such languages suggests that this implication is
> wrong. How many interpreters have I used which espoused this
> philosophy and yet ran terribly slow.
Depends on exactly what you're doing, of course. Assuming all the
performance-critical bits of your Matlab task are built-in (which is
often true), then Matlab is quite fast enough. If you need to write
lots of nested loops and things in Matlab then it's going to slow
down. The success of Matlab suggests that it does very well in its
domain. Similarly, although I have considerable doubts about the
language, Tcl and Tk make a quite adequate layer for producing a
graphical interface to something: most of the performance-critical
graphical bits are coded in C, in Tk, and interactivity is often
fine.
Something else that's perhaps not obvious is that the package has to
be trusted by the people using it. It's no good saying that
Mathematica has most of the same numerical facilities as Matlab; it
just doesn't have the same track record as Matlab (yet). We know
where most of the Matlab matrix functions came from, and we know
they're good: unless Mathematica has changed since I last looked, and
now uses LAPACK or one of the other standard libraries, that's not
true of Mathematica. Anyway, I refuse to use a system that requires
me to say "Sin[x]" or whatever its syntax is rather than "sin(x)".
(I'll put up with "(sin x)" for the sake of using Lisp, though.)
--
Bruce Stephens | email: ··········@math.ruu.nl
Utrecht University | telephone: +31 30 2534630
Department of Mathematics | telefax: +31 30 2518394
P.O. Box 80010, 3508 TA Utrecht |
The Netherlands |
In article <···············@bommel.math.ruu.nl> ········@math.ruu.nl (Bruce Stephens) writes:
>true of Mathematica. Anyway, I refuse to use a system that requires
>me to say "Sin[x]" or whatever its syntax is rather than "sin(x)".
>(I'll put up with "(sin x)" for the sake of using Lisp, though.)
>--
>Bruce Stephens | email: ··········@math.ruu.nl
>Utrecht University | telephone: +31 30 2534630
>Department of Mathematics | telefax: +31 30 2518394
>P.O. Box 80010, 3508 TA Utrecht |
>The Netherlands |
Agreed. The decision to use [...] for functions was, in my opinion,
one of the biggest mistakes in Mathematica. It relegated parentheses
to an insignificant role (perhaps an anti-Lisp reaction?) and forced
the use of a[[i]] for what it should have been a[i], as in C. In
matrix- or array-heavy modules, the visual result is "Lots of
Irritating Silly Brackets". Here is a sickening example of my
own, with apologies:
SymmSkylineMatrixFactorWithPenaltySprings[S_,tol_]:=Module[
{p,a,n,i,j,k,m,l,ii,ij,jj,jk,jmj,d,s,r,v,psl},
r=SymmSkylineMatrixRowLengths[S]; s=Max[r];
{p,a}=S; n=Length[p]-1; v=Table[0,{n}]; psl={};
Do [jj=p[[j+1]]; If[jj<0||r[[j]]==0, Continue[]]; d=a[[jj]];
jmj=Abs[p[[j]]]; jk=jj-jmj;
Do [i=j-jk+k; v[[k]]=0; ii=p[[i+1]];
If [ii<0, Continue[]]; m=Min[ii-Abs[p[[i]]],k]-1;
ij=jmj+k; v[[k]]=a[[ij]];
Do [v[[k]]-=a[[ii-m+l-1]]*v[[k-m+l-1]],{l,1,m}];
a[[ij]]=v[[k]]*a[[ii]],
{k,1,jk-1}];
Do [d-=a[[jmj+l]]*v[[l]],{l,1,jk-1}];
If [Abs[d]<tol*Sqrt[r[[j]]], d+=s; psl=Append[psl,{j,s}]];
a[[jj]]=1/d,
{j,1,n}];
Return[{{p,a},{psl}}]
];
An orgy of brackets, with not a parenthesis in sight.
Actually the F90 version is more visually appealing although
Fortran still does not recognize [] or {}.
In article <·········@lace.colorado.edu>, ······@mars.Colorado.EDU (Carlos
A. Felippa) wrote:
> Agreed. The decision to use [...] for functions was, in my opinion,
> one of the biggest mistakes in Mathematica.
In my opinion it is a strength of Mathematica. The use of brackets is
normally ambiguous in a "mathematical" setting. For instance if I write on
a blackboard or piece of paper:
a(b+c)
And show it to a mathematically literate person they would commonly
understand this to be multiplication. If I instead wrote:
f(b+c)
They would commonly understand this to be function application. Therefore
the use of () in common mathematics is ambiguous.
Some languages take the design decision - we are going to force the above
to always be function application and any multiplication must be done with
*.
Another design decision is to separate function application and
parenthesization. These are conceptually very different. I very much like
the separation. It is not as traditional but it is conceptually cleaner
and I find it better in practice.
> It relegated parentheses
> to an insignificant role (perhaps an anti-Lisp reaction?) and forced
> the use of a[[i]] for what it should have been a[i], as in C. In
> matrix- or array-heavy modules, the visual result is "Lots of
> Irritating Silly Brackets". Here is a sickening example of my
> own, with apologies:
>
> SymmSkylineMatrixFactorWithPenaltySprings[S_,tol_]:=Module[
> {p,a,n,i,j,k,m,l,ii,ij,jj,jk,jmj,d,s,r,v,psl},
> r=SymmSkylineMatrixRowLengths[S]; s=Max[r];
> {p,a}=S; n=Length[p]-1; v=Table[0,{n}]; psl={};
> Do [jj=p[[j+1]]; If[jj<0||r[[j]]==0, Continue[]]; d=a[[jj]];
> jmj=Abs[p[[j]]]; jk=jj-jmj;
> Do [i=j-jk+k; v[[k]]=0; ii=p[[i+1]];
> If [ii<0, Continue[]]; m=Min[ii-Abs[p[[i]]],k]-1;
> ij=jmj+k; v[[k]]=a[[ij]];
> Do [v[[k]]-=a[[ii-m+l-1]]*v[[k-m+l-1]],{l,1,m}];
> a[[ij]]=v[[k]]*a[[ii]],
> {k,1,jk-1}];
> Do [d-=a[[jmj+l]]*v[[l]],{l,1,jk-1}];
> If [Abs[d]<tol*Sqrt[r[[j]]], d+=s; psl=Append[psl,{j,s}]];
> a[[jj]]=1/d,
> {j,1,n}];
> Return[{{p,a},{psl}}]
> ];
>
> An orgy of brackets, with not a parenthesis in sight.
> Actually the F90 version is more visually appealing although
> Fortran still does not recognize [] or {}.
For better or for worse, I'd say that the above function is written in a
style that is not really the 'recommended' style in Mathematica.
Second even if Mathematica had delimiters of the form you are advocating
the above code would still be fairly unreadable i.e.
SymmSkylineMatrixFactorWithPenaltySprings(S_,tol_):=Module(
{p,a,n,i,j,k,m,l,ii,ij,jj,jk,jmj,d,s,r,v,psl},
r=SymmSkylineMatrixRowLengths(S); s=Max(r);
{p,a}=S; n=Length(p)-1; v=Table(0,{n}); psl={};
Do (jj=p[j+1]; If(jj<0||r[j]==0, Continue(]; d=a[jj];
jmj=Abs(p[j])); jk=jj-jmj;
Do (i=j-jk+k; v[k]=0; ii=p[i+1];
If (ii<0, Continue()); m=Min(ii-Abs(p[i]),k)-1;
ij=jmj+k; v[k]=a[ij];
Do (v[k]-=a[ii-m+l-1]*v[k-m+l-1],{l,1,m});
a[ij]=v[k]*a[ii],
{k,1,jk-1});
Do (d-=a[jmj+l]*v[l],{l,1,jk-1});
If (Abs(d)<tol*Sqrt(r[j]), d+=s; psl=Append(psl,{j,s}];
a[jj]=1/d,
{j,1,n});
Return({{p,a},{psl}})
);
Jason
In article <·························@news.edvz.uni-linz.ac.at>,
jason harris <········@phys.canterbury.ac.nz> wrote:
>In article <·········@lace.colorado.edu>, ······@mars.Colorado.EDU (Carlos
>A. Felippa) wrote:
>.... The use of brackets is
>normally ambiguous in a "mathematical" setting. For instance if I write on
>a blackboard or piece of paper:
>
>a(b+c)
>
>And show it to a mathematically literate person they would commonly
>understand this to be multiplication. If I instead wrote:
>
>f(b+c)
>
>They would commonly understand this to be function application. Therefore
>the use of () in common mathematics is ambiguous.
>
>Some languages take the design decision - we are going to force the above
>to always be function application and any multiplication must be done with
>*.
It is not the () that are ambiguous, but the space between the
first symbol and the ( that is ambiguous.
To see this, observe that
sin x has no parentheses, but is usually understood to be function
application. Whereas
a x is usually thought to be multiplication.
The ambiguity is handled more-or-less by context. Mathematicians
thrive (sometimes unconsciously) on "abuse of notation", and this
is just one example. What does the space between x and d mean in
integral x dx ?
As for whether Mathematica's choice of Sin[x] is better than
Maple/Macsyma/Fortran/Algol/Pascal/ ... sin(x) or better than TeX's
\sin x, or better than Lisp's superbly unambiguous and easy to parse,
but unconventional (sin x), is largely a matter of taste.
For more choices, see a scientific word processor where you pick
symbols from a menu, and/or it italicizes successive letters
in math mode "s" "i" but then when you type "n" it automagically
converts "sin" to Roman.
Then it has to figure out when sinh means hyperbolic sine and
when it means sin(h).
Mathematica's syntax is sufficiently Baroque than
even long-time users are occasionally surprised by it. This is
not good. On the other hand, many people find it handy for
prototyping small and perhaps inefficient code.
(see my home page for a pointer to a long review of mathematica)
--
Richard J. Fateman
·······@cs.berkeley.edu http://http.cs.berkeley.edu/~fateman/
In article <··········@agate.berkeley.edu>,
·······@peoplesparc.cs.berkeley.edu (Richard J. Fateman) wrote:
> In article,
> jason harris <········@phys.canterbury.ac.nz> wrote:
> >.... The use of brackets is
> >normally ambiguous in a "mathematical" setting. For instance if I write on
> >a blackboard or piece of paper:
> >
> >a(b+c)
> >
> >And show it to a mathematically literate person they would commonly
> >understand this to be multiplication. If I instead wrote:
> >
> >f(b+c)
> >
> >They would commonly understand this to be function application. Therefore
> >the use of () in common mathematics is ambiguous.
> >
> >Some languages take the design decision - we are going to force the above
> >to always be function application and any multiplication must be done with
> >*.
> >
> >Another design decision is to separate function application and
> >parenthesization. These are conceptually very different. I very much like
> >the separation. It is not as traditional but it is conceptually cleaner
> >and I find it better in practice.
>
> It is not the () that are ambiguous, but the space between the
> first symbol and the ( that is ambiguous.
> To see this, observe ....
Yes, you are correct. In any case, and in which ever way you view
it, when using ()'s the "traditional" mathematics notation for
function application and multiplication is problematic.
I was commenting that making a distinction between function
application and multiplication was conceptually nice and that
this was a good thing to do, or at the *least* that it was not a
bad thing to do.
> As for whether Mathematica's choice of Sin[x] is better than
> Maple/Macsyma/Fortran/Algol/Pascal/ ... sin(x) or better than TeX's
> \sin x, or better than Lisp's superbly unambiguous and easy to parse,
> but unconventional (sin x), is largely a matter of taste.
Well, in LISP one has to use prefix addition so I don't think
this is really "natural" for a language trying to capture
"standard" mathematics. Don't misunderstand me, I like Lisp,
but it is not common to see the use of prefix + * - / in
Mathematics texts.
Also to the degree that one restricts oneself to prefix operators
the other languages are also unambiguous since in Mathematica we
can write Times[a,b] and there should be a corresponding
times(a,b) or something (or some other way to get a prefix form
of an infix operator) in Maple.
However you are correct in that in the end for all of these
languages it just boils down to taste. In Mathematica one
distinguishes between function application and multiplication by
explicitly using different brackets. In other languages, like
Maple, one explicitly inserts the operator. In still other
languages, like Lisp, one does not use infix operators so the
problem does not arise.
> Mathematica's syntax is sufficiently Baroque than
> even long-time users are occasionally surprised by it. This is
> not good. On the other hand, many people find it handy for
> prototyping small and perhaps inefficient code.
> (see my home page for a pointer to a long review of mathematica)
Hmmmm, I would not really agree with this assessment of
Mathematica. In any case this is a different issue then the one
that was brought up above.
Cheers,
Jason
>Also to the degree that one restricts oneself to prefix operators
>the other languages are also unambiguous since in Mathematica we
>can write Times[a,b] and there should be a corresponding
>times(a,b) or something (or some other way to get a prefix form
>of an infix operator) in Maple.
>
Allowing x y to represent x*y can lead to some interesting ambiguities
when enmeshed with C's wonder twins ++ and --.
For example, if x=2, y=3, can somebody tell at a glance the result
of the following constructions:
x++y x ++y
without running Mathematica. Why 2x4=8 of course. Think again.
········@phys.canterbury.ac.nz (jason harris) writes:
>I was commenting that making a distinction between function
>application and multiplication was conceptually nice and that
>this was a good thing to do, or at the *least* that it was not a
>bad thing to do.
Is there really a good reason for enforcing a syntactic distinction
between function application and multiplication? Mathematica's syntax
is odd because it starts with the notation people to write maths with
pencil and paper and then modifies it to add a syntactic distinction
between the two operations.
The other languages people have been mentioning (lisp, maple etc) also
rely on syntax to dintinguish these operation. It seems surprising
that nobody's tried to use type information instead.
--
Matthew McDonald ····@cs.uwa.edu.au
Nim's longest recorded utterance was the sixteen-sign declarative
pronouncement, "Give orange me give eat orange me eat orange give me
eat orange give me you."
In article <··············@cs.uwa.edu.au>,
Matthew McDonald <····@cs.uwa.edu.au> wrote:
>The other languages people have been mentioning (lisp, maple etc) also
>rely on syntax to dintinguish these operation. It seems surprising
>that nobody's tried to use type information instead.
I believe that Axiom, or at least its predecessor Scratchpad
used to make sin x mean sin (x) since sin was a function.
And pattern matching could be used for other cases.
Using types is not too hard if you believe that it is a good thing to
declare all functions before use, and then to never re-use a
name in a slightly different context. Most people rebel against
such strictures in a language that they are told is as easy
to use as pencil and paper.
In my opinion the biggest problem in adopting types
is the annoyance factor; close behind is the loss of ambiguity
that is used so effectively in human discourse.
One of many examples:
If D means differentiation wrt x, then (D+I)y means (If I means identity)
y'+y perhaps.
What does (D^2+1)y mean?
y'+y because 1 is obviously also the identity operator?
or
y'+1 because 1 is the constant operator that returns itself ?
or
perhaps something else.
And then you have to explain that D^2 is not a power operation but
produces from D(.) the operator D(D(.))
and you have to decide when it makes sense to factor (D^2-1) or
(D^2-I).
None of these things prevent a solution from being formulated.
Just that finding one to make everyone happy is NOT easy.
Allowing non-commuting operations that look like multiplication and
powering is one obvious step. In terms of general purpose computer
algebra systems, this was introduced in Macsyma prior to 1970.
--
Richard J. Fateman
·······@cs.berkeley.edu http://http.cs.berkeley.edu/~fateman/
·······@peoplesparc.cs.berkeley.edu (Richard J. Fateman) writes:
>Using types is not too hard if you believe that it is a good thing to
>declare all functions before use, and then to never re-use a
>name in a slightly different context. Most people rebel against
>such strictures in a language that they are told is as easy
>to use as pencil and paper.
I haven't thought it through very carefully, but might it be possible
to (a) work out most type information without type declarations (as in
languages like ML) and (b) allow users to over-ride an existing
definition of a name either temporarily or permanently?
>In my opinion the biggest problem in adopting types
>is the annoyance factor; close behind is the loss of ambiguity
>that is used so effectively in human discourse.
But the ambiguity's already been lost once a syntactic distinction
between multiplication and function application is introduced.
I don't have a clue whether or not the this would work nicely in
practice. Apart from the kind of problems you raised, people who
understand the ml type system well seem to agree that ad-hoc
polymorphism significantly complicates things. It just seems that now
type systems are better understood than they were 20 years ago, it
might be possible to get a type system to do some of the work that
people have been relying on syntax for.
--
Matthew McDonald ····@cs.uwa.edu.au
Nim's longest recorded utterance was the sixteen-sign declarative
pronouncement, "Give orange me give eat orange me eat orange give me
eat orange give me you."
[...]
>
>Yes, you are correct. In any case, and in which ever way you view
>it, when using ()'s the "traditional" mathematics notation for
>function application and multiplication is problematic.
>
The analogy between conventional mathematical notation and programming
languages should not be pursued too far. Mathematical writing, like
natural languages, has evolved from generations of use.
When I write xy on the blackboard, my students (well, at least those
awake) know that I mean x*y and not the symbol 'xy'. Why? Because in
a classroom or book, mathematical objects are represented by
single Roman or Greek letters or by "decorated" letters.
If I need more symbols beyond plain letters, I use sub- or superscripts,
hats, tildes, bars, overdots, underlines or similar decorations.
Multiletter sequences are reserved for functions such as Tr or Ker or sin.
In most programming languages different conventions apply because of
various constraints:
. Symbols are represented by letter+number strings
. Decorations such as tildes are not allowed
. The meaning of = is not that of equality
. There are "evaluation time" effects not relevant in human math
. a(b+c) is ALWAYS a function reference if implied multiplication is
disallowed and [] reserved for indexing.
So until computers are trained to directly understand TeX, and eventually
read math articles, the differences should be kept in mind.
Carlos A. Felippa (······@mars.Colorado.EDU) wrote:
: The analogy between conventional mathematical notation and programming
: languages should not be pursued too far. Mathematical writing, like
: . The meaning of = is not that of equality
Indeed. Reminds me of a fellow grad student who was looking at some
code I wrote and stated emphatically, "This cannot be right. X cannot
equal X+1!" He was, of course referring to a line:
X=X+1
Cheers,
Jim
In article <··········@lace.colorado.edu> ······@mars.Colorado.EDU (Carlos A. Felippa) writes:
From: ······@mars.Colorado.EDU (Carlos A. Felippa)
Date: 16 Jul 1996 17:14:11 GMT
Organization: University of Colorado, Boulder
Path: agate!boulder!carlos
Lines: 14
Sender: Carlos A. Felippa
Distribution: world
NNTP-Posting-User: carlos
[...]
>
>a(b + c) is an array reference in Ada. As a matter of taste I believe
>that this is the single most useful notation change (over traditional
>Pascal and Algol) introduced by Ada.
>
Ada inherited that abomination from another committee-designed "monster
for all seasons" called PL/1. [Was there ever a PL/2?] PL/1 was
supposed to unify Fortran, Cobol and Algol 68 (!) --- I guess Lisp was left
out to keep the project simple. PL/1 adopted the array index delimiters
of Fortran. At least the Fortran designers had a good excuse:
the only delimiter pair in the 6-bit charcodes of the 1950s was ().
Yep. I should have said "re-introduced". But then again, I like this
notation which makes maps implemented as tables syntactically similar
to function calls :)
Cheers
--
Marco Antoniotti - Resistente Umano
===============================================================================
International Computer Science Institute | ·······@icsi.berkeley.edu
1947 Center STR, Suite 600 | tel. +1 (510) 643 9153
Berkeley, CA, 94704-1198, USA | +1 (510) 642 4274 x149
===============================================================================
...it is simplicity that is difficult to make.
...e` la semplicita` che e` difficile a farsi.
Bertholdt Brecht
Hi Richard,
"Richard J. Fateman" <·······@CS.Berkeley.EDU>
wrote
>I said...
>>> Mathematica's syntax is sufficiently Baroque that
>>> even long-time users are occasionally surprised by it. This is
>>> not good. On the other hand, many people find it handy for
>>> prototyping small and perhaps inefficient code.
>>> (see my home page for a pointer to a long review of mathematica)
>>
>>Hmmmm, I would not really agree with this assessment of
>>Mathematica. In any case this is a different issue then the one
>>that was brought up above
>
>I'm not sure which part you disagree with, but I think it is
>the syntax part...
>
[Examples you find objectionable in Mathematica's syntax]
This is definitely not the original subject that was raised.
From the previous posts you have made and the opinions you expressed in
them I believe I am aware of your opinion of Mathematica. However I do not
share all of your views. I also would like to avoid entering into a
drawn-out discussion about this since, judging by past history, there will
be no clear end. This type of thread has gone on before for ages and ages.
In any non-trivial language one can create strange constructions be it
lisp, c, haskell, Mathematica, Maple, or mathematics itself. It is
possible in all of these languages to create expressions that are not the
most visually obvious or transparent.
Beyond this I apologize but I don't think anything too productive will be
gained by discussing this. I doubt I will change your views since you have
obviously thought about this a great deal. In the end I again think this
is a matter of taste.
Sorry.
Cheers,
Jason
I (········@phys.canterbury.ac.nz (jason harris) ) wrote:
> Hi Richard,
>
> "Richard J. Fateman" <·······@CS.Berkeley.EDU>
> wrote
Hi,
I am sorry, about the last post I sent. For some reason I had thought that
the last email I had received from Richard Fateman was also somehow
forwarded to this news group which it wasn't. It was a message to me, and
I replied to it here which might make it look a little reactionary.
I am sorry for this,
Jason
>>>>> On 8 Jul 1996 16:23:35 GMT, ·······@peoplesparc.cs.berkeley.edu (Richard J. Fateman) said:
rjf> In article <··············@cs.uwa.edu.au>,
rjf> Matthew McDonald <····@cs.uwa.edu.au> wrote:
>> The other languages people have been mentioning (lisp, maple etc) also
>> rely on syntax to dintinguish these operation. It seems surprising
>> that nobody's tried to use type information instead.
rjf> I believe that Axiom, or at least its predecessor Scratchpad
rjf> used to make sin x mean sin (x) since sin was a function.
rjf> And pattern matching could be used for other cases.
rjf> Using types is not too hard if you believe that it is a good thing to
rjf> declare all functions before use, and then to never re-use a
rjf> name in a slightly different context. Most people rebel against
rjf> such strictures in a language that they are told is as easy
rjf> to use as pencil and paper.
rjf> In my opinion the biggest problem in adopting types
rjf> is the annoyance factor; close behind is the loss of ambiguity
rjf> that is used so effectively in human discourse.
rjf> One of many examples:
rjf> If D means differentiation wrt x, then (D+I)y means (If I means identity)
rjf> y'+y perhaps.
rjf> What does (D^2+1)y mean?
rjf> y'+y because 1 is obviously also the identity operator?
rjf> or
rjf> y'+1 because 1 is the constant operator that returns itself ?
rjf> or
rjf> perhaps something else.
rjf> And then you have to explain that D^2 is not a power operation but
rjf> produces from D(.) the operator D(D(.))
rjf> and you have to decide when it makes sense to factor (D^2-1) or
rjf> (D^2-I).
Indeed, this is a hard problem in general. In physics, it's even worse.
Gerry Sussman & Hal Abelson worked for a full year trying to translate some
basic variational mechanics into some consistent notation. I understand
there's a book coming out on this...
--Mitch
Mitchell Wand Internet: ····@ccs.neu.edu
College of Computer Science, Northeastern University
360 Huntington Avenue #161CN, Boston, MA 02115 Phone: (617) 373 2072
World Wide Web: http://www.ccs.neu.edu/home/wand Fax: (617) 373 5121
>
>They would commonly understand this to be function application. Therefore
>the use of () in common mathematics is ambiguous.
>
>Some languages take the design decision - we are going to force the above
>to always be function application and any multiplication must be done with
>*.
>
What's wrong with an explicit *? It frees () for grouping and
function arguments, [] for indexing, and {} for lists. To me that's
the optimal solution if all other delimiters are taken. For
function application an extra unary operator is enough.
Mathematica does in fact the right thing in its InputForm output
format and puts back the * operators explicitly.
Unfortunately "the world is short of delimiters". A fourth pair,
<>, is usually taken by other purposes, and so are \/ or /\.
Maybe if one could resurrect the mirror of the question mark
as a keyboard symbol, what's its name?
Sorry, I couldn't resist! :)
In article <··········@lace.colorado.edu> ······@mars.Colorado.EDU (Carlos A. Felippa) writes:
From: ······@mars.Colorado.EDU (Carlos A. Felippa)
Date: 14 Jul 1996 21:38:48 GMT
Organization: University of Colorado, Boulder
Path: agate!boulder!carlos
Lines: 33
Sender: Carlos A. Felippa
Distribution: world
NNTP-Posting-User: carlos
[...]
>
>Yes, you are correct. In any case, and in which ever way you view
>it, when using ()'s the "traditional" mathematics notation for
>function application and multiplication is problematic.
>
The analogy between conventional mathematical notation and programming
languages should not be pursued too far. Mathematical writing, like
natural languages, has evolved from generations of use.
When I write xy on the blackboard, my students (well, at least those
awake) know that I mean x*y and not the symbol 'xy'. Why? Because in
a classroom or book, mathematical objects are represented by
single Roman or Greek letters or by "decorated" letters.
If I need more symbols beyond plain letters, I use sub- or superscripts,
hats, tildes, bars, overdots, underlines or similar decorations.
Multiletter sequences are reserved for functions such as Tr or Ker or sin.
In most programming languages different conventions apply because of
various constraints:
. Symbols are represented by letter+number strings
Ther single reason that makes a well written program more readable
than regular math :)
. Decorations such as tildes are not allowed
. The meaning of = is not that of equality
What do you mean? '(= x e)' is equality for numbers in Lisp and A = E
is equality in Ada, Pascal and who knows in how many othe languages.
. There are "evaluation time" effects not relevant in human math
Which gives us computer scientist a lot of work trying to prove how
computationally inefficient are (some) mathematical statements :)
. a(b+c) is ALWAYS a function reference if implied multiplication is
disallowed and [] reserved for indexing.
a(b + c) is an array reference in Ada. As a matter of taste I believe
that this is the single most useful notation change (over traditional
Pascal and Algol) introduced by Ada.
So until computers are trained to directly understand TeX, and eventually
read math articles, the differences should be kept in mind.
:) :) :) So until mathematicians are trained to understand that their
math not always can be easily translated into good programs, the
distinction should be kept in mind.
:) :) :)
Peace
--
Marco Antoniotti - Resistente Umano
===============================================================================
International Computer Science Institute | ·······@icsi.berkeley.edu
1947 Center STR, Suite 600 | tel. +1 (510) 643 9153
Berkeley, CA, 94704-1198, USA | +1 (510) 642 4274 x149
===============================================================================
...it is simplicity that is difficult to make.
...e` la semplicita` che e` difficile a farsi.
Bertholdt Brecht
[...]
>
>a(b + c) is an array reference in Ada. As a matter of taste I believe
>that this is the single most useful notation change (over traditional
>Pascal and Algol) introduced by Ada.
>
Ada inherited that abomination from another committee-designed "monster
for all seasons" called PL/1. [Was there ever a PL/2?] PL/1 was
supposed to unify Fortran, Cobol and Algol 68 (!) --- I guess Lisp was left
out to keep the project simple. PL/1 adopted the array index delimiters
of Fortran. At least the Fortran designers had a good excuse:
the only delimiter pair in the 6-bit charcodes of the 1950s was ().
In article <··········@lace.colorado.edu>, ······@mars.Colorado.EDU (Carlos A. Felippa) writes:
|> [...]
|> >
|> >a(b + c) is an array reference in Ada. As a matter of taste I believe
|> >that this is the single most useful notation change (over traditional
|> >Pascal and Algol) introduced by Ada.
|> >
|>
|> Ada inherited that abomination from another committee-designed "monster
|> for all seasons" called PL/1. [Was there ever a PL/2?] PL/1 was
|> supposed to unify Fortran, Cobol and Algol 68 (!) --- I guess Lisp was left
|> out to keep the project simple. PL/1 adopted the array index delimiters
|> of Fortran. At least the Fortran designers had a good excuse:
|> the only delimiter pair in the 6-bit charcodes of the 1950s was ().
|>
Language creation Snobolled out of control in the '60s.
(Sorry, couldn't resist!)
I do have a relevant (though dim bulb) question in the following post.
--
Dave Doolin Institute for Geotechnology
······@cs.utk.edu Department of Civil Eng. UTK
__________________________________________________
You may add me to your junk email list for $1000.00,
payable in US currency. Otherwise, don't call me,
I'll call you. Sending me junk email from a list
obligates you to this contract.
_________________________________________________
Bryan O'Sullivan wrote:
>
>
> "Java's lack of performance" is at least a little of a myth.
>
> - JIT compilers currently give acceptable performance for many
> application domains.
They definitely do, when the instruction set of the intermediate
machine is built appropriately. Quite clearly, the Java Abstract
machine was not designed with JIT code generation in mind. It is
much closer to a naive stack based interpreter as described in
most compiler design school books.
For many application domains, sure. For true number crunching,
I doubt. Efficient JIT compilation with Java means decompiling
(rebuilding higher-level constructs out of a sequence of
JAM instructions) and recompiling it on th fly.
>
> In short, while a lot of work remains to be done to make use of Java
> acceptable for efficient numeric crunching tasks, there is nothing
> intrinsic to the language that makes it a worse candidate for such
> tasks than are, say, C or C++ for such tasks.
Nothing in the langage, agreed. A lot of things in the
abstract machine which is attached to its current implementation
do make it a worse candidate than C or C++...
Regards,
Darius
>>>>> "Bryan" == Bryan O'Sullivan <···@serpentine.com> writes:
Bryan> In article <·············@maths.anu.edu.au> Graham Matthews
Bryan> <···············@maths.anu.edu.au> writes:
g> The one problem with this idea is Java's lack of performance and
g> parallelism.
Bryan> "Java's lack of performance" is at least a little of a myth.
<snip>
Bryan> In short, while a lot of work remains to be done to make use of
Bryan> Java acceptable for efficient numeric crunching tasks, there is
Bryan> nothing intrinsic to the language that makes it a worse
Bryan> candidate for such tasks than are, say, C or C++ for such
Bryan> tasks. It would take some work on the language definition in
Bryan> order to make the kinds of optimisations that Fortran compilers
Bryan> can get away with safe in Java, though.
The issue here is less that Java is better or worse than C/C++ for
numerics, more that Java does not allow the compiler optimizations
that a purely functional language like Miranda etc. does.
In a functional language, there are no side effects, and therefore,
the compiler can organize the program any way it pleases, without
affecting the semantics. Case in point: Java allows you do define
different threads. No functional language, to my admittedly limited
knowledge (except maybe Lisp, but Lisp is a domain of its own),
includes threads, because they are not an issue; the compiler should
have sufficient brains to farm off separate functions to separate
threads, if that is useful.
Were I to program a MIMD machine, a functional language would probably
be the easiest way to get efficency, because the compiler can then
give the different processors different things to do.
Java may or may not be better than C for numerics. I would not use it
in preference to functional languages, however.
--
Graham Hughes <······@resnet.ucsb.edu> finger for PGP key
``Never attribute to malice that which is adequately explained by
stupidity.'' -- Hanlon's Razor
Home page at: http://www.cs.ucsb.edu/~ghughes/
Many of us here at the MathWorks have been following this discussion
of MATLAB as an "Open" language with a great deal of interest. The
functional language people are saying that MATLAB is not a serious
modern programming language. The friends of MATLAB are saying that
they sure find it useful. Both "sides" are right, of course.
MATLAB traces its origins to a pedagogical language called "PL/0",
from a 1976 textbook, "Algorithms + Data Structures = Programs",
by Niklaus Wirth. Fortran, APL, Algol and Speakeasy also had some
early influence and C has influenced more recent developments.
MATLAB's success should certainly be attributed to the extensive
collection of toolboxes, applications and textbooks associated with it,
rather than to the language itself.
We are deeply concerned about issues of programming language design,
programming methodology, ease of use and educational in science and
engineering. We hope to evolve the MATLAB language and incorporate
the modern features we feel would be useful to our community. But
we must be very careful that we don't lose our naive simplicity in
the process.
-- Cleve Moler
·····@mathworks.com
Cleve Moler (·····@mathworks.com) wrote:
: We are deeply concerned about issues of programming language design,
: programming methodology, ease of use and educational in science and
: engineering. We hope to evolve the MATLAB language and incorporate
: the modern features we feel would be useful to our community. But
: we must be very careful that we don't lose our naive simplicity in
: the process.
I don't know about the marketing implications, but what about
a "two track system"? Evolve the existing MATLAB language as well
as it can be done, but maintain it simple and 'command-line idiomatic'
for its existing customer base.
Then, create a *new* fully-rigorous all-ts-crossed-and-is
dotted superb buzzword-infested bill-and-ted-righteously-excellent language,
e.g. 'Object MATLAB.' or 'Functional MATLAB'.
What would be *imperative*, of course is to have fully transparent
interoperation between routines of the two sorts, and external MEX or
whatever files.
A translator from old to new would be useful too.
With a good language you could probably easily support much faster and
smarter compililation of 'scripts' than existing MATLAB, and by junking
literal compatibility with the past, make a big technological leap into the
future. People could write Object MATLAB classes with high performance
instead of farming out the hard work to their MEX files in C. Bluebirds
sing with joy.
Besides, it would be a way to squeeze $500 a pop out of your customers. ;-)
: -- Cleve Moler
: ·····@mathworks.com
--
Matthew B. ··········@caffeine.engr.utk.edu/I do not speak for ORNL, DOE or UT
Oak Ridge National Laboratory/University of Tennessee, Knoxville, TN USA/
*NO MASS EMAIL SPAM* It's an abuse of Federal Government computer resources
and an affront to common civility. On account of egregiously vile spamation,
my software terminates all email from "interramp.com" and "cris.com" without
human intervention.
I would like to make a few comments about programming
language choices as I have been recently been attempting to answer the
following question:
Given that I am embarking on development of a large numerically
intensive set of routines simulating radition therapy, what
is the best development paradigm?
(Any feedback would be appreciated.)
In the process I have considered, sometimes seriously sometimes
superficially, prolog, C, C++, Fortran 77, Fortran 90, Mathematica,
PV-WAVE, IDL, Matlab, Python, Ox, and Tkl.
Without trying to turn this into a dissertation, my *tentative*
conclusions are:
Development should be broken into
Step 1: prototyping in scripting language
and then
Step 2: implementation into stand-alone compilable language
module. And
the tentative choices of languages are, development in
Matlab 5.0 and implementation in Fortran 90.
Briefly, the rationale was as follows:
--interpreted scripting languages with builtin graphics outputs
save time in development, even when libraries aren't used.
This is related to the integrated environment, lack of long
recompiles, easily available help, perhaps most importantly,
using graphics to help in debugging.
However, Mathematica is far too slow for intensive numerical
work, even on a medium scale. Matlab is slower than IDL and
PVWAVE, but not too slow. Furthermore, Matlab 5.0 is supposed
to have 3-D (and higher dimensional) matrices, a must in
my field (radiation therapy). Also, I am more confortable
with Matlab's language than with PVWaves (IDL)'s language,
though that may not be paramount.
Python looks very interesting (see the most recent _Computers
in Physics_), but currently lacks modules (or written classes),
including higher dimensional
matrices, 3D graphical displays, and other higher
level math functions. Perhaps we should write what we need
ourselves? Python should be very fast, and is imminently
extensible.
Fortran 90 has many features of higher level modern languages,
and includes Matlab-like matrix operation functions.
Recoding from Matlab to Fortran 90 would probably not take much
time and would allow for single-precision storage where needed.
In fact, there is a project, called the Falcon project, to
build a compiler in Fortran 90 for Matlab, at Illinois
(the compiler has been completed).
Functional languages were not considered appropriate because
our problems are mainly matrix math and optimization problems
where things like Simpson's rule and iterations appear to be the
simplest way to think about the problem.
However, Python looks interesting as a possibility if the lack
of available code can be overcome and if some graphical capability
becomes available. Also, working directly in Fortran 90 could
become possible too, as some nice libraries are available; but
the inherent efficiency loss from moving away from a more
exploratory interpretive environment would have to be overcome.
Certainly if Matlab had a cleaner way of handling things like
global variables, and if it were as fast as compiled code, and
could use single precision, I probably wouldn't bother with
a 'lower-level' language like Fortran 90.
--Joe Deasy
****Any comments or especially corrections appreciated******
From: Richard Petti
Subject: Re: 'Open' languages: e.g., MATLAB and Macsyma
Date:
Message-ID: <4s0jnq$eeo@news-old.tiac.net>
In article <············@roentgen.bcc.louisville.edu>,
·······@roentgen.bcc.louisville.edu says...
>
>I would like to make a few comments about programming
>language choices as I have been recently been attempting to answer the
>following question:
>Given that I am embarking on development of a large numerically
>intensive set of routines simulating radition therapy, what
>is the best development paradigm?
>
>(Any feedback would be appreciated.)
>
> [snip]
>
>Fortran 90 has many features of higher level modern languages,
>and includes Matlab-like matrix operation functions.
>
Your choice of software depends of course on the project.
- If you are modeling continuous fields (electromagnetics, heat transfer,
etc.), then using a supported F.E.A. (finite element analsyis) program
saves a lot of time.
PDEase is an F.E.A. code which
o is flexible. It handles solids, fluids, heat transfer, electro-
magnetics, reaction diffusion, quantum mechanics and more in one code.
o solves static, dynamic and eigenvalue problems, currently in 2D, with
a 3D product scheduled for late 1996.
o is easy to use. It converses in terms of partial differential equations,
not in terms of finite elements.
o can read Macsyma's symbolic equations. This enables you to do the
toughest equation manipulation (e.g. vector calculus in curilinear
coordinates) in Macsyma and pass them to PDEase for numerical solution.
- If you are doing symbolic models, a symbolic-numerical program like
Macsyma or Maple or Mathematica results in tremendous savings of effort.
For translating to FORTRAN or C, Macsyma has the GENTRAN package which
translates program flow control structures (do-loops, if-then conditional
branching statements, function and subroutine definitions and calls),
matrices and other structures -- not just math expressions.
- If you are doing a lot of numerical linear algebra, a supported,
fast numerical linear algebra package with a good user interface
greatly increases efficiency.
o 18 months ago, Macsyma adopted "all" the language conventions in Matlab,
such as left and right matrix division, ellipsis, assignment into lists,
and variable number of return values.
o Macsyma includes nearly all Matlab's command names, preceded by "MAT"
(For example Matlab's EYE function is MAT_EYE in Macsyma.)
o Macsyma has a Matlab-to-Macsyma translator, which was upgraded somewhat
last winter.
* This fall, Macsyma is adding Lapack to speed up many numerical linear
algebra operations by 1-2 orders of magnitude. For large numerical
linear algebra jobs, the new Macsyma is competitive with the fastest
numerical-only libraries, but retains the advantages of an integrated
symbolic-numerical-graphical-notebook-programminglanguage environment.
I believe it is important to weight the canned power, the ease of use
and canned documentation, and the savings of programming effort attainble
with the highest quality supported packages. That is perhaps the most
important change in the landscape for scientific software in the 1990s.
If you are writing an application which is not covered by these sorts of
packages, you might write in raw seething FORTRAN or C.
I would be happy to send any reader more information about Macsyma or
PDEase.
>
>--Joe Deasy
>****Any comments or especially corrections appreciated******
--
-------------------------------------------------------------
Richard Petti
Macsyma Inc. tel: 617-646-4550
20 Academy Street fax: 617-646-3161
Arlington, MA 02174-6436 / U.S.A. email: ·····@macsyma.com
····@macsyma.com
URL: http://www.macsyma.com
-------------------------------------------------------------
In article <············@roentgen.bcc.louisville.edu>, Joe Deasy
<·······@roentgen.bcc.louisville.edu> wrote:
[snip]
Certainly if Matlab had a cleaner way of handling things like
global variables, and if it were as fast as compiled code, and
could use single precision, I probably wouldn't bother with
a 'lower-level' language like Fortran 90.
--Joe Deasy
****Any comments or especially corrections appreciated******
Have you looked at TMW's compiler and math library? Don't know if it
supports FORTRAN, but a lot of numerical work is done in C. MATLAB for
instance.
Tom
In article <··············@graham.fishnet.net>,
Graham C. Hughes <······@resnet.ucsb.edu> wrote:
>... No functional language, to my admittedly limited
>knowledge (except maybe Lisp, but Lisp is a domain of its own),
>includes threads, because they are not an issue; the compiler should
>have sufficient brains to farm off separate functions to separate
>threads, if that is useful.
I suspect I will regret continuing this thread, but I find it
occasionally necessary to toss water on the functional programming
purists. Allegro Common Lisp certainly does have light-weight
processes, and I believe so do most other implementations.
Graham mischaracterizes the reasons for them, by supposing
they would be unnecessary for a sufficiently smart compiler.
Here are a few:
(a) processes to watch for asynchronous messages from an emacs
editor.
(b) processes to watch for mouse-button activity / mouse-tracking,
graphics control.
(c) processes to watch for network-related traffic (superset of (a),
perhaps).
(d) explicit multiprocessing (heuristic search perhaps?)
While I prefer "functional" style programming, it is not a cure-all.
I would use such a "style" of programming if I were using Java.
--
Richard J. Fateman
·······@cs.berkeley.edu http://http.cs.berkeley.edu/~fateman/
Graham C. Hughes <······@resnet.ucsb.edu> wrote:
> >... No functional language, to my admittedly limited
> >knowledge (except maybe Lisp, but Lisp is a domain of its own),
> >includes threads, because they are not an issue; the compiler should
> >have sufficient brains to farm off separate functions to separate
> >threads, if that is useful.
Richard J. Fateman wrote:
> I suspect I will regret continuing this thread, but I find it
> occasionally necessary to toss water on the functional programming
> purists. Allegro Common Lisp certainly does have light-weight
> processes, and I believe so do most other implementations.
> Graham mischaracterizes the reasons for them, by supposing
> they would be unnecessary for a sufficiently smart compiler.
>
> Here are a few:
> (a) processes to watch for asynchronous messages from an emacs
> editor.
> (b) processes to watch for mouse-button activity / mouse-tracking,
> graphics control.
> (c) processes to watch for network-related traffic (superset of (a),
> perhaps).
> (d) explicit multiprocessing (heuristic search perhaps?)
>
> While I prefer "functional" style programming, it is not a cure-all.
Richard,
No-one is claiming that functional programming is a cure-all. There are
some tasks that I would prefer to do in a non functional language (although
with the arrival of monads the number of these is diminishing all the
time). What we are saying is that for the "computing the results" part
of computations functional languages can't be beat. You might (!) need
an imperative language to display results, but not to compute them.
As to your examples above, my guess is that all of them can be programmed
quite easily in a functional language supporting monads and explicit
threads I am no monad expert so I am not sure, but I think so.
graham
--
Poor man want to be rich
Rich man want to be king
But a king ain't satisfied
Till he rules everything
Graham C. Hughes (······@resnet.ucsb.edu) wrote:
: The issue here is less that Java is better or worse than C/C++ for
: numerics, more that Java does not allow the compiler optimizations
: that a purely functional language like Miranda etc. does.
: In a functional language, there are no side effects, and therefore,
: the compiler can organize the program any way it pleases, without
: affecting the semantics.
This is true, but really, how smart are the compilers? To be specific,
can you write an SVD routine in idiomatic functional language which is
automagically as efficient in space and time as conventional algorithms?
The conventional algorithms embody a whole bunch of human sweatwork which went
into figuring out efficient ways of implementing things given the physics
of mutable state computers. Also the ordering of computations has
somewhat nontrivial effects with the finite precision approximation
of typical hardware supported floating point.
Some of that may be needless I am willing to grant. But it seems that
in some circumstance you will end up writing in a particular idiom in
which you heuristically 'know' what sorts of transformations this version
of this compiler will do to produce the sort of procedure that you know
is space and time efficient. Then programming a functional language
and getting good results would be way too much 'black voodoo' for my
tastes.
The transformations known to a compiler are necessarily broad and
general, and can't understand emergent properties of an algorithm or
typically expected input data.
This could also be used as an argument to use assembly but practical
technology has proven it rather unnecessary, perhaps functional languages
will be that good sometime? Is that time now?
: Case in point: Java allows you do define
: different threads. No functional language, to my admittedly limited
: knowledge (except maybe Lisp, but Lisp is a domain of its own),
: includes threads, because they are not an issue; the compiler should
: have sufficient brains to farm off separate functions to separate
: threads, if that is useful.
It should, but generally people who use very parallel machines say that
you really need human smarts to get good use out of them and entire
rearchitecting of your problem. Consider also that the distribution of
code and data often involves subtle properties of the run-time communication
patterns of the algorithms and the sort of input data fed to the program.
This stuff goes into the design.
Or is the state of the art much better than I imagine?
: Were I to program a MIMD machine, a functional language would probably
: be the easiest way to get efficency, because the compiler can then
: give the different processors different things to do.
Upto a point I bet yes.
: --
: Graham Hughes <······@resnet.ucsb.edu> finger for PGP key
: ``Never attribute to malice that which is adequately explained by
: stupidity.'' -- Hanlon's Razor
: Home page at: http://www.cs.ucsb.edu/~ghughes/
--
Matthew B. ··········@caffeine.engr.utk.edu/I do not speak for ORNL, DOE or UT
Oak Ridge National Laboratory/University of Tennessee, Knoxville, TN USA/
*NO MASS EMAIL SPAM* It's an abuse of Federal Government computer resources
and an affront to common civility. On account of egregiously vile spamation,
my software terminates all email from "interramp.com" and "cris.com" without
human intervention.
···············@maths.anu.edu.au> writes:
: The one problem with this idea is Java's lack of performance and
: parallelism.
"Bryan" == Bryan O'Sullivan <···@serpentine.com> writes:
: Bryan> "Java's lack of performance" is at least a little of a myth.
: Bryan> ... there is
: Bryan> nothing intrinsic to the language that makes it a worse
: Bryan> candidate for such tasks than are, say, C or C++ for such
: Bryan> tasks.
Graham C. Hughes wrote:
: The issue here is less that Java is better or worse than C/C++ for
: numerics, more that Java does not allow the compiler optimizations
: that a purely functional language like Miranda etc. does.
You win the big prize! This was precisely my point!
Graham C. Hughes wrote:
> In a functional language, there are no side effects, and therefore,
> the compiler can organize the program any way it pleases, without
> affecting the semantics. Case in point: Java allows you do define
> different threads. No functional language,...,
> includes threads, because they are not an issue; the compiler should
> have sufficient brains to farm off separate functions to separate
> threads, if that is useful.
Exactly! For those who might disbelieve some/all of what is said above
cf http://www.llnl.gov/sisal/SisalHomePage.html
> Were I to program a MIMD machine, a functional language would probably
> be the easiest way to get efficency, because the compiler can then
> give the different processors different things to do.
Indeed thats what I was trying to get at.
graham
--
Go west, go west
Where there's work so I'm told
California's never cold
So go west
>>>>> "Cleve" == Cleve Moler <·····@mathworks.com> writes:
> Many of us here at the MathWorks have been following this discussion
> of MATLAB as an "Open" language with a great deal of interest. The
> functional language people are saying that MATLAB is not a serious
> modern programming language. The friends of MATLAB are saying that
> they sure find it useful. Both "sides" are right, of course.
Speaking as a defender of MATLAB, I agree with both sides, to a large
extent. I don't think MATLAB's language is a particularly clean, pure
one, but then, like Perl I suppose, that may well be a strength. It
wins over many other packages by being dead easy to use interactively,
and simply by having a vast library of robust code: if I want a random
sparse symmetric positive definite matrix (which I do, often!) to
check my program on, then MATLAB can generate one with what looks like
about 15 lines of code, most which produce the output in the form my
program requires (the actual matrix is generated by a single function
call). Similarly, if I want to compare the cholesky factor my program
produces with the "real" one, I can do that with a few lines in
MATLAB, because it has a function to compute Cholesky factors of
sparse matrices.
I'd quite like something with a different programming language,
preferably Lisp, but mostly for the pragmatic reason that I know Lisp
(I use it when fiddling with GNU Emacs), and whenever I have to do
programming in MATLAB, I end up spending a lot of the time looking in
help files for syntax which would be obvious (to me!) if it were
Lisp. If I used MATLAB much more, probably I wouldn't care much.
I'm not at all sure I'd want a pure functional programming language:
I'm sure they have great potential, and I think Sisal looks
interesting, but they still feel alien: iterative methods feel as
though they ought to be destructively modifying things, regardless of
the fact that you *can* write them as sequences of results.
--
Bruce Stephens | email: ··········@math.ruu.nl
Utrecht University | telephone: +31 30 2534630
Department of Mathematics | telefax: +31 30 2518394
P.O. Box 80010, 3508 TA Utrecht |
The Netherlands |
"Cleve" == Cleve Moler <·····@mathworks.com> writes:
> > Many of us here at the MathWorks have been following this discussion
> > of MATLAB as an "Open" language with a great deal of interest. The
> > functional language people are saying that MATLAB is not a serious
> > modern programming language. The friends of MATLAB are saying that
> > they sure find it useful. Both "sides" are right, of course.
Bruce Stephens wrote:
> Speaking as a defender of MATLAB, I agree with both sides, to a large
> extent. I don't think MATLAB's language is a particularly clean, pure
> one, but then, like Perl I suppose, that may well be a strength. It
> wins over many other packages by being dead easy to use interactively,
> and simply by having a vast library of robust code:
The problem with this argument is that its not an argument against
functional programming languages, its only an argument against bad
implementations of languages. The functional programming people are
not arguing that Matlab is not useful (it certainly is since lots
of people use it), rather they are arguing that you can have all those
friendly things you like in Matlab (such as interactivity) in a fast
modern well implemented functional language. The issue is one of potential.
What potential does Matlab have for future improvement versus what
potential a functional language has to get a library like Matlabs,
for example.
> I'm not at all sure I'd want a pure functional programming language:
> I'm sure they have great potential, and I think Sisal looks
> interesting, but they still feel alien: iterative methods feel as
> though they ought to be destructively modifying things, regardless of
> the fact that you *can* write them as sequences of results.
It doesn't take long to get used to doing iterative methods as sequences
of results. Indeed it doesn't take long before you feel that doing it
any other way feels alien :-)
graham
--
Poor man want to be rich
Rich man want to be king
But a king ain't satisfied
Till he rules everything
Graham Matthews wrote:
>
> > I'm not at all sure I'd want a pure functional programming language:
> > I'm sure they have great potential, and I think Sisal looks
> > interesting, but they still feel alien: iterative methods feel as
> > though they ought to be destructively modifying things, regardless of
> > the fact that you *can* write them as sequences of results.
>
> It doesn't take long to get used to doing iterative methods as sequences
> of results. Indeed it doesn't take long before you feel that doing it
> any other way feels alien :-)
>
My experience is that recursive non-destructive programming is dead easy
to learn, and that if you learn that first, going over to imperative,
destructive, pointer-mangling languages is terribly PAINFUL.
A bunch of first-year students here first learnt real programming using ML,
and then switchin to C was hard work...
It is all a matter of what you've learnt. In my experience, functional
programming, recursion and higher-order programming is REALLY EASY, if only
you HAVEN'T got any experience with unpure languages (like all imperative
langugaes without garbage collection).
/jakob
----------------------------------------------------------------------------
Jakob Engblom. Computer Science Student @ Uppsala University, Sweden
presently an ERASMUS exchange student in Stuttgart, Germany
email Uppsala: ·····@docs.uu.se
email Stuttgart: ········@tick.informatik.uni-stuttgart.de
homepage: http://www.csd.uu.se/~jakob
>
>My experience is that recursive non-destructive programming is dead easy
>to learn, and that if you learn that first, going over to imperative,
>destructive, pointer-mangling languages is terribly PAINFUL.
>
>A bunch of first-year students here first learnt real programming using ML,
>and then switchin to C was hard work...
>
>It is all a matter of what you've learnt. In my experience, functional
>programming, recursion and higher-order programming is REALLY EASY, if only
>you HAVEN'T got any experience with unpure languages (like all imperative
>langugaes without garbage collection).
>
>/jakob
>
>----------------------------------------------------------------------------
> Jakob Engblom. Computer Science Student @ Uppsala University, Sweden
> presently an ERASMUS exchange student in Stuttgart, Germany
If I correctly understand this thread, the discussion is whether
writing (or rewriting) software products in a purely functional language
would be a "good thing" for developers and users. Any conclusions could
be important in influencing future strategic directions for Computer Science
instruction, as discussed at the recent ACM MIT workshop.
The decision could be made easier if the advocates of these languages
could point out to medium-scale, commercial or public-domain products
written with them. Something of the order of TeX, Photoshop, Netscape,
d-Base, early Nastran, or Berkeley Unix. These applications were written
by one person or a small team; hence the effect of the choice of
language (as opposed to that of project management) is important.
Then developers and users of those products could be invited to share
their enlightening experiences.
Outside of the AI community, I can think of two medium-scale examples:
Macsyma was originally written in Lisp (1.5?) at MIT although I am
not sure if the commercial version is Lispian. And the Parc Alto machine
(widthdrwan as commercial product) was programmed in Smalltalk.
Of course, Lisp and Smalltalk might not qualify as "pure" functional
languages in the current sense. Unfortunately the real world may require
some impure compromises when one goes beyond the Towers of Hanoi.
So some newer examples would be welcome.
In article <··········@lace.colorado.edu>,
Carlos A. Felippa <······@mars.Colorado.EDU> wrote:
>If I correctly understand this thread, the discussion is whether
>writing (or rewriting) software products in a purely functional language
>would be a "good thing" for developers and users. Any conclusions could
>be important in influencing future strategic directions for Computer Science
>instruction, as discussed at the recent ACM MIT workshop.
>
>The decision could be made easier if the advocates of these languages
>could point out to medium-scale, commercial or public-domain products
>written with them.
I don't know about "purely functional"
but many applications written in Lisp have a functional implementation
flavor to them.
Macsyma is indeed still written in Lisp, but Common Lisp. It was
originally written in Maclisp (not Lisp 1.5).
The operating system for Lisp machines is/was written in lisp. Even
using stock hardware, there are many many examples ... environments,
editors, formatters, compilers, window systems, mechanical
design, as well as many AI-ish programs for
vision understanding, language understanding... etc
The anecdotatl evidence is suggestive that programs can be more easily
written/debugged to fit into such a system. But there is a barrier to
learning a complex system, especially if students perceive C++ as the
only language of commercial interest.)
Most lisp programmers are not "purists" however, and their programs
are a mixture of functional, imperative, object-oriented, and other
styles.
--
Richard J. Fateman
·······@cs.berkeley.edu http://http.cs.berkeley.edu/~fateman/
From: Sebastian Erich Good
Subject: Re: 'Open' languages: e.g., MATLAB
Date:
Message-ID: <4rkh81$8ka@larry.rice.edu>
With apologies:
If I correctly understand this thread, the discussion is whether writing
(or rewriting) software products in a high level language instead of
assembly would be a "good thing" for developers and users. Any
conclusions could be important in influencing future strategic directions
for Computer Science instruction.
The decision could be made easier if the advocates of these languages
could point out to medium-scale, commercial or public-domain products
written with them. Something of the order of Lotus 1-2-3, OS/2, Borland
Pascal 3.0 [His roots as a PC user are clear -Ed.] etc. These applications
were written in the only language considered accteptable at the time:
assembly.
Then developers and users of those products could be invited to share
their enlightening experiences.
Of course, FORTRAN and Algol might not qualify as "pure" higher level
languages in the current sense. Unfortunately the real world may require
some impure compromises when one goes beyond the Towers of Hanoi.
So some newer examples would be welcome.
In article <··········@larry.rice.edu>
····@ural.owlnet.rice.edu "Sebastian Erich Good" writes:
> With apologies:
>
> If I correctly understand this thread, the discussion is whether writing
> (or rewriting) software products in a high level language instead of
> assembly would be a "good thing" for developers and users. Any
> conclusions could be important in influencing future strategic directions
> for Computer Science instruction.
Are you sure that assembly language is relevant, here? My
impression is that this thread is discussion the relative
virtues of high level languages and tools, e.g. MATLAB, and
the degree to which functional languages (and other "modern"
ideas - they're far from _new_) may accomplish the task of
what I'd call "exploratory programming".
> The decision could be made easier if the advocates of these languages
> could point out to medium-scale, commercial or public-domain products
> written with them. Something of the order of Lotus 1-2-3, OS/2, Borland
> Pascal 3.0 [His roots as a PC user are clear -Ed.] etc. These applications
> were written in the only language considered accteptable at the time:
> assembly.
Err, many - if not all - of these products are now written in
languages like C or Pascal, not assembly language. There may
still be some parts written in assembly, like bottlenecks, but
making code rather more portable than assembly is an important
issue for developers these days. Perhaps you're remembering the
days when code was written for _DOS_, where you knew which CPU
the code would likely run on, and had to make it all fit into
a finite amount of memory (640K, for example).
The demands of the PC software market are very different to the
software being discussed in this thread, unless I've misread well
over 50 of the articles posted to it.
> Then developers and users of those products could be invited to share
> their enlightening experiences.
My experience as a developer is that few app developers use
assembly language heavily anymore, except in very special cases
(e.g. some device drivers, not all, or apps where performance
is more important than easy porting to other CPUs). One very
good reason for not using assembly language anymore is that a
good compiler will be able to optimise the code for a modern
CPU in ways that would be very tedious and expensive for a human
to do by hand.
> Of course, FORTRAN and Algol might not qualify as "pure" higher level
> languages in the current sense. Unfortunately the real world may require
> some impure compromises when one goes beyond the Towers of Hanoi.
> So some newer examples would be welcome.
In what way is the Towers of Hanoi relevant to MATLAB? Could
this just be a cheap attack on the languages that you dislike?
If not, then please make your point clearer, as it appears to
be made based on a great deal of ignorance. You might be suprised
by what people are using in the "Real World" (take a look at the
newsgroups that this thread is crossposted to), but right now
I'm more curious about what you might be saying about MATLAB.
There are times when I wish for a comp.lang.advocacy newsgroup. ;)
I hope that this isn't going to be one of them, as this thread
has been fascinating so far. Let's not confuse the issues by
introducing assembly language or PC software into the thread.
If they were relevant, then why has a week passed before someone
bothers to mention them?
--
<URL:http://www.enrapture.com/cybes/> You can never browse enough
I have it at last: 'And She Closed Her Eyes', by Stina Nordenstam
Cyber Surfer <············@wildcard.demon.co.uk> wrote:
> ····@ural.owlnet.rice.edu "Sebastian Erich Good" writes:
>
>> With apologies:
>>
>> If I correctly understand this thread, the discussion is whether writing
>> (or rewriting) software products in a high level language instead of
>> assembly would be a "good thing" for developers and users. Any
>> conclusions could be important in influencing future strategic directions
>> for Computer Science instruction.
>
>Are you sure that assembly language is relevant, here? My
>impression is that this thread is discussion the relative
>virtues of high level languages and tools, e.g. MATLAB, and
>the degree to which functional languages (and other "modern"
>ideas - they're far from _new_) may accomplish the task of
>what I'd call "exploratory programming".
[rest snipped -- careful reading of Sebastian's post in conjunction
with its predecessor required, along with a keen sense of irony]
Whoosh! That was the sound of a joke going way over Cyber Surfer's
head.
Never mind, Sebastian, some of us did take your point, and appreciate
the witty way in which it was presented.
James Lawry.
From: Sebastian Erich Good
Subject: Re: 'Open' languages: e.g., MATLAB
Date:
Message-ID: <4rp0kg$gja@larry.rice.edu>
In article <············@wildcard.demon.co.uk>,
Cyber Surfer <············@wildcard.demon.co.uk> wrote:
>
>> The decision could be made easier if the advocates of these languages
>> could point out to medium-scale, commercial or public-domain products
>> written with them. Something of the order of Lotus 1-2-3, OS/2, Borland
>> Pascal 3.0 [His roots as a PC user are clear -Ed.] etc. These applications
>> were written in the only language considered accteptable at the time:
>> assembly.
>
>Err, many - if not all - of these products are now written in
>languages like C or Pascal, not assembly language.
My point exactly. I was trying to make the point, too subtly I suspect,
that some aspects of the debate of 'functional vs. normal' languages have
the same flavor as the much older 'high level vs assembly' debate. That
these products are written in C, and you can very easily spout the very
reasons they are is ample evidence that the debate of when a C-like
langauge should be used and when assembly should be used is largely
finished. Other debates -- including those for and against functional,
scripting, and object oriented languages are still raging, and I was
trying to sound a small (flippant) voice of protest: don't worry: C will
be dead like assembly before long. Not unused, just specially used.
So I guess I share your sentiments. On the subject of the
attractiveness, usefulness, etc. of MATLAB and similar languages, I feel
that the original poster whom I copied was bringin irrelevant issues in
-- the old functional programming crusade. I wanted to show that. Sorry
for bending any feathers.
Cheers,
Sebastian
-- wrote:
>
> That kind of argument doesn't hold water. Just because you specify a
> problem very generally and give the compiler lots of freedom to
> optimize doesn't mean that the compiler has the algorithms and domain
> knowledge to actually perform those kinds of optimizations.
>
Have a look at
http://www.cs.kun.nl/~clean/
for a (free) functional languages offering automatic threading etc.
Using graph reduction techniques, it is REALLY SIMPLE. It does work.
/jakob
Have faith in your compiler -- it is usually smarter than you!
--
----------------------------------------------------------------------------
Jakob Engblom. Computer Science Student @ Uppsala University, Sweden
presently an ERASMUS exchange student in Stuttgart, Germany
email Uppsala: ·····@docs.uu.se
email Stuttgart: ········@tick.informatik.uni-stuttgart.de
homepage: http://www.csd.uu.se/~jakob
Hi all,
I am new to this news group. I am writing a small program that would
take a list and an atom as an argument and return the number of times th
e atom is in the list:
eg:(foo '(a b c a r) '(a)) rmany
-> 2.
Is there a built-in function that would count the number of elements the
atom has so that I would use a loop and use that number as my required
iteration?
All help appreciated.
Thank you
Kevin
·······@DSIBM.OKLADOT.STATE.OK.US wrote:
> I am new to this news group. I am writing a small program that would
> take a list and an atom as an argument and return the number of times th
> e atom is in the list:
> eg:(foo '(a b c a r) '(a)) rmany
> -> 2.
first, '(a) is not an atom... it is a list... 'a would be the atom that
you want.
> Is there a built-in function that would count the number of elements the
> atom has so that I would use a loop and use that number as my required
> iteration?
to count the number of items in a list there is a function defined on our version of
scheme (berkeley scm) called count (i.e., count -list-) that returns the number of
elements in the list, *however* this _is_ an extention for us, and not in standard
scheme i believe (i couldnt find it in the on-line R4RS index).
that function is relatively easy to write though.
good luck.
jay
uc berkeley student struggling on a scheme class, too.
In article <·····················@DSIBM.OKLADOT.STATE.OK.US>, ·······@DSIBM.OKLADOT.STATE.OK.US writes:
|>
|> Hi all,
|>
|> I am new to this news group. I am writing a small program that would
|> take a list and an atom as an argument and return the number of times th
|> e atom is in the list:
|> eg:(foo '(a b c a r) '(a)) rmany
|> -> 2.
|> Is there a built-in function that would count the number of elements the
|> atom has so that I would use a loop and use that number as my required
|> iteration?
Sure. Try (count 'a '(a b c a r)).
Jeff
PS I suggest that you get a lisp manual and spend some of your spare
time looking through it. It will help you build a few intuitions:
(1) if you want to do "foo", see if there is a function named "foo"
around--there often is, (2) any time you have an item and a
sequence (list or vector) as arguments, guess that the item is the
first argument and the sequence is the second, and (3) virtually all
search and ``is it there'' problems have builtins to solve them.
As you learn the language, pay particular attention to the things
documented along with member, find, assoc, and the like. Also, read
about their optional keyword arguments and do some experimenting.
Good luck.
From: Robert Munyer
Subject: Re: Function to count the members in a list
Date:
Message-ID: <4skhns$q3n@Venus.mcs.com>
In article <·····················@dsibm.okladot.state.ok.us>,
<·······@DSIBM.OKLADOT.STATE.OK.US> wrote:
>
>Hi all,
>
> I am new to this news group. I am writing a small program that would
>take a list and an atom as an argument and return the number of times th
>e atom is in the list:
> eg:(foo '(a b c a r) '(a)) rmany
> -> 2.
>Is there a built-in function that would count the number of elements the
>atom has so that I would use a loop and use that number as my required
>iteration?
> All help appreciated.
>
>Thank you
>
>Kevin
It's a little hard to tell what you really want. "The number of
elements the atom has" doesn't make much sense in Lisp. In fact,
"atom" comes from the Greek word for "indivisible," i. e. something
that can't be divided into elements. [*] Also it's not clear why
your example is
(foo '(a b c a r) '(a))
instead of just
(foo '(a b c a r) 'a)
Whatever you are trying to do, there is probably something built
in to Common Lisp that will do it. But maybe you want to write
your own function instead of using something that is built in.
In that case, very likely the length is something you do not need
to know at all. You should try to think about the problem a little
differently, possibly using mathematical induction. And it always
helps to think about how you would do it without a computer.
Suppose you have a child's picture book and you want to count the
number of pages that have a picture of a rooster. Suppose the book
(meant for small children) has no page numbers. Do you need to
start out by counting the number of pages? No. All you need to
know is:
(1) How to start at the first page.
(2) How to flip from one page to the next.
(3) How to stop flipping when you reach the end.
(4) How to keep a running total, in your head or on paper.
(5) How to recognize a page with a rooster when you see one.
(6) How to add 1 to your running total when appropriate.
Note that in real life, you could either start at the beginning
and work forward, or start at the end and work backward. You can
also do it both ways in Lisp. It is instructive to try doing it
both ways, and to think about which version is easier for the
programmer, and which version is easier for the computer, and why.
-- Robert
P. S. If you really just wanted to know how to find the number of
elements in a list, the answer is LENGTH. As in (length '(a b c)).
[*] In Lisp, as in physics, there are esoteric ways to dismantle
an atom. But you don't need to be concerned about that just yet.
> It's a little hard to tell what you really want. "The number of
> [*] In Lisp, as in physics, there are esoteric ways to dismantle
> an atom. But you don't need to be concerned about that just yet.
I always wondered why EXPLODE and IMPLODE weren't called SPLIT (FISSION?)
and FUSE (FUSION?). Or something like that.
Roly Perera
----
Interactive Computers Ltd
3 Cumberland Road
Acton
London W3 6EX
Phone: +44 (956) 414 395
Phax: +44 (181) 932 2490
Email: ·····@private.nethead.co.uk
----
In article <·············@cochise.cs.berkeley.edu> Jay <········@cochise.cs.berkeley.edu> writes:
From: Jay <········@cochise.cs.berkeley.edu>
Newsgroups: comp.lang.scheme,comp.lang.lisp,comp.lang.misc,comp.lang.prolo
Date: Wed, 17 Jul 1996 18:43:56 -0700
Organization: UC Berkeley
Path: agate!usenet
Lines: 26
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 3.0b4 (X11; I; HP-UX A.09.05 9000/712)
Xref: agate comp.lang.scheme:16288 comp.lang.lisp:22170 comp.lang.misc:26383
·······@DSIBM.OKLADOT.STATE.OK.US wrote:
> I am new to this news group. I am writing a small program that would
> take a list and an atom as an argument and return the number of times th
> e atom is in the list:
> eg:(foo '(a b c a r) '(a)) rmany
> -> 2.
first, '(a) is not an atom... it is a list... 'a would be the atom that
you want.
> Is there a built-in function that would count the number of elements the
> atom has so that I would use a loop and use that number as my required
> iteration?
to count the number of items in a list there is a function defined
on our version of
scheme (berkeley scm) called count (i.e., count -list-) that
returns the number of
elements in the list, *however* this _is_ an extention for us, and
not in standard
scheme i believe (i couldnt find it in the on-line R4RS index).
The function in Common Lisp is 'count'. The function in Scheme is
bound to vary according the nth implementor of the latest improved
(and slightly incompatible) interpreter. :)
From dpANS in 'info' format taken from the GCL distribution:
===============================================================================
File: gcl.info, Node: count, Next: length, Prev: reduce, Up: Sequences Dictionary
count, count-if, count-if-not [Function]
---------------------------------------------------------------------------
`count' item sequence &key from-end start end key test test-not => n
`count-if' predicate sequence &key from-end start end key => n
`count-if-not' predicate sequence &key from-end start end key => n
Arguments and Values::
......................
item--an object.
sequence--a proper sequence.
predicate--a designator for a function of one argument that returns a
generalized boolean.
from-end--a generalized boolean. The default is false.
test--a designator for a function of two arguments that returns a
generalized boolean.
test-not--a designator for a function of two arguments that returns a
generalized boolean.
start, end--bounding index designators of sequence. The defaults for
start and end are 0 and nil, respectively.
key--a designator for a function of one argument, or nil.
n--a non-negative integer less than or equal to the length of sequence.
Description::
.............
count, count-if, and count-if-not count and return the number of elements
in the sequence bounded by start and end that satisfy the test.
The from-end has no direct effect on the result. However, if from-end is
true, the elements of sequence will be supplied as arguments to the test,
test-not, and key in reverse order, which may change the side-effects, if
any, of those functions.
Examples::
..........
(count #\a "how many A's are there in here?") => 2
(count-if-not #'oddp '((1) (2) (3) (4)) :key #'car) => 2
(count-if #'upper-case-p "The Crying of Lot 49" :start 4) => 2
Exceptional Situations::
........................
Should be prepared to signal an error of type type-error if sequence is
not a proper sequence.
See Also::
..........
*Note Rules about Test Functions::,
*Note Traversal Rules and Side Effects::
Notes::
.......
The :test-not argument is deprecated.
The function count-if-not is deprecated.
--
Marco Antoniotti - Resistente Umano
===============================================================================
International Computer Science Institute | ·······@icsi.berkeley.edu
1947 Center STR, Suite 600 | tel. +1 (510) 643 9153
Berkeley, CA, 94704-1198, USA | +1 (510) 642 4274 x149
===============================================================================
...it is simplicity that is difficult to make.
...e` la semplicita` che e` difficile a farsi.
Bertholdt Brecht
Marco Antoniotti wrote:
> From dpANS in 'info' format taken from the GCL distribution:
> [the rest cut b/c i dont understand it]
can somebody please decipher the previous message for me:
what is gcl? and is count in standard scheme?
thanks
jay
In article <·····················@DSIBM.OKLADOT.STATE.OK.US> ·······@DSIBM.OKLADOT.STATE.OK.US writes:
> I am writing a small program that would take a list and an atom
> as an argument and return the number of times the atom is in the
> list.
Here are some ways to do it in Common Lisp
(count 'a '(a b c a r))
(loop for x in '(a b c a r)
count (eq x 'a))
(length (remove 'a '(a b c a r) :test-not #'eql))
(length (remove 'a '(a b c a r) :test (complement #'eql)))
(length (remove-if-not #'(lambda (x) (eql x 'a))
'(a b c a r)))
(length (remove-if #'(lambda (x) (not (eql x 'a)))
'(a b c a r)))
(let ((n 0))
(dolist (x '(a b c a r))
(when (eq x 'a) (incf n)))
n)
(do ((n 0)
(l '(a b c a r) (cdr l)))
((not l) n)
(when (eq (car l) 'a) (incf n)))
Of course, Jay is right that '(a) is not an atom. But if you meant
to count any of a set of atoms, you might try:
(count-if #'(lambda (x) (member x '(a b)))
'(a b c a r))
=> 3
Of course, for the simple example you suggest, COUNT is what you
want. But I provide the others to illustrate some language features
you might want to read more about.
You can find an online reference to the Common Lisp language at
http://www.harlequin.com/books/HyperSpec/
Good luck!
Jakob Engblom wrote:
>
> Graham Matthews wrote:
> >
> > > I'm not at all sure I'd want a pure functional programming language:
>
> My experience is that recursive non-destructive programming is dead easy
> to learn, and that if you learn that first, going over to imperative,
> destructive, pointer-mangling languages is terribly PAINFUL.
But this actually might be an argument against learning functional/logic
programing first or even at all! Yes, these recursive system are powerful
and elegant but in the long time they've existed, they haven't been used
producing in a significant number of commercially sucessful products.
(This is a good yardstick to measure their usefulness because
commercial programmers really do want things that will make life easier for
us). Would that this weren't so. But it's is more than just prejudice.
As a C++/Windows programmer, I see functional/logic languages as
pleasant because they shield the programmers from the nitty-gritty of
memory management. But this same feature will always
be a problem for performance.
Always meaning forever.
Memory management is a hard problem and you no more likely to solve it
in general than you are to create a self-programming computers. Goedel's
theorem is standing between the specification of a program and the
efficient implementation of said specification. Applicative/logic
programming takes you closer to specification of the
program and further from its implementation.
One solution might be a language that seperates logic and memory management
but even this could be a problem. Imperative programmers simultaneously
choose memory management functions - like "new"ing a variable - and control
statement. While this is indeed messy, it forces the programmer to choose a
control structure with a reasonable memory management scheme along with it.
>
> A bunch of first-year students here first learnt real programming using ML,
> and then switchin to C was hard work...But is creating someone with prejudices similar to you doing them a favor?
What about when they out to find jobs in the "real world."
>
> It is all a matter of what you've learnt. In my experience, functional
> programming, recursion and higher-order programming is REALLY EASY, if only
> you HAVEN'T got any experience with unpure languages (like all imperative
> langugaes without garbage collection).I didn't really have that much trouble learning them even though I started
with c. But I can see how people would get caught in one mind-set or the other.
And it's really silly to get caught in one mindset.
I love pure functional/logic/object oriented languages, they give
someone a good idea of what they should be aiming for in their "real world"
code. But sadly these paradigms seem to have little chance of "catching on in
the real world."
Max
······@sirius.com
|One typpo per post guarenteed. The rest are bonuses!|
In article <·············@sirius.com> ······@sirius.com "Max Anger" writes:
> But this actually might be an argument against learning functional/logic
> programing first or even at all! Yes, these recursive system are powerful
> and elegant but in the long time they've existed, they haven't been used
> producing in a significant number of commercially sucessful products.
> (This is a good yardstick to measure their usefulness because
> commercial programmers really do want things that will make life easier for
> us). Would that this weren't so. But it's is more than just prejudice.
How many commercial functional languages are there for Windows?
You're implying that they're available, so if they, could you please
tell me about them?
> As a C++/Windows programmer, I see functional/logic languages as
> pleasant because they shield the programmers from the nitty-gritty of
> memory management. But this same feature will always
> be a problem for performance.
What performance problems are you refering to? If you're
comparing specific implementations, then please tell us
which ones you've used, and for which platforms. All of the
functional languages I've found that will run under DOS
or Win32 have been interpreted, but not all functional
languages are interpreted.
The choice of a language implementation is important, as
not all implementations of a language will give the same
performance for the same code. Not all functional languages
are equivalent, either. Some are intended more for research
than commercial development work.
Are you making a fair comparison, or just trying to prove
that we can't, in your opinion, use functional languages?
I'm more interested in getting the code written than any
programming ideology, so any tool that helps me will also
interest me. Unfortunately, the compiled functional languages
tend to be available for Unix, which I can't use (mainly
because I'm paid to develop for Windows, and not Unix).
Apparently, there are some Real World apps written in
functional languages, but they're not the kind that you're
likely to see running under Windows. Curiously, MS have
used a functional language for their ActiveVRML proposal,
so perhaps this may change. MS may be redefining their
definition of 'always'...
As I always like say, people use what they do _because they
can_. It won't matter what you or I think of it. Think about
how MS operate. If they want to use ActiveVRML, then they
will, regardless of what the VRML think of it. What will
count is what the people who use it will think of it, assuming
that some people _will_ use it. If MS push it, then I bet that
it'll get used by enough people, so the only question is will
MS push it, and how hard?
That's why I dislike 'advocacy' threads like this one so
much. It's good to debate these issues, but there tends to
be a great deal of misinformation - which often gets swiftly
challanged by people armed will CS papers. However, this
thread has at least been more interesting than many that I've
seen, even if that's not saying much. All of the arguments
made have been far better than average, in my experience of
'advocacy' threads.
No doubt this is due to the newsgroups that this thread is
crossposted to. ;)
--
<URL:http://www.enrapture.com/cybes/> You can never browse enough
I have it at last: 'And She Closed Her Eyes', by Stina Nordenstam
Max Anger <······@sirius.com> writes:
>As a C++/Windows programmer, I see functional/logic languages as
>pleasant because they shield the programmers from the nitty-gritty of
>memory management. But this same feature will always
>be a problem for performance.
>Always meaning forever.
>Memory management is a hard problem and you no more likely to solve it
>in general than you are to create a self-programming computers. Goedel's
>theorem is standing between the specification of a program and the
>efficient implementation of said specification. Applicative/logic
>programming takes you closer to specification of the
>program and further from its implementation.
Gosh how this takes me back to the arguments about why
high level languages would never take over from assembler.
Yes, memory management is hard. THAT'S WHY MOST PROGRAMMERS GET IT WRONG.
Obviously, you have some sort of "straw man" definition of "memory
management" and what it means to "solve" it.
If you have more modest goals, like "functions running as fast as or faster
than typical hand coded memory management, with no memory management errors
possible, and with small space overheads", then the problem has been solved
for some time.
Sisal has already been mentioned. I don't remember if Clean has or not,
but the Clean system that I use on a Mac has the zippiest IDE of any of
the programming languages I use there, and that IDE is written in Clean.
The point is, we human beings have small heads, short lives, and low
bandwidth. Every second we spend on programming memory management is
a second we _aren't_ spending on doing something useful. Programming
your own memory management makes about as much sense these days as
programming your own stack frames.
>I love pure functional/logic/object oriented languages, they give
>someone a good idea of what they should be aiming for in their "real world"
>code. But sadly these paradigms seem to have little chance of "catching on in
>the real world."
Largely because of FUD.
Take a look at the manual memory management required for OLE some time.
Then consider becoming an undertaker; it's less scary.
--
Fifty years of programming language research, and we end up with C++ ???
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.
Richard A. O'Keefe wrote:
>
> Max Anger <······@sirius.com> writes:
>
> >As a C++/Windows programmer, I see functional/logic languages as
> >pleasant because they shield the programmers from the nitty-gritty of
> >memory management. But this same feature will always
> >be a problem for performance.
>
> >Always meaning forever.
>
> >Memory management is a hard problem and you no more likely to solve it
> >in general than you are to create a self-programming computers. Goedel's
> >theorem is standing between the specification of a program and the
> >efficient implementation of said specification. Applicative/logic
> >programming takes you closer to specification of the
> >program and further from its implementation.
>
> Gosh how this takes me back to the arguments about why
> high level languages would never take over from assembler.1) I'm not saying that no abstraction is useful. Obviously
high level languages are an advance over assembler. But they were
able to beat assembler by not taking on the job of formulating the
algorythm.
2) The high level languages that won are those streamlined the decisions
people made while writing assembler. They didn't predent to make a big
chunk of hard choices for the programmer.
>
> Yes, memory management is hard. THAT'S WHY MOST PROGRAMMERS GET IT WRONG.Yes, they get it wrong but IN THE LARGE, they can get it much less wrong
than computers. Look at the state of "artificial intelligence."
> Obviously, you have some sort of "straw man" definition of "memory
> management" and what it means to "solve" it.
No, I have a totally general definition. Go from a logical specification of
a program's output - in 1st order logic - to a turing machine that satisfies
this output in the most efficient way. Hard problem, huh?
> If you have more modest goals, like "functions running as fast as or faster
> than typical hand coded memory management, with no memory management errors
> possible, and with small space overheads", then the problem has been solved
> for some time.Human programmers encounter problems that are in general hard (NP etc) but which
can be decomposed by knowledge of the program domain. (many sorting routines
spring to mind but there are many other seemingly easy but actually hard problems
out there. Programmers usually use their knowledge of the problem domain to choose
simple algorythm that will efficient - so their activity has little appeal for CS
professors.
Any system that puts the emphasis on specificying outcomes is going to
lose this advantage. It lead to frustration when a quick specification of problem
solution leads to an application whose speed scales exponentially.
>[snip references to other system - I don't have any knowledge of]
>
> The point is, we human beings have small heads, short lives, and low
> bandwidth. Every second we spend on programming memory management is
> a second we _aren't_ spending on doing something useful. You, there are some problems that may entirely boring but which human beings
do far better than computers. See above.
> Programming your own memory management makes about as much sense these
> days as programming your own stack frames.Yes, few programmers do their own large scale memory management BUT
when they program in c++, they are close enough to the specification
of the memory management to be able to choose a correct algorythm. (see
above reasoning) Also, using automatic variables, dynamic memory
management, and point is quite easy "on the small." Once you get to
a larger scale, you use good design, memory leak finders and other
tools to make sure that your structure works. I admit this structure
is clunky and requires people to actually understand things but
until you can create
>
> >I love pure functional/logic/object oriented languages, they give
> >someone a good idea of what they should be aiming for in their "real world"
> >code. But sadly these paradigms seem to have little chance of "catching on in
> >the real world."
>
> Largely because of FUD.If you assemble a single team to produce a superior product in
these languages, the FUD will quickly go in the direction of these
new lanaguages. The industry may not be wholely rational but isn't
moved by enertia either. C++ was spread by FUD - the prospect of language
that solved scaling problems was extremely appealing. And MS Windows
Smalltalk systems have been trying to get going since Win3.0 - with plenty
of hype but no commercial success.
> Take a look at the manual memory management required for OLE some time.
> Then consider becoming an undertaker; it's less scary.
A lot of this has to do with the over-head of having a system that integrates
with many language/system interfaces at once. But this is another one of
those problems that doesn't look like it's going away. If you find a
better way to solve it, I'm sure you'd be a hero all.
> --
> Fifty years of programming language research, and we end up with C++ ???
> Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.
"C++ is the worse programming language ever created, except for all the others"
Winston Churchill
Max
······@sirius.com
In article <·············@sirius.com>, Max Anger <······@sirius.com> wrote:
> As a C++/Windows programmer, I see functional/logic languages as
> pleasant because they shield the programmers from the nitty-gritty
> of memory management. But this same feature will always be a problem
> for performance.
>
> Always meaning forever.
This is true, if you assume that programmer time is plentiful and
costs nothing. But if your man hour budget is not unlimited, every
hour you spend futzing around with manual memory reclamation is an
hour that you can't spend improving the algorithms that are central
to the performance of your program.
Manual reclamation is just an optimization, and eventually nearly
everyone will see it as one that is rarely worth doing. Of course
it might still be popular in situations where programmer time is
virtually free. For example a deep space probe, where the cost of
programming is nothing compared to the cost of fuel.
I wouldn't be at all surprised if garbage collection becomes standard
in C++ one of these years. Of course it wouldn't be mandatory;
more likely it would be something you could choose, by declaration,
on a class by class basis.
-- Robert
Robert Munyer wrote:
>
> In article <·············@sirius.com>, Max Anger <······@sirius.com> wrote:
>
> > As a C++/Windows programmer, I see functional/logic languages as
> > pleasant because they shield the programmers from the nitty-gritty
> > of memory management. But this same feature will always be a problem
> > for performance.
> >
> > Always meaning forever.
>
> This is true, if you assume that programmer time is plentiful and
> costs nothing. But if your man hour budget is not unlimited, every
> hour you spend futzing around with manual memory reclamation is an
> hour that you can't spend improving the algorithms that are central
> to the performance of your program.
But what I am saying above is that memory management
WILL BE the the algorythm that is central to your program - if you work with the
typical sorts of programs people see in the field.
Everyone knows memory management will cost something. I'm saying that it will always
cost BIG. Some problems are hard - mathematics has taught us this. Memory management, IN
FULL GENERALITY, is one.
Show me a real life situation where you can optimize without having any control of the
memory management process. Show me anything outside of mathematical programming. Show me
a simple searching problem. Show me a window-management problem.
>
> Manual reclamation is just an optimization, and eventually nearly
> everyone will see it as one that is rarely worth doing. Everyone thinks it is useless because when you're deleting things as you go, it's easy
(and dangerous, with ways of getting around the danger using proper asserts).
When you have do deleting after the fact or when a dumb device is doing it, it suddenly
is a hard problem.
> Of course
> it might still be popular in situations where programmer time is
> virtually free. For example a deep space probe, where the cost of
> programming is nothing compared to the cost of fuel.See above
>
> I wouldn't be at all surprised if garbage collection becomes standard
> in C++ one of these years. Of course it wouldn't be mandatory;
> more likely it would be something you could choose, by declaration,
> on a class by class basis.That could work. But most programmers don't even use the reference-counted classes that
are out-there.
Another way to say my point is that C++ has the virtue of focusing some of a
programmer's limited attentions onto the question managing memory. It is quite possible
to program using automatic memory memanagement here but the focus on manual management
seems in practice to produce faster programs.
>
> -- RobertMax
······@sirius.com
Max Anger wrote:
>
>
> Show me a real life situation where you can optimize without having any control of the
> memory management process. Show me anything outside of mathematical programming. Show me
> a simple searching problem. Show me a window-management problem.
>
Well, we write compilers with a language that supports a fully automatic garbage collector.
The data structures we cope with are very complex, far too complex (in our opinion) to be
handled manually. Having a GC allows us to improve the structure significantly, achieving
a 3 fold performance improvement. Such a structure update would have been almost impossible
if we had to take care of the memory management implications ourselves.
Regards,
Darius
Macsyma has a MATLAB->Macsyma translation stream (and the obvious
interfaces for Macsyma.) So, for example, you can type
input_language:matlab;
and later
input-language=Macsyma [return]
or compile matlab programs or even just LOAD matlab files automagically.
Graham Matthews:
> > My experience is that recursive non-destructive programming is dead easy
> > to learn, and that if you learn that first, going over to imperative,
> > destructive, pointer-mangling languages is terribly PAINFUL.
Max Anger wrote:
> But this actually might be an argument against learning functional/logic
> programing first or even at all! Yes, these recursive system are powerful
> and elegant but in the long time they've existed, they haven't been used
> producing in a significant number of commercially sucessful products.
> (This is a good yardstick to measure their usefulness because
> commercial programmers really do want things that will make life easier for
> us). Would that this weren't so. But it's is more than just prejudice.
All the premises are fine, but I disagree with the conclusion. In other words I
agree that commercial programmers want to make their lives easier. I also
agree that functional languages have not been used significantly in a
commercial sense. But what can we conclude from this? Nothing. If these
commercial programmers wanted to make their lives easier why do so many
people use C++ when Smalltalk is much easier to use (of languages in that
vein)? Your argument ignores things like inertia in the market and in
products in the market. For example software houses tend to develop new
applications in the language they developed old applications in. Your
answer also ignores the general ignorance in programming circles about
what a functional language is and what they are capable of (this is not
meant as a criticism just a fact). Your answer also ignores the commercial
deals that go on to entrench certain products no matter what their
qualities.
graham
--
Democracy don't rule the world
You'd better get that in your head
This world is ruled by violence
But I guess that's better left unsaid
Max Anger wrote:
>
> I love pure functional/logic/object oriented languages, they give
> someone a good idea of what they should be aiming for in their "real world"
> code. But sadly these paradigms seem to have little chance of "catching on in
> the real world."
Have a look at Ericssons Erlang language. It's an absolutely wonderful
functional language using pattern matching for control structures and only
non-destructive assigment, garbage collection, ect... and it is used to
prgoram telephone exchanges and is tailored to high-reliability, real-time,
distributed systems. It clearly works, and a lot better than C++ at that.
http://www.ericsson.se/cslab/erlang/
http://www.ericsson.se/erlang/
And finally, I believe in using the added power of today's computers in
helping us programmers program.
/jakob
----------------------------------------------------------------------------
Jakob Engblom. Computer Science Student @ Uppsala University, Sweden
presently an ERASMUS exchange student in Stuttgart, Germany
email Uppsala: ·····@docs.uu.se
email Stuttgart: ········@tick.informatik.uni-stuttgart.de
homepage: http://www.csd.uu.se/~jakob
[Followups to comp.lang.misc]
In article <·············@sirius.com> Max Anger <······@sirius.com>
writes:
m> Show me a real life situation where you can optimize without having
m> any control of the memory management process. Show me anything
m> outside of mathematical programming. Show me a simple searching
m> problem. Show me a window-management problem.
- Something outside of mathematical programming:
3D Science Labs has a product that is some kind of CAD/CAM
application for Windows, written in C++, that uses garbage
collection.
- A searching problem:
I'm responsible for developing a piece of load-sharing software that
we use at Sun for a variety of tasks. The scheduling kernel (much
of whose job consists of searching for good candidate machines) is
written in Scheme (which is garbage collected), and must have very
high performance for our needs. It does.
- Window management:
You might want to look at Trestle, from Digital. It's an X11
toolkit written in Modula-3.
m> It is quite possible to program using automatic memory memanagement
m> here but the focus on manual management seems in practice to
m> produce faster programs.
This jars with your apparent ignorance of real-world garbage collected
software, as noted above.
<b
--
Let us pray:
What a Great System. ···@eng.sun.com
Please Do Not Crash. ···@serpentine.com
·····@P6 http://www.serpentine.com/~bos