plain text follows
----------------------------------------
What's “In-place Algorithm”?
Xah Lee, 2012-02-29
This page tells you what's “In-place algorithm”, using {python, perl,
emacs lisp} code to illustrate.
Here's Wikipedia In-place algorithm excerpt:
In computer science, an in-place algorithm (or in Latin in situ) is an
algorithm which transforms input using a data structure with a small,
constant amount of extra storage space. The input is usually
overwritten by the output as the algorithm executes. An algorithm
which is not in-place is sometimes called not-in-place or out-of-
place.
Python
Here's a python code for reversing a list. Done by creating a new
list, NOT using in-place:
On Wed, 29 Feb 2012 20:07:49 -0800, Xah Lee wrote:
> Here's in-place algorithm for reversing a list:
> # python
> # in-place algorithm for reversing a list
> list_a = ["a", "b", "c", "d", "e", "f", "g"]
> list_length = len(list_a)
> for i in range(list_length/2):
> x = list_a[i]
> list_a[i] = list_a[ list_length -1 - i] > list_a[ list_length -1 - i] = x
> print list_a
This is a good example of code written by somebody not very familiar with Python idioms. You don't need a temporary variable to swap two values in Python. A better way to reverse a list using more Pythonic idioms is:
for i in range(len(list_a)//2):
list_a[i], list_a[-i-1] = list_a[-i-1], list_a[i]
But the best way (even more idiomatic and much, much faster) is this:
+comp.lang.pyt...@pearwood.info> wrote:
> You don't need a temporary variable to swap two values in
> Python. A better way to reverse a list using more Pythonic idioms is:
> for i in range(len(list_a)//2):
> list_a[i], list_a[-i-1] = list_a[-i-1], list_a[i]
forgive me sir, but i haven't been at python for a while. :)
i was, actually, refreshing myself of what little polyglot skills i
have.
> On Wed, Feb 29, 2012 at 8:07 PM, Xah Lee <xah...@gmail.com
> <mailto:xah...@gmail.com>> wrote:
> This page tells you what's “In-place algorithm”, using {python, perl,
> emacs lisp} code to illustrate.
> Aren't in-place reversals rather non-functional?
There is one place where they're reasonably idiomatic in Lispy
languages, at least by my understanding. That occurs when you are
writing a function that returns a list and there is a natural recursive
way to build up the answer -- but backwards. The idiom then is to build
up a temporary list up backwards, then call an in-place reversal
function. (NREVERSE in Common Lisp. I thought there was a reverse! in
Scheme, but apparently not.)
This doesn't break the external view of a pure function because the list
that's being reversed is a fresh, temporary list, which is why this
idiom would even fit in pretty well in Scheme.
> plain text follows
> ----------------------------------------
> What's “In-place Algorithm”?
> Xah Lee, 2012-02-29
> This page tells you what's “In-place algorithm”, using {python, perl,
> emacs lisp} code to illustrate.
> Here's Wikipedia In-place algorithm excerpt:
> In computer science, an in-place algorithm (or in Latin in situ) is an
> algorithm which transforms input using a data structure with a small,
> constant amount of extra storage space. The input is usually
> overwritten by the output as the algorithm executes. An algorithm
> which is not in-place is sometimes called not-in-place or out-of-
> place.
> Python
> Here's a python code for reversing a list. Done by creating a new
> list, NOT using in-place:
NB: The fact that a sufficiently sophisticated compiler might be able
to fix this automatically emphasizes the deficiencies of the original
attempt, it doesn't excuse them.
On Mar 1, 7:04 am, Kaz Kylheku <k...@kylheku.com> wrote:
lisp:
(floor (/ x y)) --[rewrite]--> (floor x y)
Thanks for this interesting point.
I don't think it's a good lang design, more of a lang quirk.
similarly, in Python 2.x,
x/y
will work when both x and y are integers. Also,
x//y
works too, but that // is just perlish unreadable syntax quirk.
similarly, in perl, either one
require POSIX; floor(x/y);
the require POSIX instead of Math is a quirk. But even, floor should
really be builtin.
or
using a perl hack
int(x/y)
all of the above are quirks. They rely on computer engineering by-
products (such as int), or rely on the lang's idiosyncrasy. One easy
way to measure it is whether a programer can read and understand a
program without having to delve into its idiosyncrasies. Problem with
these lang idioms is that it's harder to understand, and whatever
advantage/optimization they provide is microscopic and temporary.
best is really floor(x/y).
idiomatic programing, is a bad thing. It was spread by perl, of
course, in the 1990s. Idiomatic lang, i.e. lang with huge number of
bizarre idioms, such as perl, is the worst.
> similarly, in perl, either one
> require POSIX; floor(x/y);
> the require POSIX instead of Math is a quirk. But even, floor should
> really be builtin.
> or
> using a perl hack
> int(x/y)
> all of the above are quirks. They rely on computer engineering by-
> products (such as int),
Integral numbers are not 'a computer engineering byproduct'.
> or rely on the lang's idiosyncrasy. One easy way to measure it is
> whether a programer can read and understand a program without having
> to delve into its idiosyncrasies. Problem with these lang idioms is
> that it's harder to understand, and whatever advantage/optimization
> they provide is microscopic and temporary.
It's hard to understand for someone who knows only mathematical
idiosyncrasies and who is also convinced that this should really be
more than enough for a lifetime. But that's not some kind of 'natural
knowledge' people just happen to have but systematically drilled into
pupils from a very early age, despite most of them won't ever have any
use for any of it insofar it goes beyond + - * /.
[...]
> idiomatic programing, is a bad thing.
If you have to use something (like a particular programming language)
but you resent learning how to use it and rather make lofty excuses,
chances are that you are rather a lazy f*cker than a great philosopher
...
On Fri, Mar 2, 2012 at 9:04 AM, Xah Lee <xah...@gmail.com> wrote:
> One easy
> way to measure it is whether a programer can read and understand a
> program without having to delve into its idiosyncrasies.
Neither the behavior of ints nor the behavior of IEEE floating point
is a "quirk" or an "idiosyncracy". These are data types with
well-defined semantics, and you need to understand them to use them.
The fact that dividing two positive integers and producing (or casting
to) a third integer rounds the result down is just as much a part of
the definition as is two's complement negatives, which most people can
safely ignore because they "just work" the way you expect.
Learn what you're working with, if you expect to get decent results from it.
> plain text follows
> ----------------------------------------
> What's “In-place Algorithm”?
> Xah Lee, 2012-02-29
> This page tells you what's “In-place algorithm”, using {python, perl,
> emacs lisp} code to illustrate.
> Here's Wikipedia In-place algorithm excerpt:
> In computer science, an in-place algorithm (or in Latin in situ) is an
> algorithm which transforms input using a data structure with a small,
> constant amount of extra storage space. The input is usually
> overwritten by the output as the algorithm executes. An algorithm
> which is not in-place is sometimes called not-in-place or out-of-
> place.
> Python
> Here's a python code for reversing a list. Done by creating a new
> list, NOT using in-place:
«… One easy way to measure it is whether a programer can read and
understand a program without having to delve into its idiosyncrasies.
…»
Chris Angelico wrote:
«Neither the behavior of ints nor the behavior of IEEE floating point
is a "quirk" or an "idiosyncracy". …»
they are computer engineering by-products. Are quirks and
idiosyncracies. Check out a advanced lang such as Mathematica. There,
one can learn how the mathematical concept of integer or real number
are implemented in a computer language, without lots by-products of
comp engineering as in vast majority of langs (all those that chalks
up to some IEEEEEEE. (which, sadly, includes C, C++, java, perl,
python, lisp, and almost all. (lisp idiots speak of the jargon “number
tower” instead IEEEE.) (part of the reason almost all langs stick to
some IEEEEEEEE stuff is because it's kinda standard, and everyone
understand it, in the sense that unix RFC (aka really fucking common)
is wide-spread because its free yet technically worst. (in a sense,
when everybody's stupid, there arise a cost to not be stupid.)))).
