On Fri, Apr 26, 2019 at 1:02 AM Stephan Hoyer wrote:
> On Thu, Apr 25, 2019 at 3:39 PM Ralf Gommers
> wrote:
>
>>
>> On Fri, Apr 26, 2019 at 12:04 AM Stephan Hoyer wrote:
>>
>>> I do like the look of this, but keep in mind that there is a downside to
>>> exposing the implementation of NumPy fun
Hi all,
In https://github.com/numpy/numpy/pull/13207 a discussion started about the
tradeoff between performance gain for one function vs increasing the size
of a NumPy build by a couple of percent. We also discussed that in the
community call on Wednesday and concluded that it may be useful to as
Le vendredi 26 avril 2019, 11:10:56 SAST Ralf Gommers a écrit :
Hi Ralf,
>
> Right now a wheel is 16 MB. If we increase that by 10%/50%/100% - are we
> causing a real problem for someone?
Access to large bandwidth is not universal at all, and in many countries (I'd
even say in most of the count
Here’s my take on it: The goal is basically “separation of interface from
implementation”, NumPy reference becomes just one (reference) implementation
(kind of like CPython is today). The idea is that unumpy/NumPy drive the
interface, while there can be many implementations.
To make duck-arrays
here is a baseline
https://en.wikipedia.org/wiki/List_of_countries_by_Internet_connection_speeds
. Probably a good idea to throttle values at 60% of the bandwidth and you
get a crude average delay it would cause per 1MB worldwide.
On Fri, Apr 26, 2019 at 11:49 AM Éric Depagne wrote:
> Le vendr
Le vendredi 26 avril 2019, 12:49:39 SAST Ilhan Polat a écrit :
Hi Ihlan,
That's an interesting link, but they provide the average, which is not a very
good indicator. I have myself a 100 Mb/s link where I live, which means that
as Akamai ranks my country with an average speed of 6.7 Mb/s, a lot
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
On Fri, Apr 26, 2019 at 1:24 AM Ralf Gommers wrote:
> Thanks, this helped clarify what's going on here. This example is clear.
> The problem seems to be that there's two separate discussions in this
> thread:
> 1. your original proposal, __numpy_implementation__. it does not have the
> problem of
On Fri, Apr 26, 2019 at 3:10 AM Hameer Abbasi
wrote:
> Here’s how `uarray` solves each of these issues:
>
>1. Backends… There is no default implementation.
>2. This is handled by (thread-safe) context managers, which make
>switching easy.
>3. There’s one coercion function per type
Hi Stephan,
> Hameer, it's great that you are exploring these problems with a fresh
> approach! I'm excited to see how dispatching problems could be solved without
> the constraint of compatibility with NumPy's legacy approaches.
>
> When you have a prototype and/or design documents ready for re
Hi everyone,
We are happy to announce that Sebastian Berg has joined the team at
BIDS, and will be working full-time on NumPy for the next two years.
Sebastian has been a core contributor to the project for seven years
already, and we are delighted that he will now be able to spend even
more of hi
Hi,
We understand that it can be burden, of course a larger binary is bad
but that bad usually also comes with good, like better performance or
more features.
How much of a burden is it and where is the line between I need twice as
long to download it which is just annoying and I cannot use it any
12 matches
Mail list logo