internlm/SWE-Fixer-Train-110K huggingface dataset:
Repository: chainer/chainer

Issue:
Progress bar exceeds 100% in some situation
In some situation, the progress bar in `progress_bar` extension exceeds 100%. We can find such situation in the PTB example. Where the default total epoch number (39) is not divisible by 7, the number epochs consumed in one iteration.

```
%(master)[]./train_ptb.py --test
#vocab = 10000
     total [#####################################################] 107.69%
this epoch [..................................................]  0.00%
         6 iter, 42 epoch / 39 epochs
  0.068392 iters/sec. Estimated time to finish: -1 day, 23:59:53.733622.
```

Detail discussion is found in #1384.

Progress bar exceeds 100% in some situation
In some situation, the progress bar in `progress_bar` extension exceeds 100%. We can find such situation in the PTB example. Where the default total epoch number (39) is not divisible by 7, the number epochs consumed in one iteration.

```
%(master)[]./train_ptb.py --test
#vocab = 10000
     total [#####################################################] 107.69%
this epoch [..................................................]  0.00%
         6 iter, 42 epoch / 39 epochs
  0.068392 iters/sec. Estimated time to finish: -1 day, 23:59:53.733622.
```

Detail discussion is found in #1384.



Discussion:
> (2) Fix ProgressBar so that it accepts the situation in which current epoch number can exceed the number of total epochs.

Can I try this one out?
Yes, go ahead! Let us know if you need this discussion on the specification.
> (2) Fix ProgressBar so that it accepts the situation in which current epoch number can exceed the number of total epochs.

Can I try this one out?
Yes, go ahead! Let us know if you need this discussion on the specification.

Resolving patch:
diff --git a/chainer/training/extensions/progress_bar.py b/chainer/training/extensions/progress_bar.py
--- a/chainer/training/extensions/progress_bar.py
+++ b/chainer/training/extensions/progress_bar.py
@@ -77,6 +77,7 @@ def __call__(self, trainer):
                 rate = iteration / length
             else:
                 rate = epoch / length
+            rate = min(rate, 1.0)
 
             bar_length = self._bar_length
             marks = '#' * int(rate * bar_length)
@@ -104,6 +105,7 @@ def __call__(self, trainer):
                 estimated_time = (length - iteration) / speed_t
             else:
                 estimated_time = (length - epoch) / speed_e
+            estimated_time = max(estimated_time, 0.0)
             out.write('{:10.5g} iters/sec. Estimated time to finish: {}.\n'
                       .format(speed_t,
                               datetime.timedelta(seconds=estimated_time)))


Test patch:
Repository: chainer/chainer

Issue:
Can't use chainer.grad for LSTM
I tried to differentiate a LSTM block with `chainer.grad` function along with `enable_double_backprop=True` option. Then got the error:

Code:
```
import numpy as np
import chainer
import chainer.links as L

x = chainer.Variable(np.random.rand(10, 20).astype('f'))
lstm = L.LSTM(20, 20)
y = lstm(x)
dydx, = chainer.grad([y], [x], enable_double_backprop=True)
```

Error:
```
~/.pyenv/versions/anaconda3-5.0.0/lib/python3.6/site-packages/chainer/functions/activation/lstm.py in backward(self, indexes, grads)
    111     def backward(self, indexes, grads):
    112         grad_inputs = (
--> 113             self.get_retained_inputs() + self.get_retained_outputs() + grads)
    114         return LSTMGrad()(*grad_inputs)
```

Is this a bug of LSTM module or my wrong usage of LSTM?
I'm using Chainer v4.0.0b3.

Any comments will help. Thanks.


Discussion:
`chainer.grad` defines `gys` as a list here: https://github.com/chainer/chainer/blob/master/chainer/function_node.py#L826
and gives it to `backward_accumulate`, and then it's directly given to `backward` method of each `FunctionNode` here: https://github.com/chainer/chainer/blob/master/chainer/function_node.py#L541
I guess it causes the above error. How should I fix this? And we may need to add more tests of `chainer.grad` with various `FunctionNode`s?

Resolving patch:
diff --git a/chainer/functions/activation/lstm.py b/chainer/functions/activation/lstm.py
--- a/chainer/functions/activation/lstm.py
+++ b/chainer/functions/activation/lstm.py
@@ -179,6 +179,14 @@ def backward(self, inputs, grads):
 
         c_prev, x, c, gc, gh = inputs
         ggc_prev, ggx = grads
+        batch = len(x)
+
+        if gc is None:
+            gc = xp.zeros_like(c)
+        if gh is None:
+            gh = xp.zeros_like(c[:batch])
+        if ggc_prev is None:
+            ggc_prev = xp.zeros_like(c_prev)
 
         gc_prev = xp.empty_like(c_prev)
         gx = xp.empty_like(x)
@@ -186,7 +194,6 @@ def backward(self, inputs, grads):
         ggc = xp.empty_like(ggc_prev)
         ggh = xp.empty_like(gh)
 
-        batch = len(x)
         gc_prev[batch:] = 0
         gc_next[batch:] = 0
         ggc[batch:] = ggc_prev[batch:]


Test patch:
Repository: chainer/chainer

Issue:
Feature request: Variable.xp to get the array module of its data array
I often need to call `chainer.cuda.get_array_module` for `Variable` objects. Like `Link.xp`, `Variable.xp` would be a useful property.


Discussion:
I think it is good to have this feature. Any objections from core team?

One small thing to decide is that how should it behave when the Variable is not initialized (e.g., `chainer.Variable(None).xp`).  Links are always on CPU initially.
Although `chainer.cuda.get_array_module(chainer.Variable(None))` returns numpy, raising an error for uninitialized Variables makes more sense to me, at least for `Variable.xp`.

Resolving patch:
diff --git a/chainer/variable.py b/chainer/variable.py
--- a/chainer/variable.py
+++ b/chainer/variable.py
@@ -487,6 +487,16 @@ def __repr__(self):
     def __str__(self):
         return variable_str(self)
 
+    @property
+    def xp(self):
+        """Array module for this variable.
+
+        Depending on which of CPU/GPU this variable is on, this property
+        returns :mod:`numpy` or :mod:`cupy`.
+
+        """
+        return cuda.get_array_module(self)
+
     @property
     def name(self):
         return self._node.name


Test patch:
diff --git a/tests/chainer_tests/test_variable.py b/tests/chainer_tests/test_variable.py
--- a/tests/chainer_tests/test_variable.py
+++ b/tests/chainer_tests/test_variable.py
@@ -88,6 +88,10 @@ def test_attributes_cpu(self):
     def test_attributes_gpu(self):
         self.check_attributes(True)
 
+    def test_uninitialized(self):
+        a = chainer.Variable(None)
+        assert a.xp is np
+
     def check_grad(self, x, xp):
         g = xp.array(x)
         v = chainer.Variable(x)
@@ -366,8 +370,10 @@ def test_to_cpu_from_cpu(self):
     @attr.gpu
     def test_to_cpu(self):
         a = chainer.Variable(cuda.cupy.zeros(3, dtype=np.float32))
+        assert a.xp is cuda.cupy
         a.grad = cuda.cupy.ones_like(a.data)
         a.to_cpu()
+        assert a.xp is np
         np.testing.assert_array_equal(a.data, np.zeros(3, dtype=np.float32))
         np.testing.assert_array_equal(a.grad, np.ones(3, dtype=np.float32))
 
@@ -390,8 +396,10 @@ def test_to_gpu_from_gpu(self):
     def test_to_gpu(self):
         cp = cuda.cupy
         a = chainer.Variable(np.zeros(3, dtype=np.float32))
+        assert a.xp is np
         a.grad = np.ones(3, dtype=np.float32)
         a.to_gpu()
+        assert a.xp is cuda.cupy
         cp.testing.assert_array_equal(a.data, cp.zeros(3, dtype=np.float32))
         cp.testing.assert_array_equal(a.grad, cp.ones(3, dtype=np.float32))
 
@@ -1707,8 +1715,10 @@ def _check_variable_shape_and_dtype(self, var):
 
     def test_cpu_to_intel64(self):
         x = chainer.Variable(self.x_data)
+        assert x.xp is np
         prev_x_data = x.data
         x.to_intel64()
+        assert x.xp is np
 
         # Converted to mdarray only if dtype == float32.
         # Otherwise, data should be left untouched.
Repository: chainer/chainer

Issue:
Inconsistent behavior between `cuda.get_array_module` and `cuda.get_device_from_array`
`cuda.get_array_module` will return correct module even if the input is a chainer `Variable`, however, `cuda.get_device_from_array` will return `DummyDeviceType` if the input is `Variable`.

Though we can still simply use `variable.data` to get the correct results, the ambiguous behavior makes user confused when debugging (at least for me). Thus I think it is better to modify the `cuda.get_device_from_array` to have the similar behavior to `cuda.get_array_module`, i.e., automatically detect the `Variable` as input, and use `variable.data` to get the expected result.

Or at least, we should mention this difference between the two functions.


Discussion:

Resolving patch:
diff --git a/chainer/backends/cuda.py b/chainer/backends/cuda.py
--- a/chainer/backends/cuda.py
+++ b/chainer/backends/cuda.py
@@ -168,8 +168,16 @@ def get_device_from_array(*arrays):
 
     The device on which the given CuPy array reside is returned.
 
+    .. note::
+
+        This method only recognizes :class:`cupy.ndarray`\\ s in arguments.
+        Especially note that, unlike :func:`get_array_module`, this method
+        does not recognize :class:`~chainer.Variable` objects.
+        If you need to get device from the :class:`~chainer.Variable` instance
+        ``v``, you need to use ``get_device_from_array(v.array)``.
+
     Args:
-        array (cupy.ndarray or list of cupy.ndarray):
+        arrays (:class:`cupy.ndarray` or list of :class:`cupy.ndarray`):
             A CuPy array which this function returns the device corresponding
             to. If a list of :class:`cupy.ndarray`\\ s are given, it returns
             the first device object of an array in the list.


Test patch:
Repository: chainer/chainer

Issue:
`import chainer` fails when matplotlib version is old
```
>>> import chainer
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File ".../chainer/__init__.py", line 28, in <module>
    from chainer import training  # NOQA
  File ".../chainer/training/__init__.py", line 2, in <module>
    from chainer.training import extensions  # NOQA
  File ".../chainer/training/extensions/__init__.py", line 30, in <module>
    from chainer.training.extensions.variable_statistics_plot import VariableStatisticsPlot  # NOQA
  File ".../chainer/training/extensions/variable_statistics_plot.py", line 16, in <module>
    _plot_color = matplotlib.colors.to_rgba('#1f77b4')  # C0 color
AttributeError: module 'matplotlib.colors' has no attribute 'to_rgba'
```

It is resolved after upgrading matplotlib.

## Conditions
* chainer: 4.0.0
* matplotlib: 1.5.3




Discussion:

Resolving patch:
diff --git a/chainer/training/extensions/variable_statistics_plot.py b/chainer/training/extensions/variable_statistics_plot.py
--- a/chainer/training/extensions/variable_statistics_plot.py
+++ b/chainer/training/extensions/variable_statistics_plot.py
@@ -13,15 +13,23 @@
 
 try:
     import matplotlib
-    _plot_color = matplotlib.colors.to_rgba('#1f77b4')  # C0 color
-    _plot_color_trans = _plot_color[:3] + (0.2,)  # apply alpha
-    _plot_common_kwargs = {
-        'alpha': 0.2, 'linewidth': 0, 'color': _plot_color_trans}
     _available = True
 except ImportError:
     _available = False
 
 
+if _available:
+    if hasattr(matplotlib.colors, 'to_rgba'):
+        _to_rgba = matplotlib.colors.to_rgba
+    else:
+        # For matplotlib 1.x
+        _to_rgba = matplotlib.colors.ColorConverter().to_rgba
+    _plot_color = _to_rgba('#1f77b4')  # C0 color
+    _plot_color_trans = _plot_color[:3] + (0.2,)  # apply alpha
+    _plot_common_kwargs = {
+        'alpha': 0.2, 'linewidth': 0, 'color': _plot_color_trans}
+
+
 def _check_available():
     if not _available:
         warnings.warn('matplotlib is not installed on your environment, '


Test patch:
Repository: chainer/chainer

Issue:
Favicon for websites
Currently our websites do not have favicons. They should have them.

- [x] [chainer.org](https://chainer.org/)
- [x] [cupy.chainer.org](https://cupy.chainer.org/)
- [ ] [docs.chainer.org](https://docs.chainer.org/)
- [ ] [docs-cupy.chainer.org](https://docs-cupy.chainer.org/)


Discussion:
This issue has been automatically marked as stale because it has not had recent activity. It will be closed after 30 days if no further activity occurs. Thank you for your contributions.

bump
This issue has been automatically marked as stale because it has not had recent activity. It will be closed after 30 days if no further activity occurs. Thank you for your contributions.

bump

Resolving patch:
diff --git a/docs/source/conf.py b/docs/source/conf.py
--- a/docs/source/conf.py
+++ b/docs/source/conf.py
@@ -170,7 +170,7 @@
 # The name of an image file (within the static path) to use as favicon of the
 # docs.  This file should be a Windows icon file (.ico) being 16x16 or 32x32
 # pixels large.
-#html_favicon = None
+html_favicon = '_static/favicon.png'
 
 # Add any paths that contain custom static files (such as style sheets) here,
 # relative to this directory. They are copied after the builtin static files,


Test patch:
Repository: chainer/chainer

Issue:
Required CuPy version specification in the stable version looks incomplete
Current minor versions of Chainer requires CuPy (if installed) older than the unseen next minor version. For example, the recent release of Chainer v3.2.0 requires CuPy <2.3. I think it should be fixed so that 1) it does not allow too old CuPy, and 2) it allows any newer version of CuPy at the same major version.


Discussion:
I'd like to fix this in next release. For Chainer v3.4.0 release, let's use `2.4<=cupy, cupy<2.5`.

Besides that, we are currently not detecting version mismatch caused after installation (i.e., install cupy, install chainer, then upgrade/downgrade cupy). Runtime detection may also be needed.
How about this?

```
For stable branch:
  v4.0.0: `>=4.0.0, <5.0.0`
  v4.1.0: `>=4.1.0, <5.0.0`
  ...
For master branch:
  v5.0.0a1: `==5.0.0a1`
  v5.0.0b1: `==5.0.0b1`
  ...
```

Resolving patch:
diff --git a/setup.py b/setup.py
--- a/setup.py
+++ b/setup.py
@@ -21,7 +21,7 @@
 
 
 def cupy_requirement(pkg):
-    return '{}==4.1.0'.format(pkg)
+    return '{} >=4.1.0, <5.0.0'.format(pkg)
 
 
 requirements = {


Test patch:
Repository: chainer/chainer

Issue:
Document: type specification of arrays
In function documentation, input arrays are described as **"`Variable` or `numpy.ndarray` or `cupy.ndarray`"** ([example](https://docs.chainer.org/en/stable/reference/generated/chainer.functions.squeeze.html)).

Currently we only support those two ndarray types, but we will need to generalize this to support more backend arrays (e.g. iDeep). It would be better to specify types in a general term and describe in detail in another documentation (just like initializer (example: [F.linear](https://docs.chainer.org/en/stable/reference/generated/chainer.links.Linear.html) links to [initializer documentation](https://docs.chainer.org/en/stable/reference/initializers.html))


Discussion:
This issue has been automatically marked as stale because it has not had recent activity. It will be closed after 30 days if no further activity occurs. Thank you for your contributions.

This issue is closed as announced. Feel free to re-open it if needed.


Resolving patch:
diff --git a/chainer/functions/activation/clipped_relu.py b/chainer/functions/activation/clipped_relu.py
--- a/chainer/functions/activation/clipped_relu.py
+++ b/chainer/functions/activation/clipped_relu.py
@@ -129,8 +129,7 @@ def clipped_relu(x, z=20.0):
     .. math:: \\text{ClippedReLU}(x, z) = \\min(\\max(0, x), z).
 
     Args:
-        x (:class:`~chainer.Variable` or :class:`numpy.ndarray` or \
-        :class:`cupy.ndarray`):
+        x (:class:`~chainer.Variable` or `ndarray`):
             Input variable. A :math:`(s_1, s_2, ..., s_n)`-shaped float array.
         z (float): Clipping value. (default = 20.0)
 


Test patch:
Repository: chainer/chainer

Issue:
Document modes of BatchNormalization
Improve documentation on each modes of batch normzalization (train, finetune, test).
Context: #4553


Discussion:

Resolving patch:
diff --git a/chainer/links/normalization/batch_normalization.py b/chainer/links/normalization/batch_normalization.py
--- a/chainer/links/normalization/batch_normalization.py
+++ b/chainer/links/normalization/batch_normalization.py
@@ -21,17 +21,21 @@ class BatchNormalization(link.Link):
 
     In training mode, it normalizes the input by *batch statistics*. It also
     maintains approximated population statistics by moving averages, which can
-    be used for instant evaluation in testing mode.
+    be used for instant evaluation in testing mode. Training mode is enabled
+    when ``chainer.config.train`` is set to ``True`` and :meth:`__call__`
+    is invoked with ``finetune=False`` (the default is False).
 
     In fine-tuning mode, it accumulates the input to compute *population
     statistics*. In order to correctly compute the population statistics, a
     user must use this mode to feed mini-batches running through whole training
-    dataset.
+    dataset. Finetuning mode is enabled when ``chainer.config.train`` is set to
+    ``True`` and :meth:`__call__` is invoked with ``finetune=True``.
 
     In testing mode, it uses pre-computed population statistics to normalize
     the input variable. The population statistics is approximated if it is
     computed by training mode, or accurate if it is correctly computed by
-    fine-tuning mode.
+    fine-tuning mode. Testing mode is enabled when ``chainer.config.train``
+    is set to ``False``.
 
     Args:
         size (int, tuple of ints, or None): Size (or shape) of channel


Test patch:
Repository: chainer/chainer

Issue:
`Chain.children` not returns its children in registered order
## Version
chainer==5.0.0b4

## Problem

In the documentation of `chainer.Chain`, `children` is explained as follows:
```
    The child link is accessible via :meth:`children`
    generator, which returns a generator running through the children in
    registered order.
```

However, `Chain.children` returns its children sorted by their names.

```
    def children(self):
        d = self.__dict__
        for name in sorted(self._children):
            yield d[name]
```

## Cause
I think the documentation is wrong.


Discussion:
I confirmed that this phenomenon is from chainer==v5.0.0b4.

```check.py
import chainer
import chainer.links as L

print(chainer.__version__)


class Model(chainer.Chain):
    def __init__(self):
        super(Model, self).__init__()
        with self.init_scope():
            self.a3 = L.Linear(1, 1)
            self.a1 = L.Linear(1, 1)
            self.a2 = L.Linear(1, 1)


model = Model()
for link in model.children():
    print(link.name)

```
chainer==v5.0.0b4
```b4.py
5.0.0b4
a1
a2
a3
```
chainer==v5.0.0b3
```b3.py
5.0.0b3
a3
a1
a2
```

This is originated from commit 88c1c196. (#5119)
Thanks for reporting. As you suggested, we should update the docs.

It seems we failed to remove the sentence "in registered order" in #2657.
In and after Chainer v2, we are using `set` to keep children, which does not guarantee the order.

Resolving patch:
diff --git a/chainer/link.py b/chainer/link.py
--- a/chainer/link.py
+++ b/chainer/link.py
@@ -760,7 +760,7 @@ class Chain(Link):
     deserialization, and involved in the optimization. The registered link
     is called a child. The child link is accessible via :meth:`children`
     generator, which returns a generator running through the children in
-    registered order.
+    lexical order.
 
     On registration of a child link, its :attr:`~Link.name` attribute is also
     set (or overwritten if the link has already been registered to another


Test patch:
Repository: chainer/chainer

Issue:
PrintHook may fail
* Conditions
```
>>> chainer.print_runtime_info()
Platform: Darwin-17.7.0-x86_64-i386-64bit
Chainer: 5.0.0b4
NumPy: 1.16.0.dev0+591880b
CuPy: Not Available
```
* Code to reproduce
```
>>> x = chainer.Variable(np.random.rand(2, 3).astype('f'))
>>> lstm = chainer.links.LSTM(3)
>>> y = lstm(x)
>>> with chainer.function_hooks.PrintHook():
...     chainer.functions.sum(y).backward()
...
```

* Error messages, stack traces, or logs
```
function	Sum
input data
<variable at 0x1152b3438>
- device: CPU
- backend: <class 'numpy.ndarray'>
- shape: (2, 3)
- dtype: float32
- statistics: mean=-0.08529118, std=0.18154962
- grad: None
function	Sum
input data
(removed)
output gradient
<variable at 0x1152b33c8>
- device: CPU
- backend: <class 'numpy.ndarray'>
- shape: ()
- dtype: float32
- statistics: mean=0.00000000, std=0.00000000
- grad: mean=1.00000000, std=0.00000000
function	BroadcastTo
input data
<variable at 0x1152b3710>
- device: CPU
- backend: <class 'numpy.ndarray'>
- shape: ()
- dtype: float32
- statistics: mean=1.00000000, std=0.00000000
- grad: None
function	LSTM
input data
<variable at 0x1152b3668>
- device: CPU
- backend: <class 'numpy.ndarray'>
- shape: (2, 3)
- dtype: float32
- statistics: mean=0.00000000, std=0.00000000
- grad: None
<variable at 0x1152b3668>
- device: CPU
- backend: <class 'numpy.ndarray'>
- shape: (2, 12)
- dtype: float32
- statistics: mean=0.53247088, std=0.91164017
- grad: None
output gradient
Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
  File "/Users/tos/GitHub/chainer/chainer/variable.py", line 963, in backward
    self._backward_main(retain_grad, loss_scale)
  File "/Users/tos/GitHub/chainer/chainer/variable.py", line 1025, in _backward_main
    hook.backward_preprocess(func, in_data, out_grad_data)
  File "/Users/tos/GitHub/chainer/chainer/function_hooks/debug_print.py", line 87, in backward_preprocess
    self._process(function, in_data, out_grad)
  File "/Users/tos/GitHub/chainer/chainer/function_hooks/debug_print.py", line 77, in _process
    v = variable.Variable(xp.zeros_like(d, dtype=d.dtype))
AttributeError: 'NoneType' object has no attribute 'dtype'
```


Discussion:

Resolving patch:
diff --git a/chainer/function_hooks/debug_print.py b/chainer/function_hooks/debug_print.py
--- a/chainer/function_hooks/debug_print.py
+++ b/chainer/function_hooks/debug_print.py
@@ -73,9 +73,12 @@ def _process(self, function, in_data, out_grad=None):
         if out_grad is not None:
             self._print('output gradient')
             for d in out_grad:
-                xp = cuda.get_array_module(d)
-                v = variable.Variable(xp.zeros_like(d, dtype=d.dtype))
-                v.grad = d
+                if d is None:
+                    v = variable.Variable()
+                else:
+                    xp = cuda.get_array_module(d)
+                    v = variable.Variable(xp.zeros_like(d, dtype=d.dtype))
+                    v.grad = d
                 self._print(v.debug_print())
         if self.flush:
             self.file.flush()


Test patch: