In article <5317e640$0$29985$c3e8da3$54964...@news.astraweb.com>,
Steven D'Aprano wrote:
> On Wed, 05 Mar 2014 21:31:51 -0500, Roy Smith wrote:
>
> > In article <53176225$0$29987$c3e8da3$54964...@news.astraweb.com>,
> > Steven D'Aprano wrote:
> >
> >> Physics is the fundamental science, at l
On 2014-03-06, Roy Smith wrote:
> In article <53176225$0$29987$c3e8da3$54964...@news.astraweb.com>,
> Steven D'Aprano wrote:
>
>> Physics is the fundamental science, at least according to the
>> physicists, and Real Soon Now they'll have a Theory Of Everything,
>> something small enough to print
On Thu, Mar 6, 2014 at 2:06 PM, Steven D'Aprano
wrote:
> They ask a computer programmer to adjudicate who is right, so he writes a
> program to print out all the primes:
>
> 1 is prime
> 1 is prime
> 1 is prime
> 1 is prime
> 1 is prime
And he claimed that he was correct, because he had - as is k
On Wed, 05 Mar 2014 21:31:51 -0500, Roy Smith wrote:
> In article <53176225$0$29987$c3e8da3$54964...@news.astraweb.com>,
> Steven D'Aprano wrote:
>
>> Physics is the fundamental science, at least according to the
>> physicists, and Real Soon Now they'll have a Theory Of Everything,
>> something
In article <53176225$0$29987$c3e8da3$54964...@news.astraweb.com>,
Steven D'Aprano wrote:
> Physics is the fundamental science, at least according to the physicists,
> and Real Soon Now they'll have a Theory Of Everything, something small
> enough to print on a tee-shirt, which will explain eve
On 5 March 2014 17:43, Steven D'Aprano
wrote:
> On Wed, 05 Mar 2014 12:21:37 +, Oscar Benjamin wrote:
>>
>> The argument that the sum of all natural numbers comes to -1/12 is just
>> some kind of hoax. I don't think *anyone* seriously believes it.
>
> You would be wrong. I suggest you read the
On 2014-03-05, Chris Kaynor wrote:
> On Wed, Mar 5, 2014 at 9:43 AM, Steven D'Aprano <
> steve+comp.lang.pyt...@pearwood.info> wrote:
>
>> At one time, Euler summed an infinite series and got -1, from which he
>> concluded that -1 was (in some sense) larger than infinity. I don't know
>> what just
On Wed, Mar 5, 2014 at 9:43 AM, Steven D'Aprano <
steve+comp.lang.pyt...@pearwood.info> wrote:
> At one time, Euler summed an infinite series and got -1, from which he
> concluded that -1 was (in some sense) larger than infinity. I don't know
> what justification he gave, but the way I think of it
On Thu, Mar 6, 2014 at 4:43 AM, Steven D'Aprano
wrote:
> Physics is the fundamental science, at least according to the physicists,
> and Real Soon Now they'll have a Theory Of Everything, something small
> enough to print on a tee-shirt, which will explain everything. At least
> in principle.
Eve
On Wed, 05 Mar 2014 12:21:37 +, Oscar Benjamin wrote:
> On 5 March 2014 07:52, Steven D'Aprano wrote:
>> On Tue, 04 Mar 2014 23:25:37 -0500, Roy Smith wrote:
>>
>>> I stopped paying attention to mathematicians when they tried to
>>> convince me that the sum of all natural numbers is -1/12.
>>
On 5 March 2014 07:52, Steven D'Aprano wrote:
> On Tue, 04 Mar 2014 23:25:37 -0500, Roy Smith wrote:
>
>> I stopped paying attention to mathematicians when they tried to convince
>> me that the sum of all natural numbers is -1/12.
>
> I'm pretty sure they did not. Possibly a physicist may have tri
Mathematics?
The Flexible String Representation is a very nice example
of a mathematical absurdity.
jmf
PS Do not even think to expect to contradict me. Hint:
sheet of paper and pencil.
--
https://mail.python.org/mailman/listinfo/python-list
Following up on my own post.
On Wed, 05 Mar 2014 07:52:01 +, Steven D'Aprano wrote:
> On Tue, 04 Mar 2014 23:25:37 -0500, Roy Smith wrote:
>
>> I stopped paying attention to mathematicians when they tried to
>> convince me that the sum of all natural numbers is -1/12.
[...]
> In effect, the
On Tue, 04 Mar 2014 23:25:37 -0500, Roy Smith wrote:
> I stopped paying attention to mathematicians when they tried to convince
> me that the sum of all natural numbers is -1/12.
I'm pretty sure they did not. Possibly a physicist may have tried to tell
you that, but most mathematicians conside
In article ,
Rustom Mody wrote:
> I cannot find the exact quote so from memory Weyl says something to this
> effect:
>
> Cantor's diagonalization PROOF is not in question.
> Its CONCLUSION very much is.
> The classical/platonic mathematician (subject to wooly thinking) concludes
> that
> the
On Wednesday, March 5, 2014 9:11:13 AM UTC+5:30, Steven D'Aprano wrote:
> On Wed, 05 Mar 2014 02:15:14 +, Albert van der Horst wrote:
> > Adding cf's adds all computable numbers in infinite precision. However
> > that is not even a drop in the ocean, as the computable numbers have
> > measure
On Wed, 05 Mar 2014 02:15:14 +, Albert van der Horst wrote:
> Adding cf's adds all computable numbers in infinite precision. However
> that is not even a drop in the ocean, as the computable numbers have
> measure zero.
On the other hand, it's not really clear that the non-computable numbers
In article ,
Chris Angelico wrote:
>On Tue, Mar 4, 2014 at 1:45 PM, Albert van der Horst
> wrote:
>>>No, the Python built-in float type works with a subset of real numbers:
>>
>> To be more precise: a subset of the rational numbers, those with a
>> denominator
>> that is a power of two.
>
>And n
In article ,
Ian Kelly wrote:
>On Mon, Mar 3, 2014 at 11:35 PM, Chris Angelico wrote:
>> In constant space, that will produce the sum of two infinite sequences
>> of digits. (And it's constant time, too, except when it gets a stream
>> of nines. Adding three thirds together will produce an infin
On Tue, Mar 4, 2014 at 4:19 AM, Ian Kelly wrote:
> def cf_sqrt(n):
> """Yield the terms of the square root of n as a continued fraction."""
>m = 0
> d = 1
> a = a0 = floor_sqrt(n)
> while True:
> yield a
> next_m = d * a - m
> next_d = (n - next_m * next
On Mon, Mar 3, 2014 at 11:35 PM, Chris Angelico wrote:
> In constant space, that will produce the sum of two infinite sequences
> of digits. (And it's constant time, too, except when it gets a stream
> of nines. Adding three thirds together will produce an infinite loop
> as it waits to see if the
On Tue, Mar 4, 2014 at 4:53 PM, Steven D'Aprano wrote:
> On Tue, 04 Mar 2014 14:46:25 +1100, Chris Angelico wrote:
>
>> That's neat, didn't know that. Is there an efficient way to figure out,
>> for any integer N, what its sqrt's CF sequence is? And what about the
>> square roots of non-integers -
On Tue, 04 Mar 2014 14:46:25 +1100, Chris Angelico wrote:
> That's neat, didn't know that. Is there an efficient way to figure out,
> for any integer N, what its sqrt's CF sequence is? And what about the
> square roots of non-integers - can you represent √π that way? I suspect,
> though I can't pr
On Tuesday, March 4, 2014 9:16:25 AM UTC+5:30, Chris Angelico wrote:
> On Tue, Mar 4, 2014 at 2:13 PM, Rustom Mody wrote:
> >> But it's a far cry from "all real numbers". Even allowing for
> >> continued fractions adds only some more; I don't think you can
> >> represent surds that way.
> > See
>
On Tue, Mar 4, 2014 at 2:13 PM, Rustom Mody wrote:
>> But it's a far cry from "all real numbers". Even allowing for
>> continued fractions adds only some more; I don't think you can
>> represent surds that way.
>
> See
>
> http://www.maths.surrey.ac.uk/hosted-sites/R.Knott/Fibonacci/cfINTRO.html#s
On Tuesday, March 4, 2014 8:32:01 AM UTC+5:30, Chris Angelico wrote:
> On Tue, Mar 4, 2014 at 1:45 PM, Albert van der Horst wrote:
> >>No, the Python built-in float type works with a subset of real numbers:
> > To be more precise: a subset of the rational numbers, those with a
> > denominator
> >
On Tue, Mar 4, 2014 at 1:45 PM, Albert van der Horst
wrote:
>>No, the Python built-in float type works with a subset of real numbers:
>
> To be more precise: a subset of the rational numbers, those with a denominator
> that is a power of two.
And no more than N bits (53 in a 64-bit float) in the
In article ,
Chris Angelico wrote:
>On Wed, Feb 12, 2014 at 7:17 PM, Ben Finney wrote:
>> Chris Angelico writes:
>>
>>> I have yet to find any computer that works with the set of real
>>> numbers in any way. Never mind optimization, they simply cannot work
>>> with real numbers.
>>
>> Not *any*
"Grant Edwards" wrote:
Not *any* computer? Not in *any* way? The Python built-in "float"
type "works with the set of real numbers", in a way.
The only people who think that are people who don't actualy _use_
floating point types on computers.
FPU parsing the IEEE spec, or?. I didn't quite pa
On 2014-02-12, Ben Finney wrote:
> Chris Angelico writes:
>
>> I have yet to find any computer that works with the set of real
>> numbers in any way. Never mind optimization, they simply cannot work
>> with real numbers.
>
> Not *any* computer? Not in *any* way? The Python built-in "float"
> type
On Wednesday, February 12, 2014 7:55:32 PM UTC+5:30, Mark Lawrence wrote:
> On 12/02/2014 14:14, Rustom Mody wrote:
> > On Wednesday, February 12, 2014 7:34:42 PM UTC+5:30, Mark Lawrence wrote:
> >> I ask you, members of the jury, to find the accused, jmf, guilty of
> >> writing nonsense and delibe
On 12/02/2014 14:14, Rustom Mody wrote:
On Wednesday, February 12, 2014 7:34:42 PM UTC+5:30, Mark Lawrence wrote:
I ask you, members of the jury, to find the accused, jmf, guilty of
writing nonsense and deliberately using google groups to double line
space. The evidence is directly above and q
On Wednesday, February 12, 2014 7:34:42 PM UTC+5:30, Mark Lawrence wrote:
> I ask you, members of the jury, to find the accused, jmf, guilty of
> writing nonsense and deliberately using google groups to double line
> space. The evidence is directly above and quite clearly prooves, beyond
> a r
On 12/02/2014 07:49, wxjmfa...@gmail.com wrote:
Le mardi 11 février 2014 20:04:02 UTC+1, Mark Lawrence a écrit :
On 11/02/2014 18:53, wxjmfa...@gmail.com wrote:
Le lundi 10 février 2014 15:43:08 UTC+1, Tim Chase a écrit :
On 2014-02-10 06:07, wxjmfa...@gmail.com wrote:
Python does no
Chris Angelico writes:
> On Wed, Feb 12, 2014 at 7:57 PM, Jussi Piitulainen wrote:
> >> In Python, integers have arbitrary precision, but floats, Fractions,
> >> and Decimals, don't. Nearly any operation on arbitrarily large
> >> numbers will be either more accurate or more efficient (maybe both)
>
Chris Angelico writes:
> On Wed, Feb 12, 2014 at 7:17 PM, Ben Finney wrote:
> > What specific behaviour would, for you, qualify as “works with the
> > set of real numbers in any way”?
>
> Being able to represent surds, pi, e, etc, for a start. It'd
> theoretically be possible with an algebraic not
On Wed, Feb 12, 2014 at 7:57 PM, Jussi Piitulainen
wrote:
>> In Python, integers have arbitrary precision, but floats, Fractions,
>> and Decimals, don't. Nearly any operation on arbitrarily large
>> numbers will be either more accurate or more efficient (maybe both)
>> with integers than with any
Chris Angelico writes:
> On Wed, Feb 12, 2014 at 6:49 PM, wrote:
> > The day you find an operator working on the set of
> > reals (R) and it is somehow "optimized" for N
> > (the subset of natural numbers), let me know.
...
> In Python, integers have arbitrary precision, but floats, Fractions,
Le mercredi 12 février 2014 09:35:38 UTC+1, wxjm...@gmail.com a écrit :
> Integers are integers. (1)
>
> Characters are characters. (2)
>
>
>
> (1) is a unique "natural" set.
>
>
>
> (2) is an artificial construct working
>
> with 3 sets (unicode).
>
>
>
> jmf
Addendum: One should not c
On Wed, Feb 12, 2014 at 7:17 PM, Ben Finney wrote:
> Chris Angelico writes:
>
>> I have yet to find any computer that works with the set of real
>> numbers in any way. Never mind optimization, they simply cannot work
>> with real numbers.
>
> Not *any* computer? Not in *any* way? The Python built
Integers are integers. (1)
Characters are characters. (2)
(1) is a unique "natural" set.
(2) is an artificial construct working
with 3 sets (unicode).
jmf
--
https://mail.python.org/mailman/listinfo/python-list
Chris Angelico writes:
> I have yet to find any computer that works with the set of real
> numbers in any way. Never mind optimization, they simply cannot work
> with real numbers.
Not *any* computer? Not in *any* way? The Python built-in ‘float’ type
“works with the set of real numbers”, in a w
On Wed, Feb 12, 2014 at 6:49 PM, wrote:
> The day you find an operator working on the set of
> reals (R) and it is somehow "optimized" for N
> (the subset of natural numbers), let me know.
I have yet to find any computer that works with the set of real
numbers in any way. Never mind optimization
Le mardi 11 février 2014 20:04:02 UTC+1, Mark Lawrence a écrit :
> On 11/02/2014 18:53, wxjmfa...@gmail.com wrote:
>
> > Le lundi 10 février 2014 15:43:08 UTC+1, Tim Chase a écrit :
>
> >> On 2014-02-10 06:07, wxjmfa...@gmail.com wrote:
>
> >>
>
> >>> Python does not save memory at all. A str (
On 11/02/2014 18:53, wxjmfa...@gmail.com wrote:
Le lundi 10 février 2014 15:43:08 UTC+1, Tim Chase a écrit :
On 2014-02-10 06:07, wxjmfa...@gmail.com wrote:
Python does not save memory at all. A str (unicode string)
uses less memory only - and only - because and when one uses
explicitly
Le lundi 10 février 2014 15:43:08 UTC+1, Tim Chase a écrit :
> On 2014-02-10 06:07, wxjmfa...@gmail.com wrote:
>
> > Python does not save memory at all. A str (unicode string)
>
> > uses less memory only - and only - because and when one uses
>
> > explicitly characters which are consuming less
On 2014-02-10, Ned Batchelder wrote:
> On 2/10/14 9:43 AM, Tim Chase wrote:
>>> The opposite of what the utf8/utf16 do!
>>>
>> sys.getsizeof(('a' * 100 + 'oe' +
>> '\U0001').encode('utf-8'))
>>> 123
>> sys.getsizeof(('a' * 100 + 'oe' +
>> '\U0001').encode('utf-1
On 2/10/14 9:43 AM, Tim Chase wrote:
On 2014-02-10 06:07, wxjmfa...@gmail.com wrote:
Python does not save memory at all. A str (unicode string)
uses less memory only - and only - because and when one uses
explicitly characters which are consuming less memory.
Not only the memory gain is zero, P
On 2014-02-10 06:07, wxjmfa...@gmail.com wrote:
> Python does not save memory at all. A str (unicode string)
> uses less memory only - and only - because and when one uses
> explicitly characters which are consuming less memory.
>
> Not only the memory gain is zero, Python falls back to the
> wors
On 10/02/2014 14:25, Asaf Las wrote:
On Monday, February 10, 2014 4:07:14 PM UTC+2, wxjm...@gmail.com wrote:
Interesting
sys.getsizeof('a' * 100)
here you get string type
sys.getsizeof(('a' * 100 + 'oe' + '\U0001').encode('utf-8'))
and here bytes
type ('a' * 1)
type(('a
On Monday, February 10, 2014 4:07:14 PM UTC+2, wxjm...@gmail.com wrote:
Interesting
> >>> sys.getsizeof('a' * 100)
here you get string type
> >>> sys.getsizeof(('a' * 100 + 'oe' + '\U0001').encode('utf-8'))
and here bytes
>>> type ('a' * 1)
>>> type(('a' * 100 + 'oe' + '\U
Le samedi 8 février 2014 03:48:12 UTC+1, Steven D'Aprano a écrit :
>
>
> We consider it A GOOD THING that Python spends memory for programmer
>
> convenience and safety. Python looks for memory optimizations when it can
>
> save large amounts of memory, not utterly trivial amounts. So in a Py
On Sunday, February 9, 2014 8:46:50 AM UTC+5:30, Ned Batchelder wrote:
> On 2/8/14 10:09 PM, David Hutto wrote:
> > Maybe I'll just roll my fat, bald, troll arse out from under the bridge,
> > and comment back, off list, next time.
> I'm not sure what happened in this thread. It might be that you
On 2/8/14 10:09 PM, David Hutto wrote:
Maybe I'll just roll my fat, bald, troll arse out from under the bridge,
and comment back, off list, next time.
I'm not sure what happened in this thread. It might be that you think
Rustom Mody was referring to you when he said, "BTW: In my book this
Maybe I'll just roll my fat, bald, troll arse out from under the bridge,
and comment back, off list, next time.
--
https://mail.python.org/mailman/listinfo/python-list
On 2/8/14 9:56 PM, David Hutto wrote:
On Sat, Feb 8, 2014 at 8:25 PM, Rustom Mody mailto:rustompm...@gmail.com>> wrote:
On Sunday, February 9, 2014 4:15:50 AM UTC+5:30, David Hutto wrote:
> One could argue that if you're parsing a particular file, a very
large one, that those 9 b
On Sat, Feb 8, 2014 at 9:59 PM, Chris Angelico wrote:
> On Sun, Feb 9, 2014 at 1:56 PM, David Hutto
> wrote:
> >>
> >> Yes... There are cases when python is an inappropriate language to
> use...
> >> So???
> >
> >
> > I didn't say she couldn't optimize in another language, and was just
> > prot
On Sun, Feb 9, 2014 at 1:56 PM, David Hutto wrote:
>>
>> Yes... There are cases when python is an inappropriate language to use...
>> So???
>
>
> I didn't say she couldn't optimize in another language, and was just
> prototyping in Python. I just said she was optimizing her python
> code...dufus.
On Sat, Feb 8, 2014 at 8:25 PM, Rustom Mody wrote:
> On Sunday, February 9, 2014 4:15:50 AM UTC+5:30, David Hutto wrote:
> > One could argue that if you're parsing a particular file, a very large
> one, that those 9 bytes can go into the optimization of parsing
> aforementioned file. Of, course w
On Sunday, February 9, 2014 4:15:50 AM UTC+5:30, David Hutto wrote:
> One could argue that if you're parsing a particular file, a very large one,
> that those 9 bytes can go into the optimization of parsing aforementioned
> file. Of, course we have faster processors, so why care?
> Because it go
On Sat, Feb 8, 2014 at 8:17 AM, Mark Lawrence wrote:
> On 08/02/2014 02:48, Steven D'Aprano wrote:
>
>> On Thu, 06 Feb 2014 05:51:54 -0800, wxjmfauth wrote:
>>
>> Sorry, I'm only pointing you may lose memory when working with short
>>> strings as it was explained. I really, very really, do not se
On 08/02/2014 02:48, Steven D'Aprano wrote:
On Thu, 06 Feb 2014 05:51:54 -0800, wxjmfauth wrote:
Sorry, I'm only pointing you may lose memory when working with short
strings as it was explained. I really, very really, do not see what is
absurd or obsure in:
sys.getsizeof('abc' + 'EURO')
46
On 02/07/2014 06:48 PM, Steven D'Aprano wrote:
That is not a trade-off that the core developers have chosen to make,
and I agree with them.
Even though you haven't broken all the build-bots yet, you can still stop saying
"them". ;)
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/pyth
On Thu, 06 Feb 2014 05:51:54 -0800, wxjmfauth wrote:
> Sorry, I'm only pointing you may lose memory when working with short
> strings as it was explained. I really, very really, do not see what is
> absurd or obsure in:
>
sys.getsizeof('abc' + 'EURO')
> 46
sys.getsizeof(('abc' + 'EURO')
Some mysterious problem with the "euro".
Let's take a real "French" char.
>>> sys.getsizeof('abc' + 'œ')
46
>>> sys.getsizeof(('abc' + 'œ').encode('utf-32'))
37
or a "German" char, ẞ
>>> sys.getsizeof('abc' + '\N{LATIN CAPITAL LETTER SHARP S}')
46
>>> sys.getsizeof(('abc' + '\N{LATIN CAPITAL
Le jeudi 6 février 2014 12:10:08 UTC+1, Ned Batchelder a écrit :
> On 2/6/14 5:15 AM, wxjmfa...@gmail.com wrote:
>
>
>
>
>
> sum([sys.getsizeof(c) for c in ['a', 'a EURO', 'aa EURO']*3])
>
> > 336
>
> sum([sys.getsizeof(c) for c in ['aa EURO aa EURO']*3])
>
> > 150
>
> s
On 2/6/14 5:15 AM, wxjmfa...@gmail.com wrote:
sum([sys.getsizeof(c) for c in ['a', 'a EURO', 'aa EURO']*3])
336
sum([sys.getsizeof(c) for c in ['aa EURO aa EURO']*3])
150
sum([sys.getsizeof(c.encode('utf-32')) for c in ['a', 'a EURO', 'aa EURO']*3])
261
sum([sys.getsizeof(c.encode('utf-32
Le mercredi 5 février 2014 12:44:47 UTC+1, Chris Angelico a écrit :
> On Wed, Feb 5, 2014 at 10:00 PM, Steven D'Aprano
>
> wrote:
>
> >> where stopWords.txt is a file of size 4KB
>
> >
>
> > My guess is that if you split a 4K file into words, then put the words
>
> > into a list, you'll proba
On 05/02/2014 14:33, Ayushi Dalmia wrote:
Please stop sending double line spaced messages, just follow the
instructions here https://wiki.python.org/moin/GoogleGroupsPython to
prevent this happening, thanks.
--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can
On Wednesday, February 5, 2014 7:13:34 PM UTC+5:30, Dave Angel wrote:
> Ayushi Dalmia Wrote in message:
>
> > On Wednesday, February 5, 2014 12:59:46 AM UTC+5:30, Tim Chase wrote:
>
> >> On 2014-02-04 14:21, Dave Angel wrote:
>
> >>
>
> >> > To get the "total" size of a list of strings, try
Ayushi Dalmia Wrote in message:
> On Wednesday, February 5, 2014 12:59:46 AM UTC+5:30, Tim Chase wrote:
>> On 2014-02-04 14:21, Dave Angel wrote:
>>
>> > To get the "total" size of a list of strings, try (untested):
>>
>> >
>>
>> > a = sys.getsizeof (mylist )
>>
>> > for item in mylist:
>>
On Wed, Feb 5, 2014 at 10:00 PM, Steven D'Aprano
wrote:
>> where stopWords.txt is a file of size 4KB
>
> My guess is that if you split a 4K file into words, then put the words
> into a list, you'll probably end up with 6-8K in memory.
I'd guess rather more; Python strings have a fair bit of fixed
On Tue, 04 Feb 2014 21:35:05 -0800, Ayushi Dalmia wrote:
> On Wednesday, February 5, 2014 12:59:46 AM UTC+5:30, Tim Chase wrote:
>> On 2014-02-04 14:21, Dave Angel wrote:
>>
>> > To get the "total" size of a list of strings, try (untested):
>>
>> >
>> > a = sys.getsizeof (mylist )
>> > for ite
Ayushi Dalmia wrote:
> On Wednesday, February 5, 2014 12:51:31 AM UTC+5:30, Dave Angel wrote:
>> Ayushi Dalmia Wrote in message:
>>
>>
>>
>> >
>>
>> > Where am I going wrong? What are the alternatives I can try?
>>
>>
>>
>> You've rejected all the alternatives so far without showing your
On Wednesday, February 5, 2014 11:15:09 AM UTC+5:30, Rustom Mody wrote:
> On Wednesday, February 5, 2014 11:05:05 AM UTC+5:30, Ayushi Dalmia wrote:
>
> > This also doesn't gives the true size. I did the following:
>
>
>
> > import sys
>
> > data=[]
>
> > f=open('stopWords.txt','r')
>
>
>
>
On Wednesday, February 5, 2014 11:05:05 AM UTC+5:30, Ayushi Dalmia wrote:
> This also doesn't gives the true size. I did the following:
> import sys
> data=[]
> f=open('stopWords.txt','r')
> for line in f:
> line=line.split()
> data.extend(line)
> print sys.getsizeof(data)
> where stopW
On Wednesday, February 5, 2014 12:59:46 AM UTC+5:30, Tim Chase wrote:
> On 2014-02-04 14:21, Dave Angel wrote:
>
> > To get the "total" size of a list of strings, try (untested):
>
> >
>
> > a = sys.getsizeof (mylist )
>
> > for item in mylist:
>
> > a += sys.getsizeof (item)
>
>
>
>
On Wednesday, February 5, 2014 12:51:31 AM UTC+5:30, Dave Angel wrote:
> Ayushi Dalmia Wrote in message:
>
>
>
> >
>
> > Where am I going wrong? What are the alternatives I can try?
>
>
>
> You've rejected all the alternatives so far without showing your
>
> code, or even properly specif
On Tuesday, February 4, 2014 7:36:48 PM UTC+5:30, Dennis Lee Bieber wrote:
> On Tue, 4 Feb 2014 05:19:48 -0800 (PST), Ayushi Dalmia
>
> declaimed the following:
>
>
>
>
>
> >I need to chunk out the outputs otherwise it will give Memory Error. I need
> >to do some postprocessing on the data
On 04/02/2014 19:21, Dave Angel wrote:
Ayushi Dalmia Wrote in message:
Where am I going wrong? What are the alternatives I can try?
You've rejected all the alternatives so far without showing your
code, or even properly specifying your problem.
To get the "total" size of a list of stri
On 2014-02-04 14:21, Dave Angel wrote:
> To get the "total" size of a list of strings, try (untested):
>
> a = sys.getsizeof (mylist )
> for item in mylist:
> a += sys.getsizeof (item)
I always find this sort of accumulation weird (well, at least in
Python; it's the *only* way in many other
On Tuesday, February 4, 2014 6:23:19 PM UTC+5:30, Asaf Las wrote:
> On Tuesday, February 4, 2014 2:43:21 PM UTC+2, Ayushi Dalmia wrote:
>
> >
>
> > As I said, I need to merge large files and I cannot afford more I/O
>
> > operations. So in order to minimise the I/O operation I am writing in
>
On Tuesday, February 4, 2014 6:39:00 PM UTC+5:30, Dave Angel wrote:
> Ayushi Dalmia Wrote in message:
>
>
>
> >> getsizeof() gives you the size of the list only; to complete the picture
> >> you
>
> >>
>
> >> have to add the sizes of the lines.
>
> >>
>
> >>
>
> >>
>
> >> However,
Ayushi Dalmia Wrote in message:
>> getsizeof() gives you the size of the list only; to complete the picture you
>>
>> have to add the sizes of the lines.
>>
>>
>>
>> However, why do you want to keep track of the actual memory used by
>>
>> variables in your script? You should instead con
On Tuesday, February 4, 2014 2:43:21 PM UTC+2, Ayushi Dalmia wrote:
>
> As I said, I need to merge large files and I cannot afford more I/O
> operations. So in order to minimise the I/O operation I am writing in
> chunks. Also, I need to use the merged files as indexes later which
> should be l
On Tuesday, February 4, 2014 5:10:25 PM UTC+5:30, Peter Otten wrote:
> Ayushi Dalmia wrote:
>
>
>
> > I have 10 files and I need to merge them (using K way merging). The size
>
> > of each file is around 200 MB. Now suppose I am keeping the merged data in
>
> > a variable named mergedData, I h
Ayushi Dalmia wrote:
> I have 10 files and I need to merge them (using K way merging). The size
> of each file is around 200 MB. Now suppose I am keeping the merged data in
> a variable named mergedData, I had thought of checking the size of
> mergedData using sys.getsizeof() but it somehow doesn'
Hello,
I have 10 files and I need to merge them (using K way merging). The size of
each file is around 200 MB. Now suppose I am keeping the merged data in a
variable named mergedData, I had thought of checking the size of mergedData
using sys.getsizeof() but it somehow doesn't gives the actual
88 matches
Mail list logo
