i do agree that fortran is a pretty nice language for array mangling. still, you might want to note that two of the fastest molecular dynamics engines out in the wild at this point (NAMD and GROMACS) are (at least mostly) written in C. the gap between Fortran and "the rest" has mostly closed.
*mumble* _TWO_ heroes of the battle of Troy*mumble*
Re:I call this the LineOfView (as in PoV) Problem
on
Tim Bray Says RELAX
·
· Score: 1
Put differently: you want to be able to describe any graph, while XML is built on the tree structure. So obviously, you have to do something clever about the circles in your graph... that's why s-expression-based programming languages allow for recursion and non-local jumps. Since s-expressions and xml are (largely) equivalent, you're of course free to do so, though it's hairy to get right.
i once wrote a numerical simulator of weakly coupled harmonic oscillators. i started out writing it in python. when it got to the point that the simulations took days, i re-wrote it in c++. upon running it the first time, it exited within one second. i was a bit unsettled, that it did not complain about a segmentation fault or some other error condition, which i had expected for a first run. turns out it ran correctly. a relative speedup of about 10000. so yes, python is slow. and yes, you are right, the ability to re-write performance-critical parts in C/C++ is a great boon to python (though it's possible in most other languages as well).
on the other hand, i discovered that numerical code written in java can approach the speed of C/C++. the added bonus here (if you come from python-land, and using jython is an acceptable choice for you), is that you can call the time-intensive routines in a safe language, and without having to write any glue code. in the absence of other constraints, i would recommend that combo, if you want to script in python, but need performance in a cpu-bound environment.
it's actually very easy to get excellent performance out of java -- just use data structures as you
would use them in C:
use arrays, not array lists etc.
avoid memory allocation
avoid side effects (and make judicious use of the final qualifier)
use public static methods (which the compiler is happy to inline)
i'm currently using java to do classical molecular dynamics simulation (and statistical analyses
thereof: esra), and the speed (without any tweaking) is consistenly within a factor of two of
what i would get with C/C++. this is certainly not so with python (which, for my numerical problems,
turned out to be about four orders of magnitude slower).
YMMW, but mine is excellent... no more segfaults, dead-simple deployment, scriptability, eclipse
etc.
Then again, the filesystem is not "the system," it's only a small part of it. The user does not see the filesystem, he sees shapes on a screen, and he knows that by clicking on the right shapes and typing the correct strings, he can get some stuff computed and presented to him. So the user does not directly interact with the filesystem. He interacts with the (sic) User Interface. The UI in turn should provide him with the means to interact with the filesystem. Consequently, if you make the association UI-->desktop, which is the case for the default UI on many systems, the filesystem should be represented on the desktop.
As a result, I would like to point out that the place where information about the desktop is stored in a non-volatile manner is not the desktop. So if you say
"This is the desktop, it's the top level, well kinda, it's actually in/home/username/.kde/desktop [or c:\windows\desktop or even c:\windows\profiles\username\desktop\ ], but it's the top of your system. Under that is your hard drive... that is where the desktop is kept."
that's bound to confuse the user, because it's simply not true (although the "My Computer" thing on typical windows desktops suggests just that).
Also,
Speaking of teaching standardized file trees, you should note that/etc is where system-wide default configuration files belong. Unlike with your typical spare-time desktop RH-Linux box many users don't have the superuser privileges typically required for write permission outside ${HOME}.
"No more systems where programs store themselves anywhere!"
Speaking of this note that I personally am making heavy use of
./configure --prefix=${HOME}/packages
followed by placing the corresponding symbolic links or wrapper scripts in ${HOME}/bin etc. I for one greatly appreciate the fact that many programs can follow this simple instruction and know how to install themselves "anywhere" (given the right permissions).
this took place quite some time after the partitioning step (which, btw, i always do by hand as well). i think there was a menu which asked me if yaboot should be set up. having used bootX so far (i.e. being unfamiliar with yaboot), and being quite lazy after a satisfying installation, i went for it, and that did the job. never bothered to find out exactly what went wrong, so i guess the blame is on me. then again, your talking i386, i'm talking PPC.
Slashdot Mirror
i do agree that fortran is a pretty nice language for array mangling. still, you might want to note that two of the fastest molecular dynamics engines out in the wild at this point (NAMD and GROMACS) are (at least mostly) written in C. the gap between Fortran and "the rest" has mostly closed.
and vi vs. emacs, i hope.
*mumble* _TWO_ heroes of the battle of Troy*mumble*
Put differently: you want to be able to describe any graph, while XML is built on the tree structure. So obviously, you have to do something clever about the circles in your graph... that's why s-expression-based programming languages allow for recursion and non-local jumps. Since s-expressions and xml are (largely) equivalent, you're of course free to do so, though it's hairy to get right.
oops, got the jython link wrong. also, if you're into (CPU) performance, it might be useful to take a quick look at a relevant benchmark over at the great language shootout.
i once wrote a numerical simulator of weakly coupled harmonic oscillators. i started out writing it in python. when it got to the point that the simulations took days, i re-wrote it in c++. upon running it the first time, it exited within one second. i was a bit unsettled, that it did not complain about a segmentation fault or some other error condition, which i had expected for a first run. turns out it ran correctly. a relative speedup of about 10000. so yes, python is slow. and yes, you are right, the ability to re-write performance-critical parts in C/C++ is a great boon to python (though it's possible in most other languages as well).
on the other hand, i discovered that numerical code written in java can approach the speed of C/C++. the added bonus here (if you come from python-land, and using jython is an acceptable choice for you), is that you can call the time-intensive routines in a safe language, and without having to write any glue code. in the absence of other constraints, i would recommend that combo, if you want to script in python, but need performance in a cpu-bound environment.
it's actually very easy to get excellent performance out of java -- just use data structures as you would use them in C:
i'm currently using java to do classical molecular dynamics simulation (and statistical analyses thereof: esra), and the speed (without any tweaking) is consistenly within a factor of two of what i would get with C/C++. this is certainly not so with python (which, for my numerical problems, turned out to be about four orders of magnitude slower).
YMMW, but mine is excellent ... no more segfaults, dead-simple deployment, scriptability, eclipse
etc.
... and LSD, ironically enough comes from switzerland, though berkeley certainly played an important role.
indeed, thanks & sorry.
you can't overload the * operator.
Hecklebot
your print statement won't run (at least not with
any version of python i'm familiar with).
should read
print k, '->', v
cheers,
b.
hm. legal. calvary. charges.
is this getting to be a religious war?
too bad nobody got your point.
only one hydrogen atom of which is chemically available. in the absence of truly interesting developments, i guess methanol is the way to go.
cheers,
a professional
lol, young padawan. learn to spell before you troll the next time. if this is how you code, then good luck. cheers, b.
a programming book review that's talking about "object-orientated" programming?
or pdftex or \usepackage{times}
learn to spell, then learn to code.
cheers,
b.
as he said. you can make a reasonable argument for both sides. i would argue they should take the 0's, because then they have to remove less.
lol, mr. troll, you suck.
As a result, I would like to point out that the place where information about the desktop is stored in a non-volatile manner is not the desktop. So if you say
that's bound to confuse the user, because it's simply not true (although the "My Computer" thing on typical windows desktops suggests just that).Also,
this took place quite some time after the partitioning step (which, btw, i always do by hand as well). i think there was a menu which asked me if yaboot should be set up. having used bootX so far (i.e. being unfamiliar with yaboot), and being quite lazy after a satisfying installation, i went for it, and that did the job. never bothered to find out exactly what went wrong, so i guess the blame is on me. then again, your talking i386, i'm talking PPC.
no. although I'm primarily on NetBSD now.