[issue9056] Adding additional level of bookmarks and section numbers in python pdf documents.

[Julien Palard]

Julien Palard  added the comment:

Merged Cheryl's patch (thanks Cheryl!).

pengyu.ut if you want to test it you'll be able to see generated PDF in a 
maximum of 24h from now on [1].

Don't hesitate to ask if you need them for 3.8 we can backport it.

[1]: https://docs.python.org/dev/

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9056] Adding additional level of bookmarks and section numbers in python pdf documents.

[Cheryl Sabella]

Change by Cheryl Sabella :


--
nosy: +cheryl.sabella, mdk
versions: +Python 3.8 -Python 3.3

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9056] Adding additional level of bookmarks and section numbers in python pdf documents.

[Cheryl Sabella]

Change by Cheryl Sabella :


--
keywords: +patch
pull_requests: +9026
stage: needs patch -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Lucky numbers in Python

[Cecil Westerhof]

Op Thursday 30 Apr 2015 04:55 CEST schreef Ian Kelly:

 On Wed, Apr 29, 2015 at 6:01 PM, Cecil Westerhof ce...@decebal.nl wrote:
 Op Thursday 30 Apr 2015 00:38 CEST schreef Ian Kelly:
 In that case you can definitely omit the middle term of the slice,
 which will be both more concise and clearer in intent, though
 probably not significantly faster.

 It is certainly nit faster. It is even significantly slower. With
 the middle term lucky_numbers(int(1e6)) takes 0.13 seconds. Without
 it takes 14.3 seconds. Hundred times as long.

 That would be rather surprising, since it's the same operation being
 performed, so I did my own timing and came up with 0.25 seconds
 (best of 3) with the middle term and 0.22 seconds without.

 I suspect that you tested it as del sieve[skip_count - 1 :
 skip_count] (which would delete only one item) rather than del
 sieve[skip_count - 1 :: skip_count].

Yeah, that is how I interpreted omitting the middle term. But it
seemed to give the right results.

With your amendment it runs slightly faster. With 1E7 it is 8.0 and
7.7. So almost 4% faster.

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Lucky numbers in Python

[Cecil Westerhof]

Because I want the code to work with Python 3 also, the code is now:
def lucky_numbers(n):

Lucky numbers from 1 up-to n
http://en.wikipedia.org/wiki/Lucky_number


if n  3:
return [1]
sieve = list(range(1, n + 1, 2))
sieve_index = 1
while True:
sieve_len   = len(sieve)
if (sieve_index + 1)  sieve_len:
break
skip_count  = sieve[sieve_index]
if sieve_len  skip_count:
break
del sieve[skip_count - 1 : : skip_count]
sieve_index += 1
return sieve

It looks like the list in:
sieve = list(range(1, n + 1, 2))

does not have much influence in Python 2. So I was thinking of leaving
the code like it is. Or is it better to check and do the list only
with Python 3?

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Lucky numbers in Python

[Dave Angel]

On 04/30/2015 02:55 PM, Cecil Westerhof wrote:

Because I want the code to work with Python 3 also, the code is now:
 def lucky_numbers(n):
 
 Lucky numbers from 1 up-to n
 http://en.wikipedia.org/wiki/Lucky_number
 

 if n  3:
 return [1]
 sieve = list(range(1, n + 1, 2))
 sieve_index = 1
 while True:
 sieve_len   = len(sieve)
 if (sieve_index + 1)  sieve_len:
 break
 skip_count  = sieve[sieve_index]
 if sieve_len  skip_count:
 break
 del sieve[skip_count - 1 : : skip_count]
 sieve_index += 1
 return sieve

It looks like the list in:
 sieve = list(range(1, n + 1, 2))

does not have much influence in Python 2. So I was thinking of leaving
the code like it is. Or is it better to check and do the list only
with Python 3?



I'd do something like this at top of the module:

try:
range = xrange
except NameError as ex:
pass

then use range as it is defined in Python3.

if that makes you nervous, then define irange = xrange, and if it gets a 
NameError exception, irange = range



--
DaveA
--
https://mail.python.org/mailman/listinfo/python-list

Re: Lucky numbers in Python

[Ian Kelly]

On Wed, Apr 29, 2015 at 12:24 PM, Cecil Westerhof ce...@decebal.nl wrote:
 I was wondering if there is a way to do this:
 for del_index in range((sieve_len // skip_count) * skip_count - 1,
   skip_count - 2, -skip_count):
 del sieve[del_index]
 in a more efficient way.

You can delete using slices.

del sieve[(sieve_len // skip_count) * skip_count - 1 : skip_count - 2
: -skip_count]

Now you no longer need to do the iteration in reverse, which makes the
slicing simpler:

del sieve[skip_count - 1 : (sieve_len // skip_count) * skip_count : skip_count]

And although it's not clear to me what this is supposed to be doing,
you probably no longer need the middle term if the intention is to
continue deleting all the way to the end of the list (if it is then I
think you have a bug in the existing implementation, since the last
item in the list can never be deleted).

del sieve[skip_count - 1 :: skip_count]
-- 
https://mail.python.org/mailman/listinfo/python-list

Lucky numbers in Python

[Cecil Westerhof]

I wrote a function lucky_numbers:
def lucky_numbers(n):
if n  3:
return [1]
sieve = range(1, n + 1, 2)
sieve_index = 1
while True:
skip_count  = sieve[sieve_index]
sieve_len   = len(sieve)
if sieve_len  skip_count:
break
for del_index in range((sieve_len // skip_count) * skip_count - 1, 
  skip_count - 2, -skip_count):
del sieve[del_index]
sieve_index += 1
return sieve

I was wondering if there is a way to do this:
for del_index in range((sieve_len // skip_count) * skip_count - 1, 
  skip_count - 2, -skip_count):
del sieve[del_index]
in a more efficient way.

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Lucky numbers in Python

[Cecil Westerhof]

Op Wednesday 29 Apr 2015 21:57 CEST schreef Ian Kelly:

 On Wed, Apr 29, 2015 at 12:24 PM, Cecil Westerhof ce...@decebal.nl wrote:
 I was wondering if there is a way to do this:
 for del_index in range((sieve_len // skip_count) * skip_count - 1,
 skip_count - 2, -skip_count):
 del sieve[del_index]
 in a more efficient way.

 You can delete using slices.

 del sieve[(sieve_len // skip_count) * skip_count - 1 : skip_count -
 2 : -skip_count]

 Now you no longer need to do the iteration in reverse, which makes
 the slicing simpler:

 del sieve[skip_count - 1 : (sieve_len // skip_count) * skip_count :
 skip_count]

I expected that it could be done more efficiently, but did not expect
such a big difference: more as hundred times. The old situation took
20 seconds for 100. The new takes 0.17.

The code is know (I added a missing check):
def lucky_numbers(n):
if n  3:
return [1]
sieve = range(1, n + 1, 2)
sieve_index = 1
while True:
sieve_len   = len(sieve)
if (sieve_index + 1)  sieve_len:
break
skip_count  = sieve[sieve_index]
if sieve_len  skip_count:
break
del sieve[skip_count - 1 : (sieve_len // skip_count) * skip_count : 
skip_count]
sieve_index += 1
return sieve


 And although it's not clear to me what this is supposed to be doing,
 you probably no longer need the middle term if the intention is to
 continue deleting all the way to the end of the list (if it is then
 I think you have a bug in the existing implementation, since the
 last item in the list can never be deleted).

What do you mean by this? Executing:
lucky_numbers(5)
gives:
[1, 3]

So the last element (5) is deleted.

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Lucky numbers in Python

[Ian Kelly]

On Wed, Apr 29, 2015 at 3:45 PM, Cecil Westerhof ce...@decebal.nl wrote:
 Op Wednesday 29 Apr 2015 21:57 CEST schreef Ian Kelly:
 And although it's not clear to me what this is supposed to be doing,
 you probably no longer need the middle term if the intention is to
 continue deleting all the way to the end of the list (if it is then
 I think you have a bug in the existing implementation, since the
 last item in the list can never be deleted).

 What do you mean by this? Executing:
 lucky_numbers(5)
 gives:
 [1, 3]

 So the last element (5) is deleted.

Off by one error on my part. This is why negative skip values on
ranges and slices are not recommended: they're confusing. :-)

In that case you can definitely omit the middle term of the slice,
which will be both more concise and clearer in intent, though probably
not significantly faster.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Lucky numbers in Python

[Chris Kaynor]

On Wed, Apr 29, 2015 at 2:45 PM, Cecil Westerhof ce...@decebal.nl wrote:

  I was wondering if there is a way to do this:
  for del_index in range((sieve_len // skip_count) * skip_count - 1,
  skip_count - 2, -skip_count):
  del sieve[del_index]
  in a more efficient way.
 
  You can delete using slices.
 
  del sieve[(sieve_len // skip_count) * skip_count - 1 : skip_count -
  2 : -skip_count]
 
  Now you no longer need to do the iteration in reverse, which makes
  the slicing simpler:
 
  del sieve[skip_count - 1 : (sieve_len // skip_count) * skip_count :
  skip_count]

 I expected that it could be done more efficiently, but did not expect
 such a big difference: more as hundred times. The old situation took
 20 seconds for 100. The new takes 0.17.


Its not too surprising, as deleting the non-end element of a list is a O(n)
operation - it must copy all elements in the list into a new list each
time. This means that your algorithm is roughly O(n*n*log(n)) performance -
n for each list delete, which is wrapped in a for loop of n iterations,
which is wrapped in a while loop which will run log(n) times (I think that
while loop will run log(n) times, but have not actually tested the math).

Deleting a slice should take n time as well, however it is now done only
once rather than once per item to be removed, which should reduce the
overall algorithm to O(n*log(n)) time - aka, a HUGE difference with any
moderate to large input.

Chris
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Lucky numbers in Python

[Steven D'Aprano]

On Thu, 30 Apr 2015 05:57 am, Ian Kelly wrote:

 On Wed, Apr 29, 2015 at 12:24 PM, Cecil Westerhof ce...@decebal.nl
 wrote:
 I was wondering if there is a way to do this:
 for del_index in range((sieve_len // skip_count) * skip_count
 - 1,
   skip_count - 2, -skip_count):
 del sieve[del_index]
 in a more efficient way.
 
 You can delete using slices.
 
 del sieve[(sieve_len // skip_count) * skip_count - 1 : skip_count - 2
 : -skip_count]
 
 Now you no longer need to do the iteration in reverse, which makes the
 slicing simpler:
 
 del sieve[skip_count - 1 : (sieve_len // skip_count) * skip_count :
 skip_count]

True, but *probably* at the expense of speed. When you delete items from a
list, the remaining items have to be moved, which takes time, especially
for very large lists.

Most of the time, rather than deleting items, it is faster to set them to a
placeholder (for example None) and then copy the ones which aren't None in
a separate loop:


def erat(n):
Return a list of primes up to and including n.

This is a fixed-size version of the Sieve of Eratosthenes, using an
adaptation of the traditional algorithm.

 erat(30)
[2, 3, 5, 7, 11, 13, 17, 19, 23, 29]


if n  2:
return []
# Generate a fixed array of integers.
arr = list(range(n+1))  # A list is faster than an array.
# Cross out 0 and 1 since they aren't prime.
arr[0] = arr[1] = None
i = 2
while i*i = n:
# Cross out all the multiples of i starting from i**2.
for p in range(i*i, n+1, i):
arr[p] = None
# Advance to the next number not crossed off.
i += 1
while i = n and arr[i] is None:
i += 1
# Copy the items which aren't None.
return list(filter(None, arr))


The above is written for Python 3. In Python 2, you can safely drop the two
calls to list() since both range and filter already return lists.

Another alternative is to use slice assignment of the slices that you don't
delete, rather than deleting directly:


del alist[5:55]

is similar to:

alist[:] = alist[:4] + alist[55:]  # Note the [:] on the left.


Which is faster will probably depend on the specifics of the list.

But of course for small lists, none of this matters and you should just use
whatever is easiest and most natural to read.




-- 
Steven

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

Re: Lucky numbers in Python

[Cecil Westerhof]

Op Thursday 30 Apr 2015 00:38 CEST schreef Ian Kelly:

 On Wed, Apr 29, 2015 at 3:45 PM, Cecil Westerhof ce...@decebal.nl wrote:
 Op Wednesday 29 Apr 2015 21:57 CEST schreef Ian Kelly:
 And although it's not clear to me what this is supposed to be
 doing, you probably no longer need the middle term if the
 intention is to continue deleting all the way to the end of the
 list (if it is then I think you have a bug in the existing
 implementation, since the last item in the list can never be
 deleted).

 What do you mean by this? Executing:
 lucky_numbers(5)
 gives:
 [1, 3]

 So the last element (5) is deleted.

 Off by one error on my part. This is why negative skip values on
 ranges and slices are not recommended: they're confusing. :-)

 In that case you can definitely omit the middle term of the slice,
 which will be both more concise and clearer in intent, though
 probably not significantly faster.

It is certainly nit faster. It is even significantly slower. With the
middle term lucky_numbers(int(1e6)) takes 0.13 seconds. Without it
takes 14.3 seconds. Hundred times as long.

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Lucky numbers in Python

[Ian Kelly]

On Wed, Apr 29, 2015 at 6:01 PM, Cecil Westerhof ce...@decebal.nl wrote:
 Op Thursday 30 Apr 2015 00:38 CEST schreef Ian Kelly:
 In that case you can definitely omit the middle term of the slice,
 which will be both more concise and clearer in intent, though
 probably not significantly faster.

 It is certainly nit faster. It is even significantly slower. With the
 middle term lucky_numbers(int(1e6)) takes 0.13 seconds. Without it
 takes 14.3 seconds. Hundred times as long.

That would be rather surprising, since it's the same operation being
performed, so I did my own timing and came up with 0.25 seconds (best
of 3) with the middle term and 0.22 seconds without.

I suspect that you tested it as del sieve[skip_count - 1 :
skip_count] (which would delete only one item) rather than del
sieve[skip_count - 1 :: skip_count].
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Lucky numbers in Python

[Ian Kelly]

On Wed, Apr 29, 2015 at 6:11 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
 On Thu, 30 Apr 2015 05:57 am, Ian Kelly wrote:

 On Wed, Apr 29, 2015 at 12:24 PM, Cecil Westerhof ce...@decebal.nl
 wrote:
 I was wondering if there is a way to do this:
 for del_index in range((sieve_len // skip_count) * skip_count
 - 1,
   skip_count - 2, -skip_count):
 del sieve[del_index]
 in a more efficient way.

 You can delete using slices.

 del sieve[(sieve_len // skip_count) * skip_count - 1 : skip_count - 2
 : -skip_count]

 Now you no longer need to do the iteration in reverse, which makes the
 slicing simpler:

 del sieve[skip_count - 1 : (sieve_len // skip_count) * skip_count :
 skip_count]

 True, but *probably* at the expense of speed. When you delete items from a
 list, the remaining items have to be moved, which takes time, especially
 for very large lists.

 Most of the time, rather than deleting items, it is faster to set them to a
 placeholder (for example None) and then copy the ones which aren't None in
 a separate loop:

You're correct, but I think this would be difficult to apply to the
OP's algorithm since the list indexing depends on the items from
previous iterations having been removed.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue22206] PyThread_create_key(): fix comparison between signed and unsigned numbers in Python/thread_pthread.h

[Roundup Robot]

Roundup Robot added the comment:

New changeset 1b898b5d5ffe by Victor Stinner in branch 'default':
Issue #22206: Using pthread, PyThread_create_key() now sets errno to ENOMEM and
http://hg.python.org/cpython/rev/1b898b5d5ffe

--
nosy: +python-dev

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22206
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22206] PyThread_create_key(): fix comparison between signed and unsigned numbers in Python/thread_pthread.h

[STINNER Victor]

STINNER Victor added the comment:

I fixed the issue in Python 3.5, I close the issue.

Even if Python 2.7 and 3.4 are also affected, I prefer to not modify them to 
not take the risk of introducing a regression for a corner case.

--
resolution:  - fixed
status: open - closed
versions:  -Python 2.7, Python 3.4

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22206
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22206] PyThread_create_key(): fix comparison between signed and unsigned numbers in Python/thread_pthread.h

[STINNER Victor]

STINNER Victor added the comment:

pthread_key_create_overflow.patch: safer patch, delete the newly created key 
and return an error on integer overflow.

--
Added file: http://bugs.python.org/file36386/pthread_key_create_overflow.patch

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22206
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22206] PyThread_create_key(): fix comparison between signed and unsigned numbers in Python/thread_pthread.h

[Serhiy Storchaka]

Changes by Serhiy Storchaka storch...@gmail.com:


--
nosy: +pitrou
stage:  - patch review
type:  - behavior
versions: +Python 2.7, Python 3.4

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22206
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22206] PyThread_create_key(): fix comparison between signed and unsigned numbers in Python/thread_pthread.h

[STINNER Victor]

Changes by STINNER Victor victor.stin...@gmail.com:


--
title: PyThread_create_key(): fix comparison between signed and unsigned 
numbers - PyThread_create_key(): fix comparison between signed and unsigned 
numbers in Python/thread_pthread.h

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22206
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Question on using FP numbers in python 2

[Steven D'Aprano]

On Sat, 15 Feb 2014 00:07:49 -0500, Gene Heskett wrote:

 Can you extract the float calculations and show us, together with some
 sample data, expected result, and actual result?
 
 Not extract, but let you get  look at the code, its the top entry on
 this page:
 
 http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Simple_LinuxCNC_G-
 Code_Generators#Counterbore_Software

Here is the direct link to the Python code:

http://wiki.linuxcnc.org/uploads/counterbore.py


 Assume no bolt size is clicked on, but a wanted diameter is entered in
 the lower left pair of boxes, and its to carve .700 deep in the other
 box. The cutting tool is .250 in diameter, its to do a stepover of 25%
 of the tool diameter, while carving an additional .015 out of the .850
 hole with the tool bit turning 2000 rpm as it spirals down.

If I've understood the purpose of this program correctly, it generates 
code in some language called G-code, presumably to control some sort of 
actual physical cutting machine. So the first thing you ought to do is 
have a G-code expert look at the generated code and tell you it does what 
it is supposed to do. Or perhaps your cutting machine is buggy.

 But the hole it will cut will only be .650 in diameter,  And the
 backplot, shown in the axis interface, shows no spiral, its doing what
 it thinks is full diameter in one circular plunge cut.


Scroll to the GeneratePath method, and read the comments at the top of 
the method. They tell you that the *intention* is:

* If the tool diameter equals the hole diameter, then just Plunge 
  down to the hole depth.
 
* If the tool diameter is less than 80% of the hole diameter, 
  then Plunge to each Level and Spiral out.

* If the tool diameter is greater than 80% of the hole diameter,
  then Spiral to each Level and Spiral out.

But a little later, we see this code:

# Figure out what kind of entry into the hole
if (self.ToolDiameter * 1.25 = self.HoleDiameter):
self.CutType = 'Spiral Down to Depth of each Pass and Spiral Out'
else:
if (self.ToolDiameter  self.HoleDiameter):
self.CutType = 'Plunge Down to Depth of each Pass and Spiral 
Out'
else:
self.CutType = 'Plunge Down to Hole Depth'


Assuming that the comments are correct, the CutType is wrong. It looks 
like a simple logic error, and should be something like this:

# Figure out what kind of entry into the hole
if (self.ToolDiameter * 1.25 = self.HoleDiameter):
self.CutType = 'Plunge down and spiral out'
elif (self.ToolDiameter * 1.25  self.HoleDiameter):
self.CutType = 'Spiral down and spiral out'
else:
self.CutType = 'Plunge down'

CutType is, I believe, merely a comment, but it leads me to believe that 
there are probably similar logic errors in the rest of the GeneratePath 
method. In fact, the description states:

At this time there is a bug if you have a path that does not require a 
spiral... working on it



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

Re: Question on using FP numbers in python 2

[Gene Heskett]

On Saturday 15 February 2014 12:13:42 Steven D'Aprano did opine:

 On Sat, 15 Feb 2014 00:07:49 -0500, Gene Heskett wrote:
  Can you extract the float calculations and show us, together with
  some sample data, expected result, and actual result?
  
  Not extract, but let you get  look at the code, its the top entry on
  this page:
  
  http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Simple_LinuxCNC_G-
  Code_Generators#Counterbore_Software
 
 Here is the direct link to the Python code:
 
 http://wiki.linuxcnc.org/uploads/counterbore.py
 
  Assume no bolt size is clicked on, but a wanted diameter is entered in
  the lower left pair of boxes, and its to carve .700 deep in the other
  box. The cutting tool is .250 in diameter, its to do a stepover of 25%
  of the tool diameter, while carving an additional .015 out of the
  .850 hole with the tool bit turning 2000 rpm as it spirals down.
 
 If I've understood the purpose of this program correctly, it generates
 code in some language called G-code, presumably to control some sort
 of actual physical cutting machine.

More or less standard cNC machine control language.

 So the first thing you ought to do
 is have a G-code expert look at the generated code and tell you it does
 what it is supposed to do.
I think I might qualify for that expert label.  Looking at the output code, 
take the maximum X values it outputs plus and minus, add, then add the tool 
diameter to get the size of the pocket it will cut.  I don't need a 
graphical backplot to check that.

 Or perhaps your cutting machine is buggy.

Not impossible, but that part of the scaling code is 20+ years mature.  It 
knows exactly how many times to step the motor to move the tables 20 feet 
with micron accuracy if there is no mechanical backlash between the motor 
and the table.  Unfortunately there is in my toy mill, which is whats 
driving me to install ball screws in the table drives, which can have 
backlashes well under .0001 if properly made.

  But the hole it will cut will only be .650 in diameter,  And the
  backplot, shown in the axis interface, shows no spiral, its doing what
  it thinks is full diameter in one circular plunge cut.
 
 Scroll to the GeneratePath method, and read the comments at the top of
 the method. They tell you that the *intention* is:
 
 * If the tool diameter equals the hole diameter, then just Plunge
   down to the hole depth.
 
 * If the tool diameter is less than 80% of the hole diameter,
   then Plunge to each Level and Spiral out.
 
 * If the tool diameter is greater than 80% of the hole diameter,
   then Spiral to each Level and Spiral out.
 
 But a little later, we see this code:
 
 # Figure out what kind of entry into the hole
 if (self.ToolDiameter * 1.25 = self.HoleDiameter):
 self.CutType = 'Spiral Down to Depth of each Pass and Spiral
 Out' else:
 if (self.ToolDiameter  self.HoleDiameter):
 self.CutType = 'Plunge Down to Depth of each Pass and Spiral
 Out'
 else:
 self.CutType = 'Plunge Down to Hole Depth'
 
 
 Assuming that the comments are correct, the CutType is wrong. It looks
 like a simple logic error, and should be something like this:
 
 # Figure out what kind of entry into the hole
 if (self.ToolDiameter * 1.25 = self.HoleDiameter):
 self.CutType = 'Plunge down and spiral out'
 elif (self.ToolDiameter * 1.25  self.HoleDiameter):
 self.CutType = 'Spiral down and spiral out'
 else:
 self.CutType = 'Plunge down'
 
 CutType is, I believe, merely a comment, but it leads me to believe that
 there are probably similar logic errors in the rest of the GeneratePath
 method. In fact, the description states:
 
 At this time there is a bug if you have a path that does not require a
 spiral... working on it

And I just heard back, he is looking at it again.

Thanks Steven.

Cheers, Gene
-- 
There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order.
-Ed Howdershelt (Author)
Genes Web page http://geneslinuxbox.net:6309/gene

NOTICE: Will pay 100 USD for an HP-4815A defective but
complete probe assembly.

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

Question on using FP numbers in python 2

[Gene Heskett]

Greetings;

Is there something I can search for and fix in some python code that is 
giving me bogus answers that get good only when there is a valid digit to 
the left of the decimal point?

Cheers, Gene
-- 
There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order.
-Ed Howdershelt (Author)
Genes Web page http://geneslinuxbox.net:6309/gene

NOTICE: Will pay 100 USD for an HP-4815A defective but
complete probe assembly.

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

Re: Question on using FP numbers in python 2

[Chris Angelico]

On Sat, Feb 15, 2014 at 2:25 PM, Gene Heskett ghesk...@wdtv.com wrote:
 Is there something I can search for and fix in some python code that is
 giving me bogus answers that get good only when there is a valid digit to
 the left of the decimal point?


Interesting. I'd look for anything that mixes very large and very
small numbers, first off. Otherwise, just follow the standard
debugging technique of stripping code out of your program and seeing
if the problem's still there. Continue until you have the barest
minimum, and hope hope hope that it's a Bohr bug and not a Heisenbug!

If it really is a floating point issue, you probably don't have to
worry about, for instance, a segfault that happens when a garbage
collection run occurs between this statement and that statement...
yes, I've had to deal with that sort of thing! (Turned out to be a
refcount bug in C code. When the gc ran, something got disposed of
that shouldn't have.)

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Question on using FP numbers in python 2

[Steven D'Aprano]

On Fri, 14 Feb 2014 22:25:59 -0500, Gene Heskett wrote:

 Greetings;
 
 Is there something I can search for and fix in some python code that is
 giving me bogus answers that get good only when there is a valid digit
 to the left of the decimal point?

Er, yes? Anything which involves floating point maths?

Your question is to vague to really answer. You are basically saying I'm 
doing some calculations [what sort of calculations?] with floats [how 
many floats? of what values?], and they're wrong [wrong in what way? how 
badly wrong?] unless there is a valid digit [which digits count as valid 
and which as invalid?] to the left of the decimal point in some number.

Can you extract the float calculations and show us, together with some 
sample data, expected result, and actual result?


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

Re: Question on using FP numbers in python 2

[Grant Edwards]

On 2014-02-15, Gene Heskett ghesk...@wdtv.com wrote:

 Is there something I can search for and fix in some python code that
 is giving me bogus answers that get good only when there is a valid
 digit to the left of the decimal point?

Yes.

Search for incorrectly written code and fix it.  I'd start part way
down in that one file, and then also look in that other file, but not
as far down.

At least he doesn't think he's using real numbers...

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

Re: Question on using FP numbers in python 2

[Gene Heskett]

On Friday 14 February 2014 23:37:53 Chris Angelico did opine:

 On Sat, Feb 15, 2014 at 2:25 PM, Gene Heskett ghesk...@wdtv.com wrote:
  Is there something I can search for and fix in some python code that
  is giving me bogus answers that get good only when there is a valid
  digit to the left of the decimal point?
 
 Interesting. I'd look for anything that mixes very large and very
 small numbers, first off. Otherwise, just follow the standard
 debugging technique of stripping code out of your program and seeing
 if the problem's still there. Continue until you have the barest
 minimum, and hope hope hope that it's a Bohr bug and not a Heisenbug!
 
 If it really is a floating point issue, you probably don't have to
 worry about, for instance, a segfault that happens when a garbage
 collection run occurs between this statement and that statement...
 yes, I've had to deal with that sort of thing! (Turned out to be a
 refcount bug in C code. When the gc ran, something got disposed of
 that shouldn't have.)
 
 ChrisA

It is the top utility in this page of linuxcnc code generators:

http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Simple_LinuxCNC_G-
Code_Generators#Counterbore_Software

I looked at it, just enough to understand I haven't learned a thing in 2 
years of lurking on this list.  I see Big John has a bug note, and its 
possible this might be related.  You can get it at the upper link, or there 
is a copy on my pages, under Genes-os9-stf/LCNC directory.

Cheers, Gene
-- 
There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order.
-Ed Howdershelt (Author)
Genes Web page http://geneslinuxbox.net:6309/gene

NOTICE: Will pay 100 USD for an HP-4815A defective but
complete probe assembly.

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

Re: Question on using FP numbers in python 2

[Gene Heskett]

On Friday 14 February 2014 23:47:26 Steven D'Aprano did opine:

 On Fri, 14 Feb 2014 22:25:59 -0500, Gene Heskett wrote:
  Greetings;
  
  Is there something I can search for and fix in some python code that
  is giving me bogus answers that get good only when there is a valid
  digit to the left of the decimal point?
 
 Er, yes? Anything which involves floating point maths?
 
 Your question is to vague to really answer. You are basically saying
 I'm doing some calculations [what sort of calculations?] with floats
 [how many floats? of what values?], and they're wrong [wrong in what
 way? how badly wrong?] unless there is a valid digit [which digits
 count as valid and which as invalid?] to the left of the decimal point
 in some number.
 
 Can you extract the float calculations and show us, together with some
 sample data, expected result, and actual result?

Not extract, but let you get  look at the code, its the top entry on this 
page:

http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Simple_LinuxCNC_G-
Code_Generators#Counterbore_Software

Assume no bolt size is clicked on, but a wanted diameter is entered in the 
lower left pair of boxes, and its to carve .700 deep in the other box.  
The cutting tool is .250 in diameter, its to do a stepover of 25% of the 
tool diameter, while carving an additional .015 out of the .850 hole with 
the tool bit turning 2000 rpm as it spirals down.

But the hole it will cut will only be .650 in diameter,  And the backplot, 
shown in the axis interface, shows no spiral, its doing what it thinks is 
full diameter in one circular plunge cut.  That would leave a big post of 
steel in the center, so I will have to drill it to perhaps a half an inch 
just to keep from pinching  breaking a $20 bit.  But that is a separate 
problem.

So, I  added a .2 offset to the hole diameter, making that entry 1.05.

Then I do get the spiral outward feed, but to make a hole 1.05 in 
diameter.

As for me fixing it, that 30+ kilobytes of python may as well be Navajo.

IOW, help please?

Cheers, Gene
-- 
There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order.
-Ed Howdershelt (Author)
Genes Web page http://geneslinuxbox.net:6309/gene

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

Re: Question on using FP numbers in python 2

[Chris Angelico]

On Sat, Feb 15, 2014 at 4:07 PM, Gene Heskett ghesk...@wdtv.com wrote:
 Not extract, but let you get  look at the code, its the top entry on this
 page:

 http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Simple_LinuxCNC_G-
 Code_Generators#Counterbore_Software

Interesting. At the top of the file, it says GPL3 or later; but then
it puts a requirement on making money off the software. I'm not sure
that's a good thing (what if someone lifts a small part of that code
out and into another GPL project?), and I'm not sure it's
legal/enforceable anyway.

The GUI creation code calls to mind the discussion we had a little
while ago about an alternative way to create a GUI in Python.
Especially compare the GTK2Table() function that I posited - I'm sure
it wouldn't be hard to make a Python (and Tkinter) equivalent.
Massively complicated code for laying out a grid/table.

But check out these comments:

def GeneratePath(self):
 # If ToolDiameter  HoleDiameter then Complain
 # If ToolDiameter == HoleDiameter then Plunge to HoleDepth
 # If (ToolDiameter*1.25) = HoleDiameter then Plunge to each
Level and Spiral out to HoleDiameter
# If (ToolDiameter*1.25)  HoleDiameter then Spiral to each
Level and Spiral out to HoleDiameter

(Also, o! The GeneratePath function is indented with a mixture of
spaces and tabs. Most of it is indented four spaces and then a tab,
but some lines use other mixtures. Ow ow ow!)

Does all that make sense, and are you seeing those boundaries
correctly? I strongly suspect you're not seeing a floating-point
error, but a deliberate piece of code and maybe some other form of
bug. I very much doubt the boundary is anything to do with going over
1 in diameter; the numbers you're working with here are easily within
Python's capability (you get roughly 15 decimal digits of accuracy
with the default float type).

I'm afraid I can't really help more, as I don't speak CNC. But have a
look at GeneratePath(); it does have comments, and for all of being
two hundred lines of code, it's reasonably segmented into sections.
Manually step through it, see where it's going wrong. Standard Python
debugging, nothing to do with floats AFAICT.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Question on using FP numbers in python 2

[Gene Heskett]

On Saturday 15 February 2014 00:43:53 Chris Angelico did opine:

 On Sat, Feb 15, 2014 at 4:07 PM, Gene Heskett ghesk...@wdtv.com wrote:
  Not extract, but let you get  look at the code, its the top entry on
  this page:
  
  http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Simple_LinuxCNC_G-
  Code_Generators#Counterbore_Software
 
 Interesting. At the top of the file, it says GPL3 or later; but then
 it puts a requirement on making money off the software. I'm not sure
 that's a good thing (what if someone lifts a small part of that code
 out and into another GPL project?), and I'm not sure it's
 legal/enforceable anyway.
 
 The GUI creation code calls to mind the discussion we had a little
 while ago about an alternative way to create a GUI in Python.
 Especially compare the GTK2Table() function that I posited - I'm sure
 it wouldn't be hard to make a Python (and Tkinter) equivalent.
 Massively complicated code for laying out a grid/table.
 
 But check out these comments:
 
 def GeneratePath(self):
  # If ToolDiameter  HoleDiameter then Complain
  # If ToolDiameter == HoleDiameter then Plunge to HoleDepth
  # If (ToolDiameter*1.25) = HoleDiameter then Plunge to each
 Level and Spiral out to HoleDiameter
 # If (ToolDiameter*1.25)  HoleDiameter then Spiral to each
 Level and Spiral out to HoleDiameter
 
 (Also, o! The GeneratePath function is indented with a mixture of
 spaces and tabs. Most of it is indented four spaces and then a tab,
 but some lines use other mixtures. Ow ow ow!)
 
 Does all that make sense, and are you seeing those boundaries
 correctly? I strongly suspect you're not seeing a floating-point
 error, but a deliberate piece of code and maybe some other form of
 bug. I very much doubt the boundary is anything to do with going over
 1 in diameter; the numbers you're working with here are easily within
 Python's capability (you get roughly 15 decimal digits of accuracy
 with the default float type).
 
 I'm afraid I can't really help more, as I don't speak CNC.

Actually, the output is RS-274-D, originally from NIST.  But it has 
developed some pretty distinct accents in the 20 some years its been in 
the wild.  The NIST version was, shall we say, quite incomplete but a lot 
of the stuff shoved in to scratch this or that itch is often vaguely 
incompatible with the next vendors version of that particular function.

 But have a
 look at GeneratePath(); it does have comments, and for all of being
 two hundred lines of code, it's reasonably segmented into sections.
 Manually step through it, see where it's going wrong. Standard Python
 debugging, nothing to do with floats AFAICT.
 
 ChrisA

I'll do that when next I have both eyes open at the same time. That is 
usually about halfway thru the third cuppa. :)

Thanks Chris A.

Cheers, Gene
-- 
There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order.
-Ed Howdershelt (Author)
Genes Web page http://geneslinuxbox.net:6309/gene

NOTICE: Will pay 100 USD for an HP-4815A defective but
complete probe assembly.

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

Re: Question on using FP numbers in python 2

[Chris Angelico]

On Sat, Feb 15, 2014 at 4:50 PM, Gene Heskett ghesk...@wdtv.com wrote:
 I'm afraid I can't really help more, as I don't speak CNC.

 Actually, the output is RS-274-D, originally from NIST.  But it has
 developed some pretty distinct accents in the 20 some years its been in
 the wild.  The NIST version was, shall we say, quite incomplete but a lot
 of the stuff shoved in to scratch this or that itch is often vaguely
 incompatible with the next vendors version of that particular function.

Ehh, I don't speak that either, but now I feel like a guy who's told
Polly voo Fronsay? and says that he don't speak no Eyetalon. :)

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue9056] Adding additional level of bookmarks and section numbers in python pdf documents.

[Ezio Melotti]

Changes by Ezio Melotti ezio.melo...@gmail.com:


--
stage:  - needs patch
type:  - enhancement

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9056
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9056] Adding additional level of bookmarks and section numbers in python pdf documents.

[Ezio Melotti]

Changes by Ezio Melotti ezio.melo...@gmail.com:


--
nosy: +ezio.melotti

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9056
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9056] Adding additional level of bookmarks and section numbers in python pdf documents.

[Sandro Tosi]

Sandro Tosi sandro.t...@gmail.com added the comment:

The number of items in the bookmark is controlled by 

\setcounter{tocdepth}{1}

in sphinxmanual.cls, that's included in every latex file (the source of the PDF 
documentation). The cls file is coming directly from sphinx, so Georg: what is 
the purpose of limiting the bookmarks depth to 1? can we consider (somehow) to 
special-case if for python?

--
nosy: +georg.brandl, sandro.tosi
versions: +Python 3.3 -Python 2.6

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9056
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9056] Adding additional level of bookmarks and section numbers in python pdf documents.

[Senthil Kumaran]

Senthil Kumaran orsent...@gmail.com added the comment:

You mean Table of Contents? The index at the end serves as a
bookmark, right?  Also, Table of Contents might add up couple of more
pages to traverse.

--
nosy: +orsenthil

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9056
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9056] Adding additional level of bookmarks and section numbers in python pdf documents.

[pengyu.ut]

pengyu.ut pengyu...@gmail.com added the comment:

On Tue, Jun 22, 2010 at 6:25 AM, Senthil Kumaran rep...@bugs.python.org wrote:

 Senthil Kumaran orsent...@gmail.com added the comment:

 You mean Table of Contents? The index at the end serves as a
 bookmark, right?  Also, Table of Contents might add up couple of more
 pages to traverse.

I don't need subsubsections to be in the table of content. But I think
it is making sense to add them in the bookmarks, as the bookmarks can
be folded even if there are many bookmarks for subsubsections. I'm not
refereeing to index.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9056
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9056] Adding additional level of bookmarks and section numbers in python pdf documents.

[Fred L. Drake, Jr.]

Fred L. Drake, Jr. fdr...@acm.org added the comment:

On Mon, Jun 21, 2010 at 11:00 PM, pengyu.ut rep...@bugs.python.org wrote:
 Current pdf version of python documents don't have bookmarks for
 sussubsection. For example, there is no bookmark for the following
 section in python_2.6.5_reference.pdf.

This would be nice to have.

 Also the bookmarks don't have
 section numbers in them. I suggest to include the section numbers.

Hmm.  I'm not a huge fan of section numbers, but so long as we use them,
there's some rationale to include them in the PDF bookmarks.  So I guess
that's up to whoever creates the patch.

  -Fred

--
nosy: +fdrake

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9056
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9056] Adding additional level of bookmarks and section numbers in python pdf documents.

[pengyu.ut]

New submission from pengyu.ut pengyu...@gmail.com:

Current pdf version of python documents don't have bookmarks for
sussubsection. For example, there is no bookmark for the following
section in python_2.6.5_reference.pdf. Also the bookmarks don't have
section numbers in them. I suggest to include the section numbers.
Could these features be added in future release of python document.

3.4.1 Basic customization

--
assignee: d...@python
components: Documentation
messages: 108334
nosy: d...@python, pengyu.ut
priority: normal
severity: normal
status: open
title: Adding additional level of bookmarks and section numbers in python pdf 
documents.
versions: Python 2.6

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9056
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

How to print zero-padded floating point numbers in python 2.6.1

[Lorenzo Di Gregorio]

Hello,

I thought that I could zero-pad a floating point number in 'print' by
inserting a zero after '%', but this does not work.

I get:

print '%2.2F' % 3.5
3.50
print '%02.2F' % 3.5
3.50

How can I get print (in a simple way) to print 03.50?

Best Regards,
Lorenzo
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How to print zero-padded floating point numbers in python 2.6.1

[Lutz Horn]

Lorenzo Di Gregorio schrieb:
 print '%2.2F' % 3.5
 3.50
 print '%02.2F' % 3.5
 3.50
 
 How can I get print (in a simple way) to print 03.50?

print '%05.2F' % 3.5

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

Re: How to print zero-padded floating point numbers in python 2.6.1

[Chris Rebert]

On Wed, Nov 4, 2009 at 12:04 AM, Lorenzo Di Gregorio
lorenzo.digrego...@gmail.com wrote:
 Hello,

 I thought that I could zero-pad a floating point number in 'print' by
 inserting a zero after '%', but this does not work.

 I get:

 print '%2.2F' % 3.5
 3.50
 print '%02.2F' % 3.5
 3.50

 How can I get print (in a simple way) to print 03.50?

 print (%.2f % 3.5).zfill(5)
03.50
 print (%5.2f % 3.5).replace(' ','0')
03.50

Cheers,
Chris
--
http://blog.rebertia.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Localizing numbers in python

[Heba Farouk]

Hello 
i would like to localize numbers in python according to the current selected 
language of the web page (English, french, arabic, ...), is there any options 
in python??

thanks in advance


Yours 

Heba

   
-
Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, 
photos  more. -- 
http://mail.python.org/mailman/listinfo/python-list

Numbers in python

[brainy_muppet]

Basically, I have a code with is almost finished but I've having
difficultly with the last stage of the process. I have a program that
gets assigns different words with a different value via looking them up
in a dictionary:

eg if THE is in the writing, it assigns 0.965

 and once the whole passage is read it returns all the numbers in the
format as follows:

['0.965', '1.000', '0.291', '1.000', '0.503']

However, I can't seem to get the program to treat the numbers as
numbers. If I put them in the dictionary as 'THE' = int(0.965) the
program returns 1.0 and if I put 'THE' = float(0.965) it returns
0.9655549 or something similar. Neither of these are right! I
basically need to access each item in the string as a number, because
for my last function I want to multiply them all together by each
other.

I have tried two bits of code for this last bit, but neither are
working (I'm not sure about the first one but the second one should
work I think if I could figure out how to return the values as
numbers):

1st code
value = codons[x] * codons[x+1]
x = (int)
x = 0

print value

x +=2

if (xr):
new_value = value * codons[x]
value = new_value
x +=1
else:
print new_value

This gives the error message
Traceback (most recent call last):
  File C:\Python24\code2, line 88, in -toplevel-
value = codons[x] * codons[x+1]
NameError: name 'x' is not defined

Code 2 - the most likely code
prod = 1
for item in (codons): prod *= item
prod
print prod

Gives this error message:
Traceback (most recent call last):
  File C:\Python24\code2, line 90, in -toplevel-
for item in (codons): prod *= item
TypeError: can't multiply sequence by non-int


Anyone got any ideas?
Dave.

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

Re: Numbers in python

[Diez B. Roggisch]

 However, I can't seem to get the program to treat the numbers as
 numbers. If I put them in the dictionary as 'THE' = int(0.965) the
 program returns 1.0

It certainoly does _not_ return 1.0 - it returns 1. And that is all it can
return for being an integer that has by definition no fractional part.

 and if I put 'THE' = float(0.965) it returns 
 0.9655549 or something similar. Neither of these are right! I
 basically need to access each item in the string as a number, because
 for my last function I want to multiply them all together by each
 other.

It _is_ the right number if you use floats - you just have to take into
account that 10-based fractions can't always be represented properly by
2-based IEEE floating points, resulting in rounding errors. Which is what
you see.

http://wiki.python.org/moin/RepresentationError?highlight=%28float%29

Either you don't care about the minor differences, the use float. Or you do,
then use the decimal-class introduced in python 2.4

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

Re: Numbers in python

[Duncan Booth]

 wrote:

 If I put them in the dictionary as 'THE' = int(0.965) the
 program returns 1.0 and if I put 'THE' = float(0.965) it returns
 0.9655549 or something similar. Neither of these are right!

Your system seems to be really screwed. int(0.965) should be 0, and 
float(0.965) should be 0.96497 or something similar.

Read
http://www.python.org/doc/faq/general/#why-are-floating-point-calculations-so-inaccurate

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

Re: Numbers in python

[Fredrik Lundh]

[EMAIL PROTECTED] wrote:

 Basically, I have a code with is almost finished but I've having
 difficultly with the last stage of the process. I have a program that
 gets assigns different words with a different value via looking them up
 in a dictionary:

 eg if THE is in the writing, it assigns 0.965

 and once the whole passage is read it returns all the numbers in the
 format as follows:

 ['0.965', '1.000', '0.291', '1.000', '0.503']

 However, I can't seem to get the program to treat the numbers as
 numbers. If I put them in the dictionary as 'THE' = int(0.965) the
 program returns 1.0 and if I put 'THE' = float(0.965) it returns
 0.9655549 or something similar. Neither of these are right!

int(0.965) is 0 and int(0.965) is an error, so I'm not sure what you
did to get 1.0.

but 0.965 and 0.96497 is indeed the same thing, when
stored as binary floating point numbers:

 0.965
0.96497
 0.965 == 0.96497
True

for an explanation, see this page:

http://docs.python.org/tut/node16.html

in your case, explicitly formatting the numbers on the way might be good
enough, e.g.

print %.3f % value

for details, see:

http://docs.python.org/lib/typesseq-strings

if you really need support for decimal floating point arithmetics, see:

http://docs.python.org/lib/module-decimal.html

/F 



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

Re: Numbers in python

[brainy_muppet]

'It certainoly does _not_ return 1.0 - it returns 1. And that is all it
can
return for being an integer that has by definition no fractional part.
'

For goodness sake, it was a typo, I'm so sorry!

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

Re: Numbers in python

[Diez B. Roggisch]

 It certainoly does _not_ return 1.0 - it returns 1. And that is all it can
 return for being an integer that has by definition no fractional part.

Duncan was right of course. It returns 0.

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

Re: Numbers in python

[brainy_muppet]

'It certainoly does _not_ return 1.0 - it returns 1. And that is all it
can
return for being an integer that has by definition no fractional part.
'

For goodness sake, it was a typo, I'm so sorry!

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

Re: Numbers in python

[neildunn]

If your still worried by using floats for your values you may wish to
look into the decimal module:

http://docs.python.org/lib/module-decimal.html

Example:

 from decimal import Decimal
 Decimal(2) + Decimal('1.47')
Decimal(3.47)


Regards,
Neil

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

Re: Numbers in python

[Steve Holden]

[EMAIL PROTECTED] wrote:
 'It certainoly does _not_ return 1.0 - it returns 1. And that is all it
 can
 return for being an integer that has by definition no fractional part.
 '
 
 For goodness sake, it was a typo, I'm so sorry!
 
Guess that's what you get for calling yourself brainy_muppet then.
There's nothing as satisfying as the sight of a ego with egg on its face :-)

regards
  Steve
-- 
Steve Holden   +44 150 684 7255  +1 800 494 3119
Holden Web LLC/Ltd www.holdenweb.com
Love me, love my blog holdenweb.blogspot.com

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

Re: Numbers in python

[Cameron Laird]

In article [EMAIL PROTECTED],
Diez B. Roggisch [EMAIL PROTECTED] wrote:
 However, I can't seem to get the program to treat the numbers as
 numbers. If I put them in the dictionary as 'THE' = int(0.965) the
 program returns 1.0

It certainoly does _not_ return 1.0 - it returns 1. And that is all it can
return for being an integer that has by definition no fractional part.

 and if I put 'THE' = float(0.965) it returns 
 0.9655549 or something similar. Neither of these are right! I
 basically need to access each item in the string as a number, because
 for my last function I want to multiply them all together by each
 other.

It _is_ the right number if you use floats - you just have to take into
account that 10-based fractions can't always be represented properly by
2-based IEEE floating points, resulting in rounding errors. Which is what
you see.

http://wiki.python.org/moin/RepresentationError?highlight=%28float%29

Either you don't care about the minor differences, the use float. Or you do,
then use the decimal-class introduced in python 2.4

Diez

I wonder if the original poster might not be best off--or at
least think he is--with

str(0.965)
-- 
http://mail.python.org/mailman/listinfo/python-list