On Wed, Jul 6, 2011 at 7:01 PM, Charles R Harris
wrote:
>> Numpy already has a general mechanism for defining new dtypes and
>> slotting them in so that they're supported by ndarrays, by the casting
>> machinery, by ufuncs, and so on. In principle, we could implement
>
> Well, actually not in any
On Wed, Jul 6, 2011 at 7:34 PM, Charles R Harris
wrote:
>
>
> On Wed, Jul 6, 2011 at 8:09 PM, Nathaniel Smith wrote:
>>
>> On Wed, Jul 6, 2011 at 7:01 PM, Charles R Harris
>> wrote:
>> >> Numpy already has a general mechanism for defining new dtypes and
Hi Bruce,
I'm replying on the list instead of on github, to make it easier for
others to join in the discussion if they want. [For those joining in:
this was a comment posted at https://gist.github.com/1068264 ]
On Fri, Jul 8, 2011 at 10:36 AM, bsouthey wrote:
> I presume missing float values cou
On Sat, Jul 9, 2011 at 11:29 AM, Mark Wiebe wrote:
> typedef npy_uint8 npy_mask;
> #define NPY_MASK NPY_UINT8
> #define NPY_MASK_ISEXPOSED(mask) (((mask)&0x01) != 0)
> #define NPY_MASK_GETPAYLOAD(mask) (((npy_mask)mask) >> 1)
> #define NPY_MASK_MAKEMASK(exposed, payload) ((npy_mask)(exposed&0x01)
On Sat, Jul 9, 2011 at 7:24 PM, Mark Wiebe wrote:
> On Sat, Jul 9, 2011 at 2:38 PM, Nathaniel Smith wrote:
>>
>> On Sat, Jul 9, 2011 at 11:29 AM, Mark Wiebe wrote:
>> > typedef npy_uint8 npy_mask;
>> > #define NPY_MASK NPY_UINT8
>> > #define NP
Hi Bruce,
I think we have some fundamental misunderstandings about what this
proposal would do. Let me see if I can try to be clearer.
On Sun, Jul 10, 2011 at 7:33 PM, Bruce Southey wrote:
> On Fri, Jul 8, 2011 at 5:04 PM, Nathaniel Smith wrote:
>> Each dtype has a bunch of C
I have a different question about this than the rest of the thread. I'm
confused at why there isn't a programmatic way to create a datetime dtype,
other than by going through this special string-based mini-language. I guess
I generally think of string-based dtype descriptors as being a legacy thing
On Jul 28, 2011 8:43 AM, "Matthew Brett" wrote:
> So, 1.6.0 is returning a zero-dimensional scalar of the given type,
> and 1.5.1 returns a python scalar.
>
> Zero dimensional scalars are designed to behave in a similar way to
> python scalars, so the change should be all but invisible in practice
1) Have you considered using MxNx1 arrays for greyscale images, so all
images have the same dimensionality?
2) Instead of defining an RGB class from scratch, would a structured dtype
do what you want?
- Nathaniel
On Aug 9, 2011 2:23 PM, "Alex Flint" wrote:
> Until now, I've been representing RGB
On Thu, Sep 1, 2011 at 8:31 PM, Christopher Jordan-Squire
wrote:
> On Thu, Sep 1, 2011 at 11:14 PM, Robert Kern wrote:
>> On Thu, Sep 1, 2011 at 22:07, Christopher Jordan-Squire
>> wrote:
>>
>>> So in the mean time, are there any suggestions for what this R sample
>>> function should be called,
On Fri, Sep 2, 2011 at 10:14 AM, Christopher Jordan-Squire
wrote:
> I made the changes discussed here and pushed them to pull request.
>
> https://github.com/numpy/numpy/pull/143#issuecomment-1980897
I think you mean https://github.com/numpy/numpy/pull/151
> I changed the new function's name fro
On Mon, Sep 26, 2011 at 8:24 AM, Zachary Pincus wrote:
> Test 3:
> #Test 3 - Add 20 scalar ints
> nrep = 200 * scale_factor
> for i in range(nrep):
> a = i + 1
>
> well, python looping is slow... one doesn't do such loops in idiomatic code
> if the underlying intent can be
[Does the group actually exist yet? Google says: "No groups match
fastecuhla." Replying here instead...]
I've been following discussions around non-profit incorporation for
FOSS projects for about a decade (including some years on the internal
mailing list for SPI Inc. -- Debian's non-profit found
On Sun, Oct 16, 2011 at 3:04 PM, Matthew Brett wrote:
> If we agree that float128 is a bad name for something that isn't IEEE
> binary128, and there is already a longdouble type (thanks for pointing
> that out), then what about:
>
> Deprecating float128 / float96 as names
> Preferring longdouble f
On Sun, Oct 16, 2011 at 4:29 PM, Charles R Harris
wrote:
> On Sun, Oct 16, 2011 at 4:16 PM, Nathaniel Smith wrote:
>> I understand the argument that you don't want to call it "float80"
>> because not all machines support a float80 type. But I don't
>> u
Hi all,
I was surprised today to notice that Mark's NA mask support appears to
have been merged into numpy master and is described in the draft
release notes[1]. My surprise is because merging it to mainline
without any discussion on the list seems to contradict what what
Travis wrote in July, tha
On Sun, Oct 23, 2011 at 12:53 PM, Charles R Harris
wrote:
> On Sun, Oct 23, 2011 at 12:54 PM, Matthew Brett
> wrote:
>> I think this email might be a plea to the numpy steering group, and to
>> Travis in particular, to see if we can use a discussion of this series
>> of events to decide on a good
On Sun, Oct 23, 2011 at 2:29 PM, Eric Firing wrote:
> Ultimately, though, the numpy core developers must decide what goes in
> and what does not. Consensus is desirable but may not always be
> possible or optimal, especially if "consensus" is interpreted as
> "unanimity". There is a risk in deci
On Tue, Oct 25, 2011 at 4:49 PM, Matthew Brett wrote:
> I guess from your answer that such a warning would be complicated to
> implement, and if that's the case, I can imagine it would be low
> priority.
I assume the problem is more that it would be a weirdo check that
becomes a maintenance burde
On Tue, Oct 25, 2011 at 2:56 PM, Travis Oliphant wrote:
> I think Nathaniel and Matthew provided very
> specific feedback that was helpful in understanding other perspectives of a
> difficult problem. In particular, I really wanted bit-patterns
> implemented. However, I also understand that
On Fri, Oct 28, 2011 at 3:14 PM, Charles R Harris
wrote:
> Matthew, the problem I have is that it seems that you and Nathaniel won't be
> satisfied unless things are done *your* way.
Hi Charles,
I'm sorry if I've given this impression, and I know it's easy to feel
this way in a contentious discu
Hi again,
Okay, here's my attempt at an *uncontroversial* email!
Specifically, I think it'll be easier to talk about this NA stuff if
we can establish some common ground, and easier for people to follow
if the basic points of agreement are laid out in one place. So I'm
going to try and summarize
Hi Benjamin,
On Wed, Nov 2, 2011 at 5:25 PM, Benjamin Root wrote:
> I want to pare this down even more. I think the above lists makes too many
> unneeded extrapolations.
Okay. I found your formatting a little confusing, so I want to make
sure I understood the changes you're suggesting:
For the
On Wed, Nov 2, 2011 at 8:20 PM, Benjamin Root wrote:
> On Wednesday, November 2, 2011, Nathaniel Smith wrote:
>> By R compatibility, I specifically had in mind in-memory
>> compatibility. rpy2 provides a more-or-less seamless within-process
>> interface between R and Pyt
whatever if people prefer, this
just seemed like the easiest way to get something up there that
everyone would have write access to.
-- Nathaniel
On Wed, Nov 2, 2011 at 4:37 PM, Nathaniel Smith wrote:
> Hi again,
>
> Okay, here's my attempt at an *uncontroversial* email!
>
Hi Chris,
On Thu, Nov 3, 2011 at 9:45 AM, Chris.Barker wrote:
> On 11/2/11 7:16 PM, Nathaniel Smith wrote:
>> By R compatibility, I specifically had in mind in-memory
>> compatibility.
>
> The R crowd has had a big voice in this discussion, and I understand
> that there
Hi Lluís,
On Thu, Nov 3, 2011 at 7:28 AM, Lluís wrote:
> Well, maybe it's too low level, but I'd rather decouple the two concepts into
> two orthogonal properties that can be composed:
>
> * Destructiveness: whether the previous data value is lost whenever you
> assign a
> "special" value.
>
>
On Thu, Nov 3, 2011 at 7:54 PM, Gary Strangman
wrote:
> For the non-destructive+propagating case, do I understand correctly that
> this would mean I (as a user) could temporarily decide to IGNORE certain
> portions of my data, perform a series of computation on that data, and the
> IGNORED flag (o
On Fri, Nov 4, 2011 at 1:22 PM, T J wrote:
> I agree that it would be ideal if the default were to skip IGNORED values,
> but that behavior seems inconsistent with its propagation properties (such
> as when adding arrays with IGNORED values). To illustrate, when we did
> "x+2", we were stating th
On Fri, Nov 4, 2011 at 11:59 AM, Pauli Virtanen wrote:
> I have a feeling that if you don't start by mathematically defining the
> scalar operations first, and only after that generalize them to arrays,
> some conceptual problems may follow.
>
> On the other hand, I should note that numpy.ma does
On Fri, Nov 4, 2011 at 3:04 PM, Nathaniel Smith wrote:
> On Fri, Nov 4, 2011 at 11:59 AM, Pauli Virtanen wrote:
>> If classified this way, behaviour of items in np.ma arrays is different
>> in different operations, but seems roughly PdX, where X stands for
>> returning a
On Fri, Nov 4, 2011 at 3:08 PM, T J wrote:
> On Fri, Nov 4, 2011 at 2:29 PM, Nathaniel Smith wrote:
>> Continuing my theme of looking for consensus first... there are
>> obviously a ton of ugly corners in here. But my impression is that at
>> least for some simple cases,
On Fri, Nov 4, 2011 at 7:43 PM, T J wrote:
> On Fri, Nov 4, 2011 at 6:31 PM, Pauli Virtanen wrote:
>> An acid test for proposed rules: given two arrays `a` and `b`,
>>
>> a = [1, 2, IGNORED(3), IGNORED(4)]
>> b = [10, IGNORED(20), 30, IGNORED(40)]
[...]
> (A1) Does unmask(a+b) ==
On Fri, Nov 4, 2011 at 8:33 PM, T J wrote:
> On Fri, Nov 4, 2011 at 8:03 PM, Nathaniel Smith wrote:
>> Again, I really don't think you're going to be able to sell an API where
>> [2] + [IGNORED(20)] == [IGNORED(22)]
>> I mean, it's not me you have t
On Sat, Nov 5, 2011 at 4:07 PM, Matthew Brett wrote:
> Intel, gcc:
> 4, -2147483648
> PPC, gcc:
> 4, 2147483647
>
> I think that's what you predicted. Is it strange that the same
> compiler gives different results?
>
> It would be good if the behavior was the same across platforms - the
> unexpec
On Sat, Nov 5, 2011 at 3:22 PM, T J wrote:
> So what do people expect out of ignored values? It seems that we might need
> to extend the list you put forward so that it includes these desires. Since
> my primary use is with MISSING and not so much IGNORED, I'm not in a very
> good position to hel
If save/load actually makes a reliable difference, then it would be useful
to do something like this, and see what you see:
save("X", X)
X2 = load("X.npy")
diff = (X == X2)
# did save/load change anything?
any(diff)
# if so, then what changed?
X[diff]
X2[diff]
# any subtle differences in floating
I think you want
np.maximum(a, b, out=a)
- Nathaniel
On Dec 6, 2011 9:04 PM, "questions anon" wrote:
> thanks for responding Josef but that is not really what I am looking for,
> I have a multidimensional array and if the next array has any values
> greater than what is in my first array I wan
On Tue, Jan 3, 2012 at 9:46 AM, Ognen Duzlevski wrote:
> Hello,
>
> I am playing with adding an enum dtype to numpy (to get my feet wet in
> numpy really). I have looked at the
> https://github.com/martinling/numpy_quaternion and I feel comfortable
> with my understanding of adding a simple type t
On Sat, Jan 14, 2012 at 2:12 PM, Charles R Harris
wrote:
> This sort of makes sense, but is it the 'correct' behavior?
>
> In [20]: zeros(2, 'S')
> Out[20]:
> array(['', ''],
> dtype='|S1')
I think of numpy strings as raw fixed-length byte arrays (since, well,
that's what they are), so I wo
How would you fix it? I shouldn't speculate without profiling, but I'll be
naughty. Presumably the problem is that python turns that into something
like
hist[i,j] = hist[i,j] + 1
which means there's no way for numpy to avoid creating a temporary array.
So maybe this could be fixed by adding a fus
On Thu, Feb 16, 2012 at 12:27 AM, Dag Sverre Seljebotn
wrote:
> If non-contributing users came along on the Cython list demanding that
> we set up a system to select non-developers along on a board that would
> have discussions in order to veto pull requests, I don't know whether
> we'd ignore it
On Thu, Feb 16, 2012 at 2:08 PM, Pauli Virtanen wrote:
> 16.02.2012 14:54, josef.p...@gmail.com kirjoitti:
> [clip]
>> If I interpret you correctly, this should be a svd ticket, or an svd
>> ticket as "duplicate" ?
>
> I think it should be a multivariate normal ticket.
>
> "Fixing" SVD is in my op
On Wed, Feb 15, 2012 at 7:46 PM, Benjamin Root wrote:
> Why not the NA discussion? Would we really want to have that happen again?
> Note that it still isn't fully resolved and progress still needs to be made
> (I think the last thread did an excellent job of fleshing out the ideas, but
> it beca
On Thu, Feb 16, 2012 at 5:17 PM, Travis Vaught wrote:
> On Feb 16, 2012, at 10:56 AM, Nathaniel Smith wrote:
>
>> Travis's proposal is that we go from a large number of self-selecting
>> people putting in little bits of time to a small number of designated
>> p
On Thu, Feb 16, 2012 at 5:20 PM, Pauli Virtanen wrote:
> Hi,
>
> 16.02.2012 18:00, Nathaniel Smith kirjoitti:
> [clip]
>> I agree, but the behavior is still surprising -- people reasonably
>> expect something like svd to be deterministic. So there's probably a
>&g
On Thu, Feb 16, 2012 at 8:36 PM, Charles R Harris
wrote:
>
>
> On Thu, Feb 16, 2012 at 1:13 PM, Nathaniel Smith wrote:
>>
>> On Thu, Feb 16, 2012 at 5:17 PM, Travis Vaught wrote:
>> > On Feb 16, 2012, at 10:56 AM, Nathaniel Smith wrote:
>> >
>> &g
On Thu, Feb 16, 2012 at 11:52 PM, Chris Ball wrote:
> Buildbot is used by some big projects (e.g. Python, Chromium, and
> Mozilla), but I'm aware that several projects in the scientific/numeric
> Python ecosystem use Jenkins (including Cython, IPython, and SymPy),
> often using a hosted Jenkins so
On Wed, Mar 13, 2013 at 1:45 PM, Andrea Cimatoribus
wrote:
> Hi everybody, I hope this has not been discussed before, I couldn't find a
> solution elsewhere.
> I need to read some binary data, and I am using numpy.fromfile to do this.
> Since the files are huge, and would make me run out of memo
On Wed, Mar 13, 2013 at 2:18 PM, Andrea Cimatoribus
wrote:
> This solution does not work for me since I have an offset before the data
> that is not a multiple of the datatype (it's a header containing various
> stuff).
np.memmap takes an offset= argument.
-n
__
On Wed, Mar 13, 2013 at 2:46 PM, Andrea Cimatoribus
wrote:
>>Indeed, but that offset "it should be a multiple of the byte-size of dtype"
>>as the help says.
>
> My mistake, sorry, even if the help says so, it seems that this is not the
> case in the actual code. Still, the problem with the size
On 13 Mar 2013 15:16, "Andrea Cimatoribus"
wrote:
>
> Ok, this seems to be working (well, as soon as I get the right offset and
things like that, but that's a different story).
> The problem is that it does not go any faster than my initial function
compiled with cython, and it is still a lot slow
That does look unlikely yeah... Does this have any consequences that you've
found? Is there a test case that fails before the patch but works after?
-n
On 15 Mar 2013 09:19, "Ake Sandgren" wrote:
> Hi!
>
> Found this thing that looks like a bug in
> core/src/multiarray/dtype_transfer.c
>
> diff
On Fri, Mar 15, 2013 at 7:34 PM, Dmitrey wrote:
> --- Исходное сообщение ---
>
> От кого: "Alan G Isaac"
> Дата: 15 марта 2013, 20:38:38
>
> On 3/15/2013 9:21 AM, Dmitrey wrote:
>> Temporary walkaround for a serious bug in FuncDesigner automatic
>> differentiation kernel due to a bug in some vers
On Fri, Mar 15, 2013 at 9:52 AM, Ake Sandgren wrote:
> On Fri, 2013-03-15 at 09:44 +0000, Nathaniel Smith wrote:
>> That does look unlikely yeah... Does this have any consequences that
>> you've found? Is there a test case that fails before the patch but
>> works af
On Fri, Mar 15, 2013 at 6:47 PM, Warren Weckesser
wrote:
> Hi all,
>
> In a recent scipy pull request (https://github.com/scipy/scipy/pull/459), I
> ran into the problem of ufuncs automatically generating a signature in the
> docstring using arguments such as 'x' or 'x1, x2'. scipy.special has a
On 16 Mar 2013 11:49, "Dmitrey" wrote:
>
>
>
>
> --- Исходное сообщение ---
> От кого: "Matthieu Brucher"
> Дата: 16 марта 2013, 12:39:07
>
>> Even if they have different hashes, they can be stored in the same
underlying list before they are retrieved. Then, an actual comparison is
done to check
On 16 Mar 2013 16:41, "Chao YUE" wrote:
>
> Dear all,
>
> Is there some way to index the numpy array by specifying arbitrary axis
and arbitrary slice, while
> not knowing the actual shape of the data?
> For example, I have a 3-dim data, data.shape = (3,4,5)
> Is there a way to retrieve data[:,0,:]
On Fri, Mar 15, 2013 at 9:19 PM, Pauli Virtanen wrote:
> 15.03.2013 22:39, Nathaniel Smith kirjoitti:
> [clip]
>> - Something else...
>
> How about: scrap the automatic signatures altogether, and directly use
> the docstring provided to the ufunc creation function?
>
&g
On 20 Mar 2013 17:11, "Warren Weckesser" wrote:
>
>
>
> On Fri, Mar 15, 2013 at 4:39 PM, Nathaniel Smith wrote:
>>
>> On Fri, Mar 15, 2013 at 6:47 PM, Warren Weckesser
>> wrote:
>> > Hi all,
>> >
>> > In a recent scipy pull req
On Fri, Mar 22, 2013 at 7:47 AM, Ake Sandgren wrote:
> On Thu, 2013-03-21 at 18:02 -0600, Charles R Harris wrote:
>> The Numpy 1.7.1 release process seems to have stalled. What do we need
>> to finish up to get it going again? I think it would be nice to shoot
>> for a release maybe the weekend af
On 22 Mar 2013 14:09, "Neal Becker" wrote:
>
> I frequently find I have my 1d function that performs some reduction that
I'd
> like to apply-along some axis of an n-d array.
>
> As a trivial example,
>
> def sum(u):
> return np.sum (u)
>
> In this case the function is probably C/C++ code, but th
On Tue, Mar 26, 2013 at 9:20 AM, Phil Elson wrote:
> Bump.
>
> I'd be interested to know if this is a desirable feature for numpy?
> (specifically the 1D "find" functionality rather than the "any"/"all" also
> discussed)
> If so, I'd be more than happy to submit a PR, but I don't want to put in th
On Wed, Mar 27, 2013 at 2:41 PM, Andrea Cimatoribus
wrote:
>
> Not sure if this is really relevant to the original message, but here is my
> opinion. I think that the numpy/scipy community would greatly benefit from a
> platform enabling easy sharing of code written by users. This would provide
On Sun, Mar 31, 2013 at 6:14 AM, Ivan Oseledets
wrote:
>> I am using numpy 1.6.1,
>> and encountered a wierd fancy indexing bug:
>>
>> import numpy as np
>> c = np.random.randn(10,200,10);
>>
>> In [29]: print c[[0,1],:200,:2].shape
>> (2, 200, 2)
>>
>> In [30]: print c[[0,1],:200,[0,1]].shape
>>
On Sat, Mar 30, 2013 at 2:08 AM, Matthew Brett
wrote:
> Hi,
>
> We were teaching today, and found ourselves getting very confused
> about ravel and shape in numpy.
>
> Summary
> --
>
> There are two separate ideas needed to understand ordering in ravel and
reshape:
>
> Idea 1): ravel /
On Tue, Apr 2, 2013 at 6:59 PM, Matthew Brett wrote:
> On Tue, Apr 2, 2013 at 7:32 AM, Nathaniel Smith wrote:
>> Maybe we should go through and rename "order" to something more descriptive
>> in each case, so we'd have
>> a.reshape(..., index_order="
On Tue, Apr 2, 2013 at 8:10 PM, Todd wrote:
>
> On Tue, Apr 2, 2013 at 8:12 PM, Ralf Gommers wrote:
>>
>>
>>
>>
>> On Mon, Apr 1, 2013 at 2:27 PM, Todd wrote:
>>>
>>>
>>> There were a number of other ideas in this thread:
>>>
>>> http://mail.scipy.org/pipermail/numpy-discussion/2013-March/065699
On Tue, Apr 2, 2013 at 10:21 PM, Matthew Brett wrote:
>> This is like observing that if I say "go North" then it's ambiguous
>> about whether I want you to drive or walk, and concluding that we need
>> new words for the directions depending on what sort of vehicle you
>> use. So "go North" means d
On Wed, Apr 3, 2013 at 2:26 PM, Dave Hirschfeld
wrote:
> Andreas Hilboll hilboll.de> writes:
>> > I think your point about using current timezone in interpreting user
>> > input being dangerous is probably correct --- perhaps UTC all the way
>> > would be a safer (and simpler) choice?
>>
>> +1
>>
On Wed, Apr 3, 2013 at 11:00 PM, Chris Barker - NOAA Federal
wrote:
> Best of all is intelligent editing of the thread so far -- edit it
> down to the key points you are commenting on, and intersperse your
> comments. That way your email stands on its own as meaningful, but
> there is not a big pi
On Thu, Apr 4, 2013 at 12:52 AM, Chris Barker - NOAA Federal
wrote:
> Thanks all for taking an interest. I need to think a bot more about
> the options before commenting more, but:
>
> while we're at it:
>
> It seems very odd to me that datetime64 supports different units
> (right down to attosec
On Thu, Apr 4, 2013 at 6:06 PM, Charles R Harris
wrote:
>
>
> On Thu, Apr 4, 2013 at 11:01 AM, Chris Barker - NOAA Federal
> wrote:
>>
>> On Wed, Apr 3, 2013 at 6:02 PM, Mark Wiebe wrote:
>> > One problem with trying to give technically correct answers for the
>> > UTC/Posix format is that it ca
On Sat, Apr 6, 2013 at 8:03 PM, Alex Ford wrote:
> Hello,
>
> Do any core developers or uses have guidance on how to resolve PR #3188
> (https://github.com/numpy/numpy/pull/3188) in relation to the pickling
> behavior of array scalar objects?
>
> To summarize, pickling array scalars with object fi
On Sun, Apr 7, 2013 at 2:26 PM, Valentin Haenel wrote:
> I know that the address is contained in the 'data' field of the
> '__array_interface__' and is either an int or a long. My guess is that
> this depends on the architecture of the system, i.e. 32 vs 64 bit
> systems.
>
> My question is: what
On Sun, Apr 7, 2013 at 10:25 PM, Steve Waterbury
wrote:
> On 04/07/2013 05:02 PM, Chris Barker - NOAA Federal wrote:
>> On Sun, Apr 7, 2013 at 8:06 AM, Daπid wrote:
>>> On 7 April 2013 16:53, Happyman wrote:
>>
>>> $pip install numpy # to install package "numpy"
>>
>> as a warning, last I checke
On Sun, Apr 7, 2013 at 10:49 PM, Olivier Delalleau wrote:
> 2013/4/7
>>
>> On Sun, Apr 7, 2013 at 5:34 PM, Steve Waterbury
>> wrote:
>> > On 04/07/2013 05:30 PM, Nathaniel Smith wrote:
>> >> On Sun, Apr 7, 2013 at 10:25 PM, Steve Waterbury
>>
On 10 Apr 2013 08:01, "Dmitrey" wrote:
>
> --- Исходное сообщение ---
> От кого: "Robert Kern"
> Дата: 9 апреля 2013, 14:29:43
>
>> On Tue, Apr 9, 2013 at 4:15 PM, Dmitrey wrote:
>> >
>> >
>> > --- Исходное сообщение ---
>> > От кого: "Robert Kern"
>> > Дата: 16 марта 2013, 22:15:07
>> >
>> > O
An easy solution to all of this is to use a dict-like object that
matches keys based on object identity while ignoring __hash__ and
__eq__ entirely, e.g.:
https://bitbucket.org/pypy/pypy/src/2f51f2142f7b/lib_pypy/identity_dict.py#cl-9
-n
On Wed, Apr 10, 2013 at 10:45 AM, Sebastian Berg
wrote:
>
On Thu, Apr 11, 2013 at 11:32 AM, Sebastian Berg
wrote:
> On Wed, 2013-03-06 at 11:43 -0700, Charles R Harris wrote:
>> Hi All,
>>
>
>
>> The development branch has been accumulating stuff since last summer,
>> I suggest we look to get it out in May, branching at the end of this
>> month.
>
> Hey
On 11 Apr 2013 15:29, "Charles R Harris" wrote:
>
>
>
> On Thu, Apr 11, 2013 at 4:32 AM, Sebastian Berg <
sebast...@sipsolutions.net> wrote:
>>
>> On Wed, 2013-03-06 at 11:43 -0700, Charles R Harris wrote:
>> > Hi All,
>> >
>>
>>
>> > The development branch has been accumulating stuff since last
On Mon, Apr 8, 2013 at 8:14 AM, Georg Brandl wrote:
> Hi,
>
> is it intentional that "I" is supported as a dtype character, but cannot be
> suffixed with a size?
>
dtype('i1')
> dtype('int8')
dtype('I1')
> dtype('uint32')
"i" means "integer". "i1" means "integer with 8 bits".
"I" means
On Mon, Apr 15, 2013 at 5:29 PM, Sebastian Berg
wrote:
> Hey,
>
> the MapIter API has only been made public in master right? So it is no
> problem at all to change at least the mapiter struct, right?
>
> I got annoyed at all those special cases that make things difficult to
> get an idea where to
On 18 Apr 2013 01:29, "Chris Barker - NOAA Federal"
wrote:
> This has been annoying, particular as rank-zero scalars are kind of a
pain.
BTW, while we're on the topic, can you elaborate on this? I tend to think
scalars (as opposed to 0d ndarrays) are kind of a pain, so I'm curious if
you have spe
On Fri, Apr 19, 2013 at 4:17 PM, Chris Barker - NOAA Federal
wrote:
> On Fri, Apr 19, 2013 at 8:12 AM, Ondřej Čertík
> wrote:
>
>>> I'm pleased to announce the availability of the final NumPy 1.7.1 release.
>
> Nice work -- but darn! I was hoping a change/fix to teh datetime64
> timezone handlie
On 19 Apr 2013 19:22, "Chris Barker - NOAA Federal"
wrote:
> Anyway -- going to HDF, or netcdf, or role-your-own really seems like
> overkill for this. I just need something fast and simple and it
> doesn't need to interchange with anything else.
Just use pickle...?
-n
__
On Tue, Apr 30, 2013 at 3:19 PM, Blake Griffith
wrote:
> Hello, I'm writing a GSoC proposal, mostly concerning SciPy, but it involves
> a few changes to NumPy.
> The proposal is titled: Improvements to the sparse package of Scipy: support
> for bool dtype and better interaction with NumPy
> and ca
On Tue, Apr 30, 2013 at 4:02 PM, Pauli Virtanen wrote:
> 30.04.2013 22:37, Nathaniel Smith kirjoitti:
> [clip]
>> How do you plan to go about this? The obvious option of just calling
>> scipy.sparse.issparse() on ufunc entry raises some problems, since
>> numpy can&#x
On 1 May 2013 08:49, "Yaroslav Halchenko" wrote:
>
> Thanks everyone for the feedback.
>
> Is it worth me starting a bisection to catch where it was introduced?
Is it a bug, or just typical fp rounding issues? Do we know which answer is
correct?
-n
___
On Wed, May 1, 2013 at 9:12 AM, Pauli Virtanen wrote:
> 01.05.2013 16:01, Yaroslav Halchenko kirjoitti:
> [clip]
>> to ignorant me, even without considering 'correctness', it is just
>> a typical regression -- results changed from one release to another (and
>> not to the better side).
>
> To me t
On 1 May 2013 23:12, "Charles R Harris" wrote:
>
>
>
> On Wed, May 1, 2013 at 7:10 PM, Benjamin Root wrote:
>>
>> So, to summarize the thread so far:
>>
>> Consensus:
>> np.nanmean()
>> np.nanstd()
>> np.minmax()
>> np.argminmax()
>>
>> Vague Consensus:
>> np.sincos()
>>
>
> If the return of sinc
On Thu, May 2, 2013 at 6:26 AM, Arink Verma wrote:
> Yes, we need to ensure that..
> Code generator can be made, which can create code for table of registered
> dtype during build time itself.
I'd probably just generate it at run-time on an as-needed basis.
(I.e., use the full lookup logic the fi
On Thu, May 2, 2013 at 9:25 AM, David Cournapeau wrote:
>> * Re: the profiling, I wrote a full oprofile->callgrind format script
>> years ago: http://vorpus.org/~njs/op2calltree.py
>> Haven't used it in years either but neither oprofile nor kcachegrind
>> are terribly fast-moving projects so it's
On Thu, May 2, 2013 at 10:51 AM, Francesc Alted wrote:
> On 5/2/13 3:58 PM, Nathaniel Smith wrote:
>> callgrind has the *fabulous* kcachegrind front-end, but it only
>> measures memory access performance on a simulated machine, which is
>> very useful sometimes (if you'r
On Sun, May 5, 2013 at 5:57 PM, David Cournapeau wrote:
>> perf is a fabulous framework and doesn't have any way to get full
>> callgraph information out so IME it's been useless. They have
>> reporting modes that claim to (like some "fractal" thing?) but AFAI
>> been able to tell from docs/googli
On Mon, May 6, 2013 at 8:52 AM, Funky Dev wrote:
> Hi,
>
> I've got a project in which it turns out we need much higher precision
> than even __float128 and playing around with a few alternatives mpfr
> seems to be the highest performing possibility. So I've starting
> writing a cythonized class
On Mon, May 6, 2013 at 6:54 PM, Bago wrote:
> I submitted a patch a little while ago,
> https://github.com/numpy/numpy/pull/3107, which gave the searchsorted
> function the ability to search arrays sorted in descending order. At the
> time my approach was to detect the sortorder of the array by c
Hi Neal,
On Fri, May 10, 2013 at 7:36 PM, Neal Becker wrote:
> np.array ((0,0))
> Out[10]: array([0, 0]) <<< ok, it's 2 dimensional
Think you may have confused yourself :-). It's 1 dimensional with 2 elements...
> In [11]: np.array ((0,0)).shape
> Out[11]: (2,) <<< except, it isn't
...as per
On 17 May 2013 05:19, "Christopher Jordan-Squire" wrote:
>
> I'd been under the impression that the easiest way to get SSE support
> was to have numpy use an optimized blas/lapack. Is that not the case?
Apples and oranges. That's the easiest (only) way to get SSE support for
operations that go th
On 16 May 2013 19:48, "Jonathan Helmus" wrote:
>
> On 05/16/2013 01:42 PM, Neal Becker wrote:
> > Is there a way to get a traceback instead of just printing the
> > line that triggered the error?
> >
> > ___
> > NumPy-Discussion mailing list
> > NumPy-Di
401 - 500 of 1338 matches
Mail list logo
