Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Python: Python

f python?

 

 

First page Previous page 1 2 Next page Last page  View All Python python RSS feed   Index | Next | Previous | View Threaded


roy at panix

Apr 9, 2012, 5:45 AM

Post #26 of 50 (1882 views)
Permalink
Re: f python? [In reply to]

In article <4f82d3e2$1$fuzhry+tra$mr2ice [at] news>,
Shmuel (Seymour J.) Metz <spamtrap [at] library> wrote:

> >Null terminated strings have simplified all kids of text
> >manipulation, lexical scanning, and data storage/communication
> >code resulting in immeasurable savings over the years.
>
> Yeah, especially code that needs to deal with lengths and nulls. It's
> great for buffer overruns too.

I once worked on a C++ project that used a string class which kept a
length count, but also allocated one extra byte and stuck a null at the
end of every string.
--
http://mail.python.org/mailman/listinfo/python-list


kaz at kylheku

Apr 9, 2012, 11:55 AM

Post #27 of 50 (1882 views)
Permalink
Re: f python? [In reply to]

On 2012-04-09, Shmuel Metz <spamtrap [at] library> wrote:
> In <20120408114313.85 [at] kylheku>, on 04/08/2012
> at 07:14 PM, Kaz Kylheku <kaz [at] kylheku> said:
>
>>Null-terminated strings are infinitely better than the ridiculous
>>encapsulation of length + data.
>
> ROTF,LMAO!
>
>>For one thing, if s is a non-empty null terminated string then,
>>cdr(s) is also a string representing the rest of that string
>>without the first character,
>
> Are you really too clueless to differentiate between C and LISP?

In Lisp we can burn a list literal like '(a b c) into ROM, and compute (b c)
without allocating any memory.

Null-terminated C strings do the same thing.

In some Lisp systems, in fact, "CDR coding" was used to save space when
allocating a list all at once. This created something very similar to
a C string: a vector-like object of all the CARs, with a terminating
convention marking the end.

It's logically very similar.

I need not repeat the elegant recursion example for walking a C string.

That example is not possible with the length + data representation.
(Not without breaking the encapsulation and passing the length as a separate
recursion parameter to a recursive routine that works with the raw data part of
the string.)

>>Null terminated strings have simplified all kids of text
>>manipulation, lexical scanning, and data storage/communication
>>code resulting in immeasurable savings over the years.
>
> Yeah, especially code that needs to deal with lengths and nulls.

To get the length of a string, you call a function, in either representation,
so it is not any more complicated from a coding point of view. The function is,
of course, more expensive if the string is null terminated, but you can code
with awareness of this and not call length wastefully.

If all else was equal (so that the expense of the length operation were
the /only/ issue) then of course the length + data would be better.

However, all else is not equal.

One thing that is darn useful, for instance, is that
p + strlen(p) still points to a string which is length zero, and this
sort of thing is widely exploited in text processing code. e.g.

size_t digit_prefix_len = strspn(input_string, "0123456789");
const char *after_digits = input-string + digit_prefix_len;

if (*after_digits == 0) {
/* string consists only of digits: nothing after digits */
} else {
/* process part after digits */
}

It's nice that after_digits is a bona-fide string just like input_string,
without any memory allocation being required.

We can lexically analyze a string without ever asking it what its length is,
and as we march down the string, the remaining suffix of that string is always
a string so we can treat it as one, recurse on it, whatever.

Code that needs to deal with null "characters" is manipulating binary data, not
text, and should use a suitable data structure for that.

> It's great for buffer overruns too.

If we scan for a null terminator which is not there, we have a buffer overrun.

If a length field in front of string data is incorrect, we also have a buffer
overrrun.

A pattern quickly emerges here: invalid, corrupt data produced by buggy code
leads to incorrect results, and behavior that is not well-defined!
--
http://mail.python.org/mailman/listinfo/python-list


kaz at kylheku

Apr 9, 2012, 12:00 PM

Post #28 of 50 (1883 views)
Permalink
Re: f python? [In reply to]

On 2012-04-09, Roy Smith <roy [at] panix> wrote:
> In article <4f82d3e2$1$fuzhry+tra$mr2ice [at] news>,
> Shmuel (Seymour J.) Metz <spamtrap [at] library> wrote:
>
>> >Null terminated strings have simplified all kids of text
>> >manipulation, lexical scanning, and data storage/communication
>> >code resulting in immeasurable savings over the years.
>>
>> Yeah, especially code that needs to deal with lengths and nulls. It's
>> great for buffer overruns too.
>
> I once worked on a C++ project that used a string class which kept a
> length count, but also allocated one extra byte and stuck a null at the
> end of every string.

Me too! I worked on numerous C++ projects with such a string template
class.

It was usually called

std::basic_string

and came from this header called:

#include <string>

which also instantiated it into two flavors under two nicknames:
std::basic_string<char> being introduced as std::string, and
std::basic_string<wchar_t> as std::wstring.

This class had a c_str() function which retrieved a null-terminated
string and so most implementations just stored the data that way, but
some of the versions of that class cached the length of the string
to avoid doing a strlen or wcslen operation on the data.
--
http://mail.python.org/mailman/listinfo/python-list


rweikusat at mssgmbh

Apr 9, 2012, 1:20 PM

Post #29 of 50 (1883 views)
Permalink
Re: f python? [In reply to]

Shmuel (Seymour J.) Metz <spamtrap [at] library> writes:

[...]

>>For one thing, if s is a non-empty null terminated string then,
>>cdr(s) is also a string representing the rest of that string
>>without the first character,
>
> Are you really too clueless to differentiate between C and LISP?

In LISP, a list is a set of conses (pairs) whose car (first element of
the pair) contains a value and whose cdr (second element of the pair)
links to the next cons that's part of the list. The end of a list is
marked by a cdr whose value is nil. A so-called 'C string' is a
sequentially allocated sequence of memory locations which contain the
characters making up the string and the end of it is marked by a
memory location holding the value 0. This is logically very similar
to the LISP list and it shouldn't be to difficult to understand that
'cdr(s) is also a string representing the rest of the string' means
'given that s points to a non-empty C string, s + 1 points to a
possibly empty C string which is identical with s with the first
character removed'.

>>Null terminated strings have simplified all kids of text
>>manipulation, lexical scanning, and data storage/communication
>>code resulting in immeasurable savings over the years.
>
> Yeah, especially code that needs to deal with lengths and nulls. It's
> great for buffer overruns too.

This is, I think, a case where the opinions of people who have used C
strings and the opinions of people who haven't differ greatly. A nice
German proverb applicable to situations like that would be 'Was der
Bauer nicht kennt das frisst er nicht' ...
--
http://mail.python.org/mailman/listinfo/python-list


rweikusat at mssgmbh

Apr 9, 2012, 1:44 PM

Post #30 of 50 (1883 views)
Permalink
Re: f python? [In reply to]

Rainer Weikusat <rweikusat [at] mssgmbh> writes:
> Shmuel (Seymour J.) Metz <spamtrap [at] library> writes:
>
> [...]
>
>>>For one thing, if s is a non-empty null terminated string then,
>>>cdr(s) is also a string representing the rest of that string
>>>without the first character,
>>
>> Are you really too clueless to differentiate between C and LISP?
>
> In LISP, a list is a set of conses (pairs) whose car (first element of
> the pair) contains a value and whose cdr (second element of the pair)
> links to the next cons that's part of the list. The end of a list is
> marked by a cdr whose value is nil.

Addition: This can also be implemented very neatly in Perl by using
two element array references as 'cons cells', toy example

-----------
sub car
{
return $_[0][0];
}

sub cdr
{
return $_[0][1];
}

sub list
{
@_ && [shift, &list];
}

$l = list(0 .. 100);
while ($l) {
print(car($l), ' ');
$l = cdr($l);
}
print("\n");
-----------

and for algorithms which are well-suited for linked lists, this can
even outperform (when suitably implemented) an equivalent algorithm
using arrays.
--
http://mail.python.org/mailman/listinfo/python-list


spamtrap at library

Apr 10, 2012, 3:52 AM

Post #31 of 50 (1883 views)
Permalink
Re: f python? [In reply to]

In <20120409111329.694 [at] kylheku>, on 04/09/2012
at 06:55 PM, Kaz Kylheku <kaz [at] kylheku> said:

>Null-terminated C strings do the same thing.

C arrays are not LISP strings; there is no C analog to car and cdr.

>Code that needs to deal with null "characters" is manipulating
>binary data, not text,

That's a C limitation, not a characteristic of text. It is certainly
not true in languages unrelated to C, e.g., Ada, Algol 60, PL/I.

>If we scan for a null terminator which is not there, we have a
>buffer overrun.

You're only thinking of scanning an existing string; think of
constructing a string. The null only indicates the current length, not
the amount allocated.

>If a length field in front of string data is incorrect, we also have
>a buffer overrrun.

The languages that I'm aware of that use a string length field also
use a length field for the allocated storage. More precisely, they
require that attempts to store beyond the allocated length be
detected.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap [at] library

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


spamtrap at library

Apr 10, 2012, 3:58 AM

Post #32 of 50 (1883 views)
Permalink
Re: f python? [In reply to]

In <87vcl81wtw.fsf [at] sapphire>, on 04/09/2012
at 09:20 PM, Rainer Weikusat <rweikusat [at] mssgmbh> said:

>This is logically very similar to the LISP list

FSVO similar.

>This is, I think, a case where the opinions of people who have used
>C strings and the opinions of people who haven't differ greatly.

You would be wrong. It is a case where the opinions of people who are
oriented to a particular language and the opinions of people who have
lost count of the languages they have used greatly differ.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap [at] library

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


jeanpierreda at gmail

Apr 10, 2012, 7:32 AM

Post #33 of 50 (1885 views)
Permalink
Re: f python? [In reply to]

On Tue, Apr 10, 2012 at 6:52 AM, Shmuel Metz
<spamtrap [at] library> wrote:
> In <20120409111329.694 [at] kylheku>, on 04/09/2012
>   at 06:55 PM, Kaz Kylheku <kaz [at] kylheku> said:
>
>>Null-terminated C strings do the same thing.
>
> C arrays are not LISP strings; there is no C analog to car and cdr.

The post you're criticising specifically gave a definition for cdr
that had the semantics he wanted. "where cdr(s) is conveniently
defined as s + 1."

(car can be defined as s[0]). The real difference is the lack of error
checking and the lack of cons.

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


bc at freeuk

Apr 10, 2012, 12:55 PM

Post #34 of 50 (1885 views)
Permalink
Re: f python? [In reply to]

"Shmuel (Seymour J.)Metz" <spamtrap [at] library> wrote in
message news:4f8410ff$2$fuzhry+tra$mr2ice [at] news
> In <20120409111329.694 [at] kylheku>, on 04/09/2012
> at 06:55 PM, Kaz Kylheku <kaz [at] kylheku> said:

>>If we scan for a null terminator which is not there, we have a
>>buffer overrun.
>
> You're only thinking of scanning an existing string; think of
> constructing a string. The null only indicates the current length, not
> the amount allocated.
>
>>If a length field in front of string data is incorrect, we also have
>>a buffer overrrun.
>
> The languages that I'm aware of that use a string length field also
> use a length field for the allocated storage. More precisely, they
> require that attempts to store beyond the allocated length be
> detected.

I would have thought trying to *read* beyond the current length would be an
error.

Writing beyond the current length, and perhaps beyond the current allocation
might be OK if the string is allowed grow, otherwise that's also an error.

In any case, there is no real need for an allocated length to be passed
around with the string, if you are only going to be reading it, or only
modifying the existing characters. And depending on the memory management
arrangements, such a length need not be stored at all.

--
Bartc


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


rweikusat at mssgmbh

Apr 10, 2012, 1:10 PM

Post #35 of 50 (1882 views)
Permalink
Re: f python? [In reply to]

Shmuel (Seymour J.) Metz <spamtrap [at] library> writes:
> In <20120409111329.694 [at] kylheku>, on 04/09/2012
> at 06:55 PM, Kaz Kylheku <kaz [at] kylheku> said:
>
>>Null-terminated C strings do the same thing.
>
> C arrays are not LISP strings; there is no C analog to car and cdr.

'car' and 'cdr' refer to cons cells in Lisp, not to strings. How the
first/rest terminology can be sensibly applied to 'C strings' (which
are similar to linked-lists in the sense that there's a 'special
termination value' instead of an explicit length) was already
explained elsewhere.
--
http://mail.python.org/mailman/listinfo/python-list


tjreedy at udel

Apr 10, 2012, 4:09 PM

Post #36 of 50 (1885 views)
Permalink
Re: f python? [In reply to]

On 4/10/2012 4:10 PM, Rainer Weikusat wrote:

> 'car' and 'cdr' refer to cons cells in Lisp, not to strings. How the
> first/rest terminology can be sensibly applied to 'C strings' (which
> are similar to linked-lists in the sense that there's a 'special
> termination value' instead of an explicit length) was already
> explained elsewhere.

The idea of partitioning a collection into one item and the rest can be
applied to any collection (or subcollection). Python iterators embody
this generic idea. An iterator represents a collection (or
subcollection). Built-in next(iter) either returns an item while
updating iter to represent the subcollection without the item, or raises
StopIteration. *How* to test emptiness, 'remove' an item, and mutate the
iterator are all implementation details hidden inside the iterator. They
are mostly irrelevant to the abstract operation of repeated partitioning
to process each item of a collection.

--
Terry Jan Reedy

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


spamtrap at library

Apr 10, 2012, 6:09 PM

Post #37 of 50 (1883 views)
Permalink
Re: f python? [In reply to]

In <87wr5nl54w.fsf [at] sapphire>, on 04/10/2012
at 09:10 PM, Rainer Weikusat <rweikusat [at] mssgmbh> said:

>'car' and 'cdr' refer to cons cells in Lisp, not to strings. How the
>first/rest terminology can be sensibly applied to 'C strings' (which
>are similar to linked-lists in the sense that there's a 'special
>termination value' instead of an explicit length)

A syringe is similar to a sturgeon in the sense that they both start
with S. LISP doesn't have arrays, and C doesn't allow you to insert
into the middle of an array.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap [at] library

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


w_a_x_man at yahoo

Apr 11, 2012, 3:55 AM

Post #38 of 50 (1883 views)
Permalink
Re: f python? [In reply to]

Xah Lee wrote:

>
> so recently i switched to a Windows version of python. Now, Windows
> version takes path using win backslash, instead of cygwin slash. This
> fucking broke my find/replace scripts that takes a dir level as input.
> Because i was counting slashes.

Slashes can work under windows, up to a point:

C:\>cd info/source

C:\info\source>


Also, most languages I use under windows allow you to use
slashes in paths:

C:\>ruby -e "puts IO.read( 'c:/info/frag' )"
275439
109999
102972
109999
102972
110000
102972
109999

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


kaz at kylheku

Apr 11, 2012, 7:06 AM

Post #39 of 50 (1882 views)
Permalink
Re: f python? [In reply to]

["Followup-To:" header set to comp.lang.lisp.]
On 2012-04-11, Shmuel Metz <spamtrap [at] library> wrote:
> In <87wr5nl54w.fsf [at] sapphire>, on 04/10/2012
> at 09:10 PM, Rainer Weikusat <rweikusat [at] mssgmbh> said:
>
>>'car' and 'cdr' refer to cons cells in Lisp, not to strings. How the
>>first/rest terminology can be sensibly applied to 'C strings' (which
>>are similar to linked-lists in the sense that there's a 'special
>>termination value' instead of an explicit length)
>
> A syringe is similar to a sturgeon in the sense that they both start
> with S. LISP doesn't have arrays, and C doesn't allow you to insert
> into the middle of an array.

Lisp, however, has arrays. (Not to mention hash tables, structures, and
classes). Where have you been since 1960-something?

(let ((array #(1 2 3 4)))
(aref array 3)) ;; -> 4, O(1) access
--
http://mail.python.org/mailman/listinfo/python-list


rweikusat at mssgmbh

Apr 11, 2012, 7:49 AM

Post #40 of 50 (1883 views)
Permalink
Re: f python? [In reply to]

Shmuel (Seymour J.) Metz <spamtrap [at] library> writes:
> In <87wr5nl54w.fsf [at] sapphire>, on 04/10/2012
> at 09:10 PM, Rainer Weikusat <rweikusat [at] mssgmbh> said:
>
>>'car' and 'cdr' refer to cons cells in Lisp, not to strings. How the
>>first/rest terminology can be sensibly applied to 'C strings' (which
>>are similar to linked-lists in the sense that there's a 'special
>>termination value' instead of an explicit length)
>
> A syringe is similar to a sturgeon in the sense that they both start
> with S.

And the original definition of 'idiot' is 'a guy who cannot learn
because he is too cocksure to already know everything'. Not that this
would matter in the given context ...

> LISP doesn't have arrays,

Lisp has arrays.

> and C doesn't allow you to insert
> into the middle of an array.

Well, of course it does: You just have to move the content of all
memory cells 'after' the new insert 'one up'. But unless I'm very much
mistaken, the topic was "first and rest" (car and cdr), as the terms
could be used with a C string and not "whatever Shmuel happens to
believe to know" ...
--
http://mail.python.org/mailman/listinfo/python-list


pjb at informatimago

Apr 11, 2012, 8:32 AM

Post #41 of 50 (1884 views)
Permalink
Re: f python? [In reply to]

Shmuel (Seymour J.) Metz <spamtrap [at] library> writes:

> In <87wr5nl54w.fsf [at] sapphire>, on 04/10/2012
> at 09:10 PM, Rainer Weikusat <rweikusat [at] mssgmbh> said:
>
>>'car' and 'cdr' refer to cons cells in Lisp, not to strings. How the
>>first/rest terminology can be sensibly applied to 'C strings' (which
>>are similar to linked-lists in the sense that there's a 'special
>>termination value' instead of an explicit length)
>
> A syringe is similar to a sturgeon in the sense that they both start
> with S. LISP doesn't have arrays, and C doesn't allow you to insert
> into the middle of an array.

You're confused. C doesn't have arrays. Lisp has arrays.
C only has vectors (Lisp has vectors too).

That C calls its vectors "array", or its bytes "char" doesn't change the
fact that C has no array and no character.


cl-user> (make-array '(3 4 5) :initial-element 42)
#3A(((42 42 42 42 42) (42 42 42 42 42) (42 42 42 42 42) (42 42 42 42 42))
((42 42 42 42 42) (42 42 42 42 42) (42 42 42 42 42) (42 42 42 42 42))
((42 42 42 42 42) (42 42 42 42 42) (42 42 42 42 42) (42 42 42 42 42)))

cl-user> (make-array 10 :initial-element 42)
#(42 42 42 42 42 42 42 42 42 42)



--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.
--
http://mail.python.org/mailman/listinfo/python-list


timr at probo

Apr 11, 2012, 10:16 PM

Post #42 of 50 (1886 views)
Permalink
Re: f python? [In reply to]

"WJ" <w_a_x_man [at] yahoo> wrote:
>
>Slashes can work under windows, up to a point:

ALL Windows APIs accept forward slashes. The only place they are not
accepted is command line commands that take options which can begin with
forward slash.

>Also, most languages I use under windows allow you to use
>slashes in paths:

All of them should do so. They're just string being passed to CreateFile,
and CreateFile accepts forward slashes just fine.
--
Tim Roberts, timr [at] probo
Providenza & Boekelheide, Inc.
--
http://mail.python.org/mailman/listinfo/python-list


spamtrap at library

Apr 14, 2012, 7:57 PM

Post #43 of 50 (1839 views)
Permalink
Re: f python? [In reply to]

In <87aa2iz3l1.fsf [at] kuiper>, on 04/11/2012
at 05:32 PM, "Pascal J. Bourguignon" <pjb [at] informatimago> said:

>You're confused. C doesn't have arrays. Lisp has arrays. C only has
>vectors

Neither C nor any other programming language has vectors ;-)

>That C calls its vectors "array", or its bytes "char" doesn't change
>the fact that C has no array and no character.

That various programming languages use the term "vector" for data
structures that are not vectors does not change the fact that they
don't have vectors.

If you're going to complain about C nomenclature, you'd have a much
better case complaining about "cast".

--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap [at] library

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


ian.g.kelly at gmail

Apr 15, 2012, 9:16 AM

Post #44 of 50 (1838 views)
Permalink
Re: f python? [In reply to]

On Sat, Apr 14, 2012 at 8:57 PM, Shmuel Metz
<spamtrap [at] library> wrote:
> In <87aa2iz3l1.fsf [at] kuiper>, on 04/11/2012
> † at 05:32 PM, "Pascal J. Bourguignon" <pjb [at] informatimago> said:
>
>>You're confused. C doesn't have arrays. †Lisp has arrays. C only has
>>vectors
>
> Neither C nor any other programming language has vectors ;-)

AFAIK, C++ nomenclature notwithstanding, a vector is just an array
with only one or indices, so all languages that have arrays have
vectors.
--
http://mail.python.org/mailman/listinfo/python-list


tjreedy at udel

Apr 15, 2012, 3:49 PM

Post #45 of 50 (1833 views)
Permalink
Re: f python? [In reply to]

On 4/15/2012 12:16 PM, Ian Kelly wrote:
> On Sat, Apr 14, 2012 at 8:57 PM, Shmuel Metz
> <spamtrap [at] library> wrote:
>> In<87aa2iz3l1.fsf [at] kuiper>, on 04/11/2012
>> at 05:32 PM, "Pascal J. Bourguignon"<pjb [at] informatimago> said:
>>
>>> You're confused. C doesn't have arrays. Lisp has arrays. C only has
>>> vectors
>>
>> Neither C nor any other programming language has vectors ;-)
>
> AFAIK, C++ nomenclature notwithstanding, a vector is just an array
> with only one or indices, so all languages that have arrays have
> vectors.

Vectors are magnitude with direction, often represented by 1-d array of
projections on coordinate axes. If a = 1,2,3 and b = 3,2,1 are
(mathematical) vectors, then a+b = 4,4,4; 2*a = 2,4,6; and a*b = (3+4+3)
= 10.

--
Terry Jan Reedy

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


ian.g.kelly at gmail

Apr 15, 2012, 3:59 PM

Post #46 of 50 (1837 views)
Permalink
Re: f python? [In reply to]

On Sun, Apr 15, 2012 at 4:49 PM, Terry Reedy <tjreedy [at] udel> wrote:
> On 4/15/2012 12:16 PM, Ian Kelly wrote:
>>
>> On Sat, Apr 14, 2012 at 8:57 PM, Shmuel †Metz
>> <spamtrap [at] library> †wrote:
>>>
>>> In<87aa2iz3l1.fsf [at] kuiper>, on 04/11/2012
>>> † at 05:32 PM, "Pascal J. Bourguignon"<pjb [at] informatimago> †said:
>>>
>>>> You're confused. C doesn't have arrays. †Lisp has arrays. C only has
>>>> vectors
>>>
>>>
>>> Neither C nor any other programming language has vectors ;-)
>>
>>
>> AFAIK, C++ nomenclature notwithstanding, a vector is just an array
>> with only one or indices, so all languages that have arrays have
>> vectors.
>
>
> Vectors are magnitude with direction, often represented by 1-d array of
> projections on coordinate axes. If a = 1,2,3 and b = 3,2,1 are
> (mathematical) vectors, then a+b = 4,4,4; 2*a = 2,4,6; and a*b = (3+4+3) =
> 10.

I'm referring to the programming usage, not the mathematical usage.
See definition #4 at dictionary.com, or definition #8 at wiktionary.
--
http://mail.python.org/mailman/listinfo/python-list


tjreedy at udel

Apr 15, 2012, 5:59 PM

Post #47 of 50 (1829 views)
Permalink
Re: f python? [In reply to]

On 4/15/2012 6:59 PM, Ian Kelly wrote:
> On Sun, Apr 15, 2012 at 4:49 PM, Terry Reedy<tjreedy [at] udel> wrote:
>> On 4/15/2012 12:16 PM, Ian Kelly wrote:
>>>
>>> On Sat, Apr 14, 2012 at 8:57 PM, Shmuel Metz
>>> <spamtrap [at] library> wrote:
>>>>
>>>> In<87aa2iz3l1.fsf [at] kuiper>, on 04/11/2012
>>>> at 05:32 PM, "Pascal J. Bourguignon"<pjb [at] informatimago> said:
>>>>
>>>>> You're confused. C doesn't have arrays. Lisp has arrays. C only has
>>>>> vectors

According to the authors of C, the C standard committee, and probably
hundreds of C authors, C has 'arrays', not 'vectors'. Fortran also has
'arrays', with some systems having hardware or software extensions for
vector (and matrix) processing (where vectors have the operations I
specify below and matrixes have *their* operations).
(See for instance https://en.wikipedia.org/wiki/Fortran )

>>>> Neither C nor any other programming language has vectors ;-)

Generally not as a built-in type, though vector functions that treat 1-d
arrays as vectors are common. So are added matrix classes and functions.

>>> AFAIK, C++ nomenclature notwithstanding, a vector is just an array
>>> with only one or indices, so all languages that have arrays have
>>> vectors.

Confusing representation with concept is not very helpful. In biology, a
vector is something that carries something from here to there. That is
related to the astronomical/geometric/mathematical meaning.

>> Vectors are magnitude with direction, often represented by 1-d array of
>> projections on coordinate axes. If a = 1,2,3 and b = 3,2,1 are
>> (mathematical) vectors, then a+b = 4,4,4; 2*a = 2,4,6; and a*b = (3+4+3) =
>> 10.

> I'm referring to the programming usage, not the mathematical usage.
> See definition #4 at dictionary.com, or definition #8 at wiktionary.

But you will not find that meaning in
http://www.merriam-webster.com/dictionary/vector

The mathematical usage *is* the programming usage in many programming
languages and communities -- including Python. CPython lists are
implemented as C arrays.

===
Terry Jan Reedy
--
http://mail.python.org/mailman/listinfo/python-list


briankp at yahoo

Nov 12, 2012, 2:07 PM

Post #48 of 50 (1638 views)
Permalink
Re: f python? [In reply to]

I totally agreed about the Python syntax. Why do I need to worry about the
syntax which wasted hours to get it to work?
Brain dead python designer! Maybe Guido need to learn it from the Master,
"Go to Ruby, and see how elegant the language is done. Also, it is stupid
of google to hire Guido to prolong the death of Python. No wonder a lot of
engineers left google because they don't pay enough. Vote for your feet,
googlers.

Python eventually will die once they found out Ruby don't have this dumb
issues. Guido, you're doing a wonderful job, wasting software programmers
on hours solving your Python Stupid Syntax ( Your dumb Global variable is
another example).

Google is too dumb to understand these issues.




--
View this message in context: http://python.6.n6.nabble.com/f-python-tp4708177p4995649.html
Sent from the Python - python-list mailing list archive at Nabble.com.
--
http://mail.python.org/mailman/listinfo/python-list


d at davea

Nov 12, 2012, 2:37 PM

Post #49 of 50 (1636 views)
Permalink
Re: f python? [In reply to]

On 11/12/2012 05:07 PM, Beekeeper2020 wrote:
> I totally agreed about the Python syntax. Why do I need to worry about the
> syntax which wasted hours to get it to work?
> Brain dead python designer! Maybe Guido need to learn it from the Master,
> "Go to Ruby, and see how elegant the language is done. Also, it is stupid
> of google to hire Guido to prolong the death of Python. No wonder a lot of
> engineers left google because they don't pay enough. Vote for your feet,
> googlers.
>
> Python eventually will die once they found out Ruby don't have this dumb
> issues. Guido, you're doing a wonderful job, wasting software programmers
> on hours solving your Python Stupid Syntax ( Your dumb Global variable is
> another example).
>
> Google is too dumb to understand these issues.
>
>

In case anybody is tempted to respond to this troll message, notice it's
a first-time poster, and it replies to a 7-month old message, and gives
no context.

Useless.


--

DaveA

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


steve+comp.lang.python at pearwood

Nov 12, 2012, 2:48 PM

Post #50 of 50 (1635 views)
Permalink
Re: f python? [In reply to]

On Mon, 12 Nov 2012 17:37:50 -0500, Dave Angel wrote:

> On 11/12/2012 05:07 PM, Beekeeper2020 wrote:
[...]
>> Python eventually will die once troll troll troll troll troll...

> In case anybody is tempted to respond to this troll message,

Like you did? Without trimming?

:-P




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

First page Previous page 1 2 Next page Last page  View All Python python RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.