Hi Pauli,
> If your circles are quite small, you probably want to clip the "painting"
> to a box not much larger than a single circle:
>
> # untested, something like below
> def point_to_index(x, y, pad=0):
> return np.clip(200 * rr / (xmax - xmin) + pad, 0, 200), \
> np.clip(200 * rr
Fri, 30 Jul 2010 19:48:45 +0200, Guillaume Chérel wrote:
> Your solution is really good. It's almost exactly what I was doing, but
> shorter and I didn't know about the mgrid thing.
It's a very brute-force solution and probably won't be very fast with
many circles or large grids.
> There is an e
2010/7/30 Guillaume Chérel
> On Fri, Jul 30, 2010 at 6:15 PM, Christopher Barker
> wrote:
> > Guillaume Chérel wrote:
> >> As for the details about my problem, I'm trying to compute the total
> >> surface of overlapping disks. I approximate the surface with a grid and
> >> count how many points
Fri, 30 Jul 2010 14:21:23 +0200, Guillaume Chérel wrote:
[clip]
> As for the details about my problem, I'm trying to compute the total
> surface of overlapping disks. I approximate the surface with a grid and
> count how many points of the grid fall into at least one disk.
HTH,
import numpy as np
Hi Pauli,
Your solution is really good. It's almost exactly what I was doing,
but shorter and I didn't know about the mgrid thing.
There is an extra optimization step I perform in my code to avoid the
computation of the many points of the grid (assuming the circles are
relatively small) which you
On 7/30/2010 12:59 PM, Guillaume Chérel wrote:
> my problem may involve
> many more than 2 disks at a time
You cd approximate each disc by a polygon, as accurately
as you need, and test each point for membership in each disc:
from matplotlib.nxutils import pnpoly
hth,
Alan Isaac
_
On Fri, Jul 30, 2010 at 6:15 PM, Christopher Barker
wrote:
> Guillaume Chérel wrote:
>> As for the details about my problem, I'm trying to compute the total
>> surface of overlapping disks. I approximate the surface with a grid and
>> count how many points of the grid fall into at least one disk.
Guillaume Chérel wrote:
> As for the details about my problem, I'm trying to compute the total
> surface of overlapping disks. I approximate the surface with a grid and
> count how many points of the grid fall into at least one disk.
That is a highly approximate way to do it - which may be fine,
2010/7/30 Guillaume Chérel :
> Hello,
>
> I ran into a difficulty with floating point arithmetic in python. Namely
> that:
>
> >>> 0.001 + 1 - 1
> 0.00088987
>
> And, as a consequence, in python:
>
> >>> 0.001 + 1 - 1 == 0.001
> False
>
> In more details, my problem is that I have a
2010/7/30 Guillaume Chérel :
> Hi,
>
> Thanks for all your answers and the references (and yes, I have to admit
> that I've been a bit lazy with Goldberg's article, though it looks very
> thorough).
>
> But as numpy is designed for scientific computing, is there no
> implementation of an "exact ty
On 7/30/2010 8:21 AM, Guillaume Chérel wrote:
> is there no
> implementation of an "exact type"
You could use the fraction module:
>>> f = [Fraction(i,10) for i in range(10)]
>>> a = np.array(f, dtype=object)
>>> a
array([0, 1/10, 1/5, 3/10, 2/5, 1/2, 3/5, 7/10, 4/5, 9/10], dtype=object)
But I d
Hi,
Thanks for all your answers and the references (and yes, I have to admit
that I've been a bit lazy with Goldberg's article, though it looks very
thorough).
But as numpy is designed for scientific computing, is there no
implementation of an "exact type"
(http://floating-point-gui.de/form
Fri, 30 Jul 2010 19:52:37 +0900, David wrote:
[clip]
> Indeed, it is not, and that's expected. There are various pitfalls using
> floating point. Rational and explanations:
>
> http://docs.sun.com/source/806-3568/ncg_goldberg.html
In case of tl;dr, see also http://floating-point-gui.de/
--
Paul
2010/7/30 Guillaume Chérel :
>
> Hello,
>
> I ran into a difficulty with floating point arithmetic in python. Namely
> that:
>
> >>> 0.001 + 1 - 1
> 0.00088987
>
> And, as a consequence, in python:
>
> >>> 0.001 + 1 - 1 == 0.001
> False
>
> In more details, my problem is that I have
Hi Guillaume,
On 07/30/2010 07:45 PM, Guillaume Chérel wrote:
>Hello,
>
> I ran into a difficulty with floating point arithmetic in python.
This is not python specific, but true in any language which uses the
floating point unit of your hardware, assuming you have "conventional"
hardware.
Hello,
I ran into a difficulty with floating point arithmetic in python. Namely
that:
>>> 0.001 + 1 - 1
0.00088987
And, as a consequence, in python:
>>> 0.001 + 1 - 1 == 0.001
False
In more details, my problem is that I have a fonction which needs to
compute (a + b - c) % a.
16 matches
Mail list logo
