On 01/11/2013 14:51, Dennis Lee Bieber wrote:
On Fri, 01 Nov 2013 03:25:03 +, Mark Lawrence
declaimed the following:
On 01/11/2013 02:27, William Ray Wing wrote:
supper computers
Somebody must have tough teeth, though thinking about it I recall people
eating bicycles :)
Was
On 01/11/2013 03:50, rusi wrote:
On Friday, November 1, 2013 4:29:35 AM UTC+5:30, Denis McMahon wrote:
My mistake, that was what Albert said, you were simply standing up for
him.
Please s/you/he/ in the lines of my previous post quoted above, and
accept my apologies for my mistake.
Heh! Ch
On 2013-11-01, William Ray Wing wrote:
> Actually, FORTRAN is probably responsible for more CPU cycles being
> executed even today than most other languages. If you think about
> the fact that most large scientific simulation codes (weather
> forecasting, combustion modeling, finite-element mode
On Friday, November 1, 2013 4:29:35 AM UTC+5:30, Denis McMahon wrote:
> My mistake, that was what Albert said, you were simply standing up for
> him.
> Please s/you/he/ in the lines of my previous post quoted above, and
> accept my apologies for my mistake.
Heh! Chill! Yeah there is some hamm
On Friday, November 1, 2013 8:55:03 AM UTC+5:30, Mark Lawrence wrote:
> On 01/11/2013 02:27, William Ray Wing wrote:
> > supper computers
> Somebody must have tough teeth, though thinking about it I recall people
> eating bicycles :)
You just have to be sufficiently non-vegetarian
http://en.wik
On 01/11/2013 02:27, William Ray Wing wrote:
supper computers
Somebody must have tough teeth, though thinking about it I recall people
eating bicycles :)
--
Python is the second best programming language in the world.
But the best has yet to be invented. Christian Tismer
Mark Lawrence
-
On Oct 31, 2013, at 1:17 PM, Neil Cerutti wrote:
> On 2013-10-31, rusi wrote:
>> On Thursday, October 31, 2013 8:50:27 PM UTC+5:30, Neil Cerutti wrote:
>>> wrote:
This suggests that Pascal went against established practice.
This is false. FORTRAN used = and that was a mistake caused by
On 30/10/2013 21:43, Albert van der Horst wrote:
FORTRAN used = and that was a mistake caused by the
language being hacked together haphazardly.
Groetjes Albert
Yes, just imagine the massive amount of research that they had to go on,
given that Alan Turing had written *THE* paper some 20 ye
On Thu, 31 Oct 2013 10:56:12 -0700, rusi wrote:
> On Thursday, October 31, 2013 11:20:52 PM UTC+5:30, Denis McMahon wrote:
>> On Thu, 31 Oct 2013 09:05:04 -0700, rusi wrote:
>> > If I say: "My uncle knows more about flying planes than the Wright
>> > brothers" am I disrespecting the Wright brothe
On Fri, Nov 1, 2013 at 4:56 AM, rusi wrote:
> On Thursday, October 31, 2013 11:20:52 PM UTC+5:30, Denis McMahon wrote:
>> On Thu, 31 Oct 2013 09:05:04 -0700, rusi wrote:
>> > If I say: "My uncle knows more about flying planes than
>> > the Wright brothers" am I disrespecting the Wright brothers??
On Thursday, October 31, 2013 11:20:52 PM UTC+5:30, Denis McMahon wrote:
> On Thu, 31 Oct 2013 09:05:04 -0700, rusi wrote:
> > If I say: "My uncle knows more about flying planes than
> > the Wright brothers" am I disrespecting the Wright brothers??
> No, but that's not what you said.
> What you s
On Thu, 31 Oct 2013 09:05:04 -0700, rusi wrote:
> On Thursday, October 31, 2013 8:50:27 PM UTC+5:30, Neil Cerutti wrote:
>> wrote:
>> > This suggests that Pascal went against established practice. This is
>> > false. FORTRAN used = and that was a mistake caused by the language
>> > being hacked t
On 2013-10-31, rusi wrote:
> On Thursday, October 31, 2013 8:50:27 PM UTC+5:30, Neil Cerutti wrote:
>> wrote:
>> > This suggests that Pascal went against established practice.
>> > This is false. FORTRAN used = and that was a mistake caused by
>> > the language being hacked together haphazardly.
>
On Thursday, October 31, 2013 8:50:27 PM UTC+5:30, Neil Cerutti wrote:
> wrote:
> > This suggests that Pascal went against established practice.
> > This is false. FORTRAN used = and that was a mistake caused by
> > the language being hacked together haphazardly.
> Respectfully, the designers of FO
On Thu, Oct 31, 2013 at 10:20 AM, Neil Cerutti wrote:
> On 2013-10-30, Albert van der Horst
> wrote:
>> This suggests that Pascal went against established practice.
>> This is false. FORTRAN used = and that was a mistake caused by
>> the language being hacked together haphazardly.
>
> Respectfull
On 2013-10-30, Albert van der Horst
wrote:
> This suggests that Pascal went against established practice.
> This is false. FORTRAN used = and that was a mistake caused by
> the language being hacked together haphazardly.
Respectfully, the designers of FORTRAN deserve more respect than
that charac
On Thu, Oct 31, 2013 at 8:43 AM, Albert van der Horst
wrote:
> In article ,
> Chris Angelico wrote:
>>Pascal tried to create a new operator, := to be read "becomes"...
>
> This suggests that Pascal went against established practice.
> This is false.
As acknowledged earlier in the thread, my "cr
In article ,
Chris Angelico wrote:
>On Sun, Oct 20, 2013 at 3:22 AM, rusi wrote:
>> The problem is that python is an imperative language and uses the '=' sign
>> for assignment. In math of course
>'=' stands for equality.
>
>Pascal tried to create a new operator, := to be read "becomes", to
>d
On 2013-10-21 15:55, David Robinow wrote:
> I wasn't aware that the interactive interpreter on Linux had
> features that the Windows version didn't. I'm curious what those
> features might be.
It's mostly the benefits that come from being built with the readline
library, meaning you get
- command
On Sat, Oct 19, 2013 at 4:35 PM, Terry Reedy wrote:
> On 10/19/2013 2:31 PM, Tim Chase wrote:
>>
>> On 2013-10-19 14:08, David Robinow wrote:
>>>
>>> On Sat, Oct 19, 2013 at 9:01 AM, Chris Angelico wrote:
You can try all these out in the interactive interpreter (you
probably have ID
On Sun, Oct 20, 2013 at 9:46 AM, Ned Deily wrote:
> In article
> ,
> Chris Angelico wrote:
>> Pascal tried to create a new operator, := to be read "becomes", to
>> deal with the whole equality-vs-assignment issue.
>
> Um, Pascal was just following the lead of ALGOL 60, roughly a decade earlier.
In article
,
Chris Angelico wrote:
> Pascal tried to create a new operator, := to be read "becomes", to
> deal with the whole equality-vs-assignment issue.
Um, Pascal was just following the lead of ALGOL 60, roughly a decade earlier.
--
Ned Deily,
n...@acm.org
--
https://mail.python.org/m
On Sun, Oct 20, 2013 at 3:22 AM, rusi wrote:
> The problem is that python is an imperative language and uses the '=' sign
> for assignment. In math of course '=' stands for equality.
Pascal tried to create a new operator, := to be read "becomes", to
deal with the whole equality-vs-assignment is
On Sun, Oct 20, 2013 at 6:50 AM, Terry Reedy wrote:
> On 10/19/2013 2:08 PM, David Robinow wrote:
>>
>> On Sat, Oct 19, 2013 at 9:01 AM, Chris Angelico wrote:
>>
>>> You can try all these out in the interactive interpreter (you probably
>>> have IDLE installed, which on Windows is rather nicer to
On Sun, Oct 20, 2013 at 7:35 AM, Terry Reedy wrote:
> Idle can recall previous input two different ways, by cursor or key. One can
> use the mouse to select where to edit. CP requires use of arrow keys to move
> the cursor around. Idle recall input *statements*. CP recalls input *lines*.
> Previou
On 10/19/2013 2:31 PM, Tim Chase wrote:
On 2013-10-19 14:08, David Robinow wrote:
On Sat, Oct 19, 2013 at 9:01 AM, Chris Angelico wrote:
You can try all these out in the interactive interpreter (you
probably have IDLE installed, which on Windows is rather nicer to
work with than the default int
On 10/19/2013 2:08 PM, David Robinow wrote:
On Sat, Oct 19, 2013 at 9:01 AM, Chris Angelico wrote:
You can try all these out in the interactive interpreter (you probably
have IDLE installed, which on Windows is rather nicer to work with
than the default interactive mode).
IDLE is cross-plat
On 2013-10-19 14:08, David Robinow wrote:
> On Sat, Oct 19, 2013 at 9:01 AM, Chris Angelico wrote:
>> You can try all these out in the interactive interpreter (you
>> probably have IDLE installed, which on Windows is rather nicer to
>> work with than the default interactive mode).
>
> IDLE is cr
On Sat, Oct 19, 2013 at 9:01 AM, Chris Angelico wrote:
> You can try all these out in the interactive interpreter (you probably
> have IDLE installed, which on Windows is rather nicer to work with
> than the default interactive mode).
IDLE is cross-platform. Could you explain why you say "on Wi
On Saturday, October 19, 2013 7:04:30 PM UTC+5:30, Scott Novinger wrote:
>
> My plan is to create several different programs that perform specific
> Algebraic
> operations. My boys are learning Algebra 2 and I thought it might be a fun
> way
> to help us all learn Algebra and programming toge
On Sun, Oct 20, 2013 at 12:34 AM, Scott Novinger wrote:
> I read the link on Handling Exceptions. The first bit of code worked for my
> purposes. I was able to reduce my number of lines of code significantly and
> my program works! Thank you all for your help solving this problem!
As you get a
On Saturday, October 19, 2013 8:37:01 AM UTC-4, Mark Lawrence wrote:
> On 19/10/2013 13:23, Scott Novinger wrote:
>
> > Hello.
>
> >
>
> > I've written a program for my kids to calculate arc length. I want to
> > include some error testing for value types entered that are something other
> >
On 19/10/2013 13:57, Roy Smith wrote:
On 10/19/13 8:23 AM, Scott Novinger wrote:
My goal is to make sure that the value entered for the radius is an integer
value.
In article ,
Ned Batchelder wrote:
First, radius is the result of input(), so it is
always a string, never an int.
input()
In article ,
Ned Batchelder wrote:
> On 10/19/13 8:57 AM, Roy Smith wrote:
> > On 10/19/13 8:23 AM, Scott Novinger wrote:
> >>> My goal is to make sure that the value entered for the radius is an
> >>> integer
> >>> value.
> > In article ,
> > Ned Batchelder wrote:
> >
> >> First, radius is
On 10/19/13 8:57 AM, Roy Smith wrote:
On 10/19/13 8:23 AM, Scott Novinger wrote:
My goal is to make sure that the value entered for the radius is an integer
value.
In article ,
Ned Batchelder wrote:
First, radius is the result of input(), so it is
always a string, never an int.
input() re
On Sat, Oct 19, 2013 at 11:57 PM, Roy Smith wrote:
> On 10/19/13 8:23 AM, Scott Novinger wrote:
>> > My goal is to make sure that the value entered for the radius is an integer
>> > value.
>
> In article ,
> Ned Batchelder wrote:
>
>> First, radius is the result of input(), so it is
>> always a
On Sat, Oct 19, 2013 at 11:23 PM, Scott Novinger wrote:
> # Create the variable for radius, "radius".
> print('Please enter the circle radius and press ENTER:')
> radius = input()
>
> # Check to make sure the entered value is an integer.
> if type(radius) != type(int):
>
On 10/19/13 8:23 AM, Scott Novinger wrote:
> > My goal is to make sure that the value entered for the radius is an integer
> > value.
In article ,
Ned Batchelder wrote:
> First, radius is the result of input(), so it is
> always a string, never an int.
input() returns ints or floats for valu
On 10/19/13 8:23 AM, Scott Novinger wrote:
Hello.
I've written a program for my kids to calculate arc length. I want to include
some error testing for value types entered that are something other than
integer values.
My goal is to make sure that the value entered for the radius is an integer
On 19/10/2013 13:23, Scott Novinger wrote:
Hello.
I've written a program for my kids to calculate arc length. I want to include
some error testing for value types entered that are something other than
integer values.
My goal is to make sure that the value entered for the radius is an integer
40 matches
Mail list logo
