In article lkoi5v$vfj$1...@speranza.aioe.org,
Mark H Harris harrismh...@gmail.com wrote:
On 5/11/14 1:59 PM, Chris Angelico wrote:
julia prec=524288
524288
julia with_bigfloat_precision(prec) do
println(atan(BigFloat(1)/5)*16 - atan(BigFloat(1)/239)*4)
end
Would it be
In article 8761l9pi3n@elektro.pacujo.net,
Marko Rauhamaa ma...@pacujo.net wrote:
SNIP
Producing an effective JIT for Python seems like a formidable challenge
but not impossible in principle. After all, the developer *could*
provide that static typing information in, like, 99.9% of the code.
alb...@spenarnc.xs4all.nl (Albert van der Horst):
I always thought that the real point of JIT was that it can take
advantage of type information that is not available until runtime. If
it can infer that something is an integer, just before entering a loop
to be executed millions of times,
On Fri, May 30, 2014 at 12:50 AM, Marko Rauhamaa ma...@pacujo.net wrote:
Python code, too, is compiled into interpreted bytecode. Again, you
could compile it into machine code ahead of execution or perform the
compilation on the fly with JIT techniques. However, Python is so
ridiculously
Chris Angelico ros...@gmail.com:
On Fri, May 30, 2014 at 12:50 AM, Marko Rauhamaa ma...@pacujo.net wrote:
Python code, too, is compiled into interpreted bytecode. Again, you
could compile it into machine code ahead of execution or perform the
compilation on the fly with JIT techniques.
On 29 May 2014 14:06:47 GMT, Albert van der Horst wrote:
In article lkoi5v$vfj$1...@speranza.aioe.org,
Mark H Harris harrismh...@gmail.com wrote:
On 5/11/14 1:59 PM, Chris Angelico wrote:
julia prec=524288
524288
julia with_bigfloat_precision(prec) do
On Thu, 29 May 2014 17:50:00 +0300, Marko Rauhamaa wrote:
alb...@spenarnc.xs4all.nl (Albert van der Horst):
I always thought that the real point of JIT was that it can take
advantage of type information that is not available until runtime. If
it can infer that something is an integer, just
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info:
You're talking as if this were only theoretical. It is not. The state
of the art in compiler techniques has advanced a lot since the old
days of the Pascal P-Machine. Parakeet, for example[2], compiles
numeric functions to optimized
On Wed, 14 May 2014 07:35:35 +0300, Marko Rauhamaa wrote:
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info:
On Tue, 13 May 2014 22:57:16 +0300, Marko Rauhamaa wrote:
Producing an effective JIT for Python seems like a formidable
challenge but not impossible in principle.
Or in
Steven D'Aprano st...@pearwood.info:
On Wed, 14 May 2014 07:35:35 +0300, Marko Rauhamaa wrote:
I'm having a hard time finding information on how well it performs wrt
Java, for example. Did PyPy truly find the Philosophers' Stone?
[...] do you mean, how does PyPy compare with insert name of
Marko Rauhamaa ma...@pacujo.net writes:
Alain Ketterlin al...@dpt-info.u-strasbg.fr:
The real nice thing that makes Julia a different language is the
optional static typing, which the JIT can use to produce efficient code.
It's the only meaningful difference with the current state of python.
Ian Kelly ian.g.ke...@gmail.com wrote:
Also numba, which is reminiscent of psyco, but with more features and
Python 3 support.
For numerical computing with NumPy, Numba tends to give performance
comparable to -O2 in C. This is because it is very easy to do type
inference in most scientific
On 5/13/14 12:48 AM, Steven D'Aprano wrote:
On Tue, 13 May 2014 00:33:47 -0500, Mark H Harris wrote:
there has to be a value add for scientists to move away from R or
Matlab, or from FORTRAN. Why go to the trouble? FORTRAN works well (its
fast too), and there are zillions of lines of code
On Tuesday 13 May 2014 01:48:43 Steven D'Aprano did opine
And Gene did reply:
On Tue, 13 May 2014 00:33:47 -0500, Mark H Harris wrote:
there has to be a value add for scientists to move away from R or
Matlab, or from FORTRAN. Why go to the trouble? FORTRAN works well
(its fast too), and
On Tue, 13 May 2014 02:31:14 -0400, Gene Heskett wrote:
People who write buggy self-modifying code aren't paying attention.
[...]
IMO, people who bad-mouth self-modifying code are folks who don't have
the patience to do it right, because stable self-modifying code CAN most
certainly be done.
On Tue, 13 May 2014 15:56:50 +1000, Chris Angelico wrote:
On Tue, May 13, 2014 at 3:48 PM, Steven D'Aprano st...@pearwood.info
wrote:
Self-modifying code is a nightmare inside the head of a Lovecraftian
horror. There's a reason why almost the only people still using self-
modifying code are
On Tue, May 13, 2014 at 7:34 PM, Steven D'Aprano st...@pearwood.info wrote:
On Tue, 13 May 2014 15:56:50 +1000, Chris Angelico wrote:
On Tue, May 13, 2014 at 3:48 PM, Steven D'Aprano st...@pearwood.info
wrote:
Self-modifying code is a nightmare inside the head of a Lovecraftian
horror.
On Tuesday, May 13, 2014 3:30:36 PM UTC+5:30, Chris Angelico wrote:
Actually, even the file system can do some of this to you. I was
checking lsof on one of my Linux systems a little while ago, and found
that I had half a dozen old versions of a program, all with the same
file name, all
On Tue, May 13, 2014 at 8:44 PM, Rustom Mody rustompm...@gmail.com wrote:
On Tuesday, May 13, 2014 3:30:36 PM UTC+5:30, Chris Angelico wrote:
Actually, even the file system can do some of this to you. I was
checking lsof on one of my Linux systems a little while ago, and found
that I had half
In article 5371c834$0$11109$c3e8...@news.astraweb.com,
Steven D'Aprano st...@pearwood.info wrote:
And after 15 years, I daresay that includes you.
Sometimes code is still running for 15 years because it's so wonderful
nobody has been able to come up with anything better. Sometimes it's
On Tue, May 13, 2014 at 9:16 PM, Roy Smith r...@panix.com wrote:
Sometimes code is still running for 15 years because it's so wonderful
nobody has been able to come up with anything better. Sometimes it's
because nobody knows how it works anymore and everybody is afraid to
touch it :-)
And
On Tuesday 13 May 2014 03:22:28 Steven D'Aprano did opine
And Gene did reply:
On Tue, 13 May 2014 02:31:14 -0400, Gene Heskett wrote:
People who write buggy self-modifying code aren't paying attention.
[...]
IMO, people who bad-mouth self-modifying code are folks who don't
have the
On 13/05/2014 12:21, Chris Angelico wrote:
On Tue, May 13, 2014 at 9:16 PM, Roy Smith r...@panix.com wrote:
Sometimes code is still running for 15 years because it's so wonderful
nobody has been able to come up with anything better. Sometimes it's
because nobody knows how it works anymore and
Mark H Harris harrismh...@gmail.com writes:
On 5/12/14 3:44 AM, Alain Ketterlin wrote:
When you are doing scientific computation, this overhead is
unacceptable, because you'll have zillions of computations to perform.
I'm still trying to sort that out. I have not tested this yet, but
Alain Ketterlin al...@dpt-info.u-strasbg.fr:
The real nice thing that makes Julia a different language is the
optional static typing, which the JIT can use to produce efficient code.
It's the only meaningful difference with the current state of python.
I'm guessing the two main performance
On Tue, 13 May 2014 22:57:16 +0300, Marko Rauhamaa wrote:
Producing an effective JIT for Python seems like a formidable challenge
but not impossible in principle.
Or in practice.
http://pypy.org/
And it's predecessor: http://psyco.sourceforge.net/
--
Steven D'Aprano
On Tue, May 13, 2014 at 6:10 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
On Tue, 13 May 2014 22:57:16 +0300, Marko Rauhamaa wrote:
Producing an effective JIT for Python seems like a formidable challenge
but not impossible in principle.
Or in practice.
http://pypy.org/
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info:
On Tue, 13 May 2014 22:57:16 +0300, Marko Rauhamaa wrote:
Producing an effective JIT for Python seems like a formidable challenge
but not impossible in principle.
Or in practice.
http://pypy.org/
I'm having a hard time finding
Mark H Harris harrismh...@gmail.com writes:
On 5/11/14 12:05 PM, Alain Ketterlin wrote:
Julia is Matlab and R, Python, Lisp, Scheme; all rolled together on
steroids. Its amazing as a dynamic language, and its fast, like
lightning fast as well as multiprocessing (parallel processing) at its
On 12/05/2014 03:28, Steven D'Aprano wrote:
On Mon, 12 May 2014 01:27:17 +0100, Mark Lawrence wrote:
On 12/05/2014 00:51, Steven D'Aprano wrote:
Cars are standardized -- there are basically two types, manuals and
automatics.
Sadly they can still go wrong due to modern engineering
On 2014-05-12, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote:
On Mon, 12 May 2014 00:51:01 +0100, MRAB wrote:
On 2014-05-12 00:15, Steven D'Aprano wrote:
The F and J keys have F and J printed on them instead of G and
K. They're also in slightly different positions, offset one
On Sun, 11 May 2014 20:14:14 -0400, Roy Smith wrote:
In article mailman.9900.1399852263.18130.python-l...@python.org,
MRAB pyt...@mrabarnett.plus.com wrote:
On 2014-05-12 00:15, Steven D'Aprano wrote:
On Sun, 11 May 2014 14:43:19 -0400, Roy Smith wrote:
In article
On 5/12/14 3:44 AM, Alain Ketterlin wrote:
multiple-dispatch (i.e., dynamically testing types, converting to a
common type, and selecting the version of sqrt to use). That's probably
more than the time it takes to actually perform the computation, a bit
like what happens with x+y on integers
On Tue, 13 May 2014 00:33:47 -0500, Mark H Harris wrote:
there has to be a value add for scientists to move away from R or
Matlab, or from FORTRAN. Why go to the trouble? FORTRAN works well (its
fast too), and there are zillions of lines of code cranking away on huge
linear arrays. Enter
On Tue, May 13, 2014 at 3:48 PM, Steven D'Aprano st...@pearwood.info wrote:
Self-modifying code is a nightmare inside the head of a Lovecraftian
horror. There's a reason why almost the only people still using self-
modifying code are virus writers, and the viruses they create are
notorious for
On 5/10/14 8:42 AM, Roy Smith wrote:
Ars Technica article a couple of days ago, about Fortran, and what is
likely to replace it:
http://tinyurl.com/mr54p96
uhm, yeeah!
'Julia' is going to give everyone a not so small run for competition;
justifiably so, not just against FORTRAN.
Julia
On Sunday, May 11, 2014 11:47:55 AM UTC+5:30, Mark H. Harris wrote:
'Julia' is going to give everyone a not so small run for competition;
justifiably so, not just against FORTRAN.
Julia is Matlab and R, Python, Lisp, Scheme; all rolled together on
steroids. Its amazing as a dynamic
On Sun, 11 May 2014 01:17:55 -0500, Mark H Harris wrote:
On 5/10/14 8:42 AM, Roy Smith wrote:
Ars Technica article a couple of days ago, about Fortran, and what is
likely to replace it:
http://tinyurl.com/mr54p96
uhm, yeeah!
'Julia' is going to give everyone a not so small run for
On Sun, May 11, 2014 at 07:09:27AM +, Steven D'Aprano wrote:
On Sun, 11 May 2014 01:17:55 -0500, Mark H Harris wrote:
On 5/10/14 8:42 AM, Roy Smith wrote:
Ars Technica article a couple of days ago, about Fortran, and what is
likely to replace it:
http://tinyurl.com/mr54p96
Tomasz Rola rto...@ceti.pl:
Given that Fortran is here for almost 60 years and lot of effort has
been spent to keep it backwards compatible (AFAIK), I wouldn't hold my
breath.
I have seen a glimpse of the so-called scientific computing and Fortran
programming. I can't help but think that
On Mon, May 12, 2014 at 2:09 AM, Tomasz Rola rto...@ceti.pl wrote:
Given that Fortran is here for almost 60 years and lot of effort has
been spent to keep it backwards compatible (AFAIK), I wouldn't hold my
breath. Something may look like cool and great, but wait ten years and
see if after
Mark H Harris harrismh...@gmail.com writes:
On 5/10/14 8:42 AM, Roy Smith wrote:
http://tinyurl.com/mr54p96
'Julia' is going to give everyone a not so small run for competition;
justifiably so, not just against FORTRAN.
Julia is Matlab and R, Python, Lisp, Scheme; all rolled together on
In article 871tw0s2kl@elektro.pacujo.net,
Marko Rauhamaa ma...@pacujo.net wrote:
Tomasz Rola rto...@ceti.pl:
Given that Fortran is here for almost 60 years and lot of effort has
been spent to keep it backwards compatible (AFAIK), I wouldn't hold my
breath.
I have seen a glimpse
On Mon, May 12, 2014 at 02:42:13AM +1000, Chris Angelico wrote:
On Mon, May 12, 2014 at 2:09 AM, Tomasz Rola rto...@ceti.pl wrote:
Given that Fortran is here for almost 60 years and lot of effort has
been spent to keep it backwards compatible (AFAIK), I wouldn't hold my
breath. Something
On Mon, May 12, 2014 at 4:04 AM, Tomasz Rola rto...@ceti.pl wrote:
And the pipe
extention is one of the things I'd consider - as well as other
similar means, like SOAP or REST.
Yep. My point was, keep the processes separate and it's easy. There
are myriad ways of doing the glue.
ChrisA
--
On Mon, May 12, 2014 at 3:51 AM, Roy Smith r...@panix.com wrote:
It is fine. Computers are tools. The sign of a good tool is that you
can pick it up and use it without having to read the instruction manual.
I can jump into pretty much any car, start the engine, and drive it,
without any
On 05/11/2014 10:51 AM, Roy Smith wrote:
In article 871tw0s2kl@elektro.pacujo.net,
Marko Rauhamaa ma...@pacujo.net wrote:
Tomasz Rola rto...@ceti.pl:
Given that Fortran is here for almost 60 years and lot of effort has
been spent to keep it backwards compatible (AFAIK), I wouldn't hold
On Mon, May 12, 2014 at 4:05 AM, Ethan Furman et...@stoneleaf.us wrote:
For the most part cars are very similar, yet in some circumstances (such as
a vehicle in front of you suddenly stopping) the exact details (such as the
precise location and size and shape of the brake pedal) become
In article mailman.9891.1399833209.18130.python-l...@python.org,
Chris Angelico ros...@gmail.com wrote:
Some things are more standardized than others. A piano keyboard is
incredibly standard, to make it possible to play without having to
look at your fingers (even when jumping your hands
On 5/11/14 12:05 PM, Alain Ketterlin wrote:
Julia is Matlab and R, Python, Lisp, Scheme; all rolled together on
steroids. Its amazing as a dynamic language, and its fast, like
lightning fast as well as multiprocessing (parallel processing) at its
core. Its astounding, really.
Hmmm...
Its
On Mon, May 12, 2014 at 4:54 AM, Mark H Harris harrismh...@gmail.com wrote:
The following code will produce over 100,000 digits of π (pi) in less than 2
seconds on a low-end processor, like my mac mini dual core 2Ghz:
julia prec=524288
524288
julia with_bigfloat_precision(prec) do
On 5/11/14 1:59 PM, Chris Angelico wrote:
julia prec=524288
524288
julia with_bigfloat_precision(prec) do
println(atan(BigFloat(1)/5)*16 - atan(BigFloat(1)/239)*4)
end
Would it be quicker (and no less accurate) to represent pi as
atan(BigFloat(1))*4 instead? That's how I
On Sun, 11 May 2014 14:43:19 -0400, Roy Smith wrote:
In article mailman.9891.1399833209.18130.python-l...@python.org,
Chris Angelico ros...@gmail.com wrote:
Some things are more standardized than others. A piano keyboard is
incredibly standard, to make it possible to play without having to
On 2014-05-12 00:15, Steven D'Aprano wrote:
On Sun, 11 May 2014 14:43:19 -0400, Roy Smith wrote:
In article mailman.9891.1399833209.18130.python-l...@python.org,
Chris Angelico ros...@gmail.com wrote:
Some things are more standardized than others. A piano keyboard is
incredibly standard, to
On Mon, 12 May 2014 04:08:15 +1000, Chris Angelico wrote:
On Mon, May 12, 2014 at 3:51 AM, Roy Smith r...@panix.com wrote:
It is fine. Computers are tools. The sign of a good tool is that you
can pick it up and use it without having to read the instruction
manual. I can jump into pretty
In article mailman.9900.1399852263.18130.python-l...@python.org,
MRAB pyt...@mrabarnett.plus.com wrote:
On 2014-05-12 00:15, Steven D'Aprano wrote:
On Sun, 11 May 2014 14:43:19 -0400, Roy Smith wrote:
In article mailman.9891.1399833209.18130.python-l...@python.org,
Chris Angelico
On 12/05/2014 00:51, Steven D'Aprano wrote:
Cars are standardized -- there are basically two types, manuals and
automatics.
Sadly they can still go wrong due to modern engineering practices. In
my neck of the woods some years ago people were killed when standing at
a bus stop, because the
On Mon, 12 May 2014 00:51:01 +0100, MRAB wrote:
On 2014-05-12 00:15, Steven D'Aprano wrote:
On Sun, 11 May 2014 14:43:19 -0400, Roy Smith wrote:
Speaking of which, here's a trivia question. Without looking at your
keyboard, describe how the F and J keys (assuming a US-English key
layout)
On Mon, 12 May 2014 01:27:17 +0100, Mark Lawrence wrote:
On 12/05/2014 00:51, Steven D'Aprano wrote:
Cars are standardized -- there are basically two types, manuals and
automatics.
Sadly they can still go wrong due to modern engineering practices. In
my neck of the woods some years ago
On 05/11/2014 09:11 PM, Steven D'Aprano wrote:
On Mon, 12 May 2014 00:51:01 +0100, MRAB wrote:
Certainly not. However they may be different where *you* are :-P
I'm using an IBM keyboard, model SK-8820.
Mine have an little ridge on the keytop of those keys.
I've seen keyboards with
On 05/11/2014 02:54 PM, Mark H Harris wrote:
julia sin(BigFloat(π/4))
7.0710678118654750275194295621751674626154323953749278952436611913748
20215180412e-01 with 256 bits of precision
That answer doesn't seem to come anywhere near 256 bits of precision.
Using Python 3.2,
On 5/11/14 10:10 PM, Dave Angel wrote:
On 05/11/2014 02:54 PM, Mark H Harris wrote:
julia sin(BigFloat(π/4))
7.0710678118654750275194295621751674626154323953749278952436611913748
20215180412e-01 with 256 bits of precision
That answer doesn't seem to come anywhere near 256 bits of
On 5/11/14 11:10 PM, Mark H Harris wrote:
On 5/11/14 10:10 PM, Dave Angel wrote:
On 05/11/2014 02:54 PM, Mark H Harris wrote:
julia sin(BigFloat(π/4))
7.0710678118654750275194295621751674626154323953749278952436611913748
20215180412e-01 with 256 bits of precision
That answer doesn't
On Mon, May 12, 2014 at 2:26 PM, Mark H Harris harrismh...@gmail.com wrote:
Having said that, the accuracy was not my point; in the first place. My
point is that the sin() function is built-in...
So what? Built-in just means that there's no namespacing of
mathematical functions.
ChrisA
--
On 5/10/2014 9:42 AM, Roy Smith wrote:
In article mailman.9805.1399597367.18130.python-l...@python.org,
Dennis Lee Bieber wlfr...@ix.netcom.com wrote:
Obsolete and Legacy? Fortran still receives regular standards updates
(currently 2008, with the next revision due in 2015).
Ars
OK. It sounds like it would be easiest for me, then, to dump the
arrays to a binary file (much faster than dumping it to a text) from
the fortran program. Then use f2py to load a fortran module to read
it.?.
How well does python handle binary files? Maybe I could skit the f2py
all together if
On Sat, Feb 14, 2009 at 2:06 PM, tripp trippl...@gmail.com wrote:
OK. It sounds like it would be easiest for me, then, to dump the
arrays to a binary file (much faster than dumping it to a text) from
the fortran program. Then use f2py to load a fortran module to read
it.?.
I've done
tripp wrote:
... dump the arrays to a binary file (much faster than dumping it to a text)
from the fortran program
How well does python handle binary files? Maybe I could skit the f2py
all together if I can get python to read the fortran binary file...
Likely your best plan. Look
tripp wrote:
Hello Folks,
I have a fortran program I use to process several satellite images. I
currently output the results to a text file (~750 mb) which is then
read by a perl program that outputs a GIS-ready image using GDAL
(www.gdal.org). There are python libraries for GDAL too.
I'd
On Feb 13, 1:27 pm, MRAB goo...@mrabarnett.plus.com wrote:
tripp wrote:
Hello Folks,
I have a fortran program I use to process several satellite images. I
currently output the results to a text file (~750 mb) which is then
read by a perl program that outputs a GIS-ready image using GDAL
On 2009-02-13 11:59, tripp wrote:
Hello Folks,
I have a fortran program I use to process several satellite images. I
currently output the results to a text file (~750 mb) which is then
read by a perl program that outputs a GIS-ready image using GDAL
(www.gdal.org). There are python libraries
Jeroen Ruigrok van der Werven wrote:
I got someone who asked me to make changes in an old Fortran program she is
using for some calculations.
Why convert? Modern Fortran is an object oriented, structured language
with the singular advantage that it can run old Fortran programs.
--
-On [20080105 11:21], [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:
Why convert? Modern Fortran is an object oriented, structured language
with the singular advantage that it can run old Fortran programs.
With all due respect to Fortran but I find the syntax to be utterly
horrendous. :)
-On [20080104 19:21], Dennis Lee Bieber ([EMAIL PROTECTED]) wrote:
If the FORTRAN is using single precision reals, I'd expect a
slow-down in Python just on that alone, as Python uses doubles as the
only float type. There is also the overhead of object access for each.
In this case it uses
Jeroen Ruigrok van der Werven wrote:
-On [20080104 19:21], Dennis Lee Bieber ([EMAIL PROTECTED]) wrote:
If the FORTRAN is using single precision reals, I'd expect a
slow-down in Python just on that alone, as Python uses doubles as the
only float type. There is also the overhead of object
On Jan 4, 2:21 pm, Jeroen Ruigrok van der Werven [EMAIL PROTECTED]
nomine.org wrote:
I got someone who asked me to make changes in an old Fortran program she is
using for some calculations.
The calculations are pretty standard aside from 2 calls to DLINCG (an IMSL
numerical_libraries function
-On [20080104 14:22], Jeroen Ruigrok van der Werven ([EMAIL PROTECTED]) wrote:
What I wonder about, does anybody have a Fortran to Python conversion page
somewhere to map some of the basic types to Python equivalents?
Just to share my own ideas:
Seems
COMPLEX*16/complex*16 ~= complex
-On [20080104 15:56], Robin Becker ([EMAIL PROTECTED]) wrote:
you probably want to look at numpy an extension that handles lots of matrix
things with great ease. I think it now lives at http://scipy.org/
Yeah, I am aware of SciPy/NumPy, but aside from these two calls to do this
inverse matrix
Jeroen Ruigrok van der Werven wrote:
-On [20080104 14:22], Jeroen Ruigrok van der Werven ([EMAIL PROTECTED]) wrote:
What I wonder about, does anybody have a Fortran to Python conversion page
somewhere to map some of the basic types to Python equivalents?
Just to share my own ideas:
Seems
Jeroen Ruigrok van der Werven wrote:
I got someone who asked me to make changes in an old Fortran program she is
using for some calculations.
The calculations are pretty standard aside from 2 calls to DLINCG (an IMSL
numerical_libraries function to calculate an inverse matrix).
What I
Steven D'Aprano [EMAIL PROTECTED] wrote:
On Mon, 26 Mar 2007 06:40:49 -0700, kyosohma wrote:
Fortran also appears to be a compiled language, whereas Python is an
interpreted language.
Sheesh. Do Java developers go around telling everybody that Java is an
interpreted language? I don't think
Beliavsky [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
On Mar 26, 10:16 am, [EMAIL PROTECTED] (Cameron Laird) wrote:
In article
[EMAIL PROTECTED],[EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
Is there a mac version??
Thanks
Chris
Yes.
Several, in fact--all available at no
I feel obligated to fan the flames a bit by pointing to
http://www.fortranstatement.com/ a site which advocates discontinuing
development of Fortran and does a good job of summarizing the problems
with the contemporary development of that language.
I am not convinced that a new high performance
Tim Roberts [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
| Well, I'm being a bit argumentative here, but it's hard to deny that the
| use of compiled in the context of .pyc (or .javac) is very different
from
| the use of compiled in the context of running gcc.
Besides the fact
Terry Reedy wrote:
Tim Roberts [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
| Once upon a time,
| Basic enthusiasts would have used the word tokenized to describe .pyc
files.
Perhaps, but they would, I think, have been wrong. Tokenized Basic to the
best of my knowledge,
In article [EMAIL PROTECTED],
Beliavsky [EMAIL PROTECTED] wrote:
.
.
.
Your experience with Fortran is dated -- see below.
I'll be more clear: Fortran itself is a distinguished
language with many meritorious
On Mar 26, 12:59 pm, Erik Johnson [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
OK...
I've been told that Both Fortran and Python are easy to read, and are
quite useful in creating scientific apps for the number crunching, but
then Python is a tad
Mark Morss wrote:
Maybe somebody reading this will be able to convince me to look again
at Numpy/Scipy, but for the time being I will continue to do my
serious numerical computation in Fortran.
What I am missing in this discussion is a link to Pyrex to speed up
Python: Pyrex is almost
On Mar 27, 12:55 pm, Jaap Spies [EMAIL PROTECTED] wrote:
Mark Morss wrote:
Maybe somebody reading this will be able to convince me to look again
at Numpy/Scipy, but for the time being I will continue to do my
serious numerical computation in Fortran.
What I am missing in this discussion
Steven D'Aprano [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Sheesh. Do Java developers go around telling everybody that Java is an
interpreted language? I don't think so.
What do you think the c in .pyc files stands for? Cheese?
On the contrary... Sun is very careful to make
In [EMAIL PROTECTED], Mark Morss
wrote:
Well, the discussion was about Python vs. Fortran, and Pyrex, as I
understand it, is a tool for linking C to Python.
I think it's more than that. It's more a subset of Python with a little
static typing.
Ciao,
Marc 'BlackJack' Rintsch
--
On Mar 27, 6:32 am, [EMAIL PROTECTED] (Cameron Laird) wrote:
In article [EMAIL PROTECTED],Beliavsky [EMAIL PROTECTED] wrote:
.
.
.
Your experience with Fortran is dated -- see below.
I'll be more clear: Fortran
On Tue, 27 Mar 2007 12:11:01 -0600, Erik Johnson wrote:
But seriously... I'm not a language or architecture guru. Is there any
real difference between a JVM and an interpreter? I mean, I have some
general feel that bytecode is a lower-level, more direct and more efficient
thing to be
On 26 Mar 2007 06:20:32 -0700, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
OK...
I've been told that Both Fortran and Python are easy to read, and are
Python is hugely easier to read.
quite useful in creating scientific apps for the number crunching, but
then Python is a tad slower than Fortran
On Mar 26, 8:20 am, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
OK...
I've been told that Both Fortran and Python are easy to read, and are
quite useful in creating scientific apps for the number crunching, but
then Python is a tad slower than Fortran because of its a high level
language
On Mar 26, 9:20 am, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
OK...
I've been told that Both Fortran and Python are easy to read, and are
quite useful in creating scientific apps for the number crunching, but
then Python is a tad slower than Fortran because of its a high level
language
On Mar 26, 3:20 pm, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
OK...
I've been told that Both Fortran and Python are easy to read, and are
quite useful in creating scientific apps for the number crunching, but
then Python is a tad slower than Fortran because of its a high level
language
On Mar 26, 2:42 pm, Jean-Paul Calderone [EMAIL PROTECTED] wrote:
On 26 Mar 2007 06:20:32 -0700, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
OK...
I've been told that Both Fortran and Python are easy to read, and are
Python is hugely easier to read.
quite useful in creating scientific apps
On 26 Mar 2007 06:47:18 -0700, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
On Mar 26, 2:42 pm, Jean-Paul Calderone [EMAIL PROTECTED] wrote:
On 26 Mar 2007 06:20:32 -0700, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
OK...
I've been told that Both Fortran and Python are easy to read, and are
You can get the speed of fortran in Python by using libraries like
Numeric without losing the readability of Python.
Can you back this up with some source??
Chris
Is this really the most important issue in your choice ?
As said by others, Portability, scalability RAD as an
1 - 100 of 133 matches
Mail list logo
