headers
Fernando Perez | 1 Oct 02:39
Picon
Gravatar

Fwd: [sage-devel] Sage Days 11: November 7-10, Austin, Texas

Hi all,

I think the original announcement only went to the Sage lists, but
this should be of interest to this crowd as well.

Cheers,

f

---------- Forwarded message ----------
From: Craig Citro <craigcitro <at> gmail.com>
Date: Sun, Sep 21, 2008 at 8:47 PM
Subject: [sage-devel] Sage Days 11: November 7-10, Austin, Texas
To: sage-devel <at> googlegroups.com, sage-support <at> googlegroups.com

Hi all,

This is a reminder that Sage Days 11 is fast approaching! The topic is
"Special functions and computational number theory meet scientific
computing." The plan is to bring together a bunch of number theorists
and scientific computing/supercomputing experts, and Austin's
incredible supercomputing facilities make this the perfect place for
it.

If you're new to Sage, and interested in this topic, attending a Sage
Days is the perfect way to get more involved. (For those of you who've
been around a while, you know the drill -- just go ahead and skip this
paragraph.) Sage Days are friendly and very intensive focused
development workshops, which are probably fairly different from other
math-related conferences and workshops you've attended. There are
(Continue reading)

Permalink | Reply | 0 comments |
headers
Anne Archibald | 1 Oct 02:45
Picon

Re: Proposal: scipy.spatial

2008/9/30 Nathan Bell <wnbell <at> gmail.com>:
> On Mon, Sep 29, 2008 at 11:24 PM, Anne Archibald
> <peridot.faceted <at> gmail.com> wrote:
>
> Thanks for taking the initiative on scipy.spatial Anne.  I have no
> doubt that it will become an important and widely used part of scipy.
>
> Have you considered starting a "spatial" branch off the scipy trunk?

For now I have simply added it to the trunk, since I have code which
is documented and tested. (Also I have no experience with SVN and
merging, but reports suggest it's a horrible experience.)

> I will defer to your judgment here.  My experience, and the paper I
> referenced, is oriented towards low dimensional cases that arise in
> graphics applications.

It's quite possible that the best algorithms for low-dimensional cases
differ. It's probably worth implementing a very simple and
space-efficient kd-tree, possibly in a compiled language, to
complement what's there now.

Anne
Permalink | Reply | 6 comments |
headers
Jonathan Guyer | 1 Oct 03:40
Favicon

Re: Proposal: scipy.spatial


On Sep 30, 2008, at 8:45 PM, Anne Archibald wrote:

> (Also I have no experience with SVN and
> merging, but reports suggest it's a horrible experience.)

It is not a horrible experience. It involves a little bookkeeping, but  
it's entirely manageable. Our collected instructions for handling  
branches of FiPy (derived largely from the SVN book at red-bean) is at
http://matforge.org/fipy/browser/trunk/documentation/ADMINISTRATA.txt 
. We branch all the time.
Permalink | Reply | 4 comments |
headers
Robert Kern | 1 Oct 04:03
Picon
Gravatar

Re: Proposal: scipy.spatial

On Tue, Sep 30, 2008 at 19:45, Anne Archibald <peridot.faceted <at> gmail.com> wrote:
> 2008/9/30 Nathan Bell <wnbell <at> gmail.com>:
>> On Mon, Sep 29, 2008 at 11:24 PM, Anne Archibald
>> <peridot.faceted <at> gmail.com> wrote:
>>
>> Thanks for taking the initiative on scipy.spatial Anne.  I have no
>> doubt that it will become an important and widely used part of scipy.
>>
>> Have you considered starting a "spatial" branch off the scipy trunk?
>
> For now I have simply added it to the trunk, since I have code which
> is documented and tested. (Also I have no experience with SVN and
> merging, but reports suggest it's a horrible experience.)

It's not all that bad, particularly for cases like this, where you are
mostly adding new new directories rather than modifying code that's
already there. We would like to make a 0.7 release not too long from
now, and I'd like to do it without a completely new subpackage in the
mix.

--

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
  -- Umberto Eco
Permalink | Reply | 0 comments |
headers
Alan McIntyre | 1 Oct 06:37
Picon

Re: Next scipy release 0.7

On Mon, Sep 29, 2008 at 9:55 AM, Jarrod Millman <millman <at> berkeley.edu> wrote:
>> Just curious. Is there a new deadline for scipy 0.7 ?
>
> If anyone has time and interest in helping, it would make a huge
> difference in getting this release out.  If someone could hunt down
> the and fix the test failures and clean up all the deprecation
> warnings, we would be much closer to getting this release out the
> door.

I'll try to fix some of the deprecation warnings and/or look at
failing tests this week or over the weekend.

Alan
Permalink | Reply | 2 comments |
headers
Jarrod Millman | 1 Oct 07:11
Picon
Favicon
Gravatar

Re: Next scipy release 0.7

On Tue, Sep 30, 2008 at 9:37 PM, Alan McIntyre <alan.mcintyre <at> gmail.com> wrote:
> On Mon, Sep 29, 2008 at 9:55 AM, Jarrod Millman <millman <at> berkeley.edu> wrote:
>>> Just curious. Is there a new deadline for scipy 0.7 ?
>>
>> If anyone has time and interest in helping, it would make a huge
>> difference in getting this release out.  If someone could hunt down
>> the and fix the test failures and clean up all the deprecation
>> warnings, we would be much closer to getting this release out the
>> door.
>
> I'll try to fix some of the deprecation warnings and/or look at
> failing tests this week or over the weekend.

Thanks!  The sooner we can get some of these issues resolved the
sooner we can get a release out.

--

-- 
Jarrod Millman
Computational Infrastructure for Research Labs
10 Giannini Hall, UC Berkeley
phone: 510.643.4014
http://cirl.berkeley.edu/
Permalink | Reply | 1 comment |
headers
Barry Wark | 1 Oct 08:08
Picon
Gravatar

Re: Proposal: scipy.spatial

On Mon, Sep 29, 2008 at 8:24 PM, Anne Archibald
<peridot.faceted <at> gmail.com> wrote:
> Hi,
>
> Once again there has been a thread on the numpy/scipy mailing lists
> requesting (essentially) some form of spatial data structure. Pointers
> have been posted to ANN (sadly LGPLed and in C++) as well as a handful
> of pure-python implementations of kd-trees. I suggest the creation of
> a new submodule of scipy, scipy.spatial, to contain spatial data
> structures and algorithms. Specifically, I propose it contain a
> kd-tree implementation providing nearest-neighbor, approximate
> nearest-neighbor, and all-points-near queries. I have a few other
> suggestions for things it might contain, but kd-trees seem like a good
> first step.
>
> 2008/9/27 Nathan Bell <wnbell <at> gmail.com>:
>> On Sat, Sep 27, 2008 at 11:18 PM, Anne Archibald
>> <peridot.faceted <at> gmail.com> wrote:
>>>
>>> I think a kd-tree implementation would be a valuable addition to
>>> scipy, perhaps in a submodule scipy.spatial that might eventually
>>> contain other spatial data structures and algorithms. What do you
>>> think? Should we have one? Should it be based on Sturla Molden's code,
>>> if the license permits? I am willing to contribute one, if not.
>>
>> +1
>
> Judging that your vote and mine are enough in the absence of
> dissenting voices, I have written an implementation based on yours,
> Sturla Molden's, and the algorithms described by the authors of the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Prabhu Ramachandran | 1 Oct 08:09
Picon
Gravatar

Re: [Numpy-discussion] Proposal: scipy.spatial

Anne Archibald wrote:
> 2008/9/30 Peter <numpy-discussion <at> maubp.freeserve.co.uk>:
> I think the profusion of different implementations is an argument for
> including this in scipy. I think it is also an argument for providing
> a standard interface with (at least potentially) several different
> implementations. At the moment, that proposed interface looks like:
[...]
> In the first two cases, missing neighbors are represented with an
> infinite distance and an invalid index. In the last case, distances
> and indices are both either lists (if there's only one query point) or
> object arrays of lists (if there are many query points). If only one
> neighbor is requested, the array does not have a dimension of length 1
> in the which-neighbor position. If (potentially) many neighbors are
> returned, they are sorted by distance, nearest first.
> 
> What do you think of this interface?

This is nice.  How about a keyword argument "sort=True" that lets people 
choose if they want the results sorted by distance or not?  I have seen 
cases where unsorted results are useful.

cheers,
prabhu
Permalink | Reply | 0 comments |
headers
Anne Archibald | 1 Oct 11:46
Picon

Re: [Numpy-discussion] Proposal: scipy.spatial

2008/10/1 Prabhu Ramachandran <prabhu <at> aero.iitb.ac.in>:
> Anne Archibald wrote:
>> 2008/9/30 Peter <numpy-discussion <at> maubp.freeserve.co.uk>:
>> I think the profusion of different implementations is an argument for
>> including this in scipy. I think it is also an argument for providing
>> a standard interface with (at least potentially) several different
>> implementations. At the moment, that proposed interface looks like:
> [...]
>> In the first two cases, missing neighbors are represented with an
>> infinite distance and an invalid index. In the last case, distances
>> and indices are both either lists (if there's only one query point) or
>> object arrays of lists (if there are many query points). If only one
>> neighbor is requested, the array does not have a dimension of length 1
>> in the which-neighbor position. If (potentially) many neighbors are
>> returned, they are sorted by distance, nearest first.
>>
>> What do you think of this interface?
>
> This is nice.  How about a keyword argument "sort=True" that lets people
> choose if they want the results sorted by distance or not?  I have seen
> cases where unsorted results are useful.

That is a possibility. My current code produces results that are in a
heap, so sorting can in principle be an O(n) activity. Since the
number of results returned is rarely going to be large, I'm not sure
the gain in efficiency is worth the loss in determinism. And
additional API complexity does have a cost - in an ideal world it
should at the least double the number of unit tests. I think perhaps
this should wait on a C implementation.
(Continue reading)

Permalink | Reply | 12 comments |
headers
Anne Archibald | 1 Oct 11:54
Picon

Re: Proposal: scipy.spatial

2008/9/30 Jonathan Guyer <guyer <at> nist.gov>:
>
> On Sep 30, 2008, at 8:45 PM, Anne Archibald wrote:
>
>> (Also I have no experience with SVN and
>> merging, but reports suggest it's a horrible experience.)
>
> It is not a horrible experience. It involves a little bookkeeping, but
> it's entirely manageable. Our collected instructions for handling
> branches of FiPy (derived largely from the SVN book at red-bean) is at http://matforge.org/fipy/browser/trunk/documentation/ADMINISTRATA.txt
> . We branch all the time.

Thanks for the pointer! I've now split it off as a separate branch,
"spatial". With luck it won't be much work to reintegrate it once 0.7
is out.

Anne
Permalink | Reply | 3 comments |

Gmane