Re: tree functions daily exercise: Table

[alex goldman]

Xah Lee wrote:

> 
> well yes... but this was emulation of Mathematica functions.
> (Disclaimer: Mathematica is a trademark of Wolfram Research Inc, who is
> not affliated with this project)

You could have fooled me.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What are OOP's Jargons and Complexities?

[alex goldman]

John McGrath wrote:

> Unfortunately, there is no
> consensus as to what the term means.

If the language allows the programmer to write programs from the 'slack'
domain, by saying "just trust me on this", then it's not strongly typed.

What other meanings are there? I wasn't aware of the lack of consensus.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What are OOP's Jargons and Complexities?

[alex goldman]

Tassilo v. Parseval wrote:

> Also sprach John W. Kennedy:
> 
>> alex goldman wrote:
>>> John W. Kennedy wrote:
>>> 
>>> 
>>>>Strong typing has been a feature of mainstream programming languages
>>>>since the late 1950's.
>>> 
>>> I'm just curious, what do you mean by /strong/ typing, and which
>>> strongly typed languages do you know?
>>
>> Unfortunately, I have seen the meaning shift with the context. In Ada
>> '83, it means it is not possible to have the equivalent of a C
>> unprototyped function, and that mixed-type expressions tend to need
>> explicit casting. In other contexts (as here), I've seen it used to mean
>> simply that variables have definite types, and it is not possible
>> (except by the use of polymorphic classes) for a variable to change from
>> an integer to a float to a character string in the course of execution.
>> In this sense, compile-to-machine-code languages (ee.g., Fortran, COBOL,
>> C, C++, or Pascal), are generally strongly typed
> 
> These are statically typed. The extent to which they are also strongly
> typed differs: C++ is probably a little more strongly typed than C, but
> by and large their typing is still fairly weak.
> 
> Most often, languages with strong typing can be found on the functional
> front (such as ML and Haskell). These languages have a dynamic typing
> system. 

No, ML & Haskell are strongly and statically typed. Read this paper if
interested:

http://research.microsoft.com/Users/luca/Papers/TypeSystems.pdf


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What are OOP's Jargons and Complexities?

[alex goldman]

John W. Kennedy wrote:

> Strong
> typing has been a feature of mainstream programming languages since the
> late 1950's.

Is Fortran a strongly typed language? I don't think so. Strong typing has
been invented in the 70's, if I'm not mistaken, when ML was invented, but
strong typing has never been mainstream.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What are OOP's Jargons and Complexities?

[alex goldman]

John W. Kennedy wrote:

> Strong
> typing has been a feature of mainstream programming languages since the
> late 1950's.

I'm just curious, what do you mean by /strong/ typing, and which strongly
typed languages do you know?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Language documentation ( was Re: Computing Industry shams)

[alex goldman]

Lawrence Kirby wrote:

> On Tue, 10 May 2005 06:52:18 -0700, alex goldman wrote:
> 
>> Lawrence Kirby wrote:
> 
> ...
> 
>>> However the original quote was in the context of regular expressions, so
>>> discussion of the terminology used in regular expressions is far more
>>> relevant than the terminology used in graph search and optimisation
>>> algorithms.
>> 
>> I replied to "And from memory, that is the sort of thing done in
>> Computing
>> 101 and in  Data Structures and Algorithms 101", and I fully explained
>> what I meant by "greedy" as well. There was no ambiguity.
> 
> My response talks about relevance, not ambiguity.

Well, your response was irrelevant.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Language documentation ( was Re: Computing Industry shams)

[alex goldman]

Lawrence Kirby wrote:

> On Tue, 10 May 2005 04:58:48 -0700, alex goldman wrote:
> 
>> Sean Burke wrote:
> 
> ...
> 
>>> No, you're just confused about the optimization metric.
>>> In regexes, "greedy" match optimizes for the longest match,
>>> not the fastest.
>>> 
>>> And this is common regex terminology - man perlre and you will
>>> find discussion of "greedy" vs. "stingy" matching.
>> 
>> Read what you quoted again. Everyone (Xah, vermicule, myself) was talking
>> about "greedy" as it's used in graph search and optimization algorithms.
> 
> However the original quote was in the context of regular expressions, so
> discussion of the terminology used in regular expressions is far more
> relevant than the terminology used in graph search and optimisation
> algorithms.

I replied to "And from memory, that is the sort of thing done in Computing
101 and in  Data Structures and Algorithms 101", and I fully explained what
I meant by "greedy" as well. There was no ambiguity.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Language documentation ( was Re: Computing Industry shams)

[alex goldman]

Sean Burke wrote:

> 
> alex goldman <[EMAIL PROTECTED]> writes:
> 
>> vermicule wrote:
>> 
>> > 
>> > What is so hard to understand ?
>> > Should be perfectly clear even to a first year undergraduate.
>> > 
>> > As for "greedy" even a minimal exposure to Djikstra's shortest path
>> > algorithm would have made the concept intuitive. And from memory,
>> > that is the sort of thing done in Computing 101 and in  Data Structures
>> > and Algorithms 101
>> > 
>> > It seems to me that you want the Python doc to be written for morons.
>> > And that is not a valid complaint.
>> 
>> He's right actually. If we understand the term "greedy" as it's used in
>> graph search and optimization algorithms, Python's RE matching actually
>> IS greedy.
> 
> No, you're just confused about the optimization metric.
> In regexes, "greedy" match optimizes for the longest match,
> not the fastest.
> 
> And this is common regex terminology - man perlre and you will
> find discussion of "greedy" vs. "stingy" matching.

Read what you quoted again. Everyone (Xah, vermicule, myself) was talking
about "greedy" as it's used in graph search and optimization algorithms.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Language documentation ( was Re: Computing Industry shams)

[alex goldman]

vermicule wrote:

> 
> What is so hard to understand ?
> Should be perfectly clear even to a first year undergraduate.
> 
> As for "greedy" even a minimal exposure to Djikstra's shortest path
> algorithm would have made the concept intuitive. And from memory,
> that is the sort of thing done in Computing 101 and in  Data Structures
> and Algorithms 101
> 
> It seems to me that you want the Python doc to be written for morons.
> And that is not a valid complaint.

He's right actually. If we understand the term "greedy" as it's used in
graph search and optimization algorithms, Python's RE matching actually IS
greedy.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Lambda: the Ultimate Design Flaw

[alex goldman]

Artie Gold wrote:

> Torsten Bronger wrote:
>> Hallöchen!
>> 
>> Daniel Silva <[EMAIL PROTECTED]> writes:
>> 
>> 
>>>Shriram Krishnamurthi has just announced the following elsewhere; it
>>>might be of interest to c.l.s, c.l.f, and c.l.p:
>>>http://list.cs.brown.edu/pipermail/plt-scheme/2005-April/008382.html
>>>
>>>
>>>The Fate Of LAMBDA in PLT Scheme v300
>>> or
>>>  Lambda the Ultimate Design Flaw
>>>
>>>About 30 years ago, Scheme had FILTER and MAP courtesy of Lisp
>>>hackers who missed them from their past experience.  To this
>>>collection, Scheme added a lexically-scoped, properly-functioning
>>>LAMBDA.  But, despite of the PR value of anything with Guy
>>>Steele's name associated with it, we think these features should
>>>be cut from PLT Scheme v300.
>>>
>>>[...]
>> 
>> 
>> The whole text seems to be a variant of
>> .
>> 
>> Tschö,
>> Torsten.
>> 
> Ya think? ;-)
> 
> --ag
> 

Wow, the original is much funnier than the "joke"! (Because it's meant
seriously)


"plus the lambda is slower than the list comprehension" - ROTFL!
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Lambda: the Ultimate Design Flaw

[alex goldman]

Daniel Silva wrote:

> At any rate, FOLD must fold.

I personally think GOTO was unduly criticized by Dijkstra. With the benefit
of hindsight, we can see that giving up GOTO in favor of other primitives
failed to solve the decades-old software crisis.
-- 
http://mail.python.org/mailman/listinfo/python-list