Steven D'Aprano :
> 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 machine code on the fly using
> decorat
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
On 29 May 2014 14:06:47 GMT, Albert van der Horst wrote:
> In article ,
> Mark H Harris 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)
Chris Angelico :
> On Fri, May 30, 2014 at 12:50 AM, Marko Rauhamaa 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
>> ridicul
On Fri, May 30, 2014 at 12:50 AM, Marko Rauhamaa 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 dynamic that such
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,
In article <8761l9pi3n@elektro.pacujo.net>,
Marko Rauhamaa wrote:
>
>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. That
>would be
In article ,
Mark H Harris 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 quicker (and no less accurate
Ian Kelly 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 array computing. Numba
Marko Rauhamaa writes:
> Alain Ketterlin :
>
>> 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 perfo
Steven D'Aprano :
> 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 compiler here? I don't know.
On Wed, 14 May 2014 07:35:35 +0300, Marko Rauhamaa wrote:
> Steven D'Aprano :
>
>> 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.
Steven D'Aprano :
> 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 information on how well it perform
On Tue, May 13, 2014 at 6:10 PM, Steven D'Aprano
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/
>
> And it's predecessor: ht
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
http://import-that
Alain Ketterlin :
> 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 roadblocks for Python are:
Mark H Harris 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
> it looks like J
On 13/05/2014 12:21, Chris Angelico wrote:
On Tue, May 13, 2014 at 9:16 PM, Roy Smith 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 af
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
> > hav
On Tue, May 13, 2014 at 9:16 PM, Roy Smith 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 sometimes, b
In article <5371c834$0$11109$c3e8...@news.astraweb.com>,
Steven D'Aprano 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
because nobody knows
On Tue, May 13, 2014 at 8:44 PM, Rustom Mody 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 a dozen old ver
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 del
On Tue, May 13, 2014 at 7:34 PM, Steven D'Aprano 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
>> wrote:
>>> Self-modifying code is a nightmare inside the head of a Lovecraftian
>>> horror. There's a reason why almost the
On Tue, 13 May 2014 15:56:50 +1000, Chris Angelico wrote:
> On Tue, May 13, 2014 at 3:48 PM, Steven D'Aprano
> 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 writer
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 don
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),
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 cran
On Tue, May 13, 2014 at 3:48 PM, Steven D'Aprano 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 being buggy.
H
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 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 with
On Sun, 11 May 2014 20:14:14 -0400, Roy Smith wrote:
> In article ,
> MRAB 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 ,
>> >> Chris Angelico wrote:
>> >>
>> >>> Some things are more standardized than
On 2014-05-12, Steven D'Aprano 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 position
>>> to the lef
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 practices
Mark H Harris 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
>>> core. Its
On Mon, May 12, 2014 at 2:26 PM, Mark H Harris 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
--
https://mail.python.or
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
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 p
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,
>>> x=7071
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 thos
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
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
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
In article ,
MRAB 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 ,
> >> Chris Angelico wrote:
> >>
> >>> Some things are more standardized than others. A piano keyboard is
> >>> incredibly standard, to make it p
On Mon, 12 May 2014 04:08:15 +1000, Chris Angelico wrote:
> On Mon, May 12, 2014 at 3:51 AM, Roy Smith 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 ca
On 2014-05-12 00:15, Steven D'Aprano wrote:
On Sun, 11 May 2014 14:43:19 -0400, Roy Smith wrote:
In article ,
Chris Angelico 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 (eve
On Sun, 11 May 2014 14:43:19 -0400, Roy Smith wrote:
> In article ,
> Chris Angelico 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 around,
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 or
On Mon, May 12, 2014 at 4:54 AM, Mark H Harris 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
>> println(ata
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 num
In article ,
Chris Angelico 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 around, which
> doesn't happen as much on a computer keyboard)
Speaki
On Mon, May 12, 2014 at 4:05 AM, Ethan Furman 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
> excruciatingly importa
On 05/11/2014 10:51 AM, Roy Smith wrote:
In article <871tw0s2kl@elektro.pacujo.net>,
Marko Rauhamaa wrote:
Tomasz Rola :
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 g
On Mon, May 12, 2014 at 3:51 AM, Roy Smith 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 learning curve.
On Mon, May 12, 2014 at 4:04 AM, Tomasz Rola 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
--
https://mail
On Mon, May 12, 2014 at 02:42:13AM +1000, Chris Angelico wrote:
> On Mon, May 12, 2014 at 2:09 AM, Tomasz Rola 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 l
In article <871tw0s2kl@elektro.pacujo.net>,
Marko Rauhamaa wrote:
> Tomasz Rola :
>
> > 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 sci
Mark H Harris 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
> steroids. It
On Mon, May 12, 2014 at 2:09 AM, Tomasz Rola 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 major language
Tomasz Rola :
> 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 Fortran is succe
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/
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 sma
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 dynami
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 is
On 5/10/2014 9:42 AM, Roy Smith wrote:
In article ,
Dennis Lee Bieber wrote:
Obsolete and Legacy? Fortran still receives regular standards updates
(currently 2008, with the next revision due in 2015).
Ars Technica article a couple of days ago, about Fortran, and what is
likely to
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 int
On Sat, Feb 14, 2009 at 2:06 PM, tripp 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 something similar and
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 I
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
On Feb 13, 1:27 pm, MRAB 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
> > (www.gdal.or
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 li
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 func
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 o
-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 use
-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. :)
Furtherm
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.
--
http://ma
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
-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 c
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:
>
-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
REAL*8/
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
"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 f
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 la
"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.
>>
>> Sever
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'
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 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 c
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
--
ht
"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 care
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
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 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
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 im
Carl Banks wrote:
> On Mar 26, 10:11 am, "Andy Dingley" <[EMAIL PROTECTED]> wrote:
>
>>On 26 Mar, 14:20, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
>>
>>
>>>what are the advantages of using Python for
>>>creating number crunching apps over Fortran??
>>
>>If you have to ask, you've not experien
[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> 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
Incidentally, and a bit outside what you asked: if your "number
crunching" involves anything beyond linear
Cameron Laird <[EMAIL PROTECTED]> wrote:
...
> >If you're just trying to learn and check things out, it might be better
> >to get a more recent Python from python.org (2.5 or 2.4.4) and the
> >various other packages as and when you need them (you can use the
> >MacEnthon list as a guide:-). You
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 charge. The Python
> world is different from what experienc
On Mar 26, 10:31 am, "Carl Banks" <[EMAIL PROTECTED]> wrote:
> > You can write programs in Python that do usefully complicated things,
> > and you can get them to work in a reasonable time. Fortran can't do
> > this, for anything more than the trivial. "Classic" Fortran tasks of
> > the past are
On Mar 26, 9:06 am, stef <[EMAIL PROTECTED]> wrote:
> As said by others, "Portability, scalability & RAD" as an advantage of
> Python are probably far more important.
All of those claimed advantages can be debated, although they may
exist for some tasks.
(1) Portability. Fortran has been run on
On Mon, 26 Mar 2007 15:53:56 -0700, sturlamolden wrote:
> Python is a very high-level language. That means there are certain
> things that put constraint on the attained speed. Most importantly:
> keep the number of interpreter evals as scarce as possible. If you
> make a for loop, the interpreter
1 - 100 of 134 matches
Mail list logo
