Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #45181 > unrolled thread

Re: Python for philosophers

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Python for philosophers Citizen Kant <citizenkant@gmail.com> - 2013-05-12 16:17 +0200
    Re: Python for philosophers Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-05-12 14:30 +0000
      Re: Python for philosophers alex23 <wuwei23@gmail.com> - 2013-05-12 21:19 -0700
    Re: Python for philosophers rusi <rustompmody@gmail.com> - 2013-05-12 09:00 -0700
    Re: Python for philosophers Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2013-05-13 12:34 +1200
      Re: Python for philosophers Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-05-13 02:41 +0000
        Re: Python for philosophers rusi <rustompmody@gmail.com> - 2013-05-13 07:53 -0700
          Re: Python for philosophers Chris Angelico <rosuav@gmail.com> - 2013-05-14 02:24 +1000
            Re: Python for philosophers rusi <rustompmody@gmail.com> - 2013-05-13 11:14 -0700
              Re: Python for philosophers Chris Angelico <rosuav@gmail.com> - 2013-05-14 04:22 +1000
            Re: Python for philosophers 88888 Dihedral <dihedral88888@googlemail.com> - 2013-05-18 16:56 -0700
              Re: Python for philosophers Chris Angelico <rosuav@gmail.com> - 2013-05-19 10:04 +1000
                Re: Python for philosophers 88888 Dihedral <dihedral88888@googlemail.com> - 2013-05-18 19:30 -0700
                  Re: Python for philosophers Michael Torrie <torriem@gmail.com> - 2013-05-18 22:46 -0600
      Re: Python for philosophers Schneider <js@globe.de> - 2013-05-16 16:13 +0200
    Re: Python for philosophers Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-05-13 03:25 +0000
      Re: Python for philosophers Grant Edwards <invalid@invalid.invalid> - 2013-05-13 14:33 +0000
    Re: Python for philosophers Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-05-13 07:13 +0000
      Re: Python for philosophers alex23 <wuwei23@gmail.com> - 2013-05-13 02:05 -0700
      Re: Python for philosophers Neil Cerutti <neilc@norwich.edu> - 2013-05-13 13:52 +0000

#45181 — Re: Python for philosophers

[Multipart message — attachments visible in raw view] — view raw

Thank you very much for your answers.

I'm afraid that, at this stage, I must prevent myself from "knowing too
much" about the subject. My idea here is trying to fill the gaps, mostly,
using intuition. What I do here is to try to "understand". That's different
from just knowing. Knowledge growth must be consequence of understanding's
increasing. As the scope of my understanding increases, the more I look for
increasing my knowledge. Never vice versa, because, knowing isn't like to
be right, it's just knowing.

Greg: your point is that
-------------------------------------
>>> 12**34
492223524295202670403711324312
2008064L

The input is 6 characters long, and the output
is 37 characters long. Is that more "economical"?
--------------------------------------------------------------------------

and that's a good one. But take in account that with "shortening" I refer
to "according to Python's axiomatic parameters". What's "shorten" if
expressed in Python? For example: I'm plainly aware that the word "python"
looks shorten than "01110000 01111001 01110100 01101000 01101111 01101110".
But it's shorten just for me and you and maybe for every single human, not
for the computer. You type "python", and the language (so to speak) thinks
"in my opinion you're not being economical enough coz with this you mean
01110000 01111001 01110100 01101000 01101111 01101110", and then mirrors
the supposedly result in its particular context. My "shorten" points to
what's shorten during and inside Python's runtime.

Maybe It'd be good if I explain myself a bit more. What I'm trying here is
to grasp Python from the game's abstraction point of view, as if it were,
for example, chess. That's why I need a real_player to point me to: (so to
speak, I wish I could express the ideas according to the python's syntax
but that's out of my scope by now)

games.python.board(like the chessboard but in abstract)  # with board I'm
not necessarily referring to the black on Python's command line or any
other substitutes for that, but to its axiomatic context. Which are those
unchangeable things that limit so firmly the dynamics of the game, and that
in this context must be considered like hardware, the most material part of
Python. Coz (in my neophyte opinion) these are the things that (in a more
or less obvious way) limit "the dynamic of any attempt to introduce a
change in this game".

games.python.pieces(a finite number of named elements)   # one example of
what in Python (unless for me) seems to look like pieces are
python.keywords(python2). Might be more entities that can be considered
like pieces...

games.python.start(the position that each piece must assume over the given
board in order to conform "the sign of this kind of game's starting
point")   # following the example of the only pieces I've recognized so
far, I would drive myself to think about the state of python.keywords
Of course with "state" I could be referring to any kind of state. The only
clue is that, as far I can see, is expected that those hypothetical states
come in pairs, like state(available, unavailable)

games.python.end(game's final point or highest achievement)  #I never
forget that checkmate is just a sign that can be observed looking at the
board or "axiomatic structure that in the game remains static". That
end_sign usually is, no more nor less than a transformation of the
start_sign, transformation that, sometimes, shorten it.

games.python.pieces.behavior(the legal or non erroneous modifications that
can be made to the start_sign in order to convert it to end_sign)

games.python.player.rear.avoid(what it must be avoided by any legal -non
erroneous- means)  # seems to be that the kind of things to be avoided are
not precisely making errors, since Python will tell. Making errors is just
something that's so illegal that simply doesn't take place. With "avoid" I
mean what happens when you get checked by running code that doesn't lead to
any error messages but at the same time doesn't give the expected result.

My goal right now is to produce one or more abstracts that explain (mainly
for myself but extensive to others) about how I deal with some problems
related to our "search for emphaty" nature at the time of what we tend to
consider "interaction" (learning to write in Python in interactive mode, or
just programming, is one of that cases). In essence, due to Python's lack
of empathy, one must adopt its shape and ways to (so to speak) "interact"
with it. Python could be considered like a solitary game, and in my opinion
could be taken as it is from the beginning, in order to properly understand
what one exactly is doing. That seems to be the best way to properly
"understand" Python; then knowledge will come, naturally as a perfect
search of, exactly, the things that "understanding" needs.

Any clue about this would be highly appreciated.


2013/5/11 Citizen Kant <citizenkant@gmail.com>

> Hi,
> this could be seen as an extravagant subject but that is not my original
> purpose. I still don't know if I want to become a programmer or not. At
> this moment I'm just inspecting the environment. I'm making my way to
> Python (and OOP in general) from a philosophical perspective or point of
> view and try to set the more global definition of Python's core as an
> "entity". In order to do that, and following Wittgenstein's indication
> about that the true meaning of words doesn't reside on dictionaries but in
> the use that we make of them, the starting question I make to myself about
> Python is: which is the single and most basic use of Python as the entity
> it is? I mean, beside programming, what's the single and most basic result
> one can expect from "interacting" with it directly (interactive mode)? I
> roughly came to the idea that Python could be considered as an *economic
> mirror for data*, one that mainly *mirrors* the data the programmer types
> on its black surface, not exactly as the programmer originally typed it,
> but expressed in the most economic way possible. That's to say, for
> example, if one types >>>1+1 Python reflects >>>2. When data appears
> between apostrophes, then the mirror reflects, again, the same but
> expressed in the most economic way possible (that's to say without the
> apostrophes).
>
> So, would it be legal (true) to define Python's core as an entity that
> mirrors whatever data one presents to it (or feed it with) showing back the
> most shortened expression of that data?
>
> Don't get me wrong. I can see the big picture and the amazing things that
> programmers write on Python, it's just that my question points to the
> lowest level of it's existence.
>
> Thanks a lot for your time.
>



-- 
------------------------------------------------------------------
¿Has leído «Las Novelas Prohibidas» <http://lasnovelasprohibidas.com/>?

[toc] | [next] | [standalone]

#45182

On Sun, 12 May 2013 16:17:02 +0200, Citizen Kant wrote:

> Any clue about this would be highly appreciated.

If you are interested in the intersection of programming and philosophy, 
I strongly recommend that you read "Gödel, Escher, Bach: An Eternal 
Golden Braid" by Douglas R. Hofstadter.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#45220

On May 13, 12:30 am, Steven D'Aprano <steve
+comp.lang.pyt...@pearwood.info> wrote:
> If you are interested in the intersection of programming and philosophy,
> I strongly recommend that you read "Gödel, Escher, Bach: An Eternal
> Golden Braid" by Douglas R. Hofstadter.

+1

[toc] | [prev] | [next] | [standalone]

#45185

On May 12, 7:17 pm, Citizen Kant <citizenk...@gmail.com> wrote:
> Maybe It'd be good if I explain myself a bit more. What I'm trying here is
> to grasp Python from the game's abstraction point of view, as if it were,
> for example, chess. That's why I need a real_player to point me to: (so to
> speak, I wish I could express the ideas according to the python's syntax
> but that's out of my scope by now)

On seeing the interest in games, I can only reiterate the suggestion
to look at rewrite systems
Here is on of the classics on rewrite systems

http://rewriting.loria.fr/documents/survey-draft.ps.gz

whose starting example is a game.

[toc] | [prev] | [next] | [standalone]

#45215

Citizen Kant wrote:
> What I do here is to try to "understand". 
> That's different from just knowing. Knowledge growth must be consequence 
> of understanding's increasing. As the scope of my understanding 
> increases, the more I look for increasing my knowledge. Never vice 
> versa, because, knowing isn't like to be right, it's just knowing.

It doesn't always work that way. With some facts plus a
theory, you can deduce more facts. But it's always possible
for there to be more facts that you can't deduce from what
you already know.

> But take in account that with "shortening" I 
> refer to "according to Python's axiomatic parameters".

I think what you're trying to say is that it takes an
expression and reduces it to a canonical form, such as
a single number or single string.

That's true as far as it goes, but it barely scratches
the surface of what the Python interpreter is capable
of doing.

In the most general terms, the Python interpeter (or
any other computer system, for that matter) can be thought
of as something with an internal state, and a transition
function that takes the state together with some input
and produces another state together with some output:

    F(S1, I) --> (S2, O)

(Computer scientists call this a "finite state machine",
because there is a limited number of possible internal
states -- the computer only has so much RAM, disk space,
etc.)

This seems to be what you're trying to get at with your
game-of-chess analogy.

What distinguishes one computer system from another is
the transition function. The transition function of the
Python interpreter is rather complicated, and it's
unlikely that you would be able to figure out all its
details just by poking in inputs and observing the
outputs. If you really want to understand it, you're
going to have to learn some facts, I'm sorry to say. :-)

-- 
Greg

[toc] | [prev] | [next] | [standalone]

#45217

On Mon, 13 May 2013 12:34:13 +1200, Gregory Ewing wrote:

> In the most general terms, the Python interpeter (or any other computer
> system, for that matter) can be thought of as something with an internal
> state, and a transition function that takes the state together with some
> input and produces another state together with some output:
> 
>     F(S1, I) --> (S2, O)
> 
> (Computer scientists call this a "finite state machine", because there
> is a limited number of possible internal states -- the computer only has
> so much RAM, disk space, etc.)

That's not what finite state machine means. A finite state machine 
doesn't refer to the number of physical states of the underlying hardware 
implementing the device, it refers to the number of external states of 
the computation being performed. For example, a traffic light may be 
modelled by a Finite State Machine with three states: Red, Amber, Green. 
It may actually be implemented by a general purpose computer with 
trillions of internal states, or by a specialised electrical circuit, or 
by clockwork. The implementation doesn't matter. What matters is the 
three external states, any input to the device, plus the transition rules 
between them.

Python is not well-modelled as a Finite State Machine. Python is 
equivalent in computing power to a Turing Machine, while Finite State 
Machines are much weaker, so there are things that Python can do that a 
FSM cannot.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#45243

On May 13, 7:41 am, Steven D'Aprano <steve
+comp.lang.pyt...@pearwood.info> wrote:
> Python is not well-modelled as a Finite State Machine. Python is
> equivalent in computing power to a Turing Machine, while Finite State
> Machines are much weaker, so there are things that Python can do that a
> FSM cannot.

Consider the following.

Python is turing-equivalent; so is C and scheme.
I now write a recursive factorial function in all 3.
[To level the pitch all three are written tail-recursively]

------------Python------------------
def fact(n,acc=1):
    return acc if not n else fact(n-1,n*acc)
------------C-------------------------
#include <stdio.h>
main(int argc, char **argv)
{
  printf("fact %d is %d\n", atoi(argv[1]), fact(atoi(argv[1],1)));
}

int fact(int n, int acc)
{
  return !n? acc : fact(n-1,acc*n);
}
---------------------------------
When I run these, the C happily keeps giving answers until a million

The python crashes around a thousand.

However examined closely we find that though the C is giving answers
its giving junk after around 12
fact 17 is -288522240
And 35 onwards its 0 (!!)

So finally we do it in scheme:
(define (fact n ac)
  (if (zero? n) ac (fact (1- n) (* ac n))))
--------------------------------------------------------

This program neither crashes (because of tail recursion) nor gives
wrong answers

However around 90000 my entire machine becomes completely unusable
with top showing guile (scheme) taking all the memory and kswapd next
in line.

So whats the moral?

The Turing model is essentially infinite.
[A TM to compute factorial would never crash because it can never be
built]

The machines we use are finite.
As a first approx we may say that languages like C,Python,Scheme are
Turing-complete.

However in fact when we have to stuff these (conceptually beautiful)
infinite objects into messy finite objects such as Intel hardware,
some corners have to be cut.

And these 3 -- C, Python, Scheme -- CUT THE CORNERS DIFFERENTLY

So when these corners dont matter -- Turing-equivalence is fine
When they do, we must make do living in a more messy finite world

[toc] | [prev] | [next] | [standalone]

#45248

On Tue, May 14, 2013 at 12:53 AM, rusi <rustompmody@gmail.com> wrote:
> int fact(int n, int acc)
> {
>   return !n? acc : fact(n-1,acc*n);
> }
> ---------------------------------
> When I run these, the C happily keeps giving answers until a million
>
> However examined closely we find that though the C is giving answers
> its giving junk after around 12
> fact 17 is -288522240
> And 35 onwards its 0 (!!)

That'll depend on your integer size. If it's a 32-bit integer, you
can't store numbers greater than 2**31-1 (if you declared it as
'unsigned int', you could go all the way to 2**32-1). I'm sure you
could write this to use the GNU Multi-Precision library, but it'd be a
lot more complicated. However, as far as I know, the Turing machine
never promises that; its cells aren't meant to be infinite integers.

The Python script is, of course, governed by sys.setrecursionlimit().
But by adding a simple driver, we can test the real limit:

import sys

def fact(n,acc=1):
    return acc if not n else fact(n-1,n*acc)

n=2
while True:
        sys.setrecursionlimit(n+2)
        print("fact",n,"has",len(str(fact(n))),"digits")
        n*=2

On my 64-bit system, running a recent trunk build of CPython 3.4, it
can calculate 8192! but not 16384! (segfault). The limit seems to be
12772; after that, boom. Your crash-point will quite probably vary,
and I'd say there'll be compile-time options that would change that.

Of course, after playing with this in Python, I had to try out Pike.
Using the exact same code you proposed for C, but with a different
main() to save me the hassle of keying in numbers manually, I get
this:

fact 8192 has 28504 digits - 0.026 secs
fact 16384 has 61937 digits - 0.097 secs
fact 32768 has 133734 digits - 0.389 secs
fact 65536 has 287194 digits - 1.628 secs
fact 131072 has 613842 digits - 7.114 secs
fact 262144 has 1306594 digits - 31.291 secs
fact 524288 has 2771010 digits - 133.146 secs

It's still going. One core consumed, happily working on 1048576!, and
not actually using all that much memory. Hmm.... looks like the Pike
optimizer has turned this non-recursive. Okay, let's tweak it so it's
not tail-recursion-optimizable:

  return n?n*fact(n-1,1):1;

Now it bombs at 65536, saying:

Svalue stack overflow. (99624 of 100000 entries on stack, needed 256
more entries)

Hey, it's better than a segfault, which is what C would have done :)
And it's a tweakable value, though I don't know what the consequences
are of increasing it (presumably increased RAM usage for all Pike
programs).

Your final conclusion is of course correct; nothing we build can be
truly infinite. But we can certainly give some very good
approximations, if we're prepared to pay for them. The reality is,
though, that we usually do not want to pay for approximations to
infinity; why is IEEE 754 floating point so much more used than, say,
arbitrary-precision rational? Most of the time, we'd rather have good
performance and adequate accuracy than abysmal performance and perfect
accuracy. But hey, if you want to render a Mandelbrot set and zoom in
to infinity, the option IS there.

ChrisA

[toc] | [prev] | [next] | [standalone]

#45258

On May 13, 9:24 pm, Chris Angelico <ros...@gmail.com> wrote:
>
> Your final conclusion is of course correct; nothing we build can be
> truly infinite. But we can certainly give some very good
> approximations, if we're prepared to pay for them. The reality is,
> though, that we usually do not want to pay for approximations to
> infinity; why is IEEE 754 floating point so much more used than, say,
> arbitrary-precision rational? Most of the time, we'd rather have good
> performance and adequate accuracy than abysmal performance and perfect
> accuracy. But hey, if you want to render a Mandelbrot set and zoom in
> to infinity, the option IS there.

Lets look at the costs of locomotion (which I am rounding to neat
figures for an easy discussion)

It costs $10K for a car which goes at around 80 kmph

Now if I want to move at 800 kmph I need to switch from car to plane
and that will cost me in millions

And if I want to move at 8000 kmph I need to be in a rocket in outer
space. Cost perhaps in billions

And maybe if I spend in trillions (leaving aside the question where I
got the trillions) maybe my rocket can go at 80,000 kmph

So what will it cost me to have a rocket that will go at 300,000 m/sec
(186,000 miles per second may be more familiar)?

So what am I driving at?

Some limitations are technological. Some are fundamental.

Earlier I talked of the fact that C, python and scheme hit the
finiteness wall in different ways/places.
machine word size is C's casualty
stack size is python's
memory is scheme's

The details are technological; the fact of finiteness is fundamental
just like the speed-of-light bar is fundamental.

The example of numbers is another such case.

The set of real numbers is in general not computable
Even if we restrict ourselves to the so-called computable real
numbers...
[interestingly Turing's original paper was on computable (real)
numbers]
we get into a soup because:
One can (somewhat simplistically) think of a real number as a
(potentially) infinite list of digits.
Now comparing two finite lists for equality is a trivial operation

However comparing two infinite lists gets us into trouble because both
lists may go on and on... and be same and same... for ever and ever...
In short equality for infinite lists (and therefore real numbers) is
undecidable.
[Well technically semidecidable because if they are different we get a
'not-equal' answer]

Sorry if this all sounds abstruse...
The other day I was reading someone saying that java -- which is after
all such an 'enterprisey' language -- had goofed by not providing a
half-decent money-type.

If you think about it, this is saying the opposite of your:
> But we can certainly give some very good  approximations, if we're prepared to pay for them.

He cannot use int and have a billionaire (or more correctly a
2147483648-aire) add a dollar and get to zero
Nor is it a great idea to use floating point and have some clever
programmer skim off the sub-penny round-off errors into his personal
account.

tl;dr
Computers are hopelessly finite
Much harder to deal with this finitude than to hand-wave the problem
away

[toc] | [prev] | [next] | [standalone]

#45328

On Tue, May 14, 2013 at 4:14 AM, rusi <rustompmody@gmail.com> wrote:
> It costs $10K for a car which goes at around 80 kmph
>
> Now if I want to move at 800 kmph I need to switch from car to plane
> and that will cost me in millions
>
> And if I want to move at 8000 kmph I need to be in a rocket in outer
> space. Cost perhaps in billions
>
> And maybe if I spend in trillions (leaving aside the question where I
> got the trillions) maybe my rocket can go at 80,000 kmph
>
> So what will it cost me to have a rocket that will go at 300,000 m/sec
> (186,000 miles per second may be more familiar)?

A $1 pocket flashlight.

:)

ChrisA

[toc] | [prev] | [next] | [standalone]

#45536

Chris Angelico於 2013年5月14日星期二UTC+8上午12時24分44秒寫道：
> On Tue, May 14, 2013 at 12:53 AM, rusi <rustompmody@gmail.com> wrote:
> 
> > int fact(int n, int acc)
> 
> > {
> 
> >   return !n? acc : fact(n-1,acc*n);
> 
> > }
> 
> > ---------------------------------
> 
> > When I run these, the C happily keeps giving answers until a million
> 
> >
> 
> > However examined closely we find that though the C is giving answers
> 
> > its giving junk after around 12
> 
> > fact 17 is -288522240
> 
> > And 35 onwards its 0 (!!)
> 
> 
> 
> That'll depend on your integer size. If it's a 32-bit integer, you
> 
> can't store numbers greater than 2**31-1 (if you declared it as
> 
> 'unsigned int', you could go all the way to 2**32-1). I'm sure you
> 
> could write this to use the GNU Multi-Precision library, but it'd be a
> 
> lot more complicated. However, as far as I know, the Turing machine
> 
> never promises that; its cells aren't meant to be infinite integers.
> 
> 
> 
> The Python script is, of course, governed by sys.setrecursionlimit().
> 
> But by adding a simple driver, we can test the real limit:
> 
> 
> 
> import sys
> 
> 
> 
> def fact(n,acc=1):
> 
>     return acc if not n else fact(n-1,n*acc)
> 
> 
> 
> n=2
> 
> while True:
> 
>         sys.setrecursionlimit(n+2)
> 
>         print("fact",n,"has",len(str(fact(n))),"digits")
> 
>         n*=2
> 
> 
> 
> On my 64-bit system, running a recent trunk build of CPython 3.4, it
> 
> can calculate 8192! but not 16384! (segfault). The limit seems to be
> 
> 12772; after that, boom. Your crash-point will quite probably vary,
> 
> and I'd say there'll be compile-time options that would change that.
> 
> 
> 
> Of course, after playing with this in Python, I had to try out Pike.
> 
> Using the exact same code you proposed for C, but with a different
> 
> main() to save me the hassle of keying in numbers manually, I get
> 
> this:
> 
> 
> 
> fact 8192 has 28504 digits - 0.026 secs
> 
> fact 16384 has 61937 digits - 0.097 secs
> 
> fact 32768 has 133734 digits - 0.389 secs
> 
> fact 65536 has 287194 digits - 1.628 secs
> 
> fact 131072 has 613842 digits - 7.114 secs
> 
> fact 262144 has 1306594 digits - 31.291 secs
> 
> fact 524288 has 2771010 digits - 133.146 secs
> 
> 
> 
> It's still going. One core consumed, happily working on 1048576!, and
> 
> not actually using all that much memory. Hmm.... looks like the Pike
> 
> optimizer has turned this non-recursive. Okay, let's tweak it so it's
> 
> not tail-recursion-optimizable:
> 
> 
> 
>   return n?n*fact(n-1,1):1;
> 
> 
> 
> Now it bombs at 65536, saying:
> 
> 
> 
> Svalue stack overflow. (99624 of 100000 entries on stack, needed 256
> 
> more entries)
> 
> 
> 
> Hey, it's better than a segfault, which is what C would have done :)
> 
> And it's a tweakable value, though I don't know what the consequences
> 
> are of increasing it (presumably increased RAM usage for all Pike
> 
> programs).
> 
> 
> 
> Your final conclusion is of course correct; nothing we build can be
> 
> truly infinite. But we can certainly give some very good
> 
> approximations, if we're prepared to pay for them. The reality is,
> 
> though, that we usually do not want to pay for approximations to
> 
> infinity; why is IEEE 754 floating point so much more used than, say,
> 
> arbitrary-precision rational? Most of the time, we'd rather have good
> 
> performance and adequate accuracy than abysmal performance and perfect
> 
> accuracy. But hey, if you want to render a Mandelbrot set and zoom in
> 
> to infinity, the option IS there.
> 
> 
> 
> ChrisA

Hey, ChisA, are you delibrately to write a recursive version
to demonstrate the stack depth problem in Python?

def fact(n):
   ret=1
   if n>1: # integer checking is not used but can be added
      for x in xrange(n): ret*=x
   #print ret # debugging only for long integers 
   return ret 



In a 32 or 64 bit system, this non-recursive verssion
will be limited by the heap space not by the stack limit.

[toc] | [prev] | [next] | [standalone]

#45538

On Sun, May 19, 2013 at 9:56 AM, 88888 Dihedral
<dihedral88888@googlemail.com> wrote:
> Hey, ChisA, are you delibrately to write a recursive version
> to demonstrate the stack depth problem in Python?
>
> def fact(n):
>    ret=1
>    if n>1: # integer checking is not used but can be added
>       for x in xrange(n): ret*=x
>    #print ret # debugging only for long integers
>    return ret
>
>
>
> In a 32 or 64 bit system, this non-recursive verssion
> will be limited by the heap space not by the stack limit.

And just when we're sure Dihedral's a bot, a post like this comes through.

Dihedral, are you intelligent? I'm still in two minds about this...
which may be why you so often appear to have no minds. I dunno.
Mathematics somewhere I fancy.

ChrisA

[toc] | [prev] | [next] | [standalone]

#45543

Chris Angelico於 2013年5月19日星期日UTC+8上午8時04分45秒寫道：
> On Sun, May 19, 2013 at 9:56 AM, 88888 Dihedral
> 
> <dihedral88888@googlemail.com> wrote:
> 
> > Hey, ChisA, are you delibrately to write a recursive version
> 
> > to demonstrate the stack depth problem in Python?
> 
> >
> 
> > def fact(n):
> 
> >    ret=1
> 
> >    if n>1: # integer checking is not used but can be added
> 
> >       for x in xrange(n): ret*=x
> 
> >    #print ret # debugging only for long integers
> 
> >    return ret
> 
> >
> 
> >
> 
> >
> 
> > In a 32 or 64 bit system, this non-recursive verssion
> 
> > will be limited by the heap space not by the stack limit.
> 
> 
> 
> And just when we're sure Dihedral's a bot, a post like this comes through.
> 
> 
> 
> Dihedral, are you intelligent? I'm still in two minds about this...
> 
> which may be why you so often appear to have no minds. I dunno.
> 
> Mathematics somewhere I fancy.
> 
> 
> 
> ChrisA

I am too lazy to write a factorial computations with primes
here.

[toc] | [prev] | [next] | [standalone]

#45548

On 05/18/2013 08:30 PM, 88888 Dihedral wrote:
> I am too lazy to write a factorial computations with primes
> here.

Ahh, that's better.

[toc] | [prev] | [next] | [standalone]

#45423

Maybe the implementation of the Python Interpreter could be seen as 
transition function.
This can be understand in detail, but it even if you know how the 
interpreter works, you don't really know to work
_with_ the interpreter.
Even more, there are a lot of decisions, which are made 'by design' and 
don't have a clear answer. to see why somethings are
done in the way they are done you have to understand the philosophy of 
programming with python.

bg,
Johannes

On 13.05.2013 02:34, Gregory Ewing wrote:
> Citizen Kant wrote:
>> What I do here is to try to "understand". That's different from just 
>> knowing. Knowledge growth must be consequence of understanding's 
>> increasing. As the scope of my understanding increases, the more I 
>> look for increasing my knowledge. Never vice versa, because, knowing 
>> isn't like to be right, it's just knowing.
>
> It doesn't always work that way. With some facts plus a
> theory, you can deduce more facts. But it's always possible
> for there to be more facts that you can't deduce from what
> you already know.
>
>> But take in account that with "shortening" I refer to "according to 
>> Python's axiomatic parameters".
>
> I think what you're trying to say is that it takes an
> expression and reduces it to a canonical form, such as
> a single number or single string.
>
> That's true as far as it goes, but it barely scratches
> the surface of what the Python interpreter is capable
> of doing.
>
> In the most general terms, the Python interpeter (or
> any other computer system, for that matter) can be thought
> of as something with an internal state, and a transition
> function that takes the state together with some input
> and produces another state together with some output:
>
>    F(S1, I) --> (S2, O)
>
> (Computer scientists call this a "finite state machine",
> because there is a limited number of possible internal
> states -- the computer only has so much RAM, disk space,
> etc.)
>
> This seems to be what you're trying to get at with your
> game-of-chess analogy.
>
> What distinguishes one computer system from another is
> the transition function. The transition function of the
> Python interpreter is rather complicated, and it's
> unlikely that you would be able to figure out all its
> details just by poking in inputs and observing the
> outputs. If you really want to understand it, you're
> going to have to learn some facts, I'm sorry to say. :-)
>


-- 
GLOBE Development GmbH
Königsberger Strasse 260
48157 MünsterGLOBE Development GmbH
Königsberger Strasse 260
48157 Münster
0251/5205 390

[toc] | [prev] | [next] | [standalone]

#45219

On Sun, 12 May 2013 16:17:02 +0200, Citizen Kant wrote:

> Thank you very much for your answers.
> 
> I'm afraid that, at this stage, I must prevent myself from "knowing too
> much" about the subject. My idea here is trying to fill the gaps,
> mostly, using intuition.

Then you are doomed to failure.

Intuition is greatly over-rated. Most of the time, it's just an excuse 
for prejudice, and a way to avoid understanding.


> What I do here is to try to "understand".
> That's different from just knowing. Knowledge growth must be consequence
> of understanding's increasing. As the scope of my understanding
> increases, the more I look for increasing my knowledge. Never vice
> versa, because, knowing isn't like to be right, it's just knowing.

Define your terms. What do you think "to know" means? What do you think 
"to understand" means?

[...]
> But take in account that with "shortening" I
> refer to "according to Python's axiomatic parameters". 

You cannot hypothesis about Python's behaviour in terms of its "axiomatic 
parameters" unless they know what those axiomatic parameters are. So what 
do you think Python's "axiomatic parameters" are, and how did you come to 
that conclusion given that you know virtually nothing about Python?


> What's "shorten"
> if expressed in Python? For example: I'm plainly aware that the word
> "python" looks shorten than "01110000 01111001 01110100 01101000
> 01101111 01101110". But it's shorten just for me and you and maybe for
> every single human, not for the computer. You type "python", and the
> language (so to speak) thinks "in my opinion you're not being economical
> enough coz with this you mean 01110000 01111001 01110100 01101000
> 01101111 01101110", 


Sheer nonsense, and I don't mean the part where you anthropomorphise 
Python. (The "intentional stance" is often an excellent way of reasoning 
about complex systems.)

Your premise that Python tries to be "economical" is incorrect. If 
anything, Python is the opposite: it is often profligate with resources 
(memory mostly) in order to save the human programmer time and effort. 
For example, Python dicts and lists may easily be four times as large as 
they could be (sometimes even bigger), *by design*. A list with 10 items 
may easily have space for 40 items. This is hardly economical, but it is 
a good trade-off in order to get better, and more predictable, 
performance.

[...]
> Maybe It'd be good if I explain myself a bit more. What I'm trying here
> is to grasp Python from the game's abstraction point of view, as if it
> were, for example, chess.

A lousy analogy. Python is nothing like chess. You might as well try to 
understand Python as if it were a toothbrush.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#45242

On 2013-05-13, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:

> Your premise that Python tries to be "economical" is incorrect. If
> anything, Python is the opposite: it is often profligate with resources 
> (memory mostly) in order to save the human programmer time and effort.

IOW, Python is designed to be economical, but the resource of concern
is not computer memory, it's the programmer's time/effort.  Computer
memory gets cheaper every year.  My time gets more valuable every year
(hopefully).

-- 
Grant Edwards               grant.b.edwards        Yow! The entire CHINESE
                                  at               WOMEN'S VOLLEYBALL TEAM all
                              gmail.com            share ONE personality --
                                                   and have since BIRTH!!

[toc] | [prev] | [next] | [standalone]

#45223

Some further details on something mentioned about Python being 
"economical".

On Sun, 12 May 2013 16:17:02 +0200, Citizen Kant wrote:

> For example: I'm plainly aware that the word "python" looks shorten than
> "01110000 01111001 01110100 01101000 01101111 01101110". But it's
> shorten just for me and you and maybe for every single human, not for
> the computer. You type "python", and the language (so to speak) thinks
> "in my opinion you're not being economical enough coz with this you mean
> 01110000 01111001 01110100 01101000 01101111 01101110", and then mirrors
> the supposedly result in its particular context. My "shorten" points to
> what's shorten during and inside Python's runtime.

In fact, the string "python" is implemented differently in different 
versions of Python. Picking Python 2.7, it may be implemented something 
like this binary string:

???????? ???????? ???????? ???????? ???????? ???????? ????????
???????? ???????? ???????? ???????? ???????? ???????? 00000000
01110000 00000000 01111001 00000000 01110100 00000000 01101000
00000000 01101111 00000000 01101110 00000000 00000000

where the spaces are purely for the convenience of the reader, and the 
question marks are internal values that I don't know enough to give the 
correct value. (Although I can predict that at least two sets of eight 
question marks is probably "00000000 00000110", the length of the string.)

To be precise, this is with a "narrow build", a "wide build" is even more 
profligate with memory. 

I'm not trying to beat the original Poster up for making an error, but 
demonstrating just how badly off track you can get by trying to reason 
from first principles (as Plato may have done) instead of empirical study 
(as Aristotle or Bacon may have done). Knowledge of how things actually 
are beats understanding of how they ought to be every time.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#45231

On May 13, 5:13 pm, Steven D'Aprano <steve
+comp.lang.pyt...@pearwood.info> wrote:
> I'm not trying to beat the original Poster up for making an error, but
> demonstrating just how badly off track you can get by trying to reason
> from first principles (as Plato may have done) instead of empirical study
> (as Aristotle or Bacon may have done). Knowledge of how things actually
> are beats understanding of how they ought to be every time.

Nicely put, I may have to copy & paste this into another thread
here...

I always did have a soft spot for William James.

[toc] | [prev] | [next] | [standalone]

#45238

On 2013-05-13, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> I'm not trying to beat the original Poster up for making an
> error, but demonstrating just how badly off track you can get
> by trying to reason from first principles (as Plato may have
> done) instead of empirical study (as Aristotle or Bacon may
> have done). Knowledge of how things actually are beats
> understanding of how they ought to be every time.

Wasn't it Aristarchus who was considered a trouble-maker for
dropping different sized lead balls from a tower? They would land
simultaneously just as his teacher, who taught that heavier
objects fall faster, was walking past.

-- 
Neil Cerutti

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web