WhereIsAI/github-issue-similarity huggingface dataset:
Issue 1:
interpolate.interp1d returns nan in the following example for me (scipy version is 0.14.0):

In [7]: f = interpolate.interp1d([0, 0, 1], [0, 0, 1], kind='linear')
In [8]: f(0)
/home/jmetzen/.anaconda/lib/python2.7/site-packages/scipy/interpolate/interpolate.py:445: RuntimeWarning: invalid value encountered in true_divide
slope = (y_hi - y_lo) / (x_hi - x_lo)[:, None]
Out[8]: array(nan)

Everything works fine in the case without duplicates:

In [13]: f = interpolate.interp1d([0, 1], [0, 1], kind='linear')
In [14]: f(0)
Out[14]: array(0.0)

Duplicating any other entry besides the minimal one seems to be ok. I guess this is a bug?

Issue 2:
Original ticket http://projects.scipy.org/scipy/ticket/1552 on 2011-11-03 by @pbrod, assigned to unknown.

The following example

import numpy as np
from scipy import stats

np.set_printoptions(precision=4)
print 'true'
print 0.25, 0., 20.0
print 'estimated, floc=0, loc=0'
for i in range(10):
x = stats.lognorm.rvs(0.25, 0., 20.0, size=2000)
print np.array(stats.lognorm.fit(x, floc=0, fscale=20)), \
np.array(stats.lognorm.fit(x, loc=0))

gives the following error

Traceback (most recent call last):
File "<ipython console>", line 3, in <module>
File "C:\Python26\lib\site-packages\scipy\stats\distributions.py", line 1710, in fit
x0, func, restore, args = self._reduce_func(args, kwds)
File "C:\Python26\lib\site-packages\scipy\stats\distributions.py", line 1627, in _reduce_func
del x0[n]
IndexError: list assignment index out of range

This error is easily fixed by replacing:

def _reduce_func(self, args, kwds):
args = list(args)
Nargs = len(args)
fixedn = []
index = range(Nargs)
names = ['f%d' % n for n in range(Nargs - 2)] + ['floc', 'fscale']
x0 = args[:]
for n, key in zip(index, names):
if kwds.has_key(key):
fixedn.append(n)
args[n] = kwds[key]
del x0[n]

with this code:

def _reduce_func(self, args, kwds):
args = list(args)
Nargs = len(args)
fixedn = []
index = range(Nargs)
names = ['f%d' % n for n in range(Nargs - 2)] + ['floc', 'fscale']
x0 = args[:]
for n, key in zip(index[::-1], names[::-1]):
if kwds.has_key(key):
fixedn.append(n)
args[n] = kwds[key]
del x0[n]
Issue 1:
I am try to use RMSPropOptimizer to optimize parameters and I get NotImplementedError. But when I try AdamOptimizer, it works fine.

BTW, when I try to find the problem, it seems I find the key point:

Here is part of my code:

self.x = tf.placeholder(tf.int32, [None, sequence_length])
point = tf.get_variable( [vocabulary_size])
........
........
outputs, states = rnn.rnn(lstm_cell, x_vec, initial_state=initial_state, sequence_length = self.real_length)
index = self.x[:, 0]
index = tf.reshape(index, [-1,1])
index_point = tf.gather(point, index)
output = tf.mul(outputs[-1] , index_point)

The key point is last line output = tf.mul(outputs[-1] , index_point), when I change index_point to some others such as number 1, the error disappear.

And, when I try to use bidirectional_rnn, the error also can disappear.

Issue 2:
I use RMSPropOptimizer to optimize parameters, I get NotImplementedError. But when I change to use AdamOptimizer, it works fine.

So I try to fix the problem and I find some key point, may be it can help.

Here is my code:

self.x = tf.placeholder(tf.int32, [None, sequence_length])
point = tf.get_variable([len(embedding_matrix)])
............
............
outputs, states = rnn.rnn(lstm_cell, x, initial_state=initial_state, sequence_length=real_length)
index = self.x[:, 0]
index = tf.reshape(index, [-1,1])
index_point = tf.gather(pointt, index)
output = tf.mul(outputs[-1] , index_point)

scores = tf.nn.xw_plus_b(output, self.W, b)
losses = tf.nn.softmax_cross_entropy_with_logits(scores, self.input_y)
self.loss = tf.reduce_mean(losses)
optimizer = tf.train.RMSPropOptimizer(1e-3, decay = 0.9)
grads_and_vars = optimizer.compute_gradients(self.loss)
self.train_op = optimizer.apply_gradients(grads_and_vars)

When I try to change the line output = tf.mul(outputs[-1] , index_point) to some others such as output = tf.mul(outputs[-1] , 2), the error disappear. And I try to change to use bidirectional_rnn, the error also disappear.
Issue 1:
Bug report

What is the current behavior?

I have just updated from webpack@4.29.3 to webpack@4.29.4 and I cannot install my modules anymore. I have the following error with @webassemblyjs/wast-parser. It stops installing.

And when cancelling:

If the current behavior is a bug, please provide the steps to reproduce.

Having webpack@4.29.3 and everything working, just delete node_modules and try to install again using webpack@4.29.4.

What is the expected behavior?

To have my modules installed with webpack@4.29.4 as I had with webpack@4.29.3. When installing using webpack@4.29.3, this is the result:

Other relevant information:

webpack version: 4.29.4

Node.js version: 11.10.0

Operating System: Mac OSX

Additional tools: VSCode

Issue 2:
Bug report

This only fails in a docker container during an npm install from my experience, but may just be a low memory failure. Does not fail locally.

What is the current behavior?

npm ERR! Maximum call stack size exceeded`
The command '/bin/sh -c npm install' returned a non-zero code: 1

log from the docker container:

If the current behavior is a bug, please provide the steps to reproduce.

Install docker for mac

create a package.json with version of v4.29.4

create a dockerfile and add latest node node:lts-alpine

assure it runs npm install

What is the expected behavior?

container builds and runs npm install without error

Other relevant information:

webpack version: v4.29.4

Node.js version: v10.13.0 / npm 6.4.1

Operating System: OSX 10.13.4

Additional tools: Docker Version 2.0.0.3
Issue 1:
When compiling the following code:

use std::cell::{RefCell, RefMut};

trait FooTrait {
fn footrait(&mut self);
}

struct Foo;
impl FooTrait for Foo {
fn footrait(&mut self) { () }
}

impl<'a> FooTrait for RefMut<'a, Foo> {
fn footrait(&mut self) { () }
}

struct Bar {
bar: RefCell<Foo>,
}
impl Bar {
fn foobox(&self) -> Box<FooTrait> {
let inner = self.bar.borrow_mut();
Box::new(inner)
}
}

I get the following (confusing) error message:

<anon>:21:30: 21:42 error: cannot infer an appropriate lifetime for autoref due to conflicting requirements
<anon>:21 let inner = self.bar.borrow_mut();
^~~~~~~~~~~~
<anon>:21:21: 21:29 note: first, the lifetime cannot outlive the expression at 21:20...
<anon>:21 let inner = self.bar.borrow_mut();
^~~~~~~~
<anon>:21:21: 21:29 note: ...so that auto-reference is valid at the time of borrow
<anon>:21 let inner = self.bar.borrow_mut();
^~~~~~~~
<anon>:21:21: 21:42 note: but, the lifetime must be valid for the method call at 21:20...
<anon>:21 let inner = self.bar.borrow_mut();
^~~~~~~~~~~~~~~~~~~~~
<anon>:21:21: 21:29 note: ...so that method receiver is valid for the method call
<anon>:21 let inner = self.bar.borrow_mut();
^~~~~~~~

After a lot of trial-and-error I noticed I had to do the following change:

// old:
fn foobox(&self) -> Box<FooTrait> {
// new:
fn foobox<'a>(&'a self) -> Box<FooTrait + 'a> {

Issue 2:
Compiler panics when compiling code that implements a trait for a generic type and a generic type in a vector.

trait MyTrait {
fn foo(&self){}
}
trait OtherTrait {
fn bar(&self){}
}

impl OtherTrait for String {}
impl OtherTrait for Vec<String> {}

impl<T: OtherTrait> MyTrait for T {}
impl<T: OtherTrait> MyTrait for Vec<T> {}

fn main() {
let test_var: Vec<String> = Vec::<String>::new();
test_var.foo();
}

I expected to see this happen: As in 1.0.0-nightly (3e4be02 2015-03-13) (built 2015-03-14), the compiler should catch the conflicting implementations.

Instead, this happened: Compiler panics

Meta

rustc --version --verbose:

rustc 1.0.0-beta (9854143 2015-04-02) (built 2015-04-02)

binary: rustc

commit-hash: 9854143

commit-date: 2015-04-02

build-date: 2015-04-02

host: x86_64-pc-windows-gnu

release: 1.0.0-beta

Error: internal compiler error: coherence failed to report ambiguity: cannot locate the impl of the trait MyTrait for the type collections::vec::Vec<collections::string::String>
Issue 1:
I have 3 monitors. I created a Main layout for my center monitor, and a "communications" for my left monitor, but when I create a "operations" layout for my right hand monitor, it changes the layout of my communications monitor. If I then reset my communications monitor back to its intended layout, the layout of my operations monitor also changes to the communications layout.

Issue 2:
Environment

Windows build number: [Version 10.0.18362.387]
PowerToys version: 0.12.0.0
PowerToy module for which you are reporting the bug (if applicable): FancyZones

Steps to reproduce

I have 2 custom layouts. One for the left monitor, one for the right.

I move the mouse to the left monitor and press [WIN] ~

I choose Custom, and the left layout option.

I click Apply

I move the mouse to the right monitor and press [WIN] ~

I choose Custom, and the right layout option.

I click Apply.

The right monitor layout is applied to all monitors. I have tried also just moving the settings window before hitting apply but that doesn't work either.

I can also use the main settings window, drag to the monitor, change the layout, and the same behavior happens, both monitors are updated.

Expected behavior

Expected to be able to have a separate layout on different monitors.

Actual behavior

Identical layout applied to all monitors.

Screenshots
Issue 1:
Hi,

I updated to version 0.23.0 and all of a sudden the following code breaks:

import pandas as pd
df = pd.DataFrame(data={'date': list(pd.date_range('5.1.2018', '5.10.2018')),
'vals': list(range(10))})
df.groupby([df.date.dt.month, df.date.dt.day])['vals'].sum()

ValueError: Duplicated level name: "date", assigned to level 1, is already used for level 0.

Expected output:

Using version 0.22.0 the same code yields the following:

date date
5 1 0
2 1
3 2
4 3
5 4
6 5
7 6
8 7
9 8
10 9
Name: vals, dtype: int64

It obviously contains duplicated level names. I get why this might be a problem, but as of version 0.23.0 it's not possible to specify the resulting level names.

Issue 2:
Opening a new issue so this isn't lost.

In #18882 banned duplicate names in a MultiIndex. I think this is a good change since allowing duplicates hit a lot of edge cases when you went to actually do something. I want to make sure we understand all the cases that actually produce duplicate names in the MI though, specifically groupby.apply.

In [1]: import dask.dataframe as dd

In [2]: import pandas as pd

In [3]: pdf = pd.DataFrame({'a': [1, 2, 3, 4, 5, 6, 7, 8, 9],
...: 'b': [4, 5, 6, 3, 2, 1, 0, 0, 0]},
...: index=[0, 1, 3, 5, 6, 8, 9, 9, 9]).set_index("a")
...:
...:

In [4]: pdf.groupby(pdf.index).apply(lambda x: x.b)

Another, more realistic example: groupwise drop_duplicates:

In [18]: df = pd.DataFrame({"B": [0, 0, 0, 1, 1, 1, 2, 2, 2]}, index=pd.Index([0, 1, 1, 2, 2, 2, 0, 0, 1], name='a'))

In [19]: df
Out[19]:
B
a
0 0
1 0
1 0
2 1
2 1
2 1
0 2
0 2
1 2

In [20]: df.groupby('a').apply(pd.DataFrame.drop_duplicates)
Out[20]:
B
a a
0 0 0
0 2
1 1 0
1 2
2 2 1

Is it possible to throw a warning on this for now, in case duplicate names are more common than we thought?
Issue 1:
We are having this crash on one of our apps in the Play Store. We are using the Beta 1 version of Flutter. We got 30+ crash reports. It impacts Android 6.0 users only and the most affected device is Grand Prime Plus (grandpplte).

Logs

*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
pid: 0, tid: 0 >>> com.bendingspoons.rized.color.by.number <<<

backtrace:
#00 pc 00000000000431d4 /system/lib/libc.so (tgkill+12)
#01 pc 0000000000040de1 /system/lib/libc.so (pthread_kill+32)
#02 pc 000000000001c7e7 /system/lib/libc.so (raise+10)
#03 pc 0000000000019a65 /system/lib/libc.so (__libc_android_abort+34)
#04 pc 0000000000017600 /system/lib/libc.so (abort+4)
#05 pc 000000000013dca7 /data/app/com.bendingspoons.rized.color.by.number-1/lib/arm/libflutter.so
#06 pc 00000000001e82f9 /data/app/com.bendingspoons.rized.color.by.number-1/lib/arm/libflutter.so
#07 pc 0000000000051b91 /data/app/com.bendingspoons.rized.color.by.number-1/lib/arm/libflutter.so
#08 pc 000000000004f5d3 /data/app/com.bendingspoons.rized.color.by.number-1/lib/arm/libflutter.so
#09 pc 0000000000072f21 /data/app/com.bendingspoons.rized.color.by.number-1/lib/arm/libflutter.so
#10 pc 0000000000059535 /data/app/com.bendingspoons.rized.color.by.number-1/lib/arm/libflutter.so
#11 pc 000000000005bd7b /data/app/com.bendingspoons.rized.color.by.number-1/lib/arm/libflutter.so
#12 pc 00000000000130dd /system/lib/libutils.so (_ZN7android6Looper9pollInnerEi+532)
#13 pc 00000000000131af /system/lib/libutils.so (_ZN7android6Looper8pollOnceEiPiS1_PPv+130)
#14 pc 0000000000084e91 /system/lib/libandroid_runtime.so (_ZN7android18NativeMessageQueue8pollOnceEP7_JNIEnvP8_jobjecti+22)
#15 pc 000000000305b575 /system/framework/arm/boot.oat

Issue 2:
Project Mulligan is affected by this issue.

Steps to Reproduce

Using flutter_driver, attempt to find a Widget by its Material tooltip. Implement this by declaring a dependency upon DefaultMaterialLocalizations and using one of the tooltip strings it defines.

Observe that 'flutter/src/material/material_localizations.dart' depends on 'flutter/src/material/time.dart', which depends on 'dart:ui', which prevents usage in the stand-alone VM.

Using these strings directly to drive the UI from tests is important because it prevents duplication of Flutter string literals within test sources. If string literals were instead used within test sources, automated tests would break if a localizable string in Flutter's Material implementation were to change.

Logs

Unable to spawn isolate: The built-in library 'dart:ui' is not available on the stand-alone VM.

'package:flutter/src/material/time.dart': error: line 5 pos 1: library handler failed

import 'dart:ui' show hashValues;

^
Issue 1:
中文输入法导致 v-model 的值不更新

代码：http://jsbin.com/robetuzuxo/edit?html,js,output

demo: http://output.jsbin.com/robetuzuxo

当用手机浏览器打开 demo 后，点击 input 输入框，切换至中文输入法，随便输入，然后直接点击 submit 按钮（不要点击完成或者 done），发现 v-model 的值没有更新，但是通过原生方法找到 input 的 value，发现 value 值是更新过的，这种情况要怎么处理？目前我们的解决方案是重新封装一个 input component 出来，但是以前的上线的全部业务现在出现这种情况，直接导致业务不可用了. 当然可以使用computed setter getter 解决，但是，由于业务中有大量的表单数据，使用computed改动成本很高. 望尤大能给一个好的解决方案, 谢谢！

Bug:

Chinese input method cause v-model data is not updated.

Code：http://jsbin.com/robetuzuxo/edit?html,js,output

demo: http://output.jsbin.com/robetuzuxo

When you use the mobile browser to open the demo, click the input field input box, switch to the Chinese input method, casually enter, and then click the submit button (do not click Finish or done) and found that the value of v-model is not updated, but found by native method Input value, found that the value is updated, how to deal with this situation? At present our solution is to re-package an input component out, but the previous on-line all the business now this situation, a direct result of the business is not available. Of course, I can use the computed setter getter to solve it, but because of the large number of forms in the business data, solve it with the use of high cost changes. so hope to give a good solution. Thanks.

Issue 2:
test environment

app(or wechat) on iphone

Vue.js version

1.0 version

Reproduction Link

visit the page in wechat on iphone

Steps to reproduce

http://jsbin.com/kiquvesiju/edit?html,js,output

visit the page in wechat on iphone

switch to chinese ime(input method)

input any chinese without entering(hit) "确认/OK" and jump to next input field

Alerted message when hit the "echo a1" button is empty.

What is Expected?

expected echo data is your input message

What is actually happening?

Alerted message when hit the "echo a1" button is empty.
Issue 1:
I think backprop through torch.where is wrong in certain special cases.

To Reproduce

t = 0
x = torch.ones(()).requires_grad_()
y = t * (x / t) # just an example; anything that produces nan's works
z = torch.where(x >= t, x, y)
z.backward()

# the forward pass works fine (the `nan`'s in `y` do not affect z)
# NOTE: this is unlike a naive implement of where that does `cond * x + (1 - cond) * y`
print(z)
# tensor(1., grad_fn=<SWhereBackward>)

# but the backward pass backprops the `nan`'s from y into x, even though the y path is never taken in torch.where
print(x.grad)
# tensor(nan)

Expected behavior

print(x.grad)
# tensor(1.)

This would be the correct gradient.

In practice, this bug can easily happen if one runs the above code for different t (including 0) and assumes that the nan's for t = 0 should not matter because the torch.where always selects the first path that has no nans (and the forward pass does handle it correctly).

Environment

PyTorch Version 1.4

Issue 2:
🐛 Bug

The grad_fn of torch.where returns the gradients of the wrong argument, rather than of the selected tensor, if the other tensor's gradients have infs or nans.

To Reproduce

Run this code:

x = torch.tensor([16., 0.], requires_grad=True)
y = x/2 # tensor([8., 0.], grad_fn=<DivBackward0>)
z = x.sqrt() + 1 # tensor([5., 1.], grad_fn=<SqrtBackward>)

# Calculate dy/dx, dz/dx
dydx = torch.autograd.grad(y.sum(), x, retain_graph=True)[0] # tensor([0.5000, 0.5000])
dzdx = torch.autograd.grad(z.sum(), x, retain_graph=True)[0] # tensor([0.1250, inf])

# Define w = [w0, w1] == [y0, z1]
w = torch.where(x == 0., y, z) # tensor([5., 0.], grad_fn=<SWhereBackward>)
expected_dw_dx = torch.where(x == 0., dydx, dzdx) # tensor([0.1250, 0.5000])
dwdx = torch.autograd.grad(w.sum(), x, retain_graph=True)[0] # is actually tensor([0.1250, inf])
print("`torch.where` communicates gradients correctly:", torch.equal(expected_dw_dx, dwdx))

Expected behavior

I would expect expected_dw_dx == dwdx in the example above.

Environment

Please copy and paste the output from our

environment collection script

(or fill out the checklist below manually).

You can get the script and run it with:

wget https://raw.githubusercontent.com/pytorch/pytorch/master/torch/utils/collect_env.py
# For security purposes, please check the contents of collect_env.py before running it.
python collect_env.py

PyTorch version: 1.1.0

Is debug build: No

CUDA used to build PyTorch: 9.0.176

OS: Ubuntu 18.04.1 LTS

GCC version: (Ubuntu 7.3.0-27ubuntu1~18.04) 7.3.0

CMake version: version 3.10.2

Python version: 3.7

Is CUDA available: Yes

CUDA runtime version: 9.0.176

GPU models and configuration:

GPU 0: Quadro GP100

GPU 1: Quadro GP100

Nvidia driver version: 410.79

cuDNN version: Could not collect

Versions of relevant libraries:

[pip] numpy==1.16.4

[pip] torch==1.1.0

[pip] torchvision==0.3.0

[conda] torch 1.1.0

[conda] torchvision 0.3.0
Issue 1:
The tagline of PyTorch is:

PyTorch is a deep learning framework that puts Python first.

Pip and Pipenv are the quintessential Python package manager tools for Python...

However, upon following the Pip (Python 3.6, OS X) instructions on http://pytorch.org/, I was met with an error informing me I needed Conda. If I don't intend on using R, Fortran, etc. directly in my app, is Conda still an intrinsic requirement of projects like PyTorch that e.g., use Fortran, or could PyTorch be made to install via Pip alone?

If there are low-level system requirements, I (and I think I speak for more than myself) don't mind e.g., brew installing CUDA. IOW, I'd like to be told "look, you need to install Go and CUDA to use this library", and then be given the choice of how I want to install those low-level system requirements and / or tools. Anything else could then be easily installed via e.g., Pipenv, rather than having to install some monolithic system like Conda, which is the antithesis of Python first.

import this

...

There should be one-- and preferably only one --obvious way to do it.

...

If the implementation is hard to explain, it's a bad idea.

...

cc @ezyang @seemethere @malfet

Issue 2:
🐛 Bug

Setting PyTorch default tensor type to cuda.FloatTensor on a Colab GPU instance leads pack_sequence to a Runtime error.

To Reproduce

Steps to reproduce the behavior:

torch.set_default_tensor_type(torch.cuda.FloatTensor)

torch.nn.utils.rnn.pack_sequence([torch.tensor([1,2,3])])

The second statement will throw the following:

RuntimeError Traceback (most recent call last)
<ipython-input-7-054f3bedf067> in <module>()
1 torch.set_default_tensor_type(torch.cuda.FloatTensor)
----> 2 torch.nn.utils.rnn.pack_sequence([torch.tensor([1,2,3])])

1 frames
/usr/local/lib/python3.6/dist-packages/torch/nn/utils/rnn.py in pack_sequence(sequences, enforce_sorted)
377 """
378 lengths = [v.size(0) for v in sequences]
--> 379 return pack_padded_sequence(pad_sequence(sequences), lengths, enforce_sorted=enforce_sorted)

/usr/local/lib/python3.6/dist-packages/torch/nn/utils/rnn.py in pack_padded_sequence(input, lengths, batch_first, enforce_sorted)
231
232 data, batch_sizes = \
--> 233 _VF._pack_padded_sequence(input, lengths, batch_first)
234 return PackedSequence(data, batch_sizes, sorted_indices, None)
235

RuntimeError: 'lengths' argument should be a 1D CPU int64 tensor

Expected behavior

Return the packed sequence without fail.

Environment

A Colab GPU instance.

PyTorch version: 1.4.0

Is debug build: No

CUDA used to build PyTorch: 10.1

OS: Ubuntu 18.04.3 LTS

GCC version: (Ubuntu 7.4.0-1ubuntu1~18.04.1) 7.4.0

CMake version: version 3.12.0

Python version: 3.6

Is CUDA available: Yes

CUDA runtime version: 10.0.130

GPU models and configuration: GPU 0: Tesla T4

Nvidia driver version: 418.67

cuDNN version: /usr/lib/x86_64-linux-gnu/libcudnn.so.7.6.5

Versions of relevant libraries:

[pip3] numpy==1.17.5

[pip3] torch==1.4.0

[pip3] torchsummary==1.5.1

[pip3] torchtext==0.3.1

[pip3] torchvision==0.5.0

[conda] Could not collect

Additional context
Issue 1:
Would it be possible to set up a FancyZone that spans two monitors of the same resolution? There are times, for example, when I want to see as many pages in Word as possible and, since you can't maximise an app across multiple monitors, I have to stretch it to the size I want.

Issue 2:
Summary of the new feature/enhancement

Based on different tasks throughout my day, I would like to use different FancyZone layouts to switch between layouts quickly. As an example the 'productivity layout' would be different from 'Web Meeting' layout , then a 'focused' layout

ideally be able to select multiple fancyzone layouts that can be added to a hotkey to change in between.