Re: [Proposal] New operator graph for MXNet

2019-05-14 Thread Tianqi Chen
The core part of the proposal is to move the graph to be much more strongly
typed template class.
I think this is mainly a point of engineering taste, and both sides have
pros and cons, let me list them before I share my thoughts on this issue:

- Typed fields certainly enjoy more compile-time type checking, on the
other hand, it is hard to expose
   template of explosive possibilities to frontend languages.
- More type-erased fields provide runtime flexibility to store polymorphic
types as well as extensible attributes for graph optimization
  - It is hard to use a virtual class to expose every possible attribute
that an operator might have, such as inlining, storage pattern, gradient
etc..
  - The nature of supporting a growing set of operator attribute requires a
type-erased attrs field.
- In contrast to your argument(typing is a blocker to features),
type-erased or typed code can both get to the same feature except, except
that
  typed code gets more compile-time errors while type-erased get some of
them in runtime.
- Templatized data structures will likely introduce additional metal
burdens to developers and are not really suitable as a core data structure
   - Because they imply an explosive number of possible data structures,
while the core data structure should be a single one.

Now my view(as an MXNet PMC member) on typed vs type-erased style: If MXNet
is a pure C++ project, I might take more of the typed approach.
However, MXNet itself is a project that takes python/scala/clojure and
other frontend languages.
The introduction of more typing may not align with the original goal as the
tradeoffs I listed above.

This proposal is really a drastic change of what NNVM does, as well as the
optimization passes, and given the scope, in your analogy, "a new vehicle
to solve all the problems"
rather than a minor patch. It will take a lot of engineering effort to
bring in new features and adapting the existing ones.
Because of that, it does merit a discussion about how shall we think about
the future MXNet2.0.

Technically Relay is a serious candidate. Of course relay, as well as its
core, is in C++ but maintains the multi-language first principle, that is
why the example code was in python.
See more related discussion comparing NNVMv1 and relay:
https://discuss.tvm.ai/t/any-materials-of-relay-for-beginners/2392/5

I think the ideal graph data structure candidate for MXNet2.0 should have
natural support for:
- Native support of function, module, and recursions
- Control flows
- The ability of interpolation with multi-language frontend, e.g. being
able to prototype graph optimizations in python/scala/clojure if needed.

Adding these support needs significant engineering effort, and I do hope we
only have to do it once. While I don't want to force any conclusion here,
I do think Relay is one such candidate.

Tianqi


On Tue, May 14, 2019 at 5:58 PM Pedro Larroy 
wrote:

> Hi Tianqi
>
> Thanks for the quick response.
>
> Could you point to examples where graph.h is being exposed which would
> not be possible with what I propose? I don't think my proposal is
> having any impact in language bindings, and the way I describe it
> doesn't affect having or not having higher language bindings. Please
> elaborate so I can understand your concern.  Maybe code examples where
> the graph attributes are being changed from Python?  I don't think we
> have this on MXNet. This is such a core foundation for MXNet, that I
> don't think we should compromise on it because other project not
> directly related to MXNet might want to expose some untyped graph and
> Node attributes.  The current status makes maintaining the code very
> painful and also is preventing desired features such as higher order
> gradients to be developed. I have heard from you many times how speed
> is critical for us to innovate in this quickly changing field.
>
> My proposal is limited to the graph and wouldn't change the way
> operators are registered and arguments are processed for operators for
> example.
>
>
> Regarding the second point, the documentation about Relay in the web
> which I found for example:
>
> https://docs.tvm.ai/dev/relay_add_op.html#
>
> Is somebody working on making Imperative::Backward use this API? this
> would be a big change which I'm not aware of. And using an IR is of a
> much bigger scope than the change I'm proposing here for example.
>
> I think I'm having difficulty understanding what are the arguments
> here. I'm saying I need to change one piece of my car and what you are
> selling me is a new vehicle here?  Or your suggestion that we use
> Relay for the graph passes in MXNet?
>
> I would like to see C++ code examples, Python examples are not
> sufficient when we talk about the core MXNet.
>
> Pedro.
>
>
>
>
>
>
> On Tue, May 14, 2019 at 5:39 PM Tianqi Chen 
> wrote:
> >
> > Thanks for the proposal. Let me share some of my thoughts:
> >
> > Specific comments on the proposal
> > 

Re: [Proposal] New operator graph for MXNet

2019-05-14 Thread Pedro Larroy
Hi Tianqi

I thought a bit more about your comments and I think there is a simple
way to address your concerns that satisfies both needs.

We can have a NodeAttributes template class which has a map of string
to any as it's currenlty the case, so the graph can be used in the
highly dynamic scenario that you are concerned about.

Let me know what you think.

Pedro.


On Tue, May 14, 2019 at 5:50 PM Pedro Larroy
 wrote:
>
> Hi Tianqi
>
> Thanks for the quick response.
>
> Could you point to examples where graph.h is being exposed which would
> not be possible with what I propose? I don't think my proposal is
> having any impact in language bindings, and the way I describe it
> doesn't affect having or not having higher language bindings. Please
> elaborate so I can understand your concern.  Maybe code examples where
> the graph attributes are being changed from Python?  I don't think we
> have this on MXNet. This is such a core foundation for MXNet, that I
> don't think we should compromise on it because other project not
> directly related to MXNet might want to expose some untyped graph and
> Node attributes.  The current status makes maintaining the code very
> painful and also is preventing desired features such as higher order
> gradients to be developed. I have heard from you many times how speed
> is critical for us to innovate in this quickly changing field.
>
> My proposal is limited to the graph and wouldn't change the way
> operators are registered and arguments are processed for operators for
> example.
>
>
> Regarding the second point, the documentation about Relay in the web
> which I found for example:
>
> https://docs.tvm.ai/dev/relay_add_op.html#
>
> Is somebody working on making Imperative::Backward use this API? this
> would be a big change which I'm not aware of. And using an IR is of a
> much bigger scope than the change I'm proposing here for example.
>
> I think I'm having difficulty understanding what are the arguments
> here. I'm saying I need to change one piece of my car and what you are
> selling me is a new vehicle here?  Or your suggestion that we use
> Relay for the graph passes in MXNet?
>
> I would like to see C++ code examples, Python examples are not
> sufficient when we talk about the core MXNet.
>
> Pedro.
>
>
>
>
>
>
> On Tue, May 14, 2019 at 5:39 PM Tianqi Chen  wrote:
> >
> > Thanks for the proposal. Let me share some of my thoughts:
> >
> > Specific comments on the proposal
> > ---
> > The heavy use of generic in the Graph type was a huge departure from
> > type-erased data structure which was presented in the previous design.
> > While we understand the advantage of typed language(more compile-time
> > checking) and type-erased types(more dynamism) the heavy use of
> > the template will actually make the project solely C++ focused, making it
> > hard to expose intermediate(templatized) data structure to
> > other languages like python/scala/clojure.
> >
> > While I fully understand some of the lessons taught in programming
> > C++(reduce shared_ptr, more typing etc.)
> > We need to think about the context of MXNet project and **the need to
> > support multi-language as a first-class**.
> > Some of the type-erased types are design trade-offs made to support these
> > features, and we need to think more
> > carefully instead of just applying "rules for C++" which may bring problems.
> >
> > Future of NNVM
> > --
> > Given that this thread touched upon what we should do for better
> > computational graph handling. I would recommend also to take a look at
> > NNVMv2 -- relay.
> >
> > Relay addresses many of the wish-lists in the proposal already, such as
> > operator fusion, high order gradient, offload to hardware, isolated
> > compilation, deployment on edge and accelerators etc.
> > Relay also address problems not yet being mentioned in the proposal,
> > including control flow and dynamic runtime, automatic layout optimization
> > etc.
> >
> > Tianqi
> >
> > On Tue, May 14, 2019 at 5:06 PM Sheng Zha  wrote:
> >
> > > Hi Pedro,
> > >
> > > Thanks for taking the inititaive. Skimming through the design doc, I
> > > didn't see comparison with existing solutions such as relay in tvm, which
> > > is already a dependency of mxnet already. Could you elaborate on 
> > > comparison
> > > with existing solutions in the design doc too?
> > >
> > > -sz
> > >
> > > On 2019/05/14 23:49:30, Pedro Larroy 
> > > wrote:
> > > > Hi dev@
> > > >
> > > > As a result of my deep dives on the graph machinery I have created a
> > > > new proposal to improve the operator graph in MXNet.
> > > >
> > > > This would mean superseding the use of NNVM Graph in MXNet and having
> > > > a new implementation that we can use to simplify a lot of code and do
> > > > powerful graph manipulation and passes such as operator fusion and
> > > > other optimizations.
> > > >
> > > > As it would be a change with big impact and ramifications, your
> 

Re: [Proposal] New operator graph for MXNet

2019-05-14 Thread Pedro Larroy
Hi Tianqi

Thanks for the quick response.

Could you point to examples where graph.h is being exposed which would
not be possible with what I propose? I don't think my proposal is
having any impact in language bindings, and the way I describe it
doesn't affect having or not having higher language bindings. Please
elaborate so I can understand your concern.  Maybe code examples where
the graph attributes are being changed from Python?  I don't think we
have this on MXNet. This is such a core foundation for MXNet, that I
don't think we should compromise on it because other project not
directly related to MXNet might want to expose some untyped graph and
Node attributes.  The current status makes maintaining the code very
painful and also is preventing desired features such as higher order
gradients to be developed. I have heard from you many times how speed
is critical for us to innovate in this quickly changing field.

My proposal is limited to the graph and wouldn't change the way
operators are registered and arguments are processed for operators for
example.


Regarding the second point, the documentation about Relay in the web
which I found for example:

https://docs.tvm.ai/dev/relay_add_op.html#

Is somebody working on making Imperative::Backward use this API? this
would be a big change which I'm not aware of. And using an IR is of a
much bigger scope than the change I'm proposing here for example.

I think I'm having difficulty understanding what are the arguments
here. I'm saying I need to change one piece of my car and what you are
selling me is a new vehicle here?  Or your suggestion that we use
Relay for the graph passes in MXNet?

I would like to see C++ code examples, Python examples are not
sufficient when we talk about the core MXNet.

Pedro.






On Tue, May 14, 2019 at 5:39 PM Tianqi Chen  wrote:
>
> Thanks for the proposal. Let me share some of my thoughts:
>
> Specific comments on the proposal
> ---
> The heavy use of generic in the Graph type was a huge departure from
> type-erased data structure which was presented in the previous design.
> While we understand the advantage of typed language(more compile-time
> checking) and type-erased types(more dynamism) the heavy use of
> the template will actually make the project solely C++ focused, making it
> hard to expose intermediate(templatized) data structure to
> other languages like python/scala/clojure.
>
> While I fully understand some of the lessons taught in programming
> C++(reduce shared_ptr, more typing etc.)
> We need to think about the context of MXNet project and **the need to
> support multi-language as a first-class**.
> Some of the type-erased types are design trade-offs made to support these
> features, and we need to think more
> carefully instead of just applying "rules for C++" which may bring problems.
>
> Future of NNVM
> --
> Given that this thread touched upon what we should do for better
> computational graph handling. I would recommend also to take a look at
> NNVMv2 -- relay.
>
> Relay addresses many of the wish-lists in the proposal already, such as
> operator fusion, high order gradient, offload to hardware, isolated
> compilation, deployment on edge and accelerators etc.
> Relay also address problems not yet being mentioned in the proposal,
> including control flow and dynamic runtime, automatic layout optimization
> etc.
>
> Tianqi
>
> On Tue, May 14, 2019 at 5:06 PM Sheng Zha  wrote:
>
> > Hi Pedro,
> >
> > Thanks for taking the inititaive. Skimming through the design doc, I
> > didn't see comparison with existing solutions such as relay in tvm, which
> > is already a dependency of mxnet already. Could you elaborate on comparison
> > with existing solutions in the design doc too?
> >
> > -sz
> >
> > On 2019/05/14 23:49:30, Pedro Larroy 
> > wrote:
> > > Hi dev@
> > >
> > > As a result of my deep dives on the graph machinery I have created a
> > > new proposal to improve the operator graph in MXNet.
> > >
> > > This would mean superseding the use of NNVM Graph in MXNet and having
> > > a new implementation that we can use to simplify a lot of code and do
> > > powerful graph manipulation and passes such as operator fusion and
> > > other optimizations.
> > >
> > > As it would be a change with big impact and ramifications, your
> > > thoughts and feedback on the document would be highly appreciated so
> > > we can take potential future interesting use cases:
> > >
> > >
> > https://cwiki.apache.org/confluence/display/MXNET/MXVM%3A+Operator+graph+2.0
> > >
> > > Pedro.
> > >
> >


Re: [Proposal] New operator graph for MXNet

2019-05-14 Thread Tianqi Chen
Thanks for the proposal. Let me share some of my thoughts:

Specific comments on the proposal
---
The heavy use of generic in the Graph type was a huge departure from
type-erased data structure which was presented in the previous design.
While we understand the advantage of typed language(more compile-time
checking) and type-erased types(more dynamism) the heavy use of
the template will actually make the project solely C++ focused, making it
hard to expose intermediate(templatized) data structure to
other languages like python/scala/clojure.

While I fully understand some of the lessons taught in programming
C++(reduce shared_ptr, more typing etc.)
We need to think about the context of MXNet project and **the need to
support multi-language as a first-class**.
Some of the type-erased types are design trade-offs made to support these
features, and we need to think more
carefully instead of just applying "rules for C++" which may bring problems.

Future of NNVM
--
Given that this thread touched upon what we should do for better
computational graph handling. I would recommend also to take a look at
NNVMv2 -- relay.

Relay addresses many of the wish-lists in the proposal already, such as
operator fusion, high order gradient, offload to hardware, isolated
compilation, deployment on edge and accelerators etc.
Relay also address problems not yet being mentioned in the proposal,
including control flow and dynamic runtime, automatic layout optimization
etc.

Tianqi

On Tue, May 14, 2019 at 5:06 PM Sheng Zha  wrote:

> Hi Pedro,
>
> Thanks for taking the inititaive. Skimming through the design doc, I
> didn't see comparison with existing solutions such as relay in tvm, which
> is already a dependency of mxnet already. Could you elaborate on comparison
> with existing solutions in the design doc too?
>
> -sz
>
> On 2019/05/14 23:49:30, Pedro Larroy 
> wrote:
> > Hi dev@
> >
> > As a result of my deep dives on the graph machinery I have created a
> > new proposal to improve the operator graph in MXNet.
> >
> > This would mean superseding the use of NNVM Graph in MXNet and having
> > a new implementation that we can use to simplify a lot of code and do
> > powerful graph manipulation and passes such as operator fusion and
> > other optimizations.
> >
> > As it would be a change with big impact and ramifications, your
> > thoughts and feedback on the document would be highly appreciated so
> > we can take potential future interesting use cases:
> >
> >
> https://cwiki.apache.org/confluence/display/MXNET/MXVM%3A+Operator+graph+2.0
> >
> > Pedro.
> >
>


Re: [Proposal] New operator graph for MXNet

2019-05-14 Thread Pedro Larroy
Hi Sheng

Could  you provide relevant links to Relay and what you would
recommend to read so we have a focused discussion instead of me
potentially me miss-searching? Probably I also missed the discussion
or vote in the mail list regarding including TVM as a depedency or
future plans on using Relay.
As far as I know, we have TVM as a dependency because NNVM was
assimilated into it but we are not using it directly.  Is this
correct?

This would help me to add this information to the doc as you request.

Thanks.

Pedro.

On Tue, May 14, 2019 at 5:06 PM Sheng Zha  wrote:
>
> Hi Pedro,
>
> Thanks for taking the inititaive. Skimming through the design doc, I didn't 
> see comparison with existing solutions such as relay in tvm, which is already 
> a dependency of mxnet already. Could you elaborate on comparison with 
> existing solutions in the design doc too?
>
> -sz
>
> On 2019/05/14 23:49:30, Pedro Larroy  wrote:
> > Hi dev@
> >
> > As a result of my deep dives on the graph machinery I have created a
> > new proposal to improve the operator graph in MXNet.
> >
> > This would mean superseding the use of NNVM Graph in MXNet and having
> > a new implementation that we can use to simplify a lot of code and do
> > powerful graph manipulation and passes such as operator fusion and
> > other optimizations.
> >
> > As it would be a change with big impact and ramifications, your
> > thoughts and feedback on the document would be highly appreciated so
> > we can take potential future interesting use cases:
> >
> > https://cwiki.apache.org/confluence/display/MXNET/MXVM%3A+Operator+graph+2.0
> >
> > Pedro.
> >


Re: [Proposal] New operator graph for MXNet

2019-05-14 Thread Sheng Zha
Hi Pedro,

Thanks for taking the inititaive. Skimming through the design doc, I didn't see 
comparison with existing solutions such as relay in tvm, which is already a 
dependency of mxnet already. Could you elaborate on comparison with existing 
solutions in the design doc too?

-sz

On 2019/05/14 23:49:30, Pedro Larroy  wrote: 
> Hi dev@
> 
> As a result of my deep dives on the graph machinery I have created a
> new proposal to improve the operator graph in MXNet.
> 
> This would mean superseding the use of NNVM Graph in MXNet and having
> a new implementation that we can use to simplify a lot of code and do
> powerful graph manipulation and passes such as operator fusion and
> other optimizations.
> 
> As it would be a change with big impact and ramifications, your
> thoughts and feedback on the document would be highly appreciated so
> we can take potential future interesting use cases:
> 
> https://cwiki.apache.org/confluence/display/MXNET/MXVM%3A+Operator+graph+2.0
> 
> Pedro.
> 


[Proposal] New operator graph for MXNet

2019-05-14 Thread Pedro Larroy
Hi dev@

As a result of my deep dives on the graph machinery I have created a
new proposal to improve the operator graph in MXNet.

This would mean superseding the use of NNVM Graph in MXNet and having
a new implementation that we can use to simplify a lot of code and do
powerful graph manipulation and passes such as operator fusion and
other optimizations.

As it would be a change with big impact and ramifications, your
thoughts and feedback on the document would be highly appreciated so
we can take potential future interesting use cases:

https://cwiki.apache.org/confluence/display/MXNET/MXVM%3A+Operator+graph+2.0

Pedro.


Re: assimilation of mshadow into the MXNet codebase

2019-05-14 Thread Pedro Larroy
Hi Sheng.

Do you need some help with this?  Do we plan to have this for 1.5?

Pedro.

On Wed, Apr 24, 2019 at 4:26 PM Pedro Larroy
 wrote:
>
> Thanks. Great to read.
>
> On Wed, Apr 24, 2019 at 2:19 PM Sheng Zha  wrote:
> >
> > The community has agreed to donate mshadow to the mxnet code base. I will 
> > start the migration and build logic changes soon.
> >
> > -sz
> >
> > On 2019/04/07 21:47:39, Sheng Zha  wrote:
> > > I agree it would make development easier to donate mshadow to mxnet code 
> > > base, since mshadow is only used in MXNet. I support donating the mshadow 
> > > code to mxnet and I started an RFC for this in mshadow [1].
> > >
> > > [1] https://github.com/dmlc/mshadow/issues/373
> > >
> > > -sz
> > >
> > > On 2019/04/06 04:38:19, Tianqi Chen  wrote:
> > > > Technically, mshadow is sufficient for MXNet. Adopting other libraries (
> > > > eigen or xtensor) will unnecessarily increase the codebase complexity
> > > > without any additional gains.
> > > >
> > > > Given that mshadow is only used by mxnet. I do support donating it into
> > > > mxnet codebase.
> > > > To respect the original mshadow community. I would recommend starting a
> > > > community RFC In the mshadow github issue for a week, before we start 
> > > > the
> > > > migrating process.
> > > > Also, I would recommend a rebase merge just like the case of MXNet.jl 
> > > > code
> > > > base to preserve the contribution history.
> > > >
> > > > Tianqi
> > > >
> > > >
> > > > On Fri, Apr 5, 2019 at 9:25 PM Alfredo Luque
> > > >  wrote:
> > > >
> > > > > Do you have a link to both of these proposals?
> > > > >
> > > > > On Fri, Apr 5, 2019 at 20:14 Anirudh Acharya 
> > > > > wrote:
> > > > >
> > > > > > Hi Pedro,
> > > > > >
> > > > > > mshadow is mostly used for tensor arithmetic. There have been 
> > > > > > discussions
> > > > > > about including it within mxnet. I think it is a good idea.
> > > > > >
> > > > > > As a more long term solution using libraries like eigen to perform 
> > > > > > linear
> > > > > > algebra operations was also suggested by anirudh2290@. I think 
> > > > > > xtensor(
> > > > > > https://github.com/QuantStack/xtensor ) can also be a candidate 
> > > > > > here.
> > > > > >
> > > > > > -
> > > > > > Anirudh
> > > > > >
> > > > > >
> > > > > > On Fri, Apr 5, 2019 at 7:03 PM Pedro Larroy <
> > > > > pedro.larroy.li...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Hi
> > > > > > >
> > > > > > > Some developers have noticed that working in mshadow is 
> > > > > > > cumbersome as
> > > > > > > it's a 3rdparty subrepo.
> > > > > > >
> > > > > > > Since mshadow is a bunch of headers which don't have much of
> > > > > > > independent tests / library functionality, me and other developers
> > > > > > > believe that it would be good to assimilate this code in the
> > > > > > > repository for ease of contribution and changes without having to 
> > > > > > > go
> > > > > > > trough contortions to test PRs that modify mshadow.
> > > > > > >
> > > > > > > Would anybody oppose this change?
> > > > > > >
> > > > > > > Thanks and have a nice weekend.
> > > > > > >
> > > > > > > Pedro.
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >


Re: Python2 End of Life

2019-05-14 Thread Pedro Larroy
+1  Let python2 rest, let's simplify our infrastructure and need to
support old Python versions.

On Mon, May 13, 2019 at 1:58 PM Jake Lee  wrote:
>
> +1 Recently I upgraded the Numpy version and found out that Pylint had
> false alarm on it. The Pylint fix is only available on Python3. So I
> changed the default python version of 'make pylint' command to python3 (PR
> haven't been merged). It's time to drop support for Python2.
>
> On Mon, May 13, 2019 at 1:37 PM Junru Shao  wrote:
>
> > +1
> >
> > On Mon, May 13, 2019 at 1:34 PM Aaron Markham 
> > wrote:
> >
> > > +1 for the pledge and to start moving things to Python 3.
> > > I think our installation instructions and tutorials can be updated to
> > > default to Python3 and we should update Python2-only tutorials. I know
> > > we have a handful of those, and when I spot them, I'll create an
> > > issue.
> > > I can also look at migrating the docs build to Python 3.
> > > Should we add a new label for issues relating to migrating to Python3?
> > > Cheers,
> > > Aaron
> > >
> > > On Mon, May 13, 2019 at 12:04 PM Zach Kimberg  > >
> > > wrote:
> > > >
> > > > Right now, the official date for ending support for Python 2.7 (and all
> > > of
> > > > python2) is set to January 1 [1]. As part of it, a number of projects
> > > have
> > > > pledged to drop support for Python2 in or before 2020 including
> > > Tensorflow,
> > > > requests, pandas, ipython, numpy, pillow, and Cython [2]. I believe we
> > > > should also join in this pledge on python3statement.org [2] because it
> > > > would help clean up our project and it would be difficult to continue
> > > > supporting Python2 anyway when some of our dependencies are dropping
> > > > support.
> > > >
> > > > As a concrete step, we should decide on a date to remove all usages of
> > > > Python2 from our CI and consider that officially dropping support.
> > > > Following that, we can expect PRs will end up breaking support for
> > > Python2.
> > > > I suggest just using the same date that Python is dropping support of
> > > > January 1. We may also need to update some examples or scripts that
> > were
> > > > written only for python2 that are around the project. Any thoughts?
> > > >
> > > > Zach
> > > >
> > > >
> > > > [1] - https://www.python.org/dev/peps/pep-0373/
> > > > [2] - https://python3statement.org/
> > >
> >


Re: [INVITATION] 14th of May 2019 / Berlin MXNet Recurring User Group Meeting

2019-05-14 Thread Per da Silva
Hey Wen-Yang Chu,

Unfortunately, my talents are more on the CI/CD at the moment, so I don't
know that I'll be able to answer your question.

Is there anyone out there than can join us and shine some light in the
situation?

If no one is able to join, I'll try to understand your question and find
someone who knows the answer.

Mad props to you for bringing MXNet to Phillips and your startup!!

Cheers,

Per

On Tue., 14 May 2019, 3:21 pm Wen-Yang Chu,  wrote:

> Hi  Per da Silva,
>
> I would like to join this meeting. I would like to ask about some solution
> of how to replace the depreciated "crop" layer properly.
> I found many have the same issue and I do not find a proper solution. It
> can be a real deal breaker for me despite I am really fond
> of MXNET and use it in Philips for product development for more than 2
> years. I am opening a startup and hope to continue using mxnet.
> I am from Belgium by the way. See you today at 7PM
>
> Best regards,
>
> Wen-Yang
>
> On Tue, May 14, 2019 at 1:52 PM Per da Silva  wrote:
>
> > Dear MXNet community,
> >
> > I would like to invite you to the regular Apache MXNet (Incubating) User
> > Group meeting on the 19th of March 2019 [1].
> >
> > As usually, the meeting will have remote VC, powered by Amazon Chime [2].
> >
> > Due to availability, **TODAY** It will be held from* 7pm-8pm (CEST) /
> > 10am-11am (PST).* One hour later than usual.
> >
> > Join the meeting:
> >
> > https://chime.aws/2671929429
> >
> > Meeting ID: 2671929429
> >
> > Looking forward to meet you there.
> >
> > Best
> > Per
> >
> > [1]
> >
> >
> https://cwiki.apache.org/confluence/display/MXNET/Apache+MXNet+%28Incubating%29+
> > User+Groups+recurring+meetings
> > [2] https://chime.aws/
> >
>


Re: [INVITATION] 14th of May 2019 / Berlin MXNet Recurring User Group Meeting

2019-05-14 Thread Wen-Yang Chu
Hi  Per da Silva,

I would like to join this meeting. I would like to ask about some solution
of how to replace the depreciated "crop" layer properly.
I found many have the same issue and I do not find a proper solution. It
can be a real deal breaker for me despite I am really fond
of MXNET and use it in Philips for product development for more than 2
years. I am opening a startup and hope to continue using mxnet.
I am from Belgium by the way. See you today at 7PM

Best regards,

Wen-Yang

On Tue, May 14, 2019 at 1:52 PM Per da Silva  wrote:

> Dear MXNet community,
>
> I would like to invite you to the regular Apache MXNet (Incubating) User
> Group meeting on the 19th of March 2019 [1].
>
> As usually, the meeting will have remote VC, powered by Amazon Chime [2].
>
> Due to availability, **TODAY** It will be held from* 7pm-8pm (CEST) /
> 10am-11am (PST).* One hour later than usual.
>
> Join the meeting:
>
> https://chime.aws/2671929429
>
> Meeting ID: 2671929429
>
> Looking forward to meet you there.
>
> Best
> Per
>
> [1]
>
> https://cwiki.apache.org/confluence/display/MXNET/Apache+MXNet+%28Incubating%29+
> User+Groups+recurring+meetings
> [2] https://chime.aws/
>


[INVITATION] 14th of May 2019 / Berlin MXNet Recurring User Group Meeting

2019-05-14 Thread Per da Silva
Dear MXNet community,

I would like to invite you to the regular Apache MXNet (Incubating) User
Group meeting on the 19th of March 2019 [1].

As usually, the meeting will have remote VC, powered by Amazon Chime [2].

Due to availability, **TODAY** It will be held from* 7pm-8pm (CEST) /
10am-11am (PST).* One hour later than usual.

Join the meeting:

https://chime.aws/2671929429

Meeting ID: 2671929429

Looking forward to meet you there.

Best
Per

[1]
https://cwiki.apache.org/confluence/display/MXNET/Apache+MXNet+%28Incubating%29+
User+Groups+recurring+meetings
[2] https://chime.aws/