Yes, correct cu90 is indeed there, thanks for pointing it.
So the question, should we be publishing to Docker Hub as part of the
release process so that bindings other than python are also published and
there is a policy on what cuda versions we publish?
Thanks
ANirudh
On Sat, Jul 21, 2018 at
cu90 and cu90mkl are also available, see
https://hub.docker.com/r/mxnet/python/tags/
On Sat, Jul 21, 2018 at 9:51 PM, Anirudh Acharya
wrote:
> The python binding that is actively maintained is
>
> mxnet-mkl 1.2.1
>
>
> Other versions that use CUDA like mxnet-cu and mxnet-cumkl are not
>
The python binding that is actively maintained is
mxnet-mkl 1.2.1
Other versions that use CUDA like mxnet-cu and mxnet-cumkl are not
actively maintained.
-
Anirudh
On Sat, Jul 21, 2018 at 9:09 PM Mu Li wrote:
> Surprisingly only the python binding is actively maintained. I remember
Surprisingly only the python binding is actively maintained. I remember we
can easily push all bindings into docker hub through the script in
https://github.com/apache/incubator-mxnet/tree/master/docker.
On Sat, Jul 21, 2018 at 5:03 PM, Anirudh Acharya
wrote:
> Hi,
>
> Docker Hub(
Hi,
Docker Hub( https://hub.docker.com/u/mxnet/ ) currently hosts images of
MXNet and its various bindings but it is not actively maintained. Should we
publish MXNet images to Docker Hub as part of the release process and
actively maintain it?
The pros of publishing docker images would be ease
+1
Performance should not be affected by default.
Generally, I would treat nan as undefined behaviour and allow to explicitly
enable checks for nan which will throw exceptions.
Asmus
Am Samstag, 21. Juli 2018, 21:31:05 MESZ hat Junru Shao
Folgendes geschrieben:
However, I am not
If you behave like numpy for sparse, then things like dividing any sparse
matrix by another sparse matrix will produce a dense matrix with a lot of
NaNs in it wherever it encountered a “missing” value in both the source and
destination positions of the sparse matrices (ie 0 divided by 0). If i
However, I am not 100% sure how much performance will be sacrificed if we stick
to NumPy's approach which seems to check numeral exceptions on each step.
I believe it will be great if we could make the default setting to be "no
checking", and leave users an option to turn on these numeral
I think it is worth discussing.
NunPy has defined its own rules to handle with numeral exceptions, which makes
a lot of sense to me.
[Link](https://docs.scipy.org/doc/numpy/user/misc.html#how-numpy-handles-numerical-exceptions)
On 2018/07/20 22:19:46, Leonard Lausen wrote:
> Hello MXNet
