On Wednesday, August 13, 2014 12:59:35 AM UTC+5:30, Neil D. Cerutti wrote:
> > Some things follow from this:
> > For the lego-game of playing with functions at the REPL to work and be
> > pleasant and rewarding:
> > 1. functions should be non side-effecting; else same trials giving different
> > a
Steven D'Aprano wrote:
[...]
> I am using "abstract" in the sense of an abstraction, as opposed to
> something concrete and real, not as a mechanism for specifying interfaces
> in Java or Python. Python's float is a leaky abstraction of mathematical
> Real numbers, and Python's softed() is a leaky
On Wed, Aug 13, 2014 at 12:11 PM, Steven D'Aprano
wrote:
> both leak
> because the implementation of the abstraction spoils the abstraction.
Can you name *any* nontrivial abstraction that doesn't leak? I can't.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Rustom Mody wrote:
> I guess part of the problem is that evidently you and I use 'concrete'
> and 'abstract' in almost diametrically opposite ways.
[...]
> But now you are turning the tables and saying that the FP types/constructs
> are more abstract than the conventional ones.
[...]
> In my book,
On Wed, Aug 13, 2014 at 11:45 AM, Roy Smith wrote:
> In article ,
> Chris Angelico wrote:
>
>> I like to look at SQL as a language that specifies an end result
>> without specifying how to get there
>
> Well, sure, but sometimes the how to get there is a matter of 10x, or
> 100x, or 1000x in per
In article ,
Chris Angelico wrote:
> I like to look at SQL as a language that specifies an end result
> without specifying how to get there
Well, sure, but sometimes the how to get there is a matter of 10x, or
100x, or 1000x in performance.
I'm currently migrating a 3 TB database to a new 5
On Wed, Aug 13, 2014 at 10:47 AM, Steven D'Aprano
wrote:
> Chris Angelico wrote:
>
>> On Mon, Aug 11, 2014 at 7:44 PM, Steven D'Aprano
>> wrote:
>>> I think this is why both declarative and functional programming idioms
>>> will remain niche (although important niches). Most tasks are inherently
Chris Angelico wrote:
> On Mon, Aug 11, 2014 at 7:44 PM, Steven D'Aprano
> wrote:
>> I think this is why both declarative and functional programming idioms
>> will remain niche (although important niches). Most tasks are inherently
>> imperative to at least some degree, and often a *great* degree
On 8/12/2014 1:40 PM, Neil D. Cerutti wrote:
I disagree. For a beginner, you want to be able to break things down
into individual steps and examine the result at each point. If you do:
l= [6,2,9,12,1,4]
l2 = sorted(l,reverse=True)
you have the advantage that you can stop after creating l2 a
On 8/12/2014 2:20 PM, Rustom Mody wrote:
On Tuesday, August 12, 2014 11:10:48 PM UTC+5:30, Neil D. Cerutti wrote:
Beginners are particularly poor, in relation to experts, at noticing the
applicability of idea, and at combining ideas together. Breaking things
into component parts has multiple ben
On 12/08/2014 19:45, alister wrote:
On Tue, 12 Aug 2014 23:39:42 +1000, Chris Angelico wrote:
On Tue, Aug 12, 2014 at 8:40 PM, alister
wrote:
On Tue, 12 Aug 2014 00:21:28 -0700, wxjmfauth wrote:
[ chomp ]
Mathematicians work with numbers (Algebra is a abstraction of numerical
concepts) strin
On Tue, 12 Aug 2014 23:39:42 +1000, Chris Angelico wrote:
> On Tue, Aug 12, 2014 at 8:40 PM, alister
> wrote:
>> On Tue, 12 Aug 2014 00:21:28 -0700, wxjmfauth wrote:
>> [ chomp ]
>>
>> Mathematicians work with numbers (Algebra is a abstraction of numerical
>> concepts) strings are concerned with
On Tuesday, August 12, 2014 11:10:48 PM UTC+5:30, Neil D. Cerutti wrote:
> On 8/10/2014 2:14 PM, Roy Smith wrote:
> > Rustom Mody wrote:
> > l= [6,2,9,12,1,4]
> > sorted(l,reverse=True)[:5]
> >> [12, 9, 6, 4, 2]
> >> No need to know how sorted works nor [:5]
> >> Now you (or Steven) can
On 8/10/2014 2:14 PM, Roy Smith wrote:
In article <154cc342-7f85-4d16-b636-a1a953913...@googlegroups.com>,
Rustom Mody wrote:
l= [6,2,9,12,1,4]
sorted(l,reverse=True)[:5]
[12, 9, 6, 4, 2]
No need to know how sorted works nor [:5]
Now you (or Steven) can call it abstract.
And yet its
1. A
On Tue, Aug 12, 2014 at 8:40 PM, alister
wrote:
> On Tue, 12 Aug 2014 00:21:28 -0700, wxjmfauth wrote:
> [ chomp ]
>
> Mathematicians work with numbers (Algebra is a abstraction of numerical
> concepts) strings are concerned with characters (Arabic numerals are just
> characters commonly used to r
On Tue, 12 Aug 2014 00:21:28 -0700, wxjmfauth wrote:
> Math:
>
> Try to formalize with mathematics the Flexible String Representation.
> You should quickly realize, it is a logical mathematical absurdity.
> Unbelievable.
>
> jmf
Mathematicians work with numbers (Algebra is a abstraction of nume
On Tue, Aug 12, 2014 at 12:32 AM, Robin Becker wrote:
> Of course Python can be even more confusing so that for example
>
class NeverEqual(int):
> ... def __new__(cls,v):
> ... self = int.__new__(cls,v)
> ... return self
> ... def __eq__(self,other):
> ...
On 11/08/2014 13:30, alister wrote:
It already is a different operator from equality which is ==
Mathematicians use '=' for name binding all the time, with and without
'let':
Let u = x + y, v = x - y. Then ... .
However, name binding itself is a mental operation, not a mathematical one.
Ma
On 11/08/2014 13:30, alister wrote:
It already is a different operator from equality which is ==
perhaps it would have been better if the behaviour of these two operators
were reversed (= for equality & == for assignment) but i suspect that
Idea if even considered was quickly discarded as it wou
On 11/08/2014 13:11, Rustom Mody wrote:
But then when it comes to Steven supporting the violation 500 years* of
math conventional usage of '=':
I have no interest in the maths convention (see, you don't even know the
original, correct English, math indeed). Of far more importance in the
re
On 11/08/2014 13:30, Tim Chase wrote:
On 2014-08-11 07:55, Roy Smith wrote:
A C programmer asked to swap variables x and y, typically writes
something like
t = x; x = y; y = t;
Fine, since C cant do better.
Sure C can do better.
x = x ^ y
y = y ^ x
x = x ^ y
Any self-respecting C hacker wo
On Mon, Aug 11, 2014 at 10:41 PM, Marko Rauhamaa wrote:
> Tim Chase :
>
>> Pish, such redundancy...everyone knows a C programmer would write
>> that as
>>
>> x ^= y
>> y ^= x
>> x ^= y
>
> Aren't you forgetting something?
I don't think he is. Those are augmented assignments, just as Python
has
Tim Chase :
> Pish, such redundancy...everyone knows a C programmer would write
> that as
>
> x ^= y
> y ^= x
> x ^= y
Aren't you forgetting something?
Marko
--
https://mail.python.org/mailman/listinfo/python-list
On Mon, Aug 11, 2014 at 10:11 PM, Rustom Mody wrote:
> So evidently using notations in the ways they are conventionally used
> is a good thing.
>
> But then when it comes to Steven supporting the violation 500 years* of
> math conventional usage of '=':
Yep. It's not a violation; it's a modificat
alister :
> It already is a different operator from equality which is ==
>
> perhaps it would have been better if the behaviour of these two
> operators were reversed (= for equality & == for assignment) but i
> suspect that Idea if even considered was quickly discarded as it would
> cause major c
On Mon, 11 Aug 2014 12:56:59 +0100, Robert Kern wrote:
> On 2014-08-11 03:04, Steven D'Aprano wrote:
>> Rustom Mody wrote:
>>
>>> Its when we have variables that are assigned in multiple places that
>>> we start seeing mathematical abominations like x = x+1
>>
>> That's not a mathematical abominat
On 2014-08-11 07:55, Roy Smith wrote:
> > A C programmer asked to swap variables x and y, typically writes
> > something like
> >
> > t = x; x = y; y = t;
> >
> > Fine, since C cant do better.
>
> Sure C can do better.
>
> x = x ^ y
> y = y ^ x
> x = x ^ y
>
> Any self-respecting C hacker wo
Having it both ways aren't you?
On the one hand you say
On Monday, August 11, 2014 3:21:35 PM UTC+5:30, Chris Angelico wrote:
> On Mon, Aug 11, 2014 at 7:35 PM, Marko Rauhamaa wrote:
> > Python is a formal language with a well-defined syntax and reasonably
> > well-understood semantics. That's al
In article ,
Rustom Mody wrote:
> A C programmer asked to swap variables x and y, typically writes something
> like
>
> t = x; x = y; y = t;
>
> Fine, since C cant do better.
Sure C can do better.
x = x ^ y
y = y ^ x
x = x ^ y
Any self-respecting C hacker would write it this way :-)
--
ht
On 2014-08-11 03:04, Steven D'Aprano wrote:
Rustom Mody wrote:
Its when we have variables that are assigned in multiple places that
we start seeing mathematical abominations like
x = x+1
That's not a mathematical abomination. It's a perfectly reasonable
mathematical equation, one with no solu
On Monday, August 11, 2014 3:58:59 PM UTC+5:30, Steven D'Aprano wrote:
> On Sun, 10 Aug 2014 21:29:12 -0700, Rustom Mody wrote:
> > On Monday, August 11, 2014 8:30:32 AM UTC+5:30, Steven D'Aprano wrote:
> >> You did the same thing in your own course, the only difference being
> >> you accepted a d
Chris Angelico wrote:
> On Mon, Aug 11, 2014 at 7:44 PM, Steven D'Aprano
> wrote:
>> And even when you can
>> parallelize a series of tasks, it's
>
> ... easy for one task to get aborted part way while the rest of the
> tasks continue on, oblivious to the absence of the rest of that
> sentence?
On Mon, Aug 11, 2014 at 8:46 PM, Marko Rauhamaa wrote:
> The main thing is that the definitions must be clear. I must be able to
> look up the precise description quickly, and in fact, I always have the
> Python Library Reference in a browser tab or two because I have to
> review even familiar fun
Chris Angelico :
> On Mon, Aug 11, 2014 at 7:35 PM, Marko Rauhamaa wrote:
>> Python is a formal language with a well-defined syntax and reasonably
>> well-understood semantics. That's all that matters. Any resemblance
>> to the much more ad-hoc syntax of classical mathematics is almost
>> coincid
On Sun, 10 Aug 2014 21:29:12 -0700, Rustom Mody wrote:
> On Monday, August 11, 2014 8:30:32 AM UTC+5:30, Steven D'Aprano wrote:
>
>> You did the same thing in your own course, the only difference being
>> you accepted a different set of primitive functions. But ultimately you
>> have to introduce
On Mon, Aug 11, 2014 at 7:44 PM, Steven D'Aprano wrote:
> I think this is why both declarative and functional programming idioms
> will remain niche (although important niches). Most tasks are inherently
> imperative to at least some degree, and often a *great* degree.
Maybe that's true as a whol
On Mon, Aug 11, 2014 at 7:44 PM, Steven D'Aprano wrote:
> And even when you can
> parallelize a series of tasks, it's
... easy for one task to get aborted part way while the rest of the
tasks continue on, oblivious to the absence of the rest of that
sentence?
ChrisA
--
https://mail.python.org/m
On Mon, Aug 11, 2014 at 7:35 PM, Marko Rauhamaa wrote:
> Python is a formal language with a well-defined syntax and reasonably
> well-understood semantics. That's all that matters. Any resemblance to
> the much more ad-hoc syntax of classical mathematics is almost
> coincidental.
Well, it's a bit
On Sun, 10 Aug 2014 22:23:18 -0700, Rustom Mody wrote:
> A C programmer asked to swap variables x and y, typically writes
> something like
>
> t = x; x = y; y = t;
>
> Fine, since C cant do better.
> But then he assumes that that much sequentialization is inherent to the
> problem... Until he se
Rustom Mody :
> You think that the '=' sign not standing for math equality is ok.
>
> How come?
Python is a formal language with a well-defined syntax and reasonably
well-understood semantics. That's all that matters. Any resemblance to
the much more ad-hoc syntax of classical mathematics is almo
On Mon, Aug 11, 2014 at 6:55 PM, Steven D'Aprano wrote:
> On Sun, 10 Aug 2014 23:22:45 -0700, Rustom Mody wrote:
>
>> You think that the '=' sign not standing for math equality is ok.
>>
>> How come?
>
> For the same reason that in the following:
>
> [c.upper() for c in some_string if 'a' < c < 'x
On Sun, 10 Aug 2014 23:22:45 -0700, Rustom Mody wrote:
> You think that the '=' sign not standing for math equality is ok.
>
> How come?
For the same reason that in the following:
[c.upper() for c in some_string if 'a' < c < 'x']
having the c symbol not stand for the speed of light is okay. Li
On Monday, August 11, 2014 11:16:25 AM UTC+5:30, Chris Angelico wrote:
> On Mon, Aug 11, 2014 at 3:23 PM, Rustom Mody wrote:
> > A C programmer asked to swap variables x and y, typically writes something
> > like
> > t = x; x = y; y = t;
> > Fine, since C cant do better.
> > But then he assumes th
On Mon, Aug 11, 2014 at 3:23 PM, Rustom Mody wrote:
> A C programmer asked to swap variables x and y, typically writes something
> like
>
> t = x; x = y; y = t;
>
> Fine, since C cant do better.
> But then he assumes that that much sequentialization is inherent to the
> problem...
> Until he see
On Monday, August 11, 2014 12:33:59 AM UTC+5:30, Chris Angelico wrote:
> On Mon, Aug 11, 2014 at 4:26 AM, Rustom Mody wrote:
> > Its when we have variables that are assigned in multiple places that
> > we start seeing mathematical abominations like
> > x = x+1
> That's an abomination to you becaus
On Monday, August 11, 2014 8:30:32 AM UTC+5:30, Steven D'Aprano wrote:
> You did the same thing in your own course, the only difference being you
> accepted a different set of primitive functions. But ultimately you have to
> introduce *some* amount of concreteness, at some level, otherwise we're
On Monday, August 11, 2014 3:31:08 AM UTC+5:30, Roy Smith wrote:
> Mark Lawrence wrote:
> > On 10/08/2014 19:26, Rustom Mody wrote:
> > > Its when we have variables that are assigned in multiple places that
> > > we start seeing mathematical abominations like
> > > x = x+1
> > I'm not bothered a
Rustom Mody wrote:
> On Sunday, August 10, 2014 10:40:21 PM UTC+5:30, Roy Smith wrote:
>> Rustom Mody wrote:
>
>> > > They haven't figured out yet that the
>> > > first step to solving a problem is to decide what algorithms you're
>> > > going to use, and only then can you start translating tha
Rustom Mody wrote:
> Its when we have variables that are assigned in multiple places that
> we start seeing mathematical abominations like
> x = x+1
That's not a mathematical abomination. It's a perfectly reasonable
mathematical equation, one with no solutions since the line f(x) = x and
the line
Herion, Ketamine,Actavis promethazine codeine 16oz and 32oz available ,
Oxycontine Hydrocodone xanax and medicated
marijuana US- free shipping and other related products for sell at competitive
prices.We do world wide shipping to any clear
address.Delivery is 100% safe due to our discreetness
On Mon, Aug 11, 2014 at 8:01 AM, Roy Smith wrote:
> I'm with Mark. This isn't math, it's programming. Sure, the
> intersection of the two is non-null, but they are different things.
> I'll often do things like:
>
> for line in input:
>line = line.strip()
># do more stuff
What does mathe
In article ,
Mark Lawrence wrote:
> On 10/08/2014 19:26, Rustom Mody wrote:
> >
> > Its when we have variables that are assigned in multiple places that
> > we start seeing mathematical abominations like
> > x = x+1
> >
>
> I'm not bothered about it being a mathematical or any other type of
>
On 10/08/2014 19:26, Rustom Mody wrote:
Its when we have variables that are assigned in multiple places that
we start seeing mathematical abominations like
x = x+1
I'm not bothered about it being a mathematical or any other type of
abomination. It works, practically beats purity, so if it a
On Mon, Aug 11, 2014 at 5:14 AM, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> In computing, assignment and reassignment aren't at all problematic,
>> and neither is printing to the console, so please stop telling people
>> off for using them.
>
> Printing to the console is somewhat problematic:
>
Chris Angelico :
> In computing, assignment and reassignment aren't at all problematic,
> and neither is printing to the console, so please stop telling people
> off for using them.
Printing to the console is somewhat problematic:
>>> with open("/dev/console", "w") as console: console.write("
On Mon, Aug 11, 2014 at 4:26 AM, Rustom Mody wrote:
>
> Its when we have variables that are assigned in multiple places that
> we start seeing mathematical abominations like
> x = x+1
That's an abomination to you because it breaks your mathematical
model. It's fine to a computer, which has a sens
On Sunday, August 10, 2014 11:44:23 PM UTC+5:30, Roy Smith wrote:
> Rustom Mody wrote:
> > >>> l= [6,2,9,12,1,4]
> > >>> sorted(l,reverse=True)[:5]
> > [12, 9, 6, 4, 2]
> > No need to know how sorted works nor [:5]
> > Now you (or Steven) can call it abstract.
> > And yet its
> > 1. Actual runni
In article <154cc342-7f85-4d16-b636-a1a953913...@googlegroups.com>,
Rustom Mody wrote:
> >>> l= [6,2,9,12,1,4]
> >>> sorted(l,reverse=True)[:5]
> [12, 9, 6, 4, 2]
>
> No need to know how sorted works nor [:5]
>
> Now you (or Steven) can call it abstract.
>
> And yet its
> 1. Actual running c
Pressed Send to early.
On Sunday, August 10, 2014 11:15:03 PM UTC+5:30, Rustom Mody wrote:
> >>> # Works the same (SEEMINGLY)
> ... # Now change the return to an yield
> ...
> >>> def search(x,y):
> ...for id ,value in enumerate(x):
> ...if y==value : yield id
> ...
> >>> search
On Saturday, August 9, 2014 7:53:22 AM UTC+5:30, luofeiyu wrote:
> >>> x=["x1","x3","x7","x5"]
> >>> y="x3"
> how can i get the ordinal number by some codes?
> for id ,value in enumerate(x):
> if y==value : print(id)
> Is more simple way to do that?
I feel a bit discourteous going on a
On Sunday, August 10, 2014 10:40:21 PM UTC+5:30, Roy Smith wrote:
> Rustom Mody wrote:
> > > They haven't figured out yet that the
> > > first step to solving a problem is to decide what algorithms you're
> > > going to use, and only then can you start translating that into code.
> > > They
Rustom Mody wrote:
> On Saturday, August 9, 2014 9:04:22 PM UTC+5:30, Roy Smith wrote:
[...]
>> They haven't figured out yet that the
>> first step to solving a problem is to decide what algorithms you're
>> going to use, and only then can you start translating that into code.
>> They need to be l
In article ,
Rustom Mody wrote:
> > They haven't figured out yet that the
> > first step to solving a problem is to decide what algorithms you're
> > going to use, and only then can you start translating that into code.
> > They need to be led in small steps towards basic knowledge.
> [...]
On Saturday, August 9, 2014 9:04:22 PM UTC+5:30, Roy Smith wrote:
> Rustom Mody wrote:
> > [To the OP]
> > Yeah I am in the minority at least out here in considering
> > comprehensions simpler than loops. Take your pick
> When comprehensions first came out, I stubbornly refused to get my head
Roy Smith wrote:
> But, putting on my instructor's hat, I think it's important to answer
> questions at a level that can be understood by the student. Painting
> with a broad brush, there's three or four kinds of people asking
> questions on this list:
[...]
> I think suggesting comprehensions in
In article <338e8fb0-c9ec-462a-b560-1c1ff77de...@googlegroups.com>,
Rustom Mody wrote:
> [To the OP]
> Yeah I am in the minority at least out here in considering
> comprehensions simpler than loops. Take your pick
When comprehensions first came out, I stubbornly refused to get my head
around t
On 8/9/14 1:35 PM, luofeiyu wrote:
>>> x=["x1","x3","x7","x5","x3"]
>>> x.index("x3")
1
if i want the result of 1 and 4 ?
If you tell us more about your problem, and what you will do with the 1
and 4, there might be an even better way to do what you want.
On 8/8/2014 7:25 PM, Larry Mart
On 09.08.2014 19:22, luofeiyu wrote:
x=["x1","x3","x7","x5"]
y="x3"
>
> how can i get the ordinal number by some codes?
>
> for id ,value in enumerate(x):
> if y==value : print(id)
>
> Is more simple way to do that?
print(x.index(y))
HTH,
Johannes
--
>> Wo hattest Du das Beben
On Saturday, August 9, 2014 8:36:28 AM UTC+5:30, Steven D'Aprano wrote:
> luofeiyu wrote:
> > >>> x=["x1","x3","x7","x5","x3"]
> > >>> x.index("x3")
> > 1
> > if i want the result of 1 and 4 ?
> def index_all(source, target):
> results = []
> for i, obj in enumerate(source):
> i
luofeiyu wrote:
> >>> x=["x1","x3","x7","x5","x3"]
> >>> x.index("x3")
> 1
> if i want the result of 1 and 4 ?
def index_all(source, target):
results = []
for i, obj in enumerate(source):
if obj == target:
results.append(i)
return results
index_all(x, "x3")
=> r
On Sun, Aug 10, 2014 at 3:35 AM, luofeiyu wrote:
x=["x1","x3","x7","x5","x3"]
x.index("x3")
> 1
> if i want the result of 1 and 4 ?
Want to know what you can do with some object? Try this:
>>> help(x)
In this case, though, I suspect there's no built-in to search for
*all* of the occur
>>> x=["x1","x3","x7","x5","x3"]
>>> x.index("x3")
1
if i want the result of 1 and 4 ?
On 8/8/2014 7:25 PM, Larry Martell wrote:
On Sat, Aug 9, 2014 at 1:22 PM, luofeiyu wrote:
x=["x1","x3","x7","x5"]
y="x3"
how can i get the ordinal number by some codes?
for id ,value in enumerate(x):
On Sat, Aug 9, 2014 at 1:22 PM, luofeiyu wrote:
x=["x1","x3","x7","x5"]
y="x3"
>
> how can i get the ordinal number by some codes?
>
> for id ,value in enumerate(x):
> if y==value : print(id)
>
> Is more simple way to do that?
print x.index(y)
--
https://mail.python.org/mailman/li
>>> x=["x1","x3","x7","x5"]
>>> y="x3"
how can i get the ordinal number by some codes?
for id ,value in enumerate(x):
if y==value : print(id)
Is more simple way to do that?
--
https://mail.python.org/mailman/listinfo/python-list
74 matches
Mail list logo
