[bugs] Last week...
Last week I found three "bugs" related to the coding of characters / unicode (Py 3). Bugs, that are making impossible to write safe code when manipulating text/strings as Python is supposed to do. Safe code == not broken, nothing to do with a "regression". jmf -- https://mail.python.org/mailman/listinfo/python-list
Re: [bugs] Last week...
In article <477157e9-2c36-477b-90b7-a2bd26596...@googlegroups.com>, wxjmfa...@gmail.com wrote: > Last week I found three "bugs" related to the coding of > characters / unicode (Py 3). > > Bugs, that are making impossible to write safe code > when manipulating text/strings as Python is supposed > to do. If you believe you have found unreported bugs in Python, please open issues for them on the Python bug tracker: http://bugs.python.org Mentioning them here with no details helps no one. -- Ned Deily, n...@acm.org -- https://mail.python.org/mailman/listinfo/python-list
Re: [bugs] Last week...
On 4/29/14 4:57 AM, Ned Deily wrote: In article <477157e9-2c36-477b-90b7-a2bd26596...@googlegroups.com>, wxjmfa...@gmail.com wrote: Last week I found three "bugs" related to the coding of characters / unicode (Py 3). Bugs, that are making impossible to write safe code when manipulating text/strings as Python is supposed to do. If you believe you have found unreported bugs in Python, please open issues for them on the Python bug tracker: http://bugs.python.org Mentioning them here with no details helps no one. Once you've created the issues in the bug tracker, post the links here. I know some of us will be interested to follow their progress. We all want to see Python be the best it can be. -- Ned Batchelder, http://nedbatchelder.com -- https://mail.python.org/mailman/listinfo/python-list
Cant type unicode with compose anymore
For some time now I have this in my X startup programs: $ setxkbmap -option compose:menu After this I can type (in mostly any window) for example: (with MN being the windows-menu key) MN.. gives ... ie an ellipses MN--. gives - ie an en dash MN--- gives -- ie an em dash Not to mention all the e" giving ë etc etc - all the unicode goodies at /usr/share/X11/locale/$LANG/Compose Now suddenly its stopped working. ie it works in most other X apps but not in emacs I thought there may be a race-condition between the setxkb and emacs which are both in my startup programs. So I ran the setxkb command by hand from a shell and (re)started emacs from the shell No luck: The compose works outside emacs Doesn't work inside Any clues? Its the same for emacs 23 and 24 -- https://mail.python.org/mailman/listinfo/python-list
Cant type unicode with compose anymore
For some time now I have this in my X startup programs: $ setxkbmap -option compose:menu After this I can type (in mostly any window) for example: (with MN being the windows-menu key) MN.. gives ... ie an ellipses MN--. gives - ie an en dash MN--- gives -- ie an em dash Not to mention all the e" giving ë etc etc - all the goodies at /usr/share/X11/locale/$LANG/Compose Now suddenly its stopped working. ie it works in most other X apps but not in emacs I thought there may be a race-condition between the setxkb and emacs which are both in my startup programs. So I ran the setxkb command by hand from a shell and (re)started emacs from the shell No luck: The compose works outside emacs Doesn't work inside Any clues? Its the same for emacs 23 and 24 -- https://mail.python.org/mailman/listinfo/python-list
Re: Cant type unicode with compose anymore
On Tuesday, April 29, 2014 4:44:48 PM UTC+5:30, Rustom Mody wrote: > > Any clues? > > > Its the same for emacs 23 and 24 Whoops! Wrong list :-) -- https://mail.python.org/mailman/listinfo/python-list
Re: Cant type unicode with compose anymore
On Tuesday, April 29, 2014 4:48:51 PM UTC+5:30, Rustom Mody wrote: Ive done it a second time !?! Probably related to the temp being a cool > 40 °C -- https://mail.python.org/mailman/listinfo/python-list
Re: Significant digits in a float?
In article <535f0f9f$0$29965$c3e8da3$54964...@news.astraweb.com>,
Steven D'Aprano wrote:
> On Mon, 28 Apr 2014 12:00:23 -0400, Roy Smith wrote:
>
> [...]
> > Fundamentally, these numbers have between 0 and 4 decimal digits of
> > precision,
>
> I'm surprised that you have a source of data with variable precision,
> especially one that varies by a factor of TEN THOUSAND.
OK, you're surprised.
> I don't know what justification you have for combining such a
> mix of data sources.
Because that's the data that was given to me. Real life data is messy.
> One possible interpretation of your post is that you have a source of
> floats, where all the numbers are actually measured to the same
> precision, and you've simply misinterpreted the fact that some of them
> look like they have less precision.
Another possibility is that they're latitude/longitude coordinates, some
of which are given to the whole degree, some of which are given to
greater precision, all the way down to the ten-thousandth of a degree.
> What reason do you have to think that something recorded to 14
> decimal places was only intended to have been recorded to 4?
Because I understand the physical measurement these numbers represent.
Sometimes, Steve, you have to assume that when somebody asks a question,
they actually have asked the question then intended to ask.
> Perhaps you need to explain why you're doing this, as it seems
> numerically broken.
These are latitude and longitude coordinates of locations. Some
locations are known to a specific street address. Some are known to a
city. Some are only known to the country. So, for example, the 38.0
value represents the latitude, to the nearest whole degree, of the
geographic center of the contiguous United States.
> I really think you need to go back to the source. Trying to infer the
> precision of the measurements from the accident of the string formatting
> seems pretty dubious to me.
Sure it is. But, like I said, real-life data is messy. You can wring
your hands and say, "this data sucks, I can't use it", or you can figure
out some way to deal with it. Which is the whole point of my post. The
best I've come up with is inferring something from the string formatting
and I'm hoping there might be something better I might do.
> But I suppose if you wanted to infer the number of digits after the
> decimal place, excluding trailing zeroes (why, I do not understand), up
> to a maximum of four digits, then you could do:
>
> s = "%.4f" % number # rounds to four decimal places
> s = s.rstrip("0") # ignore trailing zeroes, whether significant or not
> count = len(s.split(".")[1])
This at least seems a little more robust than just calling str(). Thank
you :-)
> Assuming all the numbers fit in the range where they are shown in non-
> exponential format.
They're latitude/longitude, so they all fall into [-180, 180].
> Perhaps you ought to be using Decimal rather than float.
Like I said, "The numbers are given to me as Python floats; I have no
control over that".
> > I'm willing to accept that fact that I won't be able to differentiate
> > between float("38.0") and float("38."). Both of those map to 1,
> > which is OK for my purposes.
>
> That seems... well, "bizarre and wrong" are the only words that come to
> mind.
I'm trying to intuit, from the values I've been given, which coordinates
are likely to be accurate to within a few miles. I'm willing to accept
a few false negatives. If the number is float("38"), I'm willing to
accept that it might actually be float("38."), and I might be
throwing out a good data point that I don't need to.
For the purpose I'm using the data for, excluding the occasional good
data point won't hurt me. Including the occasional bad one, will.
> By the way, you contradict yourself here. Earlier, you described 38.0 as
> having zero decimal places (which is wrong). Here you describe it as
> having one, which is correct, and then in a later post you describe it as
> having zero decimal places again.
I was sloppy there. I was copy-pasting data from my program output.
Observe:
>>> print float("38")
38.0
In standard engineering parlance, the string "38" represents a number
with a precision of +/- 1 unit. Unfortunately, Python's default str()
representation turns this into "38.0", which implies +/- 0.1 unit.
Floats represented as strings (at least in some disciplines, such as
engineering) include more information than just the value. By the
number of trailing zeros, they also include information about the
precision of the measurement. That information is lost when the string
is converted to a IEEE float. I'm trying to intuit that information
back, and as I mentioned earlier, am willing to accept that the
intuiting process will be imperfect. There is real-life value in
imperfect processes.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Convert numpy array to single number
On 28.04.2014 15:04, mboyd02...@gmail.com wrote: I have a numpy array consisting of 1s and zeros for representing binary numbers: e.g. >>> binary array([ 1., 0., 1., 0.]) I wish the array to be in the form 1010, so it can be manipulated. I do not want to use built in binary converters as I am trying to build my own. Do you mean that each element in the array represents a power of two? So array([ 1., 0., 1., 0.]) represents 2^3 + 2 = 6 decimal? -- https://mail.python.org/mailman/listinfo/python-list
how to build and install multiple micro-level major.minor versions of Python
I have built and installed Python on AIX as well as installed a stack of Python tools. The version I installed is 2.7.2. Everything is working fine but I want to install Python 2.7.6 and the tool stack. Before I installed 2.7.2, I installed 2.6.x. I was able to install the 2.7.2 and 2.6.x side by side because they have different minor numbers. This allowed me to be able to thoroughly test 2.7.2 before pointing the link for python to it. Now however, I can't see an easy way to install 2.7.6 beside the 2.7.2 since by default, Python installs only to the minor number so if I install 2.7.6, it will overwrite 2.7.2 since they will both install to 2.7. I have tried editing the configuration files configure.ac and configure to set VERSION, PYTHON_VERSION, and PACKAGE_VERSION to 2.7.6. This actually seemed to work fine so I ended up with 2.7.6 installed beside 2.7. However, when I tried to install other python packages using a command like: python2.7.6 setup.py install the python2.7.6 binary was used for the install but the setup wrote the package library to .../lib/python2.7 not .../lib/python2.7.6. I thought maybe it had something to do with bin/python-config pointing to bin/python-config2.7, so I pointed python-config to python-config2.7.6 but that didn't help. Is there a way to do what I want to do (i.e. install 2.7.6 beside 2.7)? -- https://mail.python.org/mailman/listinfo/python-list
where to put global testing value
A user complains that under AppEngine I'm not allowed to import __main__. I can fix this issue merely by putting a try block around the offending import which is only used like this import __main__ testing = getattr(__main__,'_rl_testing',False) del __main__ this is only used as a hack way, during testing, to modify the behaviour of the importing module (a proxy for a C extension). During testing we keep both the C version and the supposed replacement of various functions so they can be tested against each other https://bitbucket.org/rptlab/reportlab/src/default/src/reportlab/lib/rl_accel.py Is there a more reasonable way to allow changes to module level globals before the import takes place? I guess since this module is supposed only to be imported by reportlab we can put this sort of thing onto the reportlab module itself, but that could possibly lead to import loops. Any ideas? -- Robin Becker -- https://mail.python.org/mailman/listinfo/python-list
Re: Significant digits in a float?
2014-04-28 18:00 GMT+02:00 Roy Smith :
> I'm using Python 2.7
>
> I have a bunch of floating point values. For example, here's a few (printed
> as reprs):
>
> 38.0
> 41.2586
> 40.752801
> 49.25
> 33.7951994
> 36.8371996
> 34.1489
> 45.5
>
> Fundamentally, these numbers have between 0 and 4 decimal digits of
> precision, and I want to be able to intuit how many each has, ignoring the
> obvious floating point roundoff problems. Thus, I want to map:
>
> 38.0 ==> 0
> 41.2586 ==> 4
> 40.752801 ==> 4
> 49.25 ==> 2
> 33.7951994 ==> 4
> 36.8371996 ==> 4
> 34.1489 ==> 4
> 45.5 ==> 1
>
> Is there any clean way to do that? The best I've come up with so far is to
> str() them and parse the remaining string to see how many digits it put after
> the decimal point.
>
> The numbers are given to me as Python floats; I have no control over that.
> I'm willing to accept that fact that I won't be able to differentiate between
> float("38.0") and float("38."). Both of those map to 1, which is OK for
> my purposes.
>
> ---
> Roy Smith
> r...@panix.com
>
Hi,
I doubt, many would consider a string/regex approach very clean here,
but anyway; hopefully the results conform to your specs (as far as I
understood it correctly). Alternatively, the floats can be rounded
before, if e.g. 39.999 could be a false positive for 4-digits
precision.
hth,
vbr
= = = = = = =
>>> for fl in (38.0, 41.2586, 40.752801, 49.25, 33.7951994,
>>> 36.8371996, 34.1489, 45.5, 40.0010, 39.0009, 39.999,
>>> 38.9, 40.0100, 41.2000, 43.0001):
... print repr(fl), "==>", len(re.match(r"^-?\d+\.([0-9]{0,4})(? 0
41.2586 ==> 4
40.752801 ==> 4
49.25 ==> 2
33.7951994 ==> 4
36.8371996 ==> 4
34.1489 ==> 4
45.5 ==> 1
40.001 ==> 3
39.0009 ==> 0
39.999 ==> 4
38.9 ==> 0
40.01 ==> 2
41.2 ==> 1
43.0001 ==> 4
>>>
= = = = = = =
--
https://mail.python.org/mailman/listinfo/python-list
Re: Significant digits in a float?
On Tue, Apr 29, 2014 at 11:38 PM, Roy Smith wrote:
> I'm trying to intuit, from the values I've been given, which coordinates
> are likely to be accurate to within a few miles. I'm willing to accept
> a few false negatives. If the number is float("38"), I'm willing to
> accept that it might actually be float("38."), and I might be
> throwing out a good data point that I don't need to.
You have one chance in ten, repeatably, of losing a digit. That is,
roughly 10% of your four-decimal figures will appear to be
three-decimal, and 1% of them will appear to be two-decimal, and so
on. Is that "a few" false negatives? It feels like a lot IMO. But
then, there's no alternative - the information's already gone.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: where to put global testing value
On 4/29/14 12:17 PM, Robin Becker wrote: A user complains that under AppEngine I'm not allowed to import __main__. I can fix this issue merely by putting a try block around the offending import which is only used like this import __main__ testing = getattr(__main__,'_rl_testing',False) del __main__ this is only used as a hack way, during testing, to modify the behaviour of the importing module (a proxy for a C extension). During testing we keep both the C version and the supposed replacement of various functions so they can be tested against each other https://bitbucket.org/rptlab/reportlab/src/default/src/reportlab/lib/rl_accel.py Is there a more reasonable way to allow changes to module level globals before the import takes place? I guess since this module is supposed only to be imported by reportlab we can put this sort of thing onto the reportlab module itself, but that could possibly lead to import loops. Any ideas? In coverage.py, I used environment variables to control that kind of behavior. -- Ned Batchelder, http://nedbatchelder.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Significant digits in a float?
On 4/29/14 12:30 PM, Chris Angelico wrote:
On Tue, Apr 29, 2014 at 11:38 PM, Roy Smith wrote:
I'm trying to intuit, from the values I've been given, which coordinates
are likely to be accurate to within a few miles. I'm willing to accept
a few false negatives. If the number is float("38"), I'm willing to
accept that it might actually be float("38."), and I might be
throwing out a good data point that I don't need to.
You have one chance in ten, repeatably, of losing a digit. That is,
roughly 10% of your four-decimal figures will appear to be
three-decimal, and 1% of them will appear to be two-decimal, and so
on. Is that "a few" false negatives? It feels like a lot IMO. But
then, there's no alternative - the information's already gone.
Reminds me of the story that the first survey of Mt. Everest resulted in
a height of exactly 29,000 feet, but to avoid the appearance of an
estimate, they reported it as 29,002: http://www.jstor.org/stable/2684102
--
Ned Batchelder, http://nedbatchelder.com
--
https://mail.python.org/mailman/listinfo/python-list
Re: Significant digits in a float?
On Wed, Apr 30, 2014 at 2:47 AM, Ned Batchelder wrote: > Reminds me of the story that the first survey of Mt. Everest resulted in a > height of exactly 29,000 feet, but to avoid the appearance of an estimate, > they reported it as 29,002: http://www.jstor.org/stable/2684102 Yeah. Exactly the same phenomenon as I was referring to earlier when I said that you never tell someone you need to leave in five minutes - if you say six minutes, you'll be away sooner. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Unicode 7
Let see how Python is ready for the next Unicode version
(Unicode 7.0.0.Beta).
>>> timeit.repeat("(x*1000 + y)[:-1]", setup="x = 'abc'; y = 'z'")
[1.4027834829454946, 1.38714224331963, 1.3822586635296261]
>>> timeit.repeat("(x*1000 + y)[:-1]", setup="x = 'abc'; y = '\u0fce'")
[5.462776291480395, 5.4479432055423445, 5.447874284053398]
>>>
>>>
>>> # more interesting
>>> timeit.repeat("(x*1000 + y)[:-1]",\
... setup="x = 'abc'.encode('utf-8'); y = '\u0fce'.encode('utf-8')")
[1.3496489533188765, 1.328654286266783, 1.3300913977710707]
>>>
Note 1: "lookup" is not the problem.
Note 2: From Unicode.org : "[...] We strongly encourage [...] and test
them with their programs [...]"
-> Done.
jmf
--
https://mail.python.org/mailman/listinfo/python-list
Re: Unicode 7
On 2014-04-29 10:37, wxjmfa...@gmail.com wrote:
> >>> timeit.repeat("(x*1000 + y)[:-1]", setup="x = 'abc'; y = 'z'")
> [1.4027834829454946, 1.38714224331963, 1.3822586635296261]
> >>> timeit.repeat("(x*1000 + y)[:-1]", setup="x = 'abc'; y =
> >>> '\u0fce'")
> [5.462776291480395, 5.4479432055423445, 5.447874284053398]
> >>>
> >>>
> >>> # more interesting
> >>> timeit.repeat("(x*1000 + y)[:-1]",\
> ... setup="x = 'abc'.encode('utf-8'); y =
> '\u0fce'.encode('utf-8')") [1.3496489533188765, 1.328654286266783,
> 1.3300913977710707]
> >>>
While I dislike feeding the troll, what I see here is: on your
machine, all unicode manipulations in the test should take ~5.4
seconds. But Python notices that some of your strings *don't*
require a full 32-bits and thus optimizes those operations, cutting
about 75% of the processing time (wow...4-bytes-per-char to
1-byte-per-char, I wonder where that 75% savings comes from).
So rather than highlight any *problem* with Python, your [mostly
worthless microbenchmark non-realworld] tests show that Python's
unicode implementation is awesome.
Still waiting to see an actual bug-report as mentioned on the other
thread.
-tkc
--
https://mail.python.org/mailman/listinfo/python-list
Re: Unicode 7
On 2014-04-29 18:37, wxjmfa...@gmail.com wrote:
Let see how Python is ready for the next Unicode version
(Unicode 7.0.0.Beta).
timeit.repeat("(x*1000 + y)[:-1]", setup="x = 'abc'; y = 'z'")
[1.4027834829454946, 1.38714224331963, 1.3822586635296261]
timeit.repeat("(x*1000 + y)[:-1]", setup="x = 'abc'; y = '\u0fce'")
[5.462776291480395, 5.4479432055423445, 5.447874284053398]
# more interesting
timeit.repeat("(x*1000 + y)[:-1]",\
... setup="x = 'abc'.encode('utf-8'); y = '\u0fce'.encode('utf-8')")
[1.3496489533188765, 1.328654286266783, 1.3300913977710707]
Although the third example is the fastest, it's also the wrong way to
handle Unicode:
>>> x = 'abc'.encode('utf-8'); y = '\u0fce'.encode('utf-8')
>>> t = (x*1000 + y)[:-1].decode('utf-8')
Traceback (most recent call last):
File "", line 1, in
UnicodeDecodeError: 'utf-8' codec can't decode bytes in position
3000-3001: unex
pected end of data
Note 1: "lookup" is not the problem.
Note 2: From Unicode.org : "[...] We strongly encourage [...] and test
them with their programs [...]"
-> Done.
jmf
--
https://mail.python.org/mailman/listinfo/python-list
Re: how to build and install multiple micro-level major.minor versions of Python
In article <1398785310.2673.16.camel@belmer>, "Brent S. Elmer Ph.D." wrote: > Is there a way to do what I want to do (i.e. install 2.7.6 beside 2.7)? The usual way to support multiple micro versions is to build and install to a different location on your system by using: ./configure --prefix=/new/path There is nothing magical about /usr/local or /usr other than that /usr/bin and /usr/local/bin are usually included in default $PATH. If you use a non-default prefix, it's also probably best to avoid using --enable-shared to minimize the chances of confusion with shared library loading. -- Ned Deily, n...@acm.org -- https://mail.python.org/mailman/listinfo/python-list
Re: how to build and install multiple micro-level major.minor versions of Python
On Tue, 2014-04-29 at 11:35 -0700, Ned Deily wrote: > In article <1398785310.2673.16.camel@belmer>, > "Brent S. Elmer Ph.D." wrote: > > Is there a way to do what I want to do (i.e. install 2.7.6 beside 2.7)? > > The usual way to support multiple micro versions is to build and install > to a different location on your system by using: > > ./configure --prefix=/new/path > > There is nothing magical about /usr/local or /usr other than that > /usr/bin and /usr/local/bin are usually included in default $PATH. If > you use a non-default prefix, it's also probably best to avoid using > --enable-shared to minimize the chances of confusion with shared library > loading. > > -- > Ned Deily, > n...@acm.org > Yes, I already use --prefix to build to a different path. I guess that is what I need to do but I would rather have a way to have the build and install process install to the micro level. Brent -- https://mail.python.org/mailman/listinfo/python-list
Re: how to build and install multiple micro-level major.minor versions of Python
On 4/29/14 1:53 PM, Brent S. Elmer Ph.D. wrote: Yes, I already use --prefix to build to a different path. I guess that is what I need to do but I would rather have a way to have the build and install process install to the micro level. example only, Use --prefix /usr/local/2.7.6/ Use --prefix /usr/local/2.7.2/ &c., Both of the 2.7 installs will be 2.7, but it doesn't matter because they will (each one) be installed under a different micro level. ... works great. marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: how to build and install multiple micro-level major.minor versions of Python
On 4/29/14 1:53 PM, Brent S. Elmer Ph.D. wrote: I would rather have a way to have the build and install process install to the micro level. I agree. On the other hand, is there really a special need to thoroughly test against a micro level. I have the latest 2.6, 2.7, 3.2, 3.3, 3.4 ... there might a critical reason for splitting hairs, but honestly, probably not. -- https://mail.python.org/mailman/listinfo/python-list
Re: Significant digits in a float?
On 2014-04-29, Roy Smith wrote: > Another possibility is that they're latitude/longitude coordinates, some > of which are given to the whole degree, some of which are given to > greater precision, all the way down to the ten-thousandth of a degree. That makes sense. 1° of longitude is about 111 km at the equator, 78 km at 45°N or S, & 0 km at the poles. "A man pitches his tent, walks 1 km south, walks 1 km east, kills a bear, & walks 1 km north, where he's back at his tent. What color is the bear?" ;-) -- War is God's way of teaching Americans geography. [Ambrose Bierce] -- https://mail.python.org/mailman/listinfo/python-list
Re: Significant digits in a float?
On 4/29/14 3:16 PM, Adam Funk wrote: "A man pitches his tent, walks 1 km south, walks 1 km east, kills a bear, & walks 1 km north, where he's back at his tent. What color is the bear?" ;-) Who manufactured the tent? marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: how to build and install multiple micro-level major.minor versions of Python
On Apr 29, 2014, at 11:53 , Brent S. Elmer Ph.D. wrote: > Yes, I already use --prefix to build to a different path. I guess that > is what I need to do but I would rather have a way to have the build and > install process install to the micro level. Python deliberately does not provide a way to install to the micro level as an important "contract" in the Python maintenance and release process is to maintain ABI compatibility among maintenance (i.j.k) releases in the same major release series (i.j). We sometimes fail in that but we do try really hard to make it painless to move from i.j.k to i.j.x. That's also why we only supply fixes for the most recent micro release. -- Ned Deily n...@acm.org -- [] -- https://mail.python.org/mailman/listinfo/python-list
Re: Significant digits in a float?
On Tue, Apr 29, 2014 at 3:16 PM, Adam Funk wrote: > > "A man pitches his tent, walks 1 km south, walks 1 km east, kills a > bear, & walks 1 km north, where he's back at his tent. What color is > the bear?" ;-) Skin or Fur? -- https://mail.python.org/mailman/listinfo/python-list
Re: Significant digits in a float?
On Wed, Apr 30, 2014 at 6:39 AM, Mark H Harris wrote: > On 4/29/14 3:16 PM, Adam Funk wrote: >> >> "A man pitches his tent, walks 1 km south, walks 1 km east, kills a >> bear, & walks 1 km north, where he's back at his tent. What color is >> the bear?" ;-) >> > > Who manufactured the tent? A man pitches his tent 1 km south and kills a bear with it. Clearly that wasn't a tent, it was a cricket ball. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Significant digits in a float?
Ned Batchelder wrote: Reminds me of the story that the first survey of Mt. Everest resulted in a height of exactly 29,000 feet, but to avoid the appearance of an estimate, they reported it as 29,002: http://www.jstor.org/stable/2684102 They could have said it was 29.000 kilofeet. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Significant digits in a float?
On 04/29/2014 01:16 PM, Adam Funk wrote: "A man pitches his tent, walks 1 km south, walks 1 km east, kills a bear, & walks 1 km north, where he's back at his tent. What color is the bear?" ;-) From how many locations on Earth can someone walk one mile south, one mile east, and one mile north and end up at their starting point? Emile -- https://mail.python.org/mailman/listinfo/python-list
Re: Significant digits in a float?
On Wed, Apr 30, 2014 at 8:42 AM, emile wrote: > On 04/29/2014 01:16 PM, Adam Funk wrote: > >> "A man pitches his tent, walks 1 km south, walks 1 km east, kills a >> bear, & walks 1 km north, where he's back at his tent. What color is >> the bear?" ;-) > > > From how many locations on Earth can someone walk one mile south, one mile > east, and one mile north and end up at their starting point? Any point where the mile east takes you an exact number of times around the globe. So, anywhere exactly one mile north of that, which is a number of circles not far from the south pole. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Problems with ZODB, I can not persist and object accessed from 2 threads
Hello, I am sorry I am stuck in this. And I need some help
I want to persist an Object with ZODB, the object can be accessed from 2
different threads. The ZODB manual says:
A multi-threaded program should open a separate Connection instance for
each thread. Different threads can then modify objects and commit their
modifications independently.
But there isn't an example of how to create a connection for each thread.
Can someone tell me how to connect to the same DB from 2 threads??
I attached an example of what I am trying to do.
And I get this error.
Traceback (most recent call last):
File "/usr/lib/python2.7/threading.py", line 810, in __bootstrap_inner
self.run()
File "/usr/lib/python2.7/threading.py", line 763, in run
self.__target(*self.__args, **self.__kwargs)
File "main.py", line 33, in thread_1
storage = FileStorage("/tmp/asdasd.fs")
File "/usr/lib/python2.7/site-packages/ZODB/FileStorage/FileStorage.py",
line 164, in *_init_*
self._lock_file = LockFile(file_name + '.lock')
File "/usr/lib/python2.7/site-packages/zc/lockfile/__init__.py", line 84,
in *_init_*
_lock_file(fp)
File "/usr/lib/python2.7/site-packages/zc/lockfile/__init__.py", line 59,
in _lock_file
raise LockError("Couldn't lock %r" % file.name)
LockError: Couldn't lock '/tmp/asdasd.fs.lock'
IF I don't connect in the "thread_1" class I can change things but
sometimes the changes from the main thread are not commited.
When I debug, I can see that when a change is made from the Second thread,
the "transaction_manager" creates a new Transaction here:
#manager.py
def get(self):
""" See ITransactionManager.
"""
if self._txn is None:
self._txn = Transaction(self._synchs, self)
return self._txn
When it happens that commit Seems to be executed succesfully but it doest
save the changes to the DB.
--
Ariel Argañaraz
main.py
Description: application/download
objects.py
Description: application/download
--
https://mail.python.org/mailman/listinfo/python-list
Re: Significant digits in a float?
On 29/04/2014 23:42, emile wrote: On 04/29/2014 01:16 PM, Adam Funk wrote: "A man pitches his tent, walks 1 km south, walks 1 km east, kills a bear, & walks 1 km north, where he's back at his tent. What color is the bear?" ;-) From how many locations on Earth can someone walk one mile south, one mile east, and one mile north and end up at their starting point? Emile Haven't you heard of The Triangular Earth Society? -- 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 -- https://mail.python.org/mailman/listinfo/python-list
Re: Significant digits in a float?
In article ,
Chris Angelico wrote:
> On Tue, Apr 29, 2014 at 11:38 PM, Roy Smith wrote:
> > I'm trying to intuit, from the values I've been given, which coordinates
> > are likely to be accurate to within a few miles. I'm willing to accept
> > a few false negatives. If the number is float("38"), I'm willing to
> > accept that it might actually be float("38."), and I might be
> > throwing out a good data point that I don't need to.
>
> You have one chance in ten, repeatably, of losing a digit. That is,
> roughly 10% of your four-decimal figures will appear to be
> three-decimal, and 1% of them will appear to be two-decimal, and so
> on. Is that "a few" false negatives?
You're looking at it the wrong way. It's not that the glass is 10%
empty, it's that it's 90% full, and 90% is a lot of good data :-)
--
https://mail.python.org/mailman/listinfo/python-list
Re: Significant digits in a float?
On Wed, Apr 30, 2014 at 9:53 AM, Roy Smith wrote:
> In article ,
> Chris Angelico wrote:
>
>> On Tue, Apr 29, 2014 at 11:38 PM, Roy Smith wrote:
>> > I'm trying to intuit, from the values I've been given, which coordinates
>> > are likely to be accurate to within a few miles. I'm willing to accept
>> > a few false negatives. If the number is float("38"), I'm willing to
>> > accept that it might actually be float("38."), and I might be
>> > throwing out a good data point that I don't need to.
>>
>> You have one chance in ten, repeatably, of losing a digit. That is,
>> roughly 10% of your four-decimal figures will appear to be
>> three-decimal, and 1% of them will appear to be two-decimal, and so
>> on. Is that "a few" false negatives?
>
> You're looking at it the wrong way. It's not that the glass is 10%
> empty, it's that it's 90% full, and 90% is a lot of good data :-)
Hah! That's one way of looking at it.
At least you don't have to worry about junk digits getting in. The
greatest precision you're working with is three digits before the
decimal and four after, and a Python float can handle that easily.
(Which is what I was concerned about when I first queried your
terminology - four digits to the right of the decimal and, say, 10-12
to the left, and you're starting to see problems.)
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Significant digits in a float?
Roy Smith writes: > In article , > Chris Angelico wrote: > > > You have one chance in ten, repeatably, of losing a digit. That is, > > roughly 10% of your four-decimal figures will appear to be > > three-decimal, and 1% of them will appear to be two-decimal, and so > > on. Is that "a few" false negatives? > > You're looking at it the wrong way. It's not that the glass is 10% > empty, it's that it's 90% full, and 90% is a lot of good data :-) The problem is you won't know *which* 90% is accurate, and which 10% is inaccurate. This is very different from the glass, where it's evident which part is good. So, I can't see that you have any choice but to say that *any* of the precision predictions should expect, on average, to be (10 + 1 + …) percent inaccurate. And you can't know which ones. Is that an acceptable error rate? -- \ “If you don't fail at least 90 percent of the time, you're not | `\aiming high enough.” —Alan Kay | _o__) | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Significant digits in a float?
On Wed, Apr 30, 2014 at 10:13 AM, Ben Finney wrote: > The problem is you won't know *which* 90% is accurate, and which 10% is > inaccurate. This is very different from the glass, where it's evident > which part is good. > > So, I can't see that you have any choice but to say that *any* of the > precision predictions should expect, on average, to be (10 + 1 + …) > percent inaccurate. And you can't know which ones. Is that an acceptable > error rate? But they're all going to be *at least* as accurate as the algorithm says. A figure of 31.4 will be treated as 1 decimal, even though it might really have been accurate to 4; but a figure of 27.1828 won't be incorrectly reported as having only 2 decimals. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Significant digits in a float?
Ben Finney writes: > The problem is you won't know *which* 90% is accurate, and which 10% is > inaccurate. This is very different from the glass, where it's evident > which part is good. Hmm. Re-reading the suggestion, I see that it is fairly predictable which estimates of precision will be inaccurate: the ones which end in explicit zeroes are more uncertain in their intended precision. -- \ “[F]reedom of speech does not entail freedom to have your ideas | `\accepted by governments and incorporated into law and policy.” | _o__) —Russell Blackford, 2010-03-06 | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Significant digits in a float?
In article , Dennis Lee Bieber wrote: > in a physics or chemistry class the recommended result is > >1.1 * 2.2 => 2.4 More than recommended. In my physics class, if you put down more significant digits than the input data justified, you got the problem marked wrong. > (one reason slide-rules were acceptable for so long -- and even my high > school trig course only required slide-rule significance even though half > the class had scientific calculators [costing >$100, when a Sterling > slide-rule could still be had for <$10]) Sterling? Snort. K&E was the way to go. -- https://mail.python.org/mailman/listinfo/python-list
Re: Significant digits in a float?
On Wed, Apr 30, 2014 at 10:37 AM, Dennis Lee Bieber wrote: > On Wed, 30 Apr 2014 08:51:32 +1000, Chris Angelico > declaimed the following: > >> >>Any point where the mile east takes you an exact number of times >>around the globe. So, anywhere exactly one mile north of that, which >>is a number of circles not far from the south pole. >> > Yeah, but he'd have had to bring his own bear... > > Bears and Penguins don't mix. Seals, OTOH, are food to the bears, and > eat the penquins. Maybe the bear was an antarctic researcher who ate Merida's cake? That'd change anyone's fate... ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Significant digits in a float?
In article <8td53bxud5@news.ducksburg.com>, Adam Funk wrote: > On 2014-04-29, Roy Smith wrote: > > > Another possibility is that they're latitude/longitude coordinates, some > > of which are given to the whole degree, some of which are given to > > greater precision, all the way down to the ten-thousandth of a degree. > > That makes sense. 1° of longitude is about 111 km at the equator, > 78 km at 45°N or S, & 0 km at the poles. > > > "A man pitches his tent, walks 1 km south, walks 1 km east, kills a > bear, & walks 1 km north, where he's back at his tent. What color is > the bear?" ;-) Assuming he shot the bear, red. -- https://mail.python.org/mailman/listinfo/python-list
Re: Significant digits in a float?
In article , Chris Angelico wrote: > On Wed, Apr 30, 2014 at 10:37 AM, Dennis Lee Bieber > wrote: > > On Wed, 30 Apr 2014 08:51:32 +1000, Chris Angelico > > declaimed the following: > > > >> > >>Any point where the mile east takes you an exact number of times > >>around the globe. So, anywhere exactly one mile north of that, which > >>is a number of circles not far from the south pole. > >> > > Yeah, but he'd have had to bring his own bear... > > > > Bears and Penguins don't mix. Seals, OTOH, are food to the bears, > > and > > eat the penquins. > > Maybe the bear was an antarctic researcher who ate Merida's cake? > That'd change anyone's fate... > > ChrisA The cake is a lie. -- https://mail.python.org/mailman/listinfo/python-list
pyodbc connect string
I am having a problem building a connect string for pyodbc. It works
when everything is hard coded, but if I build the connect string it
fails.
This works:
pyodbc.connect('DRIVER=FreeTDS;' 'SERVER=xx.xx.xx.xx;' 'PORT=1433;'
'DATABASE=blah;' 'UID=foo;' 'PWD=bar;')
But this does not:
pyodbc.connect(conn_str)
Where conn_str is:
'DRIVER=FreeTDS;' 'SERVER=xx.xx.xx.xx;' 'PORT=1433;' 'DATABASE=blah;'
'UID=foo;' 'PWD=bar;'
conn_str is constructed with:
conn_str = "'DRIVER=%s;' 'SERVER=%s;' 'PORT=%s;' 'DATABASE=%s;'
'UID=%s;' 'PWD=%s;'" \
% (RECIPE_DB['DRIVER'], RECIPE_DB['SERVER'],
RECIPE_DB['PORT'], RECIPE_DB['DATABASE'],
RECIPE_DB['USER'], RECIPE_DB['PASSWORD'])
Anyone have any ideas as to why this doesn't work.
--
https://mail.python.org/mailman/listinfo/python-list
Re: pyodbc connect string
On Wed, Apr 30, 2014 at 10:57 AM, Larry Martell wrote:
> This works:
>
> pyodbc.connect('DRIVER=FreeTDS;' 'SERVER=xx.xx.xx.xx;' 'PORT=1433;'
> 'DATABASE=blah;' 'UID=foo;' 'PWD=bar;')
>
> But this does not:
>
> pyodbc.connect(conn_str)
>
> conn_str is constructed with:
>
> conn_str = "'DRIVER=%s;' 'SERVER=%s;' 'PORT=%s;' 'DATABASE=%s;'
> 'UID=%s;' 'PWD=%s;'" \
> % (RECIPE_DB['DRIVER'], RECIPE_DB['SERVER'],
> RECIPE_DB['PORT'], RECIPE_DB['DATABASE'],
>RECIPE_DB['USER'], RECIPE_DB['PASSWORD'])
>
> Anyone have any ideas as to why this doesn't work.
Start by printing out conn_str. That'll tell you if it's actually
coming out the way you think it is. I can see where the problem
probably is (assuming these are faithful copy/pastes), in the form of
an extra double quote; but actually print them out and see what you're
getting.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: pyodbc connect string
Larry Martell writes:
> I am having a problem building a connect string for pyodbc. It works
> when everything is hard coded, but if I build the connect string it
> fails.
>
> This works:
>
> pyodbc.connect('DRIVER=FreeTDS;' 'SERVER=xx.xx.xx.xx;' 'PORT=1433;'
> 'DATABASE=blah;' 'UID=foo;' 'PWD=bar;')
This calls the function with a single string,
"DRIVER=FreeTDS;SERVER=xx.xx.xx.xx;PORT=1433;DATABASE=blah;UID=foo;PWD=bar;".
Remember that consecutive, whitespace-separated, quote-delimited
fragments specify the construction of a single string literal::
>>> 'foo'
'foo'
>>> 'foo' 'bar'
'foobar'
>>> 'foo' 'bar' 'baz'
'foobarbaz'
See the reference for how this concatenation occurs
https://docs.python.org/3/reference/lexical_analysis.html#string-literal-concatenation>.
> But this does not:
>
> pyodbc.connect(conn_str)
>
> Where conn_str is:
>
> 'DRIVER=FreeTDS;' 'SERVER=xx.xx.xx.xx;' 'PORT=1433;' 'DATABASE=blah;'
> 'UID=foo;' 'PWD=bar;'
This string is different, because it contains a whole lot of quotation
marks and whitespace not in the string you show in the first example.
> conn_str is constructed with:
>
> conn_str = "'DRIVER=%s;' 'SERVER=%s;' 'PORT=%s;' 'DATABASE=%s;'
> 'UID=%s;' 'PWD=%s;'" \
> % (RECIPE_DB['DRIVER'], RECIPE_DB['SERVER'],
> RECIPE_DB['PORT'], RECIPE_DB['DATABASE'],
>RECIPE_DB['USER'], RECIPE_DB['PASSWORD'])
Remove the extraneous quotes and whitespace, which were not in the
original string you showed above.
On a separate point: Since you have string keys for the mapping, you can
make the interpolation more readable::
conn_str = (
"DRIVER=%(DRIVER)s;SERVER=%(SERVER)s;PORT=%(PORT)s;"
"DATABASE=%(DATABASE)s;UID=%(USER)s;PWD=%(PASSWORD)s;"
) % RECIPE_DB
since the named placeholders will be looked up by key in the ‘RECIPE_DB’
mapping.
There are other improvements to suggest, but I don't want to distract
from the main point of the post.
--
\ “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
--
https://mail.python.org/mailman/listinfo/python-list
Re: pyodbc connect string
On Tue, Apr 29, 2014 at 7:09 PM, Chris Angelico wrote:
> On Wed, Apr 30, 2014 at 10:57 AM, Larry Martell
> wrote:
>> This works:
>>
>> pyodbc.connect('DRIVER=FreeTDS;' 'SERVER=xx.xx.xx.xx;' 'PORT=1433;'
>> 'DATABASE=blah;' 'UID=foo;' 'PWD=bar;')
>>
>> But this does not:
>>
>> pyodbc.connect(conn_str)
>>
>> conn_str is constructed with:
>>
>> conn_str = "'DRIVER=%s;' 'SERVER=%s;' 'PORT=%s;' 'DATABASE=%s;'
>> 'UID=%s;' 'PWD=%s;'" \
>> % (RECIPE_DB['DRIVER'], RECIPE_DB['SERVER'],
>> RECIPE_DB['PORT'], RECIPE_DB['DATABASE'],
>>RECIPE_DB['USER'], RECIPE_DB['PASSWORD'])
>>
>> Anyone have any ideas as to why this doesn't work.
>
> Start by printing out conn_str. That'll tell you if it's actually
> coming out the way you think it is. I can see where the problem
> probably is (assuming these are faithful copy/pastes), in the form of
> an extra double quote; but actually print them out and see what you're
> getting.
When I print conn_str out it does not have the double quotes, But I
was able to solve this by doing this:
pyodbc.connect('DRIVER=' + RECIPE_DB['DRIVER'] + ';' + 'SERVER=' +
RECIPE_DB['SERVER'] + ';' + 'PORT=' + RECIPE_DB['PORT'] + ';' +
'DATABASE=' + RECIPE_DB['DATABASE'] + ';' + 'UID=' + RECIPE_DB['USER']
+ ';' + 'PWD=' + RECIPE_DB['PASSWORD'] + ';')
'
Thanks.
--
https://mail.python.org/mailman/listinfo/python-list
Re: pyodbc connect string
On Tue, Apr 29, 2014 at 7:14 PM, Ben Finney wrote:
> Larry Martell writes:
>
>> I am having a problem building a connect string for pyodbc. It works
>> when everything is hard coded, but if I build the connect string it
>> fails.
>>
>> This works:
>>
>> pyodbc.connect('DRIVER=FreeTDS;' 'SERVER=xx.xx.xx.xx;' 'PORT=1433;'
>> 'DATABASE=blah;' 'UID=foo;' 'PWD=bar;')
>
> This calls the function with a single string,
> "DRIVER=FreeTDS;SERVER=xx.xx.xx.xx;PORT=1433;DATABASE=blah;UID=foo;PWD=bar;".
>
> Remember that consecutive, whitespace-separated, quote-delimited
> fragments specify the construction of a single string literal::
>
> >>> 'foo'
> 'foo'
> >>> 'foo' 'bar'
> 'foobar'
> >>> 'foo' 'bar' 'baz'
> 'foobarbaz'
>
> See the reference for how this concatenation occurs
> https://docs.python.org/3/reference/lexical_analysis.html#string-literal-concatenation>.
>
>> But this does not:
>>
>> pyodbc.connect(conn_str)
>>
>> Where conn_str is:
>>
>> 'DRIVER=FreeTDS;' 'SERVER=xx.xx.xx.xx;' 'PORT=1433;' 'DATABASE=blah;'
>> 'UID=foo;' 'PWD=bar;'
>
> This string is different, because it contains a whole lot of quotation
> marks and whitespace not in the string you show in the first example.
>
>> conn_str is constructed with:
>>
>> conn_str = "'DRIVER=%s;' 'SERVER=%s;' 'PORT=%s;' 'DATABASE=%s;'
>> 'UID=%s;' 'PWD=%s;'" \
>> % (RECIPE_DB['DRIVER'], RECIPE_DB['SERVER'],
>> RECIPE_DB['PORT'], RECIPE_DB['DATABASE'],
>>RECIPE_DB['USER'], RECIPE_DB['PASSWORD'])
>
> Remove the extraneous quotes and whitespace, which were not in the
> original string you showed above.
>
> On a separate point: Since you have string keys for the mapping, you can
> make the interpolation more readable::
>
> conn_str = (
> "DRIVER=%(DRIVER)s;SERVER=%(SERVER)s;PORT=%(PORT)s;"
> "DATABASE=%(DATABASE)s;UID=%(USER)s;PWD=%(PASSWORD)s;"
> ) % RECIPE_DB
>
> since the named placeholders will be looked up by key in the ‘RECIPE_DB’
> mapping.
>
> There are other improvements to suggest, but I don't want to distract
> from the main point of the post.
Thanks for the explanation.
--
https://mail.python.org/mailman/listinfo/python-list
Bug in Decimal??
Hello,
I believe I found a bug in the Decimal library. The natural logarithm results
seem to be off in a certain range, as compared with Wolfram Alpha.
Here's an example:
from decimal import *
getcontext().prec=2016
one=Decimal(1)
number=Decimal('1e-1007')
partial=(one+number)/(one-number)
final.ln()
The result should be 2.0... with all zeroes and 7 at the end. Instead, I'm
getting 1.99.. with 2 digits different at the end.
I checked that this happens for any 1e-N with N relatively large (above about
300 it starts showing bad digits at the end.
Set the precision even higher and you'll see more digits off, it seems for
number=10^-N, the error begins around 10^(-2N). The partial result (1+x)/(1-x)
is correct to the number of digits specified, so it seems ln() is having
accuracy problems.
Can other people confirm this or is it just my imagination? I tested with
python 2.7.5 in XUbuntu, and also with my own build of mpdecimal 2.4.0 (latest,
built from source). I compared the results with wolfram Alpha, and also with an
open source arbitrary precision calculator, which matches Alpha results.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Significant digits in a float?
On Tue, 29 Apr 2014 09:38:33 -0400, Roy Smith wrote: > > What reason do you have to think that something recorded to 14 decimal > > places was only intended to have been recorded to 4? > > Because I understand the physical measurement these numbers represent. > Sometimes, Steve, you have to assume that when somebody asks a question, > they actually have asked the question then intended to ask. Heh, having been in *exactly* your situation of having people questioning my constraints, I can sympathise with your frustration. I was pretty frustrated too. But I've also been in situations where I've been so close to a question that I couldn't see the big picture, and a few dumb questions made me realise that in fact I was missing something obvious which changed the situation completely. To paraphrase: Me: How do I square the circle with only a compass and straightedge? Them: You can't. It's impossible. Are you sure you need only use compass and straightedge? Can you use a rolling circle and a marked ruler? Me: Come come, I've told you my requirements, compass and straightedge only. Now solve my problem! Them: Does it have to be in Euclidean space? Why don't you perform the construction in Gauss-Bolyai-Lobachevsky space? Me: Perhaps a rolling circle and ruler isn't such a bad idea... http://www.cut-the-knot.org/impossible/sq_circle.shtml http://mathworld.wolfram.com/CircleSquaring.html :-) -- Steven D'Aprano http://import-that.dreamwidth.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: Significant digits in a float?
On 04/29/2014 03:51 PM, Chris Angelico wrote: On Wed, Apr 30, 2014 at 8:42 AM, emile wrote: On 04/29/2014 01:16 PM, Adam Funk wrote: "A man pitches his tent, walks 1 km south, walks 1 km east, kills a bear, & walks 1 km north, where he's back at his tent. What color is the bear?" ;-) From how many locations on Earth can someone walk one mile south, one mile east, and one mile north and end up at their starting point? Any point where the mile east takes you an exact number of times around the globe. So, anywhere exactly one mile north of that, which is a number of circles not far from the south pole. Perhaps my geography is rusty, but I was under the impression that one cannot travel south if one is at the South Pole (axial, not magnetic). -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: Significant digits in a float?
On Tue, 29 Apr 2014 19:31:31 -0700, Ethan Furman wrote: > Perhaps my geography is rusty, but I was under the impression that one > cannot travel south if one is at the South Pole (axial, not magnetic). Possibly with a rocket aimed straight up. -- Steven D'Aprano http://import-that.dreamwidth.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: Significant digits in a float?
In article <5360672e$0$29965$c3e8da3$54964...@news.astraweb.com>, Steven D'Aprano wrote: > On Tue, 29 Apr 2014 19:31:31 -0700, Ethan Furman wrote: > > > Perhaps my geography is rusty, but I was under the impression that one > > cannot travel south if one is at the South Pole (axial, not magnetic). > > Possibly with a rocket aimed straight up. No, with a rocket aimed straight up, you go north. To go south, you need a rocket aimed straight down. -- https://mail.python.org/mailman/listinfo/python-list
Re: Bug in Decimal??
On Tue, 29 Apr 2014 19:37:17 -0700, pleasedontspam wrote:
> from decimal import *
> getcontext().prec=2016
> one=Decimal(1)
> number=Decimal('1e-1007')
> partial=(one+number)/(one-number)
> final.ln()
What's final? Did you mean partial?
When I try it in Python 3.3, I get:
py> from decimal import *
py> getcontext().prec=2016
py> one = Decimal(1)
py> number = Decimal('1e-1007')
py> partial = (one+number)/(one-number)
py> partial.ln()
Decimal('1.[...]987E-1007')
with a lot of 9s deleted for brevity.
> The result should be 2.0... with all zeroes and 7 at the end.
Can you demonstrate exactly how you tested it on Wolfram-Alpha, because I
cannot reproduce that. When I try it with ln((1+1e-1007)/(1-1e-1007)),
the decimal expansion shown starts off as:
2.0... × 10^-1007
By repeatedly clicking "More digits", I get:
2.000...
× 10^-1007
For brevity, I will truncate some repeated digits from this point on.
1.9[...]9...
× 10^-1007
as above, except with even more nines (477 of them if I have calculated
correctly)
2.0[...]00...
× 10^-1007
as above, with even more zeroes
and finally the last available approximation is
2.00[...]0066[...]66... × 10^-1007
with a lot of zeroes and sixes not shown. But not ending in 7.
> Instead, I'm getting 1.99.. with 2 digits different at the end.
Well, it's hard to say exactly what's going on, since Wolfram Alpha
doesn't show the context, but it looks like Python's version may agree
with two out of the seven decimal approximations Alpha makes available.
This suggests to me that it's a representation issue.
[...]
> Can other people confirm this or is it just my imagination? I tested
> with python 2.7.5 in XUbuntu, and also with my own build of mpdecimal
> 2.4.0 (latest, built from source). I compared the results with wolfram
> Alpha, and also with an open source arbitrary precision calculator,
> which matches Alpha results.
I think it's worth raising a ticket for it on the bug tracker.
I think it would help if you can provide a link or instructions to how to
replicate this in Alpha, also give the name and version number of the
arbitrary precision calculator you used. Anything that can be used to
replicate your results.
--
Steven D'Aprano
http://import-that.dreamwidth.org/
--
https://mail.python.org/mailman/listinfo/python-list
Re: Significant digits in a float?
On Wed, Apr 30, 2014 at 12:31 PM, Ethan Furman wrote: > On 04/29/2014 03:51 PM, Chris Angelico wrote: >> Any point where the mile east takes you an exact number of times >> around the globe. So, anywhere exactly one mile north of that, which >> is a number of circles not far from the south pole. > > Perhaps my geography is rusty, but I was under the impression that one > cannot travel south if one is at the South Pole (axial, not magnetic). Correct, but there's a place not far from the South Pole where the circumference of the earth (travelling east) will be exactly one mile. I could calculate where that would be on a perfect sphere, but earth isn't, so I'll just say "near the South Pole". If you start exactly one mile north of that circle, then you can accomplish the original challenge. Also, if your mile east takes you exactly twice around the circumference, you still achieve the same thing, so there's another circle (one mile north of *that* circle), and another at the three-times-around circle, etc. But I think a better answer is New York City. You start out lost, you go a mile south, a mile east, a mile north, and you are again lost. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Significant digits in a float?
On Wed, Apr 30, 2014 at 1:30 PM, Roy Smith wrote: > In article <5360672e$0$29965$c3e8da3$54964...@news.astraweb.com>, > Steven D'Aprano wrote: > >> On Tue, 29 Apr 2014 19:31:31 -0700, Ethan Furman wrote: >> >> > Perhaps my geography is rusty, but I was under the impression that one >> > cannot travel south if one is at the South Pole (axial, not magnetic). >> >> Possibly with a rocket aimed straight up. > > No, with a rocket aimed straight up, you go north. To go south, you > need a rocket aimed straight down. If I ever go travelling with you guys, I am NOT letting you navigate. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Unicode 7
On Tuesday, April 29, 2014 11:29:23 PM UTC+5:30, Tim Chase wrote: > While I dislike feeding the troll, what I see here is: Since its Unicode-troll time, here's my contribution http://blog.languager.org/2014/04/unicode-and-unix-assumption.html :-) More seriously, since Ive quoted some esteemed members of this list explicitly (Steven) and the list in general, please let me know if something is inaccurate or inappropriate -- https://mail.python.org/mailman/listinfo/python-list
Re: segmentation fault, executable python file
I try gdb the executable file in another machine and get this: Error -3 from inflate: incorrect header check Error decompresing struct if I do gdb in my machine (where I generate the executable file) I get nothing, and the app work correctly. I try to search about that, but i don't get it. Could any of you please let me know how to fix this? Thank u before -- https://mail.python.org/mailman/listinfo/python-list
