Hi,
On Thu, Jul 11, 2024 at 1:16 PM Andrew Nelson wrote:
>
>
>
> On Thu, Jul 11, 2024, 22:08 slobodan.miletic--- via NumPy-Discussion
> wrote:
>>
>> Hi,
>>
>> I am writing on behalf of my team from Endava company. Our task is to work
>> with opensource community, and setup multiple applicatio
Hi,
On Fri, Jul 5, 2024 at 3:17 PM Adrin wrote:
>
> FWIW, as Loïc already mentioned, we had the same discussions on the
> scikit-learn side.
>
> We noticed every now and then a few issues / PRs would come which were
> clearly AI generated, and in almost all those cases, the account posting them
Hi,
On Thu, Jul 4, 2024 at 6:44 PM Ralf Gommers wrote:
>
>
>
> On Thu, Jul 4, 2024 at 5:08 PM Matthew Brett wrote:
>>
>> Hi,
>>
>> On Thu, Jul 4, 2024 at 3:41 PM Ralf Gommers wrote:
>> >
>> >
>> >
>> > On Thu, Jul 4, 20
Hi,
On Thu, Jul 4, 2024 at 7:09 PM Stefan Krah wrote:
>
> On Thu, Jul 04, 2024 at 04:18:03PM +0100, Matthew Brett wrote:
> > I feel sure we would want to avoid GPL code if the copyright holders
> > felt that we were abusing their license - regardless of whether the
> >
Hi,
On Thu, Jul 4, 2024 at 4:46 PM Rohit Goswami wrote:
>
> Doesn't the project adopting wording of this kind "pass the buck" onto the
> maintainers? At the end of the day, failure to enforce our stated policy will
> be not only the responsibility of the authors but also the reviewers /
> main
Hi,
On Thu, Jul 4, 2024 at 4:04 PM Daniele Nicolodi wrote:
>
> On 04/07/24 12:49, Matthew Brett wrote:
> > Hi,
> >
> > Sorry to top-post! But - I wanted to bring the discussion back to
> > licensing. I have great sympathy for the ecological and code-quality
&g
Hi,
On Thu, Jul 4, 2024 at 4:11 PM wrote:
>
> Personally, I wouldn't (as a maintainer) take a decision to reject code based
> on if I feel it is generated by AI. It is much easier to rule on the quality
> of the contribution itself, and as noted, at least so far the AI only
> contributions are
Hi,
On Thu, Jul 4, 2024 at 3:41 PM Ralf Gommers wrote:
>
>
>
> On Thu, Jul 4, 2024 at 1:34 PM Matthew Brett wrote:
>>
>> Hi,
>>
>> On Thu, Jul 4, 2024 at 12:20 PM Ralf Gommers wrote:
>> >
>> >
>> >
>> > On Thu, Jul 4, 20
Hi,
On Thu, Jul 4, 2024 at 12:20 PM Ralf Gommers wrote:
>
>
>
> On Thu, Jul 4, 2024 at 12:55 PM Matthew Brett wrote:
>>
>> Sorry - reposting from my subscribed address:
>>
>> Hi,
>>
>> Sorry to top-post! But - I wanted to bring the discussion
ll have decided differently, since helping someone to improve
> their contribution often leads to higher quality further contributions.
> But here there seems to be no such hope.
>
> All the best,
>
> Marten
>
> Daniele Nicolodi writes:
>
> > On 03/07/24 23:40, Matthe
omeone to improve
> their contribution often leads to higher quality further contributions.
> But here there seems to be no such hope.
>
> All the best,
>
> Marten
>
> Daniele Nicolodi writes:
>
> > On 03/07/24 23:40, Matthew Brett wrote:
> >> Hi,
&
Hi,
We recently got a set of well-labeled PRs containing (reviewed)
AI-generated code:
https://github.com/numpy/numpy/pull/26827
https://github.com/numpy/numpy/pull/26828
https://github.com/numpy/numpy/pull/26829
https://github.com/numpy/numpy/pull/26830
https://github.com/numpy/numpy/pull/26831
Hi,
On Mon, Nov 13, 2023 at 7:41 AM Aaron Meurer wrote:
>
> High level abstractions like .flat or boolean indexing / np.nonzero()
> always use C ordering regardless of the underlying data.
>
> >>> list(np.asarray([[0, 1], [2, 3]]).flat)
> [0, 1, 2, 3]
> >>> list(np.asarray([[0, 1], [2, 3]], order
Hi,
On Wed, Oct 11, 2023 at 9:17 AM Peter Cock via NumPy-Discussion
wrote:
>
>
>
> On Tue, Oct 10, 2023 at 6:32 PM Matthew Brett wrote:
>>
>> Hi,
>>
>>
>> On Tue, 10 Oct 2023 at 00:55, Andrew Nelson wrote:
>> >
>> >
>> &
Hi,
On Tue, 10 Oct 2023 at 00:55, Andrew Nelson wrote:
>
>
> On Mon, 9 Oct 2023 at 23:50, Matthew Brett wrote:
>>
>> Hi,
>>
>> On Mon, Oct 9, 2023 at 11:49 AM Andrew Nelson wrote:
>> Could you say more about why you consider:
>> np.mean(x, dr
Hi,
On Mon, Oct 9, 2023 at 11:49 AM Andrew Nelson wrote:
>
> On Mon, 9 Oct 2023 at 20:34, wrote:
>>
>> Surely you can do this for all functions of eg.nan*. Why separate them is
>> the only thing that distinguishes them. Setting the parameter seems to be
>> more handy and user-friendly. Well
Hi,
Is there any reason to have separate functions - or to keep enforcing
that?I agree, an equivalent of R's rm.na argument seems like a
very reasonable and useful addition, such as (sorry for the
obviousness):
np.mean(x, dropna=True)
and so on,
Cheers,
Matthew
On Mon, Oct 9, 2023 at 9:17
On Wed, May 31, 2023 at 3:04 PM Robert Kern wrote:
>
> I would much, much rather have the special functions in the `np.*` namespace
> be more accurate than fast on all platforms. These would not have been on my
> list for general purpose speed optimization. How much time is actually spent
> ins
Hi,
On Wed, May 31, 2023 at 11:52 AM Ralf Gommers wrote:
>
>
>
> On Wed, May 31, 2023 at 12:28 PM Chris Sidebottom
> wrote:
>>
>> Matthew Brett wrote:
>> > Hi,
>> > On Wed, May 31, 2023 at 8:40 AM Matti Picus matti.pi...@gmail.com wrote:
>> &g
Hi,
On Wed, May 31, 2023 at 8:40 AM Matti Picus wrote:
>
>
> On 31/5/23 09:33, Jerome Kieffer wrote:
> > Hi Sebastian,
> >
> > I had a quick look at the PR and it looks like you re-implemented the
> > sin-cos
> > function using SIMD.
> > I wonder how it compares with SLEEF (header only library,
Hi,
On Mon, Jul 4, 2022 at 3:21 PM Charles R Harris
wrote:
>
>
>
> On Mon, Jul 4, 2022 at 7:48 AM Matthew Brett wrote:
>>
>> Hi,
>>
>> I just came across this:
>>
>> https://sfconservancy.org/GiveUpGitHub/
>>
>> I guess this is so
Hi,
I just came across this:
https://sfconservancy.org/GiveUpGitHub/
I guess this is something we should review and consider - although it
would obviously have serious costs.
Cheers,
Matthew
___
NumPy-Discussion mailing list -- numpy-discussion@pytho
Hi,
On Thu, Jun 30, 2022 at 8:14 PM Matthew Brett wrote:
>
> Hi,
>
> On Thu, Jun 30, 2022 at 10:00 AM Ralf Gommers wrote:
> >
> >
> >
> > On Thu, Jun 30, 2022 at 10:47 AM Matthew Brett
> > wrote:
> >>
> >> Hi,
> &g
Hi,
On Thu, Jun 30, 2022 at 10:00 AM Ralf Gommers wrote:
>
>
>
> On Thu, Jun 30, 2022 at 10:47 AM Matthew Brett
> wrote:
>>
>> Hi,
>>
>> On Thu, Jun 30, 2022 at 9:40 AM Ralf Gommers wrote:
>> >
>> >
>> >
>> >
Hi,
On Thu, Jun 30, 2022 at 6:30 PM Charles R Harris
wrote:
>
>
>
> On Thu, Jun 30, 2022 at 11:02 AM Matthew Brett
> wrote:
>>
>> Hi Chuck,
>>
>> On Thu, Jun 30, 2022 at 2:13 PM Charles R Harris
>> wrote:
>> >
>> >
>&
Hi Chuck,
On Thu, Jun 30, 2022 at 2:13 PM Charles R Harris
wrote:
>
>
>
> On Wed, Jun 29, 2022 at 5:26 PM Matthew Brett wrote:
>>
>> Hi,
>>
>> I am very sorry - I feel I should know this, or be able to work it
>> out, but is there a way of setting the
Hi,
On Thu, Jun 30, 2022 at 9:40 AM Ralf Gommers wrote:
>
>
>
> On Thu, Jun 30, 2022 at 10:29 AM Matthew Brett
> wrote:
>>
>> Hi,
>>
>> On Thu, Jun 30, 2022 at 12:42 AM Kevin Sheppard
>> wrote:
>> >>
>> >>
>> >>
Hi,
On Thu, Jun 30, 2022 at 12:42 AM Kevin Sheppard
wrote:
>>
>>
>> Hi,
>>
>> I am very sorry - I feel I should know this, or be able to work it
>> out, but is there a way of setting the flags to the C compiler and the
>> linker, for the Numpy build, on Windows?
>>
>> I'm trying to set the flags
Hi,
I am very sorry - I feel I should know this, or be able to work it
out, but is there a way of setting the flags to the C compiler and the
linker, for the Numpy build, on Windows?
I'm trying to set the flags for a build with Windows mingw-w64 - but I
believe Numpy is ignoring $env:LDFLAGS, $en
Hi,
On Fri, Jun 10, 2022 at 9:41 AM Jerome Kieffer wrote:
>
> Dear Numpy developpers,
>
> We are developing a set of scientific tools
> (https://github.com/silx-kit) and all our build infrastructure is based
> on `numpy.distutils` which apparently is going to disappear in the
> coming years. Besi
Hi,
On Wed, Jun 8, 2022 at 7:34 PM wrote:
>
> Hi All,
>
> Hope this is the right forum.
>
> I am working on using Numpy from the programming language Racket.
>
> My plan of attack is to use Python via `libpython`.
> That is, from Racket I use `ffilib` to load `libpython` and from there I use
> t
Hi,
On Sat, Nov 6, 2021 at 4:54 PM Ralf Gommers wrote:
>
>
>
> On Tue, Oct 26, 2021 at 9:20 PM bas van beek wrote:
>>
>> Hi all,
>>
>>
>>
>> The subject of `MachAr` recently came up in
>> https://github.com/numpy/numpy/pull/20132 and
>>
>> an earlier community meeting, more notably: it’s questi
Hi,
On Mon, Oct 18, 2021 at 11:23 PM Andrew Nelson wrote:
>
> I realised that I hadn't installed hypothesis. Now things are a little
> different (the number of tests detected), but still not working:
>
> ```
> conda create -n test -c defaults python=3.10
> conda activate test
> pip install -i ht
Hi,
On Mon, Oct 18, 2021 at 2:28 PM Andrew Nelson wrote:
>
>
>
> On Mon, 18 Oct 2021, 23:44 Charles R Harris, wrote
>>>
>>> ```
>>
>>
>> Thanks for testing. Are you on Intel or Arm?
>
>
> Intel
Running the equivalent commands in a fresh macOS 11.6 Intel virtualenv
gives no errors or test failur
Hi Stefan,
If you haven't got to it, I can do it.
Cheers,
Matthew
On Tue, Oct 12, 2021 at 1:13 AM Stefan van der Walt
wrote:
>
> On Mon, Oct 11, 2021, at 07:56, Matthew Brett wrote:
> > My guess is that that would be less than 90 minutes of work for
> > someone with
Hi,
On Mon, Oct 11, 2021 at 3:05 PM Matti Picus wrote:
>
> On 11/10/21 4:38 pm, Matthew Brett wrote:
> > Hi,
> >
> > It will probably soon be trivial to do a manylinux Alpine build / test
> > on multibuild. There's a work on progress PR here,
> >
> &
Hi,
It will probably soon be trivial to do a manylinux Alpine build / test
on multibuild. There's a work on progress PR here,
https://github.com/matthew-brett/multibuild/pull/430
that only requires someone to build a trivial test container, in order
to get merged.
It's also gene
Hi,
Dropping 32-bit wheels seems very reasonable at this stage, as long as
we keep testing on 32-bit, for the Raspberry Pi folks,
Cheers,
Matthew
On Sun, Oct 3, 2021 at 6:27 PM Charles R Harris
wrote:
>
> Hi All,
>
> Dropping 32 manylinux wheels was discussed in a triage meeting some time ago
ols
>> available for administration of the discussions. For example,
>>
>> https://github.blog/changelog/2021-09-14-notification-emails-for-discussions/
>>
>> is a recent feature. I don't work for GitHub obviously and have nothing to
>> do with them b
Hi,
On Fri, Oct 1, 2021 at 1:57 PM Rohit Goswami wrote:
>
> I guess then the approach overall would evolve to something like using the
> mailing list to announce discourse posts which need input. Though I would
> assume that the web interface essentially makes the mailing list almost like
> di
Hi,
On Fri, Oct 1, 2021 at 1:54 AM Rohit Goswami wrote:
>
> Although it is true that discourse is easier for newcomers in a lot of ways,
> it is far worse for governance and consensus. The mailing list, by having
> essentially sequential topics sent out to all subscribers is easier to keep
> t
Hi,
The only pages I could find on KML_BLAS were in Chinese. Like Matti,
I'd be interested to know about the license for this library. Which
particular ARM chips will it run on?
Cheers,
Matthew
On Mon, Feb 22, 2021 at 12:15 PM ChunLin Fang wrote:
>
> Hi all,
> Whether you're running ap
Seems like a good idea. It would need Matti or someone to set up the
various keys I think?
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion
https://gist.github.com/dc410698ca9e422aec08e4554eac6678
[2] https://gist.github.com/77879cb58b28b3d05c3c14b8a45687e8
On Fri, Aug 28, 2020 at 3:37 PM Matthew Brett wrote:
>
> Hi,
>
> On Thu, Aug 27, 2020 at 10:51 PM Charles R Harris
> wrote:
> >
> > Hi All,
> >
> &
Hi,
On Thu, Aug 27, 2020 at 10:51 PM Charles R Harris
wrote:
>
> Hi All,
>
> The 32 bit manylinux1 wheels are proving problematic, see
> https://github.com/numpy/numpy/issues/17174. One proposed solution is to only
> release manylinux2010 linux wheels for the NumPy 1.20 release. Thoughts?
I th
Hi,
On Tue, Feb 4, 2020 at 10:38 PM Nathaniel Smith wrote:
>
> Pretty sure the 2010 and 2014 images both have much newer compilers than that.
>
> There are still a lot of users on CentOS 6, so I'd still stick to 2010 for
> now on x86_64 at least. We could potentially start adding 2014 wheels for
Hi,
On Mon, Jan 20, 2020 at 3:00 PM YueCompl wrote:
>
> Hello folks,
>
> Myself a long time Numpy user, and recently done some Haskell stuff,
>
> Please have a look at
> https://github.com/e-wrks/edh/tree/master/Tour#defining-more-magic-methods
> and https://github.com/e-wrks/edh/tree/master/T
Hi,
Thanks - yes - I agree, an axis argument seems like a very sensible idea.
Cheers,
Matthew
On Fri, Sep 13, 2019 at 7:48 AM Juan Nunez-Iglesias wrote:
>
> I don’t understand why the proposal would be controversial in any way. It’s
> very natural to have `axis=` keyword arguments in NumPy, a
Hi,
Maybe worth asking over at the Pandas list? I bet there are more
Python / finance people over there.
Cheers,
Matthew
On Wed, Sep 4, 2019 at 7:11 PM Ilhan Polat wrote:
>
> +1 on removing them from NumPy. I think there are plenty of alternatives
> already so many that we might even conside
Hi,
On Sun, Jul 7, 2019 at 11:41 PM ANURAG ANURAG wrote:
>
> Sir,
> I was recently converting some Matlab codes into python, where I recently
> stumble upon bitget(n,x) function of Matlab, b = bitget(A,bit) returns the
> bit value at the position bit in integer array A. I was unable to find an
Hi,
On Wed, Jul 3, 2019 at 9:08 AM Charles R Harris
wrote:
>
>
>
> On Wed, Jul 3, 2019 at 9:08 AM Hameer Abbasi
> wrote:
>>
>> Hi,
>>
>> It turns out you're running into a bit-error. In general, the two's
>> complement of -2 ** (n-1) with the bit-length being limited to n bits is
>> itself...
Hi,
On Tue, Jun 25, 2019 at 10:57 AM Stephan Hoyer
[snip]
...
> I also agree with Alan that probably it's too late to change the behavior of
> .T for arrays with more than 2-dimensions. NumPy could certainly use a more
> comprehensive policy around backwards compatibility, but we certainly need
Hi,
Obviously this is a trade-off; if we can increase binary size we can
add more optimizations, for more platforms, and development will be a
little faster, because we are not having to spend time optimizing for
binary size.
If people on slow internet connections had to download numpy multiple
t
Hi,
I noticed that numpy.random.choice was very slow, with the
replace=False option, and then I noticed it can (for most cases) be
made many hundreds of times faster in Python code:
In [18]: sample = np.random.uniform(size=100)
In [19]: timeit np.random.choice(sample, 500, replace=False)
On Mon, Sep 17, 2018 at 2:24 PM, Warren Weckesser
wrote:
>
>
> On Mon, Sep 17, 2018 at 7:38 AM Matthew Brett
> wrote:
>>
>> Hi,
>>
>> Is there any reason that np.count_nonzero should not take an axis
>> argument? As in:
>>
>> >>>
Hi,
Is there any reason that np.count_nonzero should not take an axis
argument? As in:
>>> np.better_count_nonzero([[10, 11], [0, 3]], axis=1)
array([2, 1])
It would be much more useful if it did...
Cheers,
Matthew
___
NumPy-Discussion mailing list
Hi,
On Wed, Aug 15, 2018 at 5:36 PM, Hameer Abbasi
wrote:
> On 15. Aug 2018, at 18:25, Matthew Brett wrote:
>
> Hi,
>
> Thanks Nathaniel for this thoughtful response.
>
> On Mon, Aug 13, 2018 at 10:44 AM, Nathaniel Smith wrote:
> ...
>
> The other approach would
Hi,
Thanks Nathaniel for this thoughtful response.
On Mon, Aug 13, 2018 at 10:44 AM, Nathaniel Smith wrote:
...
> The other approach would be to incrementally add clean, well-defined
> dunder methods like __array_ufunc__, __array_concatenate__, etc. This
> way we end up putting some thought into
Hi,
Short version:
We are planning to drop 32-bit compatibility from the numpy macOS
wheels. This email is to ask for feedback.
Long version:
macOS has tooling to allow distribution of binaries that have objects
for more than one architecture. These are called "fat" binaries, and
they were us
Hi,
On Fri, Aug 3, 2018 at 9:35 AM, Stefan van der Walt
wrote:
> On August 3, 2018 09:50:38 Robert Kern wrote:
>>
>> On Thu, Aug 2, 2018 at 11:01 PM Robert Kern wrote:
>>>
>>> Nope, concision is definitely not my strength. But I hope I
>>> made the argument clear, at least.
>>
>>
>> No, wait.
Hi,
On Wed, Aug 1, 2018 at 4:12 PM, Nathan Goldbaum wrote:
>
>
> On Wed, Aug 1, 2018 at 9:49 AM, Ralf Gommers wrote:
>>
>>
>>
>> On Wed, Aug 1, 2018 at 12:20 AM, Nathan Goldbaum
>> wrote:
>>>
>>> I realize this was probably brought up in the discussions about the scipy
>>> code of conduct which
On Sat, Jun 30, 2018 at 12:36 AM, Charles R Harris
wrote:
>
>
> On Fri, Jun 29, 2018 at 4:35 PM, Matthew Brett
> wrote:
>>
>> On Fri, Jun 29, 2018 at 11:31 PM, Charles R Harris
>> wrote:
>> >
>> >
>> > On Tue, Jun 26, 2018 at 3:55 PM,
On Fri, Jun 29, 2018 at 11:31 PM, Charles R Harris
wrote:
>
>
> On Tue, Jun 26, 2018 at 3:55 PM, Matthew Brett
> wrote:
>>
>> Hi,
>>
>> On Tue, Jun 26, 2018 at 10:43 PM, Matti Picus
>> wrote:
>> > On 19/06/18 10:57, Matthew Brett wrote:
>&
Hi,
On Tue, Jun 26, 2018 at 10:43 PM, Matti Picus wrote:
> On 19/06/18 10:57, Matthew Brett wrote:
>>
>> Hi,
>>
>> On Tue, Jun 19, 2018 at 6:27 PM, Matti Picus
>> wrote:
>>>
>>> On 19/06/18 09:58, Charles R Harris wrote:
>>>>>
Hi,
On Tue, Jun 19, 2018 at 6:27 PM, Matti Picus wrote:
> On 19/06/18 09:58, Charles R Harris wrote:
>>
>> > What I was curious about is that there were no more "daily" builds of
>> > master.
>>
>> Is that right? That there were daily builds of master, on Appveyor?
>> I don't know how those work
On Tue, Jun 19, 2018 at 2:46 PM, Charles R Harris
wrote:
>
>
> On Tue, Jun 19, 2018 at 4:57 AM, Matthew Brett
> wrote:
>>
>> Hi,
>>
>> On Tue, Jun 19, 2018 at 2:44 AM, Charles R Harris
>> wrote:
>> >
>> >
>> > On Mon, Jun 18
Hi,
On Tue, Jun 19, 2018 at 2:44 AM, Charles R Harris
wrote:
>
>
> On Mon, Jun 18, 2018 at 5:58 PM, Matthew Brett
> wrote:
>>
>> On Tue, Jun 19, 2018 at 12:24 AM, Charles R Harris
>> wrote:
>> >
>> >
>> > On Mon, Jun 18, 2
On Tue, Jun 19, 2018 at 12:24 AM, Charles R Harris
wrote:
>
>
> On Mon, Jun 18, 2018 at 3:13 PM, Matthew Brett
> wrote:
>>
>> Hi,
>>
>> On Mon, Jun 18, 2018 at 9:42 PM, Charles R Harris
>> wrote:
>> >
>> >
>> > On Mon, Jun
Hi,
On Mon, Jun 18, 2018 at 9:42 PM, Charles R Harris
wrote:
>
>
> On Mon, Jun 18, 2018 at 2:22 PM, Nathan Goldbaum
> wrote:
>>
>> I think Matthew Brett needs to fix this.
>
>
> That would be nice, but I'm not convinced it is helpful :) I note that
>
Hi Nathan,
One very helpful think you could do, is add a Travis-CI matrix entry
where you are testing against the latest numpy nightly builds.
I got a bit lost in your tox setup, but the basic idea is that, for
one test entry, you add the following flags to pip:
-f
https://7933911d6844c6c53a7d-
Hi,
On Mon, May 28, 2018 at 5:21 AM, gaurav sinha wrote:
> Dear Experts
> Greetings!!
>
> About me- I am Telecom professional having ~10 years of experience in
> 2G/3G/4G mobile technologies.
>
> I have selected Python as my Programming Language. Its been some time, I
> stared to learn and work
Hi,
On Sun, May 27, 2018 at 9:12 PM, Nathaniel Smith wrote:
> Performance is an incredibly multi-dimensional thing. Modern computers are
> incredibly complex, with layers of interacting caches, different
> microarchitectural features (do you have AVX2? does your cpu's branch
> predictor interact
Hi,
On Wed, May 23, 2018 at 10:42 PM, Stefan van der Walt
wrote:
> On May 23, 2018 14:28:05 Matthew Brett wrote:
>>
>>
>> Can I ask what the plans are for supporting missing values, inside or
>> outside numpy? Is there are successor to MaskedArray - and is this
>
Hi,
On Wed, May 23, 2018 at 9:51 PM, Stefan van der Walt
wrote:
> Hi Eric,
>
> On May 23, 2018 13:25:44 Eric Firing wrote:
>
>> On 2018/05/23 9:06 AM, Matti Picus wrote:
>> I understand at least some of the motivation and potential advantages,
>> but as it stands, I find this NEP highly alarmin
he
>> community.
>
> Thanks for the suggestion, Nathan. We are coordinating with SciPy2018
> to have both a BoF and sprint at the end of the conference.
>
> On Tue, 10 Apr 2018 18:05:14 +0100, Matthew Brett wrote:
>> How about weekly open developer hangouts, recorded, to keep
Yo,
How about weekly open developer hangouts, recorded, to keep it all public?
Cheers,
Matthew
On Tue, Apr 10, 2018 at 5:59 PM, Stefan van der Walt
wrote:
> Hi Eric,
>
> On Sun, 08 Apr 2018 08:02:19 -1000, Eric Firing wrote:
>> On 2018/04/07 9:19 PM, Stefan van der Walt wrote:
>> > We would lo
Hi,
We (over at https://github.com/nipy/nibabel) often want to do stuff like this:
```
dtype_type = 'i'
size = 8
endianness = '<'
dtype = np.dtype('{}{}{}'.format(endianness, dtype_type, size))
```
I see that
"""
Use of the character codes, however, is discouraged.
"""
https://docs.scipy.org/d
Hi,
On Mon, Jan 29, 2018 at 1:02 PM, Andrew Nelson wrote:
> Something similar was mentioned at
> https://github.com/scipy/scipy/issues/8325.
Yes, that one was also for Anaconda...
Cheers,
Matthew
___
NumPy-Discussion mailing list
NumPy-Discussion@pyt
Hi,
On Mon, Jan 29, 2018 at 10:16 AM, Solbrig,Jeremy
wrote:
> I have a suite of fortran code that I compile with f2py and use as a plugin
> to a python package. I am using Python v2.7 from Anaconda. When compiled
> using numpy v1.11.3 or lower, everything works fine, but if I upgrade to any
> m
Hi,
On Tue, Jan 23, 2018 at 10:04 AM, Andrew Nelson wrote:
> Dear np list,
> from a recent scipy PR (https://github.com/scipy/scipy/pull/8322) it appears
> that the `np.testing.assert_raises` context manager still requires nose to
> be installed:
> https://ci.appveyor.com/project/scipy/scipy/buil
Hi,
On Fri, Jan 19, 2018 at 3:24 PM, Charles R Harris
wrote:
>
>
> On Fri, Jan 19, 2018 at 7:48 AM, Matthew Brett
> wrote:
>>
>> Hi Chuck,
>>
>> Thanks for the replies, they are very helpful.
>>
>> On Fri, Jan 19, 2018 at 1:51 PM, Charles R Harri
Hi Chuck,
Thanks for the replies, they are very helpful.
On Fri, Jan 19, 2018 at 1:51 PM, Charles R Harris
wrote:
>
>
> On Fri, Jan 19, 2018 at 6:41 AM, Charles R Harris
> wrote:
>>
>>
>>
>> On Fri, Jan 19, 2018 at 3:30 AM, Matthew Brett
>> wrote:
Hi,
Sorry for my confusion, but I noticed (as a result of the discussion
here [1]) that np.rint and the fallback C function [2] seem to round
to even. But - my impression was that C rint, by default, rounds down
[3]. Is numpy rint not behaving the same way as the GNU C library
rint?
In [4]: np
Hi,
On Sun, Jan 14, 2018 at 3:35 AM, Eric Wieser
wrote:
> Did recarrays change? I didn’t see anything in the release notes.
>
> Not directly, but structured arrays did, for which recarrays are really just
> a thin and somewhat buggy wrapper.
Oh dear oh dear - for some reason I had completely mis
Hi,
On Wed, Nov 8, 2017 at 7:08 PM, Julian Taylor
wrote:
> On 06.11.2017 11:10, Ralf Gommers wrote:
>>
>>
>> On Mon, Nov 6, 2017 at 7:25 AM, Charles R Harris
>> mailto:charlesr.har...@gmail.com>> wrote:
>>
>> Hi All,
>>
>> Thought I'd toss this out there. I'm tending towards better sooner
have OpenBLAS wheels;
Any objections / questions / alternatives?
Cheers,
Matthew
[1] https://github.com/numpy/numpy/issues/5479#issuecomment-185033668
[2] https://github.com/matthew-brett/build-openblas
[3] https://ci.appveyor.com/project/matthew-brett/build-openblas
[4] https://ci.appveyor.com
On Sat, Jul 29, 2017 at 11:34 AM, Matthew Brett wrote:
> Hi,
>
> On Sat, Jul 29, 2017 at 11:26 AM, Ilhan Polat wrote:
>> Yet another twirl to the existing spaghetti
>>
>> https://www.continuum.io/blog/developer-blog/open-sourcing-anaconda-accelerate
>>
>
&g
Hi,
On Sat, Jul 29, 2017 at 11:26 AM, Ilhan Polat wrote:
> Yet another twirl to the existing spaghetti
>
> https://www.continuum.io/blog/developer-blog/open-sourcing-anaconda-accelerate
>
Just to avoid some obvious confusion, Anaconda Accelerate is nothing
to do with macOS Accelerate:
"""
Accel
On Tue, Jul 25, 2017 at 3:14 PM, Nathaniel Smith wrote:
> On Tue, Jul 25, 2017 at 7:05 AM, Matthew Brett
> wrote:
>> On Tue, Jul 25, 2017 at 3:00 PM, Nathaniel Smith wrote:
>>> On Tue, Jul 25, 2017 at 6:48 AM, Matthew Brett
>>> wrote:
>>>> On Tue
On Tue, Jul 25, 2017 at 3:00 PM, Nathaniel Smith wrote:
> On Tue, Jul 25, 2017 at 6:48 AM, Matthew Brett
> wrote:
>> On Tue, Jul 25, 2017 at 2:19 PM, Nathaniel Smith wrote:
>>> I updated the bit about OpenBLAS wheel with some more information on
>>> the statu
On Tue, Jul 25, 2017 at 2:19 PM, Nathaniel Smith wrote:
> I updated the bit about OpenBLAS wheel with some more information on
> the status of that work. It's not super important, but FYI.
Maybe remove the bit (of my text) that you crossed out, or removed the
strikethrough and qualify? At the mo
Hi,
On Sun, Jul 23, 2017 at 5:07 PM, Ilhan Polat wrote:
> Ouch, that's from 2012 :( I'll add this thread as a reference to the wiki
> list.
>
>
> On Sun, Jul 23, 2017 at 5:22 PM, Nathan Goldbaum
> wrote:
>>
>> See
>> https://mail.scipy.org/pipermail/numpy-discussion/2012-August/063589.html
>> a
Hi,
On Fri, Jul 7, 2017 at 6:14 PM, Eric Wieser wrote:
> That’s a regression, and it’s on me, in 8762.
>
> That was a side effect of a fix for the weird behaviour here.
>
> I think we need to fix this in 1.13.2, so we should file an issue about it.
Thanks for the feedback. Do you want to file a
Hi,
Our (nipy's) test suite just failed with the upgrade to numpy 1.13,
and the cause boiled down to this:
```
import numpy as np
poly = np.poly1d([1])
poly.c[0] *= 2
print(poly.c)
```
Numpy 1.12 gives (to me) expected output:
[2]
Numpy 1.13 gives (to me) unexpected output:
[1]
The problem
On Thu, Jul 6, 2017 at 3:37 PM, Charles R Harris
wrote:
>
>
> On Thu, Jul 6, 2017 at 7:15 AM, Matthew Brett
> wrote:
>>
>> Hi,
>>
>> On Thu, Jul 6, 2017 at 2:10 PM, Charles R Harris
>> wrote:
>> > Hi All,
>> >
>> > I&#
Hi,
On Thu, Jul 6, 2017 at 2:10 PM, Charles R Harris
wrote:
> Hi All,
>
> I've delayed the NumPy 1.13.2 release hoping for Python 3.6.2 to show up
> fixing #29943 so we can close #9272, but the Python release has been
> delayed to July 11 (expected). The Python problem means that NumPy compiled
On Wed, Jul 5, 2017 at 11:31 AM, Peter Cock wrote:
> On Wed, Jul 5, 2017 at 11:25 AM, Ralf Gommers wrote:
>>
>>
>> On Wed, Jul 5, 2017 at 10:14 PM, Peter Cock
>> wrote:
>>>
>>> Note that TravisCI does not yet have official Python support on Mac OS X,
>>>
>>> https://github.com/travis-ci/travis-c
because I'd disabled the 32-bit builds there.
Numpy, scipy, and a fairly large number of other projects use
https://github.com/matthew-brett/multibuild to set up builds in this
way for manylinux, OSX and (with a bit more effort) Windows.
Cheers,
Matthew
__
Hi,
On Mon, May 22, 2017 at 4:52 PM, Marten van Kerkwijk
wrote:
> Hi Matthew,
>
>> it seems to me that we could get 80% of the way to a reassuring blueprint
>> with a relatively small amount of effort.
>
> My sentence "adapt the typical academic rule for conflicts of
> interests to PRs, that non
Hi,
On Sun, May 21, 2017 at 7:27 PM, Marten van Kerkwijk
wrote:
> Hi All,
>
> First, it will be great to have more people developing! On avoiding
> potential conflicts: I'm not overly worried, in part because of my
> experience with astropy (for which NASA support developers at STScI
> and CXC).
1 - 100 of 102 matches
Mail list logo
