Multiple calls to mx.sym.Variable with same name: Dangerous / unexpected behavior?

[julian90]

Description

Multiple calls to mx.sym.Variable with same name e.g. calling mx.sym.Variable('a') twice seems to result in unexpected and therefore possibly dangerous behavior in the forward and backward call.

Environment info (Required)

----------Python Info----------
Version : 3.5.2
Compiler : GCC 5.4.0 20160609
Build : ('default', 'Nov 23 2017 16:37:01')
Arch : ('64bit', 'ELF')
------------Pip Info-----------
Version : 10.0.1
Directory : /u/schamper/software/pyenvs/py3env_seye-1.18.1/lib/python3.5/site-packages/pip
----------MXNet Info-----------
Version : 1.1.0
Directory : /u/schamper/software/pyenvs/py3env_seye-1.18.1/lib/python3.5/site-packages/mxnet
Commit Hash : 07a83a0
----------System Info----------
Platform : Linux-4.13.0-36-generic-x86_64-with-Ubuntu-16.04-xenial
system : Linux
node : valin
release : 4.13.0-36-generic
version : #40~16.04.1-Ubuntu SMP Fri Feb 16 23:25:58 UTC 2018
----------Hardware Info----------
machine : x86_64
processor : x86_64
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 4
On-line CPU(s) list: 0-3
Thread(s) per core: 1
Core(s) per socket: 4
Socket(s): 1
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 58
Model name: Intel(R) Core(TM) i5-3470 CPU @ 3.20GHz
Stepping: 9
CPU MHz: 3192.812
CPU max MHz: 3600.0000
CPU min MHz: 1600.0000
BogoMIPS: 6385.62
Virtualization: VT-x
L1d cache: 32K
L1i cache: 32K
L2 cache: 256K
L3 cache: 6144K
NUMA node0 CPU(s): 0-3
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm cpuid_fault epb pti retpoline tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms xsaveopt dtherm ida arat pln pts
----------Network Test----------
Setting timeout: 10
Timing for PYPI: https://pypi.python.org/pypi/pip, DNS: 0.0093 sec, LOAD: 0.3110 sec.
Timing for MXNet: https://github.com/apache/incubator-mxnet, DNS: 0.0011 sec, LOAD: 0.8138 sec.
Timing for Gluon Tutorial(cn): https://zh.gluon.ai, DNS: 0.9853 sec, LOAD: 0.6936 sec.
Timing for FashionMNIST: https://apache-mxnet.s3-accelerate.dualstack.amazonaws.com/gluon/dataset/fashion-mnist/train-labels-idx1-ubyte.gz, DNS: 0.0264 sec, LOAD: 0.2201 sec.
Timing for Gluon Tutorial(en): http://gluon.mxnet.io, DNS: 0.1136 sec, LOAD: 0.0287 sec.

Minimum reproducible example

multiple_calls_to_sym_var.py.zip

Copied content of multiple_calls_to_sym_var.py

import mxnet as mx

var_f = mx.sym.Variable('a') * mx.sym.Variable('a')
gA = mx.nd.zeros(1)
ex_f = var_f.bind(ctx=mx.cpu(), args={'a':mx.nd.array([3])}, args_grad={"a": gA})
print(ex_f.forward())
# results in 9 as expected

ex_f.backward(out_grads=mx.nd.array([1]))
print(gA)
# results in 3 but expected gradient would be 6 (the two calls to sym.Variable
# seem to have created two versions of 'a').
# Up to now the program did not crash, so the wrong(?) usage of
# mx.sym.Variable(...) is not obvious to the programmer

print(ex_f.grad_dict)
# Only after e.g. reading the grad_dict the program crashes and the wrong usage
# becomes obvious: ValueError: Duplicate names detected, ['a', 'a']

Steps to reproduce

python3 multiple_calls_to_sym_var.py

Remarks

Is this behavior intentional and useful in any scenario? Do I miss something obvious? Maybe there is a guideline, I am not aware of, that mx.sym.Variable should not be called twice with the same name and then be used in the same computational graph, for most applications. But if so, mxnet should maybe warn the user a bit more.

I am aware of that constructing the graph e.g. via

var_a = mx.sym.Variable('a')
var_f = var_a * var_a

works and shows the expected behavior and that
mx.sym.Variable('a') is mx.sym.Variable('a') results in False, but found it still valiuable to report the behavior of the other construction.

[roywei]

@julian90 using the same name is not recommended, please refer to #9890 and #2036.
@nswamy could you help to add label Symbol? Thanks

[sandeep-krishnamurthy]

Resolving the issue, because, with 2 issues referenced, this is an expected behavior. Please reopen for any other issues.