WhereIsAI/github-issue-similarity huggingface dataset:
Issue 1:
Proposed new feature or change:

One notices that the only Linux wheels provided by numpy on PyPI are manylinux* wheels (glibc-based).

Are there plans/problems regarding musl libc-based wheels? Note that a musl-libc Linux distribution, Alpine,

does provide numpy 1.22, see https://pkgs.alpinelinux.org/packages?name=*numpy*&branch=edge - but

as far as I understand, they build numpy calling python setup.py build, see https://git.alpinelinux.org/aports/tree/community/py3-numpy

for their build script (they use openblas and gfortran) and a small patch they apply.

A naive attempt to build wheels for numpy we tried didn't work with a rather obscure error, see

https://trac.sagemath.org/ticket/33083#comment:46, or

below: #20780 (comment)

Issue 2:
Proposed new feature or change:

CI request: build PEP 656-compliant "musllinux" wheels. This will allow easy installation in Alpine Docker images. Mailing list message
Issue 1:
assignment based on a condition, something like

df[df['column']==1] = 5

raises an exception, so i have to use

df.ix[df['column']==1,'column'] = 5

or iterate through the whole DataFrame.

Issue 2:
In [27]: df
Out[27]:
a b c d
0 2 0.103795 -0.066523 NaN
1 3 -0.939895 -0.208760 NaN
2 9 1.968456 0.419374 NaN
3 6 -0.105170 0.162064 NaN
4 7 0.381707 2.126133 NaN

In [28]: df[df['a']==3]
Out[28]:
a b c d
1 3 -0.939895 -0.20876 NaN

In [29]: df[df['a']==2]
Out[29]:
a b c d
0 2 0.103795 -0.066523 NaN

In [30]: df[df['a']==2] = 100
---------------------------------------------------------------------------
IndexingError Traceback (most recent call last)
/home/adam/code/pandas/<ipython-input-30-f7da2453a9f6> in <module>()
----> 1 df[df['a']==2] = 100

/home/adam/code/pandas/pandas/core/frame.py in __setitem__(self, key, value)
1491 self._boolean_set(key, value)
1492 elif isinstance(key, (np.ndarray, list)):
-> 1493 return self._set_item_multiple(key, value)
1494 else:
1495 # set column

/home/adam/code/pandas/pandas/core/frame.py in _set_item_multiple(self, keys, value)
1516 self[k1] = value[k2]
1517 else:
-> 1518 self.ix[:, keys] = value
1519
1520 def _set_item(self, key, value):

/home/adam/code/pandas/pandas/core/indexing.py in __setitem__(self, key, value)
59 raise IndexingError('only tuples of length <= %d supported',
60 self.ndim)
---> 61 indexer = self._convert_tuple(key)
62 else:
63 indexer = self._convert_to_indexer(key)

/home/adam/code/pandas/pandas/core/indexing.py in _convert_tuple(self, key)
68 keyidx = []
69 for i, k in enumerate(key):
---> 70 idx = self._convert_to_indexer(k, axis=i)
71 keyidx.append(idx)
72 return tuple(keyidx)

/home/adam/code/pandas/pandas/core/indexing.py in _convert_to_indexer(self, obj, axis)
282 elif _is_list_like(obj):
283 if com._is_bool_indexer(obj):
--> 284 objarr = _check_bool_indexer(labels, obj)
285 return objarr
286 else:

/home/adam/code/pandas/pandas/core/indexing.py in _check_bool_indexer(ax, key)
417 mask = com.isnull(result)
418 if mask.any():
--> 419 raise IndexingError('cannot index with vector containing '
420 'NA / NaN values')
421

IndexingError: cannot index with vector containing NA / NaN values
Issue 1:
Usually C bindings requires different calling conventions per platform. For example, linux-32 usually uses cdecl, win-32 uses stdcall, and win-64 uses win64-specific convention.

So if we want to bind a function universally, we have to duplicate extern ... {} block for each platform, e.g.

#[cfg(target_os = "linux")]
extern "cdecl" {
fn func();
...
}
#[cfg(target_os = "win32", target_arch = "x86")]
extern "stdcall" {
fn func();
...
}
#[cfg(target_os = "win32", target_arch = "x86_64")]
extern { // this is identical to extern "C" or extern "cdecl"
fn func();
...
}

which is inconvenient and fragile. (I actually copied large extern blob for Mingw-w64 support (#8488).)

Other option is to generate binding code per platform from template. lifthrasiir/rust-opengles-angle uses the approach for egl binding.

I think it's good to add default calling convention keyword e.g. "platform" so that

extern "platform" {
fn func();
...
}

where "platform" is interpreted as cdecl for linux-32, stdcall for win32, and so on. It would solve the issue for most cases.

EDIT: in irc @luqmana suggested to change extern {} (no abi specified) as platform-native callconv. (It's currently interpreted as "cdecl".) I think it's the best option.

Issue 2:
Consider code like this (playpen):

fn add3<T>(x: i32) -> i32 { x + 3 }

fn main() {
println!("add3(4): {}", add3(4));
}

The Rust compiler currently rejects the above, because it cannot infer what type to assign to the type parameter T in the above invocation add3(4).

The problematic thing is the message:

<anon>:4:29: 4:33 error: unable to infer enough type information about `_`; type annotations or generic parameter binding required [E0282]
<anon>:4 println!("add3(4): {}", add3(4));
^~~~

This message complains about _, rather than referencing the parameter T of fn add3.

It might be nice if, when we encounter this error, if we also did an additional check for the function itself and see if the type parameter in question is unused in the signature of fn add (since in such a situation, there is no way that the callsite will be able to supply the information via type annotation -- the only option is the generic parameter binding form like add3::<(f64,i8)>(4), and it is likely (though not assured) that the actual bug is in the definition of fn add3 itself, rather than at the call site.
Issue 1:
Migrated issue, originally created by charles pierre (@cp2587)

Hello,

Thanks for the fantastic job you did on this library.

I recently came across a shortcoming of the actual psycopg2 library: apparently the executemany function is not optimized at all and just do a loop over execute.

In regard to sqlalchemy, this mean that your recommended way of doing massive insert/update statements is actually really slow when working with psycopg2.

For me, the difference between using execute(insert(), ..) or bulk_insert_mappings (which in the end, just execute a tons of single INSERT statement) and doing .insert().values() (which construct the correct INSERT ... VALUES), was like day and night.

Maybe you could add a warning or note in your documentation regarding the use of psycopg2 in the relevant section of your docs (for instance, here, http://docs.sqlalchemy.org/en/latest/faq/performance.html#i-m-inserting-400-000-rows-with-the-orm-and-it-s-really-slow) ?

Issue 2:
Migrated issue, originally created by Michael Bayer (@zzzeek)

as described at psycopg/psycopg2#491 (comment) we really need a hook to use psycopg2 batch mode so lets get that in.
Issue 1:
I'm submitting a ... (check one with "x")

[x] bug report => search github for a similar issue or PR before submitting
[ ] feature request
[ ] support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question

Current behavior

DatePipe format 'M/d/y hh:mm a' works well in Chrome. But in IE11 / Edge, it produces

the result like '12/17/2016 09:12/17/2016 9:56:15 PM PM'

Expected behavior

It should produces the same result like '2/17/2016 09:55 PM' in IE11 / Edge.

Minimal reproduction of the problem with instructions

https://plnkr.co/edit/9tUUlqvjUxrK0IOTgOgC?p=preview

What is the motivation / use case for changing the behavior?

Please tell us about your environment:

Angular version: 2.0.X

2.3.0

Browser: [all | Chrome XX | Firefox XX | IE XX | Safari XX | Mobile Chrome XX | Android X.X Web Browser | iOS XX Safari | iOS XX UIWebView | iOS XX WKWebView ]

Language: [all | TypeScript X.X | ES6/7 | ES5]

TypeScript

Node (for AoT issues): node --version =

Issue 2:
I'm submitting a ... (check one with "x")

[x] bug report
[ ] feature request
[ ] support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question

Current behavior

When using the date pipe In IE 11.0.9600.18350 with minutes/seconds it shows the whole date instead of the minutes and/or seconds.

Examples:

Date recieved from service | used binding | result

"2016-06-21T10:47:40Z" | {{mydate | date:'HH'}} | ‎12‎:‎00

"2016-06-21T10:47:40Z" | {{mydate | date:'mm'}} | ‎6‎/‎21‎/‎2016‎ ‎12‎:‎47‎:‎40‎ ‎PM

"2016-06-21T10:47:40Z" | {{mydate | date:'ss'}} | ‎6‎/‎21‎/‎2016‎ ‎12‎:‎47‎:‎40‎ ‎PM

"2016-06-21T10:47:40Z" | {{mydate | date:'HH:mm'}} | ‎12‎:‎00:‎6‎/‎21‎/‎2016‎ ‎12‎:‎47‎:‎40‎ ‎PM

"2016-06-21T10:47:40Z" | {{mydate | date:'mm:ss'}} | ‎6‎/‎21‎/‎2016‎ ‎12‎:‎47‎:‎40‎ ‎PM:‎6‎/‎21‎/‎2016‎ ‎12‎:‎47‎:‎40‎ ‎PM

"2016-06-21T10:47:40Z" | {{mydate | date:'HH:ss'}} | ‎12‎:‎00:‎6‎/‎21‎/‎2016‎ ‎12‎:‎47‎:‎40‎ ‎PM

"2016-06-21T10:47:40Z" | {{mydate | date:'HH:mm:ss'}} | ‎‎12‎:‎00:‎6‎/‎21‎/‎2016‎ ‎12‎:‎47‎:‎40‎ ‎PM:‎6‎/‎21‎/‎2016‎ ‎12‎:‎47‎:‎40‎ ‎PM

It seems that the minutes and seconds produce an entire date instead of the desired minutes/seconds.

Expected/desired behavior

The expected behaviour is that mm only returns the minutes and ss only returns the seconds.

Reproduction of the problem

http://plnkr.co/edit/kc8ZEMAvsx1tSbsbXTuv?p=preview

What is the expected behavior?

See above.

What is the motivation / use case for changing the behavior?

Please tell us about your environment:

Angular version: 2.0.0-rc.2 && 2.0.0-rc.3

Browser: [ IE 11.0.9600.18350 && Edge ] this does not occur on the latest versions of Chrome and Firefox. Haven't tested other browsers.

Language: [TypeScript 1.8.10]
Issue 1:
same as #13890

And I have tried tensorflow 1.4.0 , tensorflow 1.4.1 ,tensorflow 1.7 , all of them got a wrong value,and when I use cpu to calculate it ，it returns a right value .

Issue 2:
System information

Have I written custom code (as opposed to using a stock example script provided in TensorFlow): Yes

OS Platform and Distribution (e.g., Linux Ubuntu 16.04): 16.04.LTS

TensorFlow installed from (source or binary): Source

TensorFlow version (use command below): 1.3.0

Python version: 2.7.12

Bazel version (if compiling from source): 0.5.2

CUDA/cuDNN version: 8.0/6.0.21

GPU model and memory: Nvidia Tegra X2

Exact command to reproduce:tf.image.crop_and_resize(raw_sample, boxes, box_ind)

Describe the problem

I'm getting completly different results from tensorflow's function tf.image.crop_and_resize(...) when assigned it to gpu and cpu.

In other words:

-when I run this ops on CPU, I get correct results( I mean, the right crops)

-when I put it on the GPU device I get crops fulled with 0 values.

Source code / logs

Here, you can see a simple use case:

import tensorflow as tf
import numpy as np
import cv2 #Just importing cv2 to read image, you use PIL or anything else to load it

device='gpu'

def img2batch_crops(input_image):
raw_sample_tensor_4d=tf.expand_dims(input_image, 0)

#Setting the size to crop and the final size of cropped images
patches_top=[0,0.5]
patches_bottom =[0.5,0.5]
crop_size = [100,100]
boxes=tf.stack([patches_top, patches_top, patches_bottom, patches_bottom], axis=1)

##Here is the bug:
#When device == 'cpu', I got results
#When device == 'gpu', I got black cropped images( 0 values)
with tf.device('/'+device+':0'):
crops=tf.image.crop_and_resize(raw_sample_tensor_4d, boxes, box_ind=tf.zeros_like(patches_top, dtype=tf.int32), crop_size=crop_size, name="croper")

return crops

def main():

img_data = cv2.imread('image.jpg') #Just loading the image,

print("Shape and type of image input ",img_data.shape, img_data.dtype) #Print the shape and the type of the image, supposed to be a numpy array

raw_image = tf.placeholder(dtype=tf.float32, shape=img_data.shape, name='input_image')

crops = img2batch_crops(raw_image) # Adding ops to the graph

with tf.Session() as sess:
myBatchedImages = sess.run(crops, feed_dict={raw_image:img_data})
cv2.imwrite('result_'+device+'.jpg',myBatchedImages[0]) ## Savej just one cropped image to see how it looks like

main()
Issue 1:
I am using some type definitions that follow the pattern below and that have been compiling up until commit d71af8a

declare module MyModule {
class Foo extends Foo.__Class {}
module Foo {
class __Class {
constructor(x: number, y: number);
}
}
}

After commit d71af8a I'm getting errors like

error TS2506: 'Foo' is referenced directly or indirectly in its own base expression.

Issue 2:
http://typescript.codeplex.com/workitem/1125

Following should be allowed:

interface IFoo {
foo();
}

declare class Foo implements IFoo {}

If abstract classes are added in the future, they would inherit all interface methods as abstract (like in Java).
Issue 1:
Bug report

I find that the polygonOffset do not work if turn logarithmicDepthBuffer on.

I have a model which contains several totally overlapped mesh surface. And I try to use logarithmicDepthBuffer = true to solve it, but no lucky. And I try to use polygonOffset, but it only works when logarithmicDepthBuffer = false.

Is it a bug or just the feature of webglrender?

Three.js version

r117

Browser

Firefox

OS

Server: Ubuntu 18.04.4 LTS

Client: Windows 10

Issue 2:
demo

Turn off logarithmicDepthBuffer and it will display fine.

jsfiddle

logarithmicDepthBuffer : false

logarithmicDepthBuffer : true

Three.js version

[ x ] r114

Browser

All of them

Chrome

OS

All of them

Windows10

Hardware Requirements (graphics card, VR Device, ...)
Issue 1:
I have a header component with a logo image and on chrome visiting other pages does not force the logo image to reload. But on safari, every time I visit a new page all the images including the logo image reload.

I have searched the issues of this repository and believe that this is not a duplicate.

Expected Behavior

For safari to behave the same as chrome.

Current Behavior

Safari will reload the image instead of caching it.

I also get these two errors in the console. Only in safari and not chrome.

[Error] Failed to load resource: the server responded with a status of 404 (Not Found) (_error.js.map, line 0)
[Error] Failed to load resource: the server responded with a status of 404 (Not Found) (_app.js.map, line 0)

Steps to Reproduce (for bugs)

Set up simple next hello world

Create a index.js and about.js

Create a component named header.js with links to index and about and an image

Include header component in index and about pages

Start dev server

Compare between chrome and safari

Your Environment

Tech
Version

next
6.0.0

node
9.8.0

OS
MacOS 10.13.4

browser
Safari 11.1

etc

Issue 2:
I tried firebase examples. https://github.com/zeit/next.js/tree/canary/examples/with-firebase-hosting

firebase deploy works correctly.

But local emulator is broken.

$ firebase serve --only functions,hosting

logs

$ firebase serve --only functions,hosting

=== Serving from '/Users/mz/sandbox/with-firebase-hosting'...

i functions: Preparing to emulate functions.
i hosting: Serving hosting files from: public
✔ hosting: Local server: http://localhost:5000

✔ functions: next: http://localhost:5001/playground-e6572/us-central1/next
[hosting] Rewriting / to local function next
info: User function triggered, starting execution
File: /
info: Execution took 257 ms, finished with status: 'crash'
127.0.0.1 - - [24/Oct/2017:23:44:45 +0000] "GET / HTTP/1.1" 500 99 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.52 Safari/537.36"

I have searched the issues of this repository and believe that this is not a duplicate.

Expected Behavior

Run same with after firebase deploy

Current Behavior

Steps to Reproduce (for bugs)

npm i -g firebase-tools
curl https://codeload.github.com/zeit/next.js/tar.gz/master | tar -xz --strip=2 next.js-master/examples/with-firebase-hosting
cd with-firebase-hosting
npm install
npm run build-all
npm run firebase --only functions,hosting

then open localhost:5000

Context

I want to use next.js with firebase without deploy.

Your Environment

Tech
Version

next
4.1.3

node
6.11.4

OS
OSX

browser
Chrome

etc
Issue 1:
In the cpp backend, undefined Tensors are used to efficiently represent a Tensor full of 0s.

Even though we do support this in many functions, there are a lot that almost never get undefined gradients and are thus not properly implemented:

All the backwards with direct formulas in derivatives.yaml

Most functions in Functions.cpp.

In particular, the assumption that a function with a single output cannot get undefined gradients is not correct.

An example of such issue can be found in #33037 and #32619

cc @ezyang @gchanan @zou3519 @ssnl @albanD @gqchen

Issue 2:
In online hard example mining, it is helpful to know the loss for each instance separately.
Issue 1:
Challenge Name

Target the Parent/Childern of an Element using jQuery

https://www.freecodecamp.com/challenges/target-the-children-of-an-element-using-jquery

Issue Description

The $("#target5").clone().appendTo("#left-well"); is duplicating the target 5 button in the left well.

Browser Information

Browser Name, Version: Chrome 55.0.2883.95 (64-bit)

Operating System: Mac OSx Sierra 10.12.12

Mobile, Desktop, or Tablet: Macbook Pro

Your Code

<script>
$(document).ready(function() {
$("#target1").css("color", "red");
$("#target1").prop("disabled", true);
$("#target4").remove();
$("#target2").appendTo("#right-well");
$("#target5").clone().appendTo("#left-well");
$("#target1").parent().css("background-color", "red");

});
</script>

Screenshot

Issue 2:
Challenge Waypoint: Clone an Element Using jQuery has an issue.

User Agent is: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.73 Safari/537.36.

Please describe how to reproduce this issue, and include links to screenshots if possible.

Issue

I believe I've found bug in the phone simulation in Waypoint: Clone an Element Using jQuery:

I entered the code to clone target5 and append it to left-well, and now I see three target5 buttons in the phone simulator. FCC says my code is correct and advances me to the next challenge. The following challenges also show three target5 buttons:

Waypoint: Target the Parent of an Element Using jQuery

Waypoint: Target the Children of an Element Using jQuery

@qualitymanifest confirms this issue on his Linux box.

My code:

<script>
$(document).ready(function() {
$("#target1").css("color", "red");
$("#target1").prop("disabled", true);
$("#target4").remove();
$("#target2").appendTo("#right-well");
$("#target5").clone().appendTo("#left-well");
});
</script>

<!-- Only change code above this line. -->

<div class="container-fluid">
<h3 class="text-primary text-center">jQuery Playground</h3>
<div class="row">
<div class="col-xs-6">
<h4>#left-well</h4>
<div class="well" id="left-well">
<button class="btn btn-default target" id="target1">#target1</button>
<button class="btn btn-default target" id="target2">#target2</button>
<button class="btn btn-default target" id="target3">#target3</button>
</div>
</div>
<div class="col-xs-6">
<h4>#right-well</h4>
<div class="well" id="right-well">
<button class="btn btn-default target" id="target4">#target4</button>
<button class="btn btn-default target" id="target5">#target5</button>
<button class="btn btn-default target" id="target6">#target6</button>
</div>
</div>
</div>
</div>
Issue 1:
Hi!

I'm trying to run this new Windows Terminal.

After some difficulties and a few attempts I was able to build and deploy the project locally.

«Great! Finally!» I said to myself, just before clicking on the Windows Terminal (Dev Build) in the Start menu...

This was the result: an empty window.

After a few seconds, it simply disappeared and then...

Well... Nothing more!

Here are some useful (hopefully) information about my current system:

Windows 10 1903 Build 18362.175

x64 architecture

Developer mode enabled

Repo version built: v0.2.1715.0 (66cb7c4)

Build with Visual Studio 2019

Built and deployed for x64 architecture

Some time ago, I commented already here (#489 (comment)) explaining the same issue...

But, nobody could help me.

Maybe opening a Issue I will be luckier...

Sorry for the "duplicate"... 😔

Issue 2:
Description of the new feature/enhancement

When opening a new Powershell tab, it seems to use the same PATH that was present when opening Terminal. It would be nice if it used the updated path, like what you'd expect from opening a new tab in Linux.

I just installed node, and was wondering why the node -v command wouldn't work. Opened a regular powershell instance and it worked, which is why I believe it simply stems from Terminal not reloading the PATH.
Issue 1:
Hi, can you add an option to replace the tab name from the full path to a custom string the user can edit?

Thanks, great job

Issue 2:
Summary of the new feature/enhancement

When installing the terminal for the first time, it would be nice if a profile for Bash from Git for Windows would be automatically provided if Git for Windows is installed.

Proposed technical implementation details (optional)

Auto-detect via installer registry keys whether Git for Windows in installed, and if so, add an entry to profiles.json to run Bash from Git for Windows in the terminal app.
Issue 1:
🚀 Feature

All variants of ReplicationPad should accept 0-dim batch size tensors for both forward and backward autograd. Related to #38115

Test code:

def test_ReplicationPad1d_Forward():
z = torch.ones(0,3,10)
m = torch.nn.ReplicationPad1d(3)
m(z)

def test_ReplicationPad1d_Backward():
z = torch.ones(0,3,10)
m = torch.nn.ReplicationPad1d(3)
m(z).sum().backward()

def test_ReplicationPad2d_Forward():
z = torch.ones(0,3,10,10)
m = torch.nn.ReplicationPad2d(3)
m(z)

def test_ReplicationPad2d_Backward():
z = torch.ones(0,3,10,10)
m = torch.nn.ReplicationPad2d(3)
m(z).sum().backward()

def test_ReplicationPad3d_Forward():
z = torch.ones(0,3,10,10,10)
m = torch.nn.ReplicationPad3d(3)
m(z)

def test_ReplicationPad3d_Backward():
z = torch.ones(0,3,10,10,10)
m = torch.nn.ReplicationPad3d(3)
m(z).sum().backward()

Issue 2:
I've found out that gradient of index_select (i..e index_add) behaves non-deterministically - and wrong - on GPU for some rather random conditions. The following code illustrates the problem:

import numpy as np
import torch
from torch.autograd import Variable

def set_seed(seed):
np.random.seed(seed)
torch.manual_seed(seed)
torch.cuda.manual_seed(seed)

def main():
set_seed(1)
cuda = True
n, e, c = 5, 100, 5
input = torch.randn(n,c)
idxn = torch.from_numpy(np.random.randint(n,size=e)) # indices are repeated

if cuda:
input = input.cuda(); idxn = idxn.cuda()

gradsI, gradsS = [], []
N = 4
for i in range(N):
inputv = Variable(input, requires_grad=True)
sel_input = torch.index_select(inputv, 0, Variable(idxn))
sel_input.retain_grad()

# the following computation is one of the "random conditions"
data = [torch.sum(sel_input.narrow(0,0,e//2), 0),
torch.sum(sel_input.narrow(0,e//2,e//2), 0) ]
out = torch.cat(data,0)
out.exp().sum().backward()

gradsI.append(inputv.grad.data.cpu().clone())
gradsS.append(sel_input.grad.data.cpu().clone())

for i in range(N):
for j in range(N):
print(i,j,(gradsI[i]-gradsI[j]).abs().max(), (gradsS[i]-gradsS[j]).abs().max())

If cuda=False, everything works and 0s are printed, i.e. all gradients are equal. However, with cuda on many nonzero differences in gradsI but not in gradsS pop up, sometimes of high magnitude, e.g.:

0 0 0.0 0.0
0 1 1.4411518807585587e+17 0.0
0 2 1.4411518807585587e+17 0.0
0 3 1.4411518807585587e+17 0.0
1 0 1.4411518807585587e+17 0.0
1 1 0.0 0.0
1 2 3.602879701896397e+16 0.0
1 3 0.015625 0.0
2 0 1.4411518807585587e+17 0.0
2 1 3.602879701896397e+16 0.0
2 2 0.0 0.0
2 3 3.602879701896397e+16 0.0
3 0 1.4411518807585587e+17 0.0
3 1 0.015625 0.0
3 2 3.602879701896397e+16 0.0
3 3 0.0 0.0

This indicates that there is something wrong with backward of torch.index_select. Setting torch.set_default_tensor_type('torch.DoubleTensor') doesn't help. Can anybody shed light onto this?