Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #65415 > unrolled thread
| Started by | Ayushi Dalmia <ayushidalmia2604@gmail.com> |
|---|---|
| First post | 2014-02-04 03:28 -0800 |
| Last post | 2014-02-05 15:22 +0000 |
| Articles | 20 on this page of 159 — 30 participants |
Back to article view | Back to comp.lang.python
Finding size of Variable Ayushi Dalmia <ayushidalmia2604@gmail.com> - 2014-02-04 03:28 -0800
Re: Finding size of Variable Peter Otten <__peter__@web.de> - 2014-02-04 12:40 +0100
Re: Finding size of Variable Ayushi Dalmia <ayushidalmia2604@gmail.com> - 2014-02-04 04:43 -0800
Re: Finding size of Variable Asaf Las <roegltd@gmail.com> - 2014-02-04 04:53 -0800
Re: Finding size of Variable Ayushi Dalmia <ayushidalmia2604@gmail.com> - 2014-02-04 05:18 -0800
Re: Finding size of Variable Dave Angel <davea@davea.name> - 2014-02-04 08:09 -0500
Re: Finding size of Variable Ayushi Dalmia <ayushidalmia2604@gmail.com> - 2014-02-04 05:19 -0800
Re: Finding size of Variable Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-02-04 09:06 -0500
Re: Finding size of Variable Ayushi Dalmia <ayushidalmia2604@gmail.com> - 2014-02-04 21:00 -0800
Re:Finding size of Variable Dave Angel <davea@davea.name> - 2014-02-04 14:21 -0500
Re: Finding size of Variable Ayushi Dalmia <ayushidalmia2604@gmail.com> - 2014-02-04 21:15 -0800
Re: Finding size of Variable Peter Otten <__peter__@web.de> - 2014-02-05 09:27 +0100
Re: Finding size of Variable Tim Golden <mail@timgolden.me.uk> - 2014-02-04 19:28 +0000
Re: Finding size of Variable Tim Chase <python.list@tim.thechases.com> - 2014-02-04 13:29 -0600
Re: Finding size of Variable Ayushi Dalmia <ayushidalmia2604@gmail.com> - 2014-02-04 21:35 -0800
Re: Finding size of Variable Rustom Mody <rustompmody@gmail.com> - 2014-02-04 21:45 -0800
Re: Finding size of Variable Ayushi Dalmia <ayushidalmia2604@gmail.com> - 2014-02-04 22:00 -0800
Re: Finding size of Variable Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-02-05 11:00 +0000
Re: Finding size of Variable Chris Angelico <rosuav@gmail.com> - 2014-02-05 22:44 +1100
Re: Finding size of Variable wxjmfauth@gmail.com - 2014-02-06 02:15 -0800
Re: Finding size of Variable Ned Batchelder <ned@nedbatchelder.com> - 2014-02-06 06:10 -0500
Re: Finding size of Variable wxjmfauth@gmail.com - 2014-02-06 05:51 -0800
Re: Finding size of Variable wxjmfauth@gmail.com - 2014-02-06 06:15 -0800
Re: Finding size of Variable Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-02-08 02:48 +0000
Re: Finding size of Variable Ethan Furman <ethan@stoneleaf.us> - 2014-02-07 19:02 -0800
Re: Finding size of Variable Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-02-08 13:17 +0000
Re: Finding size of Variable David Hutto <dwightdhutto@gmail.com> - 2014-02-08 17:45 -0500
Re: Finding size of Variable Rustom Mody <rustompmody@gmail.com> - 2014-02-08 17:25 -0800
Re: Finding size of Variable David Hutto <dwightdhutto@gmail.com> - 2014-02-08 21:56 -0500
Re: Finding size of Variable Chris Angelico <rosuav@gmail.com> - 2014-02-09 13:59 +1100
Re: Finding size of Variable David Hutto <dwightdhutto@gmail.com> - 2014-02-08 22:07 -0500
Re: Finding size of Variable Ned Batchelder <ned@nedbatchelder.com> - 2014-02-08 22:09 -0500
Re: Finding size of Variable David Hutto <dwightdhutto@gmail.com> - 2014-02-08 22:09 -0500
Re: Finding size of Variable Ned Batchelder <ned@nedbatchelder.com> - 2014-02-08 22:16 -0500
Re: Finding size of Variable Rustom Mody <rustompmody@gmail.com> - 2014-02-08 19:30 -0800
Re: Finding size of Variable wxjmfauth@gmail.com - 2014-02-10 06:07 -0800
Re: Finding size of Variable Asaf Las <roegltd@gmail.com> - 2014-02-10 06:25 -0800
Re: Finding size of Variable Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-02-10 14:39 +0000
Re: Finding size of Variable Tim Chase <python.list@tim.thechases.com> - 2014-02-10 08:43 -0600
Re: Finding size of Variable wxjmfauth@gmail.com - 2014-02-11 10:53 -0800
Re: Finding size of Variable Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-02-11 19:04 +0000
Re: Finding size of Variable wxjmfauth@gmail.com - 2014-02-11 23:49 -0800
Re: Finding size of Variable Chris Angelico <rosuav@gmail.com> - 2014-02-12 19:06 +1100
Re: Finding size of Variable Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2014-02-12 10:57 +0200
Re: Finding size of Variable Chris Angelico <rosuav@gmail.com> - 2014-02-12 20:24 +1100
Re: Finding size of Variable Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2014-02-12 11:35 +0200
Working with the set of real numbers (was: Finding size of Variable) Ben Finney <ben+python@benfinney.id.au> - 2014-02-12 19:17 +1100
Re: Working with the set of real numbers (was: Finding size of Variable) wxjmfauth@gmail.com - 2014-02-12 00:35 -0800
Re: Working with the set of real numbers (was: Finding size of Variable) wxjmfauth@gmail.com - 2014-02-12 00:46 -0800
Re: Working with the set of real numbers Ben Finney <ben+python@benfinney.id.au> - 2014-02-12 19:52 +1100
Re: Working with the set of real numbers (was: Finding size of Variable) Grant Edwards <invalid@invalid.invalid> - 2014-02-12 15:24 +0000
Re: Working with the set of real numbers (was: Finding size of Variable) "Gisle Vanem" <gvanem@yahoo.no> - 2014-02-12 17:23 +0100
Re: Working with the set of real numbers (was: Finding size of Variable) Chris Angelico <rosuav@gmail.com> - 2014-02-12 19:47 +1100
Re: Working with the set of real numbers (was: Finding size of Variable) Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2014-02-12 11:23 +0200
Re: Working with the set of real numbers (was: Finding size of Variable) albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-03-04 02:45 +0000
Re: Working with the set of real numbers (was: Finding size of Variable) Chris Angelico <rosuav@gmail.com> - 2014-03-04 14:02 +1100
Re: Working with the set of real numbers (was: Finding size of Variable) Rustom Mody <rustompmody@gmail.com> - 2014-03-03 19:13 -0800
Re: Working with the set of real numbers (was: Finding size of Variable) Chris Angelico <rosuav@gmail.com> - 2014-03-04 14:46 +1100
Re: Working with the set of real numbers (was: Finding size of Variable) Rustom Mody <rustompmody@gmail.com> - 2014-03-03 21:19 -0800
Re: Working with the set of real numbers (was: Finding size of Variable) Steven D'Aprano <steve@pearwood.info> - 2014-03-04 05:53 +0000
Re: Working with the set of real numbers (was: Finding size of Variable) Chris Angelico <rosuav@gmail.com> - 2014-03-04 17:35 +1100
Re: Working with the set of real numbers Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-03-05 00:05 +1300
Re: Working with the set of real numbers Chris Angelico <rosuav@gmail.com> - 2014-03-04 23:43 +1100
Re: Working with the set of real numbers Marko Rauhamaa <marko@pacujo.net> - 2014-03-04 21:49 +0200
Re: Working with the set of real numbers Chris Angelico <rosuav@gmail.com> - 2014-03-05 06:58 +1100
Re: Working with the set of real numbers Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2014-03-04 20:55 +0000
Re: Working with the set of real numbers Marko Rauhamaa <marko@pacujo.net> - 2014-03-04 23:05 +0200
Re: Working with the set of real numbers Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2014-03-04 22:08 +0000
Re: Working with the set of real numbers Chris Angelico <rosuav@gmail.com> - 2014-03-05 08:18 +1100
Re: Working with the set of real numbers Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2014-03-04 22:02 +0000
Re: Working with the set of real numbers Chris Angelico <rosuav@gmail.com> - 2014-03-05 09:18 +1100
Re: Working with the set of real numbers Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2014-03-04 22:54 +0000
Re: Working with the set of real numbers Chris Angelico <rosuav@gmail.com> - 2014-03-05 10:01 +1100
Re: Working with the set of real numbers Dave Angel <davea@davea.name> - 2014-03-04 18:20 -0500
Re: Working with the set of real numbers Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2014-03-05 11:59 +0000
Re: Working with the set of real numbers Dave Angel <davea@davea.name> - 2014-03-05 07:57 -0500
Re: Working with the set of real numbers Dave Angel <davea@davea.name> - 2014-03-05 08:32 -0500
Re: Working with the set of real numbers Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2014-03-06 12:27 +0000
Re: Working with the set of real numbers Chris Angelico <rosuav@gmail.com> - 2014-03-07 00:16 +1100
Re: Working with the set of real numbers (was: Finding size of Variable) Ian Kelly <ian.g.kelly@gmail.com> - 2014-03-04 04:19 -0700
Re: Working with the set of real numbers (was: Finding size of Variable) albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-03-05 02:27 +0000
Re: Working with the set of real numbers (was: Finding size of Variable) Ian Kelly <ian.g.kelly@gmail.com> - 2014-03-04 04:23 -0700
Re: Working with the set of real numbers (was: Finding size of Variable) albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-03-05 02:15 +0000
Re: Working with the set of real numbers (was: Finding size of Variable) Steven D'Aprano <steve@pearwood.info> - 2014-03-05 03:41 +0000
Re: Working with the set of real numbers (was: Finding size of Variable) Rustom Mody <rustompmody@gmail.com> - 2014-03-04 20:15 -0800
Re: Working with the set of real numbers (was: Finding size of Variable) Roy Smith <roy@panix.com> - 2014-03-04 23:25 -0500
Re: Working with the set of real numbers Ben Finney <ben+python@benfinney.id.au> - 2014-03-05 15:37 +1100
Re: Working with the set of real numbers Rustom Mody <rustompmody@gmail.com> - 2014-03-04 20:57 -0800
Re: Working with the set of real numbers Roy Smith <roy@panix.com> - 2014-03-05 00:29 -0500
Re: Working with the set of real numbers (was: Finding size of Variable) Steven D'Aprano <steve@pearwood.info> - 2014-03-05 07:52 +0000
Re: Working with the set of real numbers (was: Finding size of Variable) Steven D'Aprano <steve@pearwood.info> - 2014-03-05 08:38 +0000
Re: Working with the set of real numbers (was: Finding size of Variable) wxjmfauth@gmail.com - 2014-03-05 01:00 -0800
Re: Working with the set of real numbers Ned Batchelder <ned@nedbatchelder.com> - 2014-03-05 06:23 -0500
Re: Working with the set of real numbers (was: Finding size of Variable) Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2014-03-05 12:21 +0000
Re: Working with the set of real numbers (was: Finding size of Variable) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-05 17:43 +0000
Re: Working with the set of real numbers (was: Finding size of Variable) Chris Angelico <rosuav@gmail.com> - 2014-03-06 05:01 +1100
Re: Working with the set of real numbers (was: Finding size of Variable) Chris Kaynor <ckaynor@zindagigames.com> - 2014-03-05 10:03 -0800
Re: Working with the set of real numbers (was: Finding size of Variable) Grant Edwards <invalid@invalid.invalid> - 2014-03-05 19:13 +0000
Re: Working with the set of real numbers (was: Finding size of Variable) Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2014-03-05 21:22 +0000
Re: Working with the set of real numbers (was: Finding size of Variable) Roy Smith <roy@panix.com> - 2014-03-05 21:31 -0500
Re: Working with the set of real numbers (was: Finding size of Variable) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-06 03:06 +0000
Re: Working with the set of real numbers (was: Finding size of Variable) Chris Angelico <rosuav@gmail.com> - 2014-03-06 14:14 +1100
Re: Working with the set of real numbers (was: Finding size of Variable) Roy Smith <roy@panix.com> - 2014-03-05 23:05 -0500
Re: Working with the set of real numbers (was: Finding size of Variable) Grant Edwards <invalid@invalid.invalid> - 2014-03-06 03:34 +0000
Re: Working with the set of real numbers Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-03-05 12:50 +0000
Re: Working with the set of real numbers Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-05 17:49 +0000
Re: Working with the set of real numbers Ben Finney <ben+python@benfinney.id.au> - 2014-02-12 19:56 +1100
Re: Working with the set of real numbers Chris Angelico <rosuav@gmail.com> - 2014-02-12 20:16 +1100
Re: Working with the set of real numbers Ben Finney <ben+python@benfinney.id.au> - 2014-02-12 21:07 +1100
Re: Working with the set of real numbers Rustom Mody <rustompmody@gmail.com> - 2014-02-12 06:11 -0800
Re: Working with the set of real numbers Ian Kelly <ian.g.kelly@gmail.com> - 2014-02-12 13:45 -0700
Re: Working with the set of real numbers Rustom Mody <rustompmody@gmail.com> - 2014-02-12 17:47 -0800
Re: Working with the set of real numbers Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-02-13 11:09 +1300
Re: Working with the set of real numbers Steven D'Aprano <steve@pearwood.info> - 2014-02-13 03:31 +0000
Re: Working with the set of real numbers Ben Finney <ben+python@benfinney.id.au> - 2014-02-13 14:45 +1100
Re: Working with the set of real numbers Chris Angelico <rosuav@gmail.com> - 2014-02-13 15:17 +1100
Re: Working with the set of real numbers Chris Angelico <rosuav@gmail.com> - 2014-02-12 21:20 +1100
Re: Working with the set of real numbers wxjmfauth@gmail.com - 2014-02-12 02:55 -0800
Re: Working with the set of real numbers Ned Batchelder <ned@nedbatchelder.com> - 2014-02-12 06:55 -0500
Re: Working with the set of real numbers Marko Rauhamaa <marko@pacujo.net> - 2014-02-12 14:48 +0200
Re: Working with the set of real numbers Chris Angelico <rosuav@gmail.com> - 2014-02-13 00:20 +1100
Re: Working with the set of real numbers Marko Rauhamaa <marko@pacujo.net> - 2014-02-12 16:13 +0200
Re: Working with the set of real numbers Chris Angelico <rosuav@gmail.com> - 2014-02-13 04:52 +1100
Re: Working with the set of real numbers Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-02-13 11:24 +1300
Re: Working with the set of real numbers Dave Angel <davea@davea.name> - 2014-02-12 17:56 -0500
Re: Working with the set of real numbers Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-02-14 18:26 +1300
Re: Working with the set of real numbers Ben Finney <ben+python@benfinney.id.au> - 2014-02-12 22:44 +1100
Re: Working with the set of real numbers Chris Angelico <rosuav@gmail.com> - 2014-02-12 22:58 +1100
Re: Working with the set of real numbers Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-02-13 11:32 +1300
Re: Working with the set of real numbers Grant Edwards <invalid@invalid.invalid> - 2014-02-12 23:23 +0000
Re: Finding size of Variable Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-02-12 14:04 +0000
Re: Finding size of Variable Rustom Mody <rustompmody@gmail.com> - 2014-02-12 06:14 -0800
Re: Finding size of Variable Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-02-12 14:25 +0000
Re: Finding size of Variable Rustom Mody <rustompmody@gmail.com> - 2014-02-12 06:32 -0800
Re: Working with the set of real numbers Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2014-02-13 12:48 +0000
Re: Working with the set of real numbers Marko Rauhamaa <marko@pacujo.net> - 2014-02-13 16:00 +0200
Re: Working with the set of real numbers Chris Angelico <rosuav@gmail.com> - 2014-02-14 06:25 +1100
Re: Working with the set of real numbers Marko Rauhamaa <marko@pacujo.net> - 2014-02-13 21:47 +0200
Re: Working with the set of real numbers Chris Angelico <rosuav@gmail.com> - 2014-02-14 07:08 +1100
Re: Working with the set of real numbers Devin Jeanpierre <jeanpierreda@gmail.com> - 2014-02-13 22:05 -0800
Re: Working with the set of real numbers Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-02-15 00:30 +1300
Re: Working with the set of real numbers Devin Jeanpierre <jeanpierreda@gmail.com> - 2014-02-14 16:26 -0800
Re: Working with the set of real numbers albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-03-05 02:38 +0000
Re: Working with the set of real numbers Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-02-14 19:37 +1300
Re: Working with the set of real numbers Chris Angelico <rosuav@gmail.com> - 2014-02-14 17:44 +1100
Re: Working with the set of real numbers Rustom Mody <rustompmody@gmail.com> - 2014-02-14 07:13 -0800
Re: Working with the set of real numbers Dave Angel <davea@davea.name> - 2014-02-14 07:30 -0500
Re: Working with the set of real numbers Grant Edwards <invalid@invalid.invalid> - 2014-02-14 15:09 +0000
Re: Working with the set of real numbers Rotwang <sg552@hotmail.co.uk> - 2014-02-13 21:29 +0000
Re: Working with the set of real numbers Marko Rauhamaa <marko@pacujo.net> - 2014-02-14 00:00 +0200
Re: Working with the set of real numbers Rotwang <sg552@hotmail.co.uk> - 2014-02-13 22:21 +0000
Re: Working with the set of real numbers Marko Rauhamaa <marko@pacujo.net> - 2014-02-14 01:16 +0200
Re: Working with the set of real numbers Ben Finney <ben+python@benfinney.id.au> - 2014-02-14 03:57 +1100
Re: Finding size of Variable Ned Batchelder <ned@nedbatchelder.com> - 2014-02-10 10:02 -0500
Re: Finding size of Variable Neil Cerutti <neilc@norwich.edu> - 2014-02-11 14:29 +0000
Re: Finding size of Variable Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-02-05 22:14 -0500
Re: Finding size of Variable Dave Angel <davea@davea.name> - 2014-02-05 08:43 -0500
Re: Finding size of Variable Ayushi Dalmia <ayushidalmia2604@gmail.com> - 2014-02-05 06:33 -0800
Re: Finding size of Variable Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-02-05 15:22 +0000
Page 3 of 8 — ← Prev page 1 2 [3] 4 5 6 7 8 Next page →
| From | Mark Lawrence <breamoreboy@yahoo.co.uk> |
|---|---|
| Date | 2014-02-11 19:04 +0000 |
| Message-ID | <mailman.6695.1392145462.18130.python-list@python.org> |
| In reply to | #65944 |
On 11/02/2014 18:53, wxjmfauth@gmail.com wrote:
> Le lundi 10 février 2014 15:43:08 UTC+1, Tim Chase a écrit :
>> On 2014-02-10 06:07, wxjmfauth@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
>>
>>> worse case.
>>
>>>
>>
>>>>>> sys.getsizeof('a' * 1000000)
>>
>>> 1000025
>>
>>>>>> sys.getsizeof('a' * 1000000 + 'oe')
>>
>>> 2000040
>>
>>>>>> sys.getsizeof('a' * 1000000 + 'oe' + '\U00010000')
>>
>>> 4000048
>>
>>
>>
>> If Python used UTF-32 for EVERYTHING, then all three of those cases
>>
>> would be 4000048, so it clearly disproves your claim that "python
>>
>> does not save memory at all".
>>
>>
>>
>>> The opposite of what the utf8/utf16 do!
>>
>>>
>>
>>>>>> sys.getsizeof(('a' * 1000000 + 'oe' +
>>
>>>>>> '\U00010000').encode('utf-8'))
>>
>>> 1000023
>>
>>>>>> sys.getsizeof(('a' * 1000000 + 'oe' +
>>
>>>>>> '\U00010000').encode('utf-16'))
>>
>>> 2000025
>>
>>
>>
>> However, as pointed out repeatedly, string-indexing in fixed-width
>>
>> encodings are O(1) while indexing into variable-width encodings (e.g.
>>
>> UTF8/UTF16) are O(N). The FSR gives the benefits of O(1) indexing
>>
>> while saving space when a string doesn't need to use a full 32-bit
>>
>> width.
>>
>>
>
> A utf optimizes the memory and the performance at the same time.
> It behaves like a mathematical operator, a unique operator for
> a unique set of elements. Unbeatable.
>
> The FSR is an exclusive or mechanism. I you wish to
> same memory, you have to encode, and if you are encoding,
> maybe because you have to, one loses performance. Paradoxal.
>
> Your O(1) indexing works only and only because and
> when you are working explicitly with a "static" unicode
> string you never touch.
> It's a little bit the the "corresponding" performance
> case of the memory case.
>
> jmf
>
Why are you so rude as to continually post your nonsense here that not a
single person believes, and at the same time still quite deliberately
use gg to post it with double line spacing. If you lack the courtesy to
stop the former, please have the courtesy to stop the latter.
--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.
Mark Lawrence
---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com
[toc] | [prev] | [next] | [standalone]
| From | wxjmfauth@gmail.com |
|---|---|
| Date | 2014-02-11 23:49 -0800 |
| Message-ID | <71e578f8-0d23-4b8e-b9f2-b987bdc9c01d@googlegroups.com> |
| In reply to | #65948 |
Le mardi 11 février 2014 20:04:02 UTC+1, Mark Lawrence a écrit :
> On 11/02/2014 18:53, wxjmfauth@gmail.com wrote:
>
> > Le lundi 10 février 2014 15:43:08 UTC+1, Tim Chase a écrit :
>
> >> On 2014-02-10 06:07, wxjmfauth@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
>
> >>
>
> >>> worse case.
>
> >>
>
> >>>
>
> >>
>
> >>>>>> sys.getsizeof('a' * 1000000)
>
> >>
>
> >>> 1000025
>
> >>
>
> >>>>>> sys.getsizeof('a' * 1000000 + 'oe')
>
> >>
>
> >>> 2000040
>
> >>
>
> >>>>>> sys.getsizeof('a' * 1000000 + 'oe' + '\U00010000')
>
> >>
>
> >>> 4000048
>
> >>
>
> >>
>
> >>
>
> >> If Python used UTF-32 for EVERYTHING, then all three of those cases
>
> >>
>
> >> would be 4000048, so it clearly disproves your claim that "python
>
> >>
>
> >> does not save memory at all".
>
> >>
>
> >>
>
> >>
>
> >>> The opposite of what the utf8/utf16 do!
>
> >>
>
> >>>
>
> >>
>
> >>>>>> sys.getsizeof(('a' * 1000000 + 'oe' +
>
> >>
>
> >>>>>> '\U00010000').encode('utf-8'))
>
> >>
>
> >>> 1000023
>
> >>
>
> >>>>>> sys.getsizeof(('a' * 1000000 + 'oe' +
>
> >>
>
> >>>>>> '\U00010000').encode('utf-16'))
>
> >>
>
> >>> 2000025
>
> >>
>
> >>
>
> >>
>
> >> However, as pointed out repeatedly, string-indexing in fixed-width
>
> >>
>
> >> encodings are O(1) while indexing into variable-width encodings (e.g.
>
> >>
>
> >> UTF8/UTF16) are O(N). The FSR gives the benefits of O(1) indexing
>
> >>
>
> >> while saving space when a string doesn't need to use a full 32-bit
>
> >>
>
> >> width.
>
> >>
>
> >>
>
> >
>
> > A utf optimizes the memory and the performance at the same time.
>
> > It behaves like a mathematical operator, a unique operator for
>
> > a unique set of elements. Unbeatable.
>
> >
>
> > The FSR is an exclusive or mechanism. I you wish to
>
> > same memory, you have to encode, and if you are encoding,
>
> > maybe because you have to, one loses performance. Paradoxal.
>
> >
>
> > Your O(1) indexing works only and only because and
>
> > when you are working explicitly with a "static" unicode
>
> > string you never touch.
>
> > It's a little bit the the "corresponding" performance
>
> > case of the memory case.
>
> >
>
> > jmf
>
> >
>
>
>
> Why are you so rude as to continually post your nonsense here that not a
>
> single person believes, and at the same time still quite deliberately
>
> use gg to post it with double line spacing. If you lack the courtesy to
>
> stop the former, please have the courtesy to stop the latter.
>
>
>
> --
>
> My fellow Pythonistas, ask not what our language can do for you, ask
>
> what you can do for our language.
>
>
Nonsense?
>>> sys.getsizeof('') - sys.getsizeof('a')
-1
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.
A conflict is quickly appearing. Either the operator is
not correctly defined or the choice of the set is wrong.
You can replace the "operator" with an "encoding" and
the "set" with a "repertoire of characters".
It's the main reason, why we have to live today with
all these coding schemes. Even in more sophisticated
cases like, CID-fonts or "char boxes" in a pdf (with the
hope you understand how it works).
jmf
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2014-02-12 19:06 +1100 |
| Message-ID | <mailman.6732.1392192393.18130.python-list@python.org> |
| In reply to | #66004 |
On Wed, Feb 12, 2014 at 6:49 PM, <wxjmfauth@gmail.com> 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, they simply cannot work with real numbers. As to operations that are optimized for integers (usually not for naturals - supporting zero and negatives isn't hard), they are legion. 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 of the other types. Letting you know, that's all. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Jussi Piitulainen <jpiitula@ling.helsinki.fi> |
|---|---|
| Date | 2014-02-12 10:57 +0200 |
| Message-ID | <qotmwhwk8s1.fsf@ruuvi.it.helsinki.fi> |
| In reply to | #66006 |
Chris Angelico writes: > On Wed, Feb 12, 2014 at 6:49 PM, <wxjmfauth@gmail.com> 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, > 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 of the other types. Is that true about Fractions?
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2014-02-12 20:24 +1100 |
| Message-ID | <mailman.6741.1392197059.18130.python-list@python.org> |
| In reply to | #66015 |
On Wed, Feb 12, 2014 at 7:57 PM, Jussi Piitulainen <jpiitula@ling.helsinki.fi> 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 of the other types. > > Is that true about Fractions? I'm not 100% sure if fraction.Fraction and decimal.Decimal ever limit the size or precision of their data, but certainly if they don't, it'll be at horrendous expense of performance. (Decimal can add and subtract in reasonable time complexity, but multiplication and division will get slow when you have huge numbers of digits. Fraction can multiply and divide efficiently, but will get crazily slow on addition and subtraction.) Integers are an optimized case in many ways. I can do accurate arbitrary-precision integer arithmetic without worrying about simple operations suddenly saturating the CPU. I can't do that with non-integers in any way. It's not optimized for natural numbers (nonnegative integers), as negatives are just as cheap as positives, but it's certainly an optimization for integers. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Jussi Piitulainen <jpiitula@ling.helsinki.fi> |
|---|---|
| Date | 2014-02-12 11:35 +0200 |
| Message-ID | <qoteh38k71h.fsf@ruuvi.it.helsinki.fi> |
| In reply to | #66019 |
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) > >> with integers than with any of the other types. > > > > Is that true about Fractions? > > I'm not 100% sure if fraction.Fraction and decimal.Decimal ever limit > the size or precision of their data, but certainly if they don't, > it'll be at horrendous expense of performance. (Decimal can add and > subtract in reasonable time complexity, but multiplication and > division will get slow when you have huge numbers of digits. Fraction > can multiply and divide efficiently, but will get crazily slow on > addition and subtraction.) Integers are an optimized case in many > ways. I can do accurate arbitrary-precision integer arithmetic without > worrying about simple operations suddenly saturating the CPU. I can't > do that with non-integers in any way. > > It's not optimized for natural numbers (nonnegative integers), as > negatives are just as cheap as positives, but it's certainly an > optimization for integers. Right. I don't know about Decimal, but I don't think there are any precision restrictions in Fraction, other than running out of heap (or possibly integer precision). In my (quite limited) experience, the most expensive operation on both exact rationals and exact integers has been the printing, in decimal, of several screenfuls of digits. The actual calculations have taken a couple of seconds and then I have wished that I could interrupt the printing of a single number :)
[toc] | [prev] | [next] | [standalone]
| From | Ben Finney <ben+python@benfinney.id.au> |
|---|---|
| Date | 2014-02-12 19:17 +1100 |
| Subject | Working with the set of real numbers (was: Finding size of Variable) |
| Message-ID | <mailman.6734.1392193040.18130.python-list@python.org> |
| In reply to | #66004 |
Chris Angelico <rosuav@gmail.com> 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 way. The <URL:http://docs.python.org/2/library/numbers.html#numbers.Real> ABC defines behaviours for types implementing the set of real numbers. What specific behaviour would, for you, qualify as “works with the set of real numbers in any way”? -- \ “The fact that I have no remedy for all the sorrows of the | `\ world is no reason for my accepting yours. It simply supports | _o__) the strong probability that yours is a fake.” —Henry L. Mencken | Ben Finney
[toc] | [prev] | [next] | [standalone]
| From | wxjmfauth@gmail.com |
|---|---|
| Date | 2014-02-12 00:35 -0800 |
| Subject | Re: Working with the set of real numbers (was: Finding size of Variable) |
| Message-ID | <f06bb5d6-53d7-496c-8e79-ee1f05f3795d@googlegroups.com> |
| In reply to | #66008 |
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
[toc] | [prev] | [next] | [standalone]
| From | wxjmfauth@gmail.com |
|---|---|
| Date | 2014-02-12 00:46 -0800 |
| Subject | Re: Working with the set of real numbers (was: Finding size of Variable) |
| Message-ID | <df2776ba-90be-4759-971b-aa36373ae4c0@googlegroups.com> |
| In reply to | #66009 |
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 confuse unicode and the implementation of unicode. jmf
[toc] | [prev] | [next] | [standalone]
| From | Ben Finney <ben+python@benfinney.id.au> |
|---|---|
| Date | 2014-02-12 19:52 +1100 |
| Subject | Re: Working with the set of real numbers |
| Message-ID | <mailman.6738.1392195185.18130.python-list@python.org> |
| In reply to | #66009 |
wxjmfauth@gmail.com writes: > (2) is an artificial construct working > with 3 sets (unicode). jmf, you are being exceedingly disruptive: attempting to derail unrelated discussions for your favourite hobby-horse topic. Please stop. Everyone else: Please don't engage these attempts; instead, avoid engaging with this trollish behaviour. -- \ “… one of the main causes of the fall of the Roman Empire was | `\ that, lacking zero, they had no way to indicate successful | _o__) termination of their C programs.” —Robert Firth | Ben Finney
[toc] | [prev] | [next] | [standalone]
| From | Grant Edwards <invalid@invalid.invalid> |
|---|---|
| Date | 2014-02-12 15:24 +0000 |
| Subject | Re: Working with the set of real numbers (was: Finding size of Variable) |
| Message-ID | <ldg3nt$cti$3@reader1.panix.com> |
| In reply to | #66008 |
On 2014-02-12, Ben Finney <ben+python@benfinney.id.au> wrote:
> Chris Angelico <rosuav@gmail.com> 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 way.
The only people who think that are people who don't actualy _use_
floating point types on computers.
> What specific behaviour would, for you, qualify as "works with the
> set of real numbers in any way"
There's a whole laundry list of things (some of them rather nasty and
difficult) you have to worry about when using FP that simply don't
apply to "real" numbers.
--
Grant Edwards grant.b.edwards Yow! HUGH BEAUMONT died
at in 1982!!
gmail.com
[toc] | [prev] | [next] | [standalone]
| From | "Gisle Vanem" <gvanem@yahoo.no> |
|---|---|
| Date | 2014-02-12 17:23 +0100 |
| Subject | Re: Working with the set of real numbers (was: Finding size of Variable) |
| Message-ID | <ldg76h$9sk$1@dont-email.me> |
| In reply to | #66045 |
"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 parse what *you* wrote. To paraphrase: #include <math.h> "there are FP_NORMAL and FP_SUBNORMAL people in the world; those who understand IEEE 754 and those who don't." .. --gv
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2014-02-12 19:47 +1100 |
| Subject | Re: Working with the set of real numbers (was: Finding size of Variable) |
| Message-ID | <mailman.6735.1392194885.18130.python-list@python.org> |
| In reply to | #66004 |
On Wed, Feb 12, 2014 at 7:17 PM, Ben Finney <ben+python@benfinney.id.au> wrote:
> Chris Angelico <rosuav@gmail.com> 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 way.
No, the Python built-in float type works with a subset of real numbers:
>>> float("pi")
Traceback (most recent call last):
File "<pyshell#1>", line 1, in <module>
float("pi")
ValueError: could not convert string to float: 'pi'
>>> float("π")
Traceback (most recent call last):
File "<pyshell#2>", line 1, in <module>
float("π")
ValueError: could not convert string to float: 'π'
Same goes for fractions.Fraction and [c]decimal.Decimal. All of them
are restricted to some subset of rational numbers, not all reals.
> The <URL:http://docs.python.org/2/library/numbers.html#numbers.Real> ABC
> defines behaviours for types implementing the set of real numbers.
>
> 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 notation (eg by carrying
through some representation like "2*pi" rather than 6.28....), but
otherwise, irrationals can't be represented with finite storage and a
digit-based system.
ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Jussi Piitulainen <jpiitula@ling.helsinki.fi> |
|---|---|
| Date | 2014-02-12 11:23 +0200 |
| Subject | Re: Working with the set of real numbers (was: Finding size of Variable) |
| Message-ID | <qotioskk7li.fsf@ruuvi.it.helsinki.fi> |
| In reply to | #66011 |
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 notation (eg by carrying > through some representation like "2*pi" rather than 6.28....), but > otherwise, irrationals can't be represented with finite storage and > a digit-based system. I've seen papers on exact computable reals that would, in effect, generate more precision when needed for some operation. It wasn't symbolic like 2pi, more like 6.28... with a promise to delve into the ellipsis, and some notable operations not supported. Equality testing was missing, I think, and I think it could not be known in general whether such a number is positive, zero or negative, so even approximate printing in the usual digit notation would not be possible. (Interval arithmetic, I hear, has a similar problem about not knowing the sign of a number.) In stark contrast, exact rationals work nicely, up to efficiency considerations.
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-03-04 02:45 +0000 |
| Subject | Re: Working with the set of real numbers (was: Finding size of Variable) |
| Message-ID | <53153e66$0$24931$e4fe514c@dreader36.news.xs4all.nl> |
| In reply to | #66011 |
In article <mailman.6735.1392194885.18130.python-list@python.org>,
Chris Angelico <rosuav@gmail.com> wrote:
>On Wed, Feb 12, 2014 at 7:17 PM, Ben Finney <ben+python@benfinney.id.au> wrote:
>> Chris Angelico <rosuav@gmail.com> 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 way.
>
>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.
>
>>>> float("pi")
>Traceback (most recent call last):
> File "<pyshell#1>", line 1, in <module>
> float("pi")
>ValueError: could not convert string to float: 'pi'
>>>> float("π")
>Traceback (most recent call last):
> File "<pyshell#2>", line 1, in <module>
> float("π")
>ValueError: could not convert string to float: 'π'
>
>Same goes for fractions.Fraction and [c]decimal.Decimal. All of them
>are restricted to some subset of rational numbers, not all reals.
>
>> The <URL:http://docs.python.org/2/library/numbers.html#numbers.Real> ABC
>> defines behaviours for types implementing the set of real numbers.
>>
>> 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 notation (eg by carrying
>through some representation like "2*pi" rather than 6.28....), but
>otherwise, irrationals can't be represented with finite storage and a
>digit-based system.
An interesting possibility is working with rules that generate the
continued fraction sequence of a real number. Say yield() gives the
next coefficient (or the next hex digit).
It was generally believed that summing two numbers in their cf representation
was totally impractical because it required conversion to a rational number.
OTOH if we consider a cf as an ongoing progress, the situation is much better.
Summing would be a process that yields coefficients of the sum, and you could
just stop when you've enough precision. Fascinating stuff.
It is described in a self contained, type writer style document gosper.txt
that is found on the web in several places e.g.
http://home.strw.leidenuniv.nl/~gurkan/gosper.pdf
I have a gosper.txt, don't know from where.
It really is a cookbook, one could built a python implementation from
there, without being overly math savvy. I'd love to hear if
some one does it.
( in principle a coefficient of a cf can overflow machine precision,
that has never been observed in the wild. A considerable percentage
of the coefficients for a random number are ones or otherwise small.
The golden ratio has all ones.)
>
>ChrisA
Groetjes Albert
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2014-03-04 14:02 +1100 |
| Subject | Re: Working with the set of real numbers (was: Finding size of Variable) |
| Message-ID | <mailman.7687.1393902132.18130.python-list@python.org> |
| In reply to | #67630 |
On Tue, Mar 4, 2014 at 1:45 PM, Albert van der Horst <albert@spenarnc.xs4all.nl> 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 numerator, and the denominator between the limits of the exponent. (Unless it's subnormal. That adds another set of small numbers.) It's a pretty tight set of restrictions, and yet good enough for so many purposes. 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. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Rustom Mody <rustompmody@gmail.com> |
|---|---|
| Date | 2014-03-03 19:13 -0800 |
| Subject | Re: Working with the set of real numbers (was: Finding size of Variable) |
| Message-ID | <59dd57ad-39b0-4c71-a58e-b4ae6517b385@googlegroups.com> |
| In reply to | #67631 |
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 > > that is a power of two. > And no more than N bits (53 in a 64-bit float) in the numerator, and > the denominator between the limits of the exponent. (Unless it's > subnormal. That adds another set of small numbers.) It's a pretty > tight set of restrictions, and yet good enough for so many purposes. > 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#sqrts
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2014-03-04 14:46 +1100 |
| Subject | Re: Working with the set of real numbers (was: Finding size of Variable) |
| Message-ID | <mailman.7689.1393904790.18130.python-list@python.org> |
| In reply to | #67632 |
On Tue, Mar 4, 2014 at 2:13 PM, Rustom Mody <rustompmody@gmail.com> 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#sqrts 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 prove, that there will be numbers that can't be represented even with an infinite series - or at least numbers whose series can't be easily calculated. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Rustom Mody <rustompmody@gmail.com> |
|---|---|
| Date | 2014-03-03 21:19 -0800 |
| Subject | Re: Working with the set of real numbers (was: Finding size of Variable) |
| Message-ID | <3e6e8aa4-b2f5-4aec-bae3-20423978a4a0@googlegroups.com> |
| In reply to | #67635 |
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 > > http://www.maths.surrey.ac.uk/hosted-sites/R.Knott/Fibonacci/cfINTRO.html#sqrts > 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 prove, that there will be numbers that can't > be represented even with an infinite series - or at least numbers > whose series can't be easily calculated. You are now asking questions that are really (real-ly?) outside my capacities. What I know (which may be quite off the mark :-) ) Just as all real numbers almost by definition have a decimal form (may be infinite eg 1/3 becomes 0.33333...) all real numbers likewise have a CF form For some mathematical (aka arcane) reasons the CF form is actually better. Furthermore: 1. Transcendental numbers like e and pi have non-repeating infinite CF forms 2. Algebraic numbers (aka surds) have repeating maybe finite(?) forms 3. For some numbers its not known whether they are transcendental or not (vague recollection pi^sqrt(pi) is one such) 4 Since e^ipi is very much an integer, above question is surprisingly non-trivial
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2014-03-04 05:53 +0000 |
| Subject | Re: Working with the set of real numbers (was: Finding size of Variable) |
| Message-ID | <53156a42$0$2923$c3e8da3$76491128@news.astraweb.com> |
| In reply to | #67635 |
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 prove, that there will be numbers that can't be
> represented even with an infinite series - or at least numbers whose
> series can't be easily calculated.
Every rational number can be written as a continued fraction with a
finite number of terms[1]. Every irrational number can be written as a
continued fraction with an infinite number of terms, just as every
irrational number can be written as a decimal number with an infinite
number of digits. Most of them (to be precise: an uncountably infinite
number of them) will have no simple or obvious pattern.
[1] To be pedantic, written as *two* continued fractions, one ending with
the term 1, and one with one less term which isn't 1. That is:
[a; b, c, d, ..., z, 1] == [a; b, c, d, ..., z+1]
Any *finite* CF ending with one can be simplified to use one fewer term.
Infinite CFs of course don't have a last term.
--
Steven
[toc] | [prev] | [next] | [standalone]
Page 3 of 8 — ← Prev page 1 2 [3] 4 5 6 7 8 Next page →
Back to top | Article view | comp.lang.python
csiph-web