visualpython-users

[Visualpython-users] inconsistent arange() behavior

[Joe H. <hea...@gm...>]

Okay this is driving me crazy. Typing arange(0.1,0.4,0.1) should give [0.1,
0.2, 0.3] but instead it gives [0.1, 0.2, 0.3, 0.4]. Typing arange(0.1,0.5,
0.1) should give [0.1, 0.2, 0.3, 0.4] and it indeed does. Another example
that doesn't give the "correct" result is arange(0.2,0.8,0.2), which gives [
0.2, 0.4, 0.6, 0.8]. Is this a bug in the arange() code? I've tinkered with
this for two days and there seems to be no way to predict when arange() will
behave as documented. I have my students working on a small assignment that
uses arange() and I don't want this to affect their work. Is there some
detail I'm overlooking?
Joe

Re: [Visualpython-users] inconsistent arange() behavior

[Frédéric M. <fre...@gb...>]

On dimanche 30 mars 2008, Joe Heafner wrote:

> Okay this is driving me crazy. Typing arange(0.1,0.4,0.1) should give
> [0.1, 0.2, 0.3] but instead it gives [0.1, 0.2, 0.3, 0.4]. Typing
> arange(0.1,0.5, 0.1) should give [0.1, 0.2, 0.3, 0.4] and it indeed
> does. Another example that doesn't give the "correct" result is
> arange(0.2,0.8,0.2), which gives [ 0.2, 0.4, 0.6, 0.8]. Is this a bug in
> the arange() code? I've tinkered with this for two days and there seems
> to be no way to predict when arange() will behave as documented. I have
> my students working on a small assignment that uses arange() and I don't
> want this to affect their work. Is there some detail I'm overlooking?

    arange([start,] stop[, step,], dtype=None)

    For integer arguments, just like range() except it returns an array
    whose type can be specified by the keyword argument dtype.  If dtype
    is not specified, the type of the result is deduced from the type of
    the arguments.

    For floating point arguments, the length of the result is ceil((stop -
    start)/step).  This rule may result in the last element of the result
    being greater than stop.

I'm afraid you will have to check the result, and correct it. But I agree, 
this is a strange behaviour!

-- 
   Frédéric

   http://www.gbiloba.org

[Visualpython-users] Learning Python and Visual

[Doug M. <dou...@gm...>]

Hi all,

I created a blog entry about my experiences learning python and visual at: 
http://dougmair.blogspot.com/

Please check it out and make suggestions.

I created two programs (source files are also on the blog).

The Rubik cube program works well, but is not written in a very python like 
way.
I spend most of my time programming in C#, so it's hard for me to think in 
the python way.
I would appreciate any code review telling me how it could be done better in 
python.

The MagDisc.py program is a simulation of magnetic forces between 
freespinning discs with magnets fixed on them.
I'm trying to create a virtual free energy simulator.  It's cheaper than 
building it in the real world.
This program works pretty well, but I'm having trouble with the equation 
that converts the magnetic forces into the angular momentum of the discs.
Any physics advice would be appreciated.

Also, I tried the Rubiks cube with the version 4 beta on Windows Vista and 
it had lots of problems.

Thanks for any help,
Doug Mair 

Re: [Visualpython-users] Learning Python and Visual

[Bruce S. <Bru...@nc...>]

Very impressive and sophisticated, especially for a first try! I'll 
mention that the Rubiks cube program does run on the highly experimental 
as-yet-unreleased-under-rapid-development new version, at least on Vista.

In MagDisc, I believe the force calculation is incorrect, and the 
rotational motion update is incorrect.

The force that one magnet exerts on another is quite complicated. You 
can get the right answer by pretending that a magnet is an electric 
dipole (with small separation between the + and - charges) instead of a 
magnetic dipole, to reduce the problem to a simpler case, and then 
calculate the electric forces among all the individual point charges. 
What you have in MagDisc seems to be a calculation of a 1/r^2 field made 
by one magnet, multiplying by a constant representing the other magnet 
to get the force. But the field of a magnet isn't a simple 1/r^2 field, 
and the force it exerts on another magnet isn't simply a constant times 
that field.

Also, you seem to increment the angle of a disc proportional to the 
torque acting on the disc. But you have to increment the angular 
momentum of the disc (moment of inertia times angular speed) 
proportional to the net torque (magnetic and frictional), then use the 
new angular speed to increment the angle.

Bruce Sherwood

Doug Mair wrote:
> Hi all,
> 
> I created a blog entry about my experiences learning python and visual 
> at: http://dougmair.blogspot.com/
> 
> Please check it out and make suggestions.
> 
> I created two programs (source files are also on the blog).
> 
> The Rubik cube program works well, but is not written in a very python 
> like way.
> I spend most of my time programming in C#, so it's hard for me to think 
> in the python way.
> I would appreciate any code review telling me how it could be done 
> better in python.
> 
> The MagDisc.py program is a simulation of magnetic forces between 
> freespinning discs with magnets fixed on them.
> I'm trying to create a virtual free energy simulator.  It's cheaper than 
> building it in the real world.
> This program works pretty well, but I'm having trouble with the equation 
> that converts the magnetic forces into the angular momentum of the discs.
> Any physics advice would be appreciated.
> 
> Also, I tried the Rubiks cube with the version 4 beta on Windows Vista 
> and it had lots of problems.
> 
> Thanks for any help,
> Doug Mair

Re: [Visualpython-users] inconsistent arange() behavior

[Bruce S. <Bru...@nc...>]

It's nothing more than the fact that floating-point numbers can be 
represented only approximately in a computer. A simple example from 
ordinary pencil-and-paper calculations is that 1/3 + 1/3 + 1/3 = 1, but 
0.33+0.33+0.33 = .99. If you want arange to produce 0, "1/3", "2/3", but 
not "1", you should write something like arange(0.0, 1.0-.1, 1.0/3.0). 
More generally, if you want to go from xi to xf in floating-point 
increments dx, and not include xf, write arange(xi, xf-0.5*dx, dx). 
Another solution is something like this, using integers:

while n in range(ni, nf, dn):
	x = scale*n # where scale is a floating-point scale factor
	....

Bruce Sherwood

Frédéric Mantegazza wrote:
> On dimanche 30 mars 2008, Joe Heafner wrote:
> 
>> Okay this is driving me crazy. Typing arange(0.1,0.4,0.1) should give
>> [0.1, 0.2, 0.3] but instead it gives [0.1, 0.2, 0.3, 0.4]. Typing
>> arange(0.1,0.5, 0.1) should give [0.1, 0.2, 0.3, 0.4] and it indeed
>> does. Another example that doesn't give the "correct" result is
>> arange(0.2,0.8,0.2), which gives [ 0.2, 0.4, 0.6, 0.8]. Is this a bug in
>> the arange() code? I've tinkered with this for two days and there seems
>> to be no way to predict when arange() will behave as documented. I have
>> my students working on a small assignment that uses arange() and I don't
>> want this to affect their work. Is there some detail I'm overlooking?
> 
>     arange([start,] stop[, step,], dtype=None)
> 
>     For integer arguments, just like range() except it returns an array
>     whose type can be specified by the keyword argument dtype.  If dtype
>     is not specified, the type of the result is deduced from the type of
>     the arguments.
> 
>     For floating point arguments, the length of the result is ceil((stop -
>     start)/step).  This rule may result in the last element of the result
>     being greater than stop.
> 
> I'm afraid you will have to check the result, and correct it. But I agree, 
> this is a strange behaviour!
> 

Re: [Visualpython-users] inconsistent arange() behavior

[Gary P. <gar...@gm...>]

On Sun, Mar 30, 2008 at 11:18 AM, Bruce Sherwood
<Bru...@nc...> wrote:
> It's nothing more than the fact that floating-point numbers can be
>  represented only approximately in a computer. A simple example from
>  ordinary pencil-and-paper calculations is that 1/3 + 1/3 + 1/3 = 1, but
>  0.33+0.33+0.33 = .99. If you want arange to produce 0, "1/3", "2/3", but
>  not "1", you should write something like arange(0.0, 1.0-.1, 1.0/3.0).
>  More generally, if you want to go from xi to xf in floating-point
>  increments dx, and not include xf, write arange(xi, xf-0.5*dx, dx).
>  Another solution is something like this, using integers:
>
>  while n in range(ni, nf, dn):
>         x = scale*n # where scale is a floating-point scale factor
>         ....
>
>  Bruce Sherwood

another common solution is to use numpy's linspace function:

In [6]: import numpy

In [7]: numpy.linspace(0, 0.3, 4)
Out[7]: array([ 0. ,  0.1,  0.2,  0.3])


In [9]: numpy.linspace?
Type:           function
Base Class:     <type 'function'>
String Form:    <function linspace at 0x0118C9B0>
Namespace:      Interactive
File:
c:\python25\lib\site-packages\numpy-1.0.4.dev3954-py2.5-win32.egg\numpy\lib\function_base.py
Definition:     numpy.linspace(start, stop, num=50, endpoint=True,
retstep=False)
Docstring:
   Return evenly spaced numbers.

Return num evenly spaced samples from start to stop.  If
endpoint is True, the last sample is stop. If retstep is
True then return the step value used.

>
>
>  Frédéric Mantegazza wrote:
>  > On dimanche 30 mars 2008, Joe Heafner wrote:
>  >
>  >> Okay this is driving me crazy. Typing arange(0.1,0.4,0.1) should give
>  >> [0.1, 0.2, 0.3] but instead it gives [0.1, 0.2, 0.3, 0.4]. Typing
>  >> arange(0.1,0.5, 0.1) should give [0.1, 0.2, 0.3, 0.4] and it indeed
>  >> does. Another example that doesn't give the "correct" result is
>  >> arange(0.2,0.8,0.2), which gives [ 0.2, 0.4, 0.6, 0.8]. Is this a bug in
>  >> the arange() code? I've tinkered with this for two days and there seems
>  >> to be no way to predict when arange() will behave as documented. I have
>  >> my students working on a small assignment that uses arange() and I don't
>  >> want this to affect their work. Is there some detail I'm overlooking?
>  >
>  >     arange([start,] stop[, step,], dtype=None)
>  >
>  >     For integer arguments, just like range() except it returns an array
>  >     whose type can be specified by the keyword argument dtype.  If dtype
>  >     is not specified, the type of the result is deduced from the type of
>  >     the arguments.
>  >
>  >     For floating point arguments, the length of the result is ceil((stop -
>  >     start)/step).  This rule may result in the last element of the result
>  >     being greater than stop.
>  >
>  > I'm afraid you will have to check the result, and correct it. But I agree,
>  > this is a strange behaviour!
>  >
>
>
>
> -------------------------------------------------------------------------
>  Check out the new SourceForge.net Marketplace.
>  It's the best place to buy or sell services for
>  just about anything Open Source.
>  http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
>  _______________________________________________
>  Visualpython-users mailing list
>  Vis...@li...
>  https://lists.sourceforge.net/lists/listinfo/visualpython-users
>