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

[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

[Cecil Westerhof]

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

> On Wed, Apr 29, 2015 at 6:01 PM, Cecil Westerhof  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

[Ian Kelly]

On Wed, Apr 29, 2015 at 6:11 PM, Steven D'Aprano
 wrote:
> On Thu, 30 Apr 2015 05:57 am, Ian Kelly wrote:
>
>> On Wed, Apr 29, 2015 at 12:24 PM, Cecil Westerhof 
>> 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

Re: Lucky numbers in Python

[Ian Kelly]

On Wed, Apr 29, 2015 at 6:01 PM, Cecil Westerhof  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

[Cecil Westerhof]

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

> On Wed, Apr 29, 2015 at 3:45 PM, Cecil Westerhof  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

[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 
> 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

[Chris Kaynor]

On Wed, Apr 29, 2015 at 2:45 PM, Cecil Westerhof  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

[Ian Kelly]

On Wed, Apr 29, 2015 at 3:45 PM, Cecil Westerhof  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

[Cecil Westerhof]

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

> On Wed, Apr 29, 2015 at 12:24 PM, Cecil Westerhof  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 12:24 PM, Cecil Westerhof  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: 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:
> > 
> >  > 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 

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

[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:
> 
>  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

[Chris Angelico]

On Sat, Feb 15, 2014 at 4:50 PM, Gene Heskett  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

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  wrote:
> > Not extract, but let you get & look at the code, its the top entry on
> > this page:
> > 
> >  > 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 

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:07 PM, Gene Heskett  wrote:
> Not extract, but let you get & look at the code, its the top entry on this
> page:
>
>  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 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:



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 

-- 
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  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:



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 

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

[Grant Edwards]

On 2014-02-15, Gene Heskett  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

[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

[Chris Angelico]

On Sat, Feb 15, 2014 at 2:25 PM, Gene Heskett  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

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 

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

-- 
https://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
 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

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

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

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

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

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

[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

[Sybren Stuvel]

[EMAIL PROTECTED] enlightened us with:
> if I put 'THE' = float(0.965) it returns 0.9655549 or something
> similar.

That's for the same reasons as you can't write 1/3rd in decimal
notation. Computers can't write 1/10th in binary notation.

Sybren
-- 
The problem with the world is stupidity. Not saying there should be a
capital punishment for stupidity, but why don't we just take the
safety labels off of everything and let the problem solve itself? 
 Frank Zappa
-- 
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

[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

 



-- 
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

[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

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 (xhttp://mail.python.org/mailman/listinfo/python-list