Hello, MXNet community,
Following up on recent announcement of office hours introduction from MXNet
Berlin team, we are trying to see if we can introduce some modifications to
that to make process a bit more streamlined and easier to track. Also, we are
trying to see how to scale that process
Hi, Hen,
Thanks a lot for your feedback, it is very valuable!
I should have been probably more explicit about idea and intention of providing
users with office hours channel of communication. The idea behind office hours
is to provide an additional communication channel to Apache MXNet users. I
Hi, MXNet community,
I would like to suggest that we (participants of dev@ list) spend couple more
days thinking about and discussing proposal for office hours and then, if no
active discussion is happening, move towards lazy vote to get to conclusion on
whether we can incorporate suggested pra
Hello, Apache MXNet community,
I would like to submit for your consideration updated and improved suggestion
for Apache MXNet User Groups meetings: [1]. Main goals of this initiative are:
- make it easy: users and developers should be able to understand what is Group
Meeting and how to parti
+1 on option #2. Having clear Java interface for NDArray, from my perspective,
would be a better experience for Java users as it won't require them to deal
with Scala code in any capacity. Overhead of extra code for additional macros
is justified, in my mind, as it will be introduced with option
Hello, MXNet community,
As part of mine and couple of my team mates day job we are working on
contributing towards C++ and C APIs that MXNet exposes. We would like to
propose to create a separate board in jira in order to make it easier to track
work around MXNet C/C++ APIs. Very similar to
Not so long ago there was a design shared for MXNet Java API: [1]
In a couple of days we are going to have initial version of its implementation.
We are looking for users who would like to get this initial version and
evaluate how well it suits their use cases or just play around with it and
pr
play around we use the java api branch? is there a link to some
example
> code?
>
> Thanks.
>
> On Fri, Oct 12, 2018 at 9:16 PM Davydenko, Denis <
> dzianis.davydze...@gmail.com> wrote:
>
> > Not so long ago there was a design share
I suggest to include this issue into tracked ones for the release:
https://github.com/apache/incubator-mxnet/issues/12255. It has proven to be a
problem with MXNet start up time and it will cause even more problems down the
line with Elastic Training, EIA where MXNet is a commodity rather than
Kellen, please see conversation [1] on previously published proposal re: maven
publishing pipeline. I think your concerns are valid and we should look into
security aspect of running our CI on a broader scope, not bound to just
artifact publishing.
I believe right now Qing's question is whether
I support idea of putting brands of MXNet and Gluon closer together. I agree
with your argument, Mu, but MXNet is quite far away from TF place at this time
so I don’t know how well that argument is transferable from TF position to
MXNet position.
MXNet Imperative is definitely too restrictive o
on to align it with
MXNet without changing its name.
On 3/22/19, 4:57 PM, "Mu Li" wrote:
Are you proposing to rename Gluon? I think Pedro's opinion is about a
better way to communicate what's Gluon and how it's related to MXNet.
On Fri, Mar 22, 20
On Fri, Mar 22, 2019 at 5:07 PM Davydenko, Denis <
dzianis.davydze...@gmail.com> wrote:
> As subject suggests this is a proposal for re-branding of Gluon to align
> it with MXNet. One of the common things undertaken for re-branding
> exercises is renaming.
According to Sandeep's evaluation of perf regression on operator level [1] we
have 77 op/input combinations for forward pass and 50 for backward pass where
regression is 5%+ (biggest regressions observed are about 86% and 84%
respectively) out of 290 tests. If I raise threshold of degradation to
t is to keep up with the existing users
and their trust. If a new release performs worse for the same kind of
workload, they might lose trust into our release process and in future
might be less willing to adopt a new release early-on.
-Marco
Davydenko, Denis schr
Hi, Michael,
Could you please update whether you had a chance to very MXNet v1.5.0rc2?
On 7/10/19, 10:57 AM, "Michael Wall" wrote:
Will make time to review before Sun. Thanks for the note.
Mike
On Wed, Jul 10, 2019 at 1:52 PM Lai Wei wrote:
> Dear MXNet mento
If possible it would be good to maintain Release Status page [1] so that
anybody who is planning activities around 1.6 release could refer to it and
find proper and actual dates on it.
[1]:
https://cwiki.apache.org/confluence/display/MXNET/1.6.0+Release+Plan+and+Status
--
Thanks,
Denis
On 1/
Hello, MXNet dev community,
As you all know, the experience with CI infrastructure isn’t ideal in spite of
its high cost. For this reason, we’re proposing the following changes to
improve stability, reduce cost, and grant more control to contributors. As we
work in a refresh of CI, we believe th
(to catch
stuff like lint errors etc.) before launching the full thing?
Thanks
Przemek
On 2020/02/12 18:12:07, "Davydenko, Denis"
wrote:
> Hello, MXNet dev community,
> As you all know, the experience with CI infrastructure isn’t ideal in
spite
e where all pipelines have succeeded.
On Wed, 2020-02-12 at 10:12 -0800, Davydenko, Denis wrote:
> Hello, MXNet dev community,
> As you all know, the experience with CI infrastructure isn’t ideal in
spite of
> its high cost. For this reason, we’re proposing the followi
On Wed, Feb 12, 2020 at 10:12 AM Davydenko, Denis
wrote:
>
> Hello, MXNet dev community,
> As you all know, the experience with CI infrastructure isn’t ideal in
spite of its high cost. For this reason, we’re proposing the following changes
to improve
21 matches
Mail list logo
