WhereIsAI/github-issue-similarity huggingface dataset:
Issue 1:
For smaller size matrix tf.reduce_mean works fine.

But for larger size matrix floating point results are not accurate.

I am running on CUDA 7.0, Titan X.

import tensorflow as tf

mat3 = tf.get_variable("mat3", [4500,4500], initializer=tf.constant_initializer(-1.))
reduce_mat3_ref = tf.reduce_mean(mat3)
with tf.Session('') as sess:
tf.initialize_all_variables().run()
reduce1 = sess.run(reduce_mat3_ref)
print(reduce1) # on CPU this is -1.0, on GPU this produces -1.00006
assert(reduce1 == -1.)

Issue 2:
I'm running Tensorflow 0.9.0 installed from wheel on Python 2.7 on a K40 with CUDA 7.0.

The following test case attempts to minimize the mean of a vector through gradient descent. The script finds that the vectors are equal at all steps, but the means are not. I believe the vectors being equal at all steps is pure numerical luck, since non-deterministic loss likely means non-deterministic gradient which means non-deterministic/reproducible iterative optimization. I've observed cases where training results in different final losses where the only source of non-determinism is from reduce_mean.

import numpy as np
import tensorflow as tf

n_dims = 1000
n_steps = 50

np.random.seed(2016)

vec = tf.Variable(np.random.randn(n_dims).astype(np.float32))
mean = tf.reduce_mean(vec)

optimizer = tf.train.GradientDescentOptimizer(0.01)
train_step = optimizer.minimize(mean)

def generate():
data = []
with tf.Session() as sess:
sess.run(tf.initialize_all_variables())

for _ in xrange(n_steps):
_vec, _mean, _ = sess.run([vec, mean, train_step])
data.append((_vec, _mean))

return [np.array([f[i] for f in data]) for i in xrange(2)]

first_vec, first_mean = generate()
second_vec, second_mean = generate()
print 'vecs equal:', np.all(first_vec == second_vec)

print 'mean equal:', np.all(first_mean == second_mean)
print 'means not equal at idxs:', np.nonzero(first_mean != second_mean)[0]

Example output:

vecs equal: True
mean equal: False
means not equal at idxs: [ 4 5 11 18 34 38 44 49]

From looking through the code, it appears the GPU mean reduction is implemented with GPU sum reduction: https://github.com/tensorflow/tensorflow/blob/master/tensorflow/core/kernels/reduction_ops_gpu.cu.cc#L43

I've confirmed my test case still triggers when I replace "reduce_mean" with "reduce_sum".

The GPU sum reduction appears to be implemented using CUDA's atomicAdd: https://bitbucket.org/eigen/eigen/src/241472d2a52142e23b0b2ba5c301c6c146298fa9/unsupported/Eigen/CXX11/src/Tensor/TensorReductionCuda.h?at=default&fileviewer=file-view-default#TensorReductionCuda.h-97

Atomic floating point adds on GPU are the problem. Having floating point adds to the same address in an undefined order is inherently non-deterministic due to non-associativity of floating point arithmetic.

This issue could be solved (and reduction performance improved) by using some sort of reduction tree to reduce within blocks, and then launching a second kernel (or doing some manual block synchronization tricks) to reduce across blocks.
Issue 1:
Just opening a project in vs 2015 community and that is happening:

The message below: "Output generation canceled"

In VS 2015 RC everything was fine.

Issue 2:
I've tested this on two different machines with vs2015 pro and enterprise versions. 1.5.4 broke the compile on save. ( I didn't touch default settings, compilation type is AMD). When I reverted to 1.5.3 it worked fine again.
Issue 1:
In most Mac applications, pressing Command-E fills the find buffer with the currently selected text. However, in Visual Studio Code, it appears to invoke the Quick Open menu.

Issue 2:
VSCode Version: 1.1.0

OS Version: OSX El Capitan Version 10.11.4

Steps to Reproduce:

Create directory X

In X, create file, test1.cs

Open test1.cs in VS Code

In a terminal, run mv test1.cs ..

Switch to VS Code and edit test1.cs.

VS Code creates test1.cs again rather than raising an error.
Issue 1:
Under certain settings, np.quantile makes mistakes in determining the correct quantile. Is this a bug? In the output, 0.73 means that only 73% of values are larger or equal than the determined quantile; by definition it should be >= 75% for p=0.25.

I know, that I can produce the correct result with np.quantile(x, 0.25, interpolation="lower") = 366, where 26% of values <= 366 and 76% of values >= 366. My point is, the standard version of the method delivers a result that does not fulfill the most general defintion of quantiles.

Reproducing code example:

import numpy as np
x = np.array([374, 358, 341, 355, 342, 334, 353, 346, 355, 344,
349, 330, 352, 328, 336, 359, 361, 345, 324, 386,
334, 370, 349, 327, 342, 354, 361, 354, 377, 324])

q = np.quantile(x, 0.25)

print(q)

print(len(x[x<=q]) / len(x))

print(len(x[x>=q]) / len(x))

Numpy/Python version information:

337.25

0.26666666666666666

0.7333333333333333

Issue 2:
Under certain settings, np.quantile makes mistakes in determining the correct quantile. Is this a bug? In the output, 0.73 means that only 73% of values are larger or equal than the determined quantile; by definition it should be >= 75% for p=0.25.

I know, that I can produce the correct result with np.quantile(x, 0.25, interpolation="lower") = 366, where 26% of values <= 366 and 76% of values >= 366. My point is, the standard version of the method delivers a result that does not fulfill the most general defintion of quantiles.

Reproducing code example:

import numpy as np
x = np.array([374, 358, 341, 355, 342, 334, 353, 346, 355, 344,
349, 330, 352, 328, 336, 359, 361, 345, 324, 386,
334, 370, 349, 327, 342, 354, 361, 354, 377, 324])

q = np.quantile(x, 0.25)

print(q)

print(len(x[x<=q]) / len(x))

print(len(x[x>=q]) / len(x))

Numpy/Python version information:

337.25

0.26666666666666666

0.7333333333333333
Issue 1:
Currently the standard library has no incomplete Beta function, or its logarithm:

log(B(\alpha, \beta, x))

which can be useful in some applications.

Issue 2:
After upgrading to Julia 1.7.0, interrupting scripts using Ctrl+C does not work anymore. Instead, julia seems to interrupt running calculations (the CPU usage drops to zero) and then hangs indefinitely.

This used to work up to Julia 1.6, with or without multi-threading.

Attaching gdb to the julia process and running a backtrace reveals:

Thread 1:

#0 0x00007fb6601998ca in __futex_abstimed_wait_common64 () from /usr/lib/libpthread.so.0
#1 0x00007fb660193270 in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0
#2 0x00007fb65f4720bd in usr2_handler (sig=12, info=<optimized out>, ctx=0x7fb6551aaac0)
at /buildworker/worker/package_linux64/build/src/signals-unix.c:476
#3 <signal handler called>
(...)

Thread 2:

#0 0x00007fb660196600 in __lll_lock_wait () from /usr/lib/libpthread.so.0
#1 0x00007fb66018f503 in pthread_mutex_lock () from /usr/lib/libpthread.so.0
#2 0x00007fb65f470ef2 in jl_thread_suspend_and_get_state (tid=tid@entry=0, ctx=ctx@entry=0x7fb65a280c48)
at /buildworker/worker/package_linux64/build/src/signals-unix.c:371
#3 0x00007fb65f47163b in jl_exit_thread0 (bt_data=0x7fb65fab3340 <bt_data>, bt_size=26, state=130)
at /buildworker/worker/package_linux64/build/src/signals-unix.c:440
#4 signal_listener (arg=<optimized out>) at /buildworker/worker/package_linux64/build/src/signals-unix.c:843
(...)

Threads 3 to 12:

#0 0x00007fb6601998ca in __futex_abstimed_wait_common64 () from /usr/lib/libpthread.so.0
#1 0x00007fb660193270 in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0
#2 0x00007fb647f165db in blas_thread_server () from /opt/julia-1.7.0/bin/../lib/julia/libopenblas64_.so
#3 0x00007fb66018d259 in start_thread () from /usr/lib/libpthread.so.0
#4 0x00007fb6600b65e3 in clone () from /usr/lib/libc.so.6

From a quick glance there seems to be some sort of deadlock going on.

Note however that I have not started the script with multiple threads (I have neither set JULIA_NUM_THREADS nor passed a -t argument).

Julia version: 1.7.0 (from official sources) on x86_64

Arch Linux with glibc 2.33-5
Issue 1:
I have searched the issues of this repository and believe that this is not a duplicate.

Context

Kept getting a store.runSagaTask is not a function error after copying the next-redux-saga example. Then I discovered the next-redux-saga repo has different code for store.js:

- store.sagaTask = sagaMiddleware.run(rootSaga)
+ store.runSagaTask = () => {
+ store.sagaTask = sagaMiddleware.run(rootSaga)
+ }
+
+ // run the rootSaga initially
+ store.runSagaTask()

Would it be all right if I opened a PR with that change?

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

Expected Behavior

Navigating to another non-built page should navigate after page has built successfully.

Current Behavior

Navigating to another non-built page reloads the page after intended page has built successfully. Clicking to navigate again after the intended page has been built, correctly routes to the page.

Context

Just more of a pain in development because we aren't sure that it isn't happening in a production build without double checking every time.

I am running a custom express server with custom document and app.

Your Environment

Tech
Version

next
v6

node
v9.11.1

OS
Windows 10

browser
Chrome 66

etc
Issue 1:
System info

Playwright Version: [v1.31.1]

Operating System: [All, Windows 11, Ubuntu 20, macOS 13.2, etc.]

Browser: [Chromium]

Other info: Element - scroll into view is always used, it should be

Expected

Screenshot of element - scroll into view is always used, so if you use hover the element, it scrolled and hover is sometimes lost (highcharts.js). It would be great to have options if you want scroll or not. - There is a workaround to get screenshot of whole page and then crop it

Actual

Scroll into view is always used and sometimes it is not requested behavior

Issue 2:
System info

Playwright Version: [v1.35.0]

Operating System: [Windows 10 pro]

Browser: [Chromium (Edge)]

Other info: node 16.19

Source code

[ X ] I provided exact source code that allows reproducing the issue locally.

Seems not linked to particular test code

Config file

default config file with only edge activated

// playwright.config.ts
{
name: 'Microsoft Edge',
use: { ...devices['Desktop Edge'], channel: 'msedge' },
}

Test file (self-contained)

The example.spec.js example file will do fine

test('has title', async ({ page }) => {
await page.goto('https://playwright.dev/');

// Expect a title "to contain" a substring.
await expect(page).toHaveTitle(/Playwright/);
});

Steps

npm playwright test --ui

Expected

The ui open up to launch the tests

Actual

Error

Error: spawn UNKNOWN at ChildProcess.spawn (node:internal/child_process:420:11) at Object.spawn (node:child_process:733:9) at launchProcess ([Project path]\node_modules\playwright-core\lib\utils\processLauncher.js:94:39) at Chromium._launchProcess ([Project path]\node_modules\playwright-core\lib\server\browserType.js:179:50) at processTicksAndRejections (node:internal/process/task_queues:96:5) at Chromium._innerLaunch ([Project path]\node_modules\playwright-core\lib\server\browserType.js:103:9) at Chromium._innerLaunchWithRetries ([Project path]\node_modules\playwright-core\lib\server\browserType.js:84:14) at ProgressController.run ([Project path]\node_modules\playwright-core\lib\server\progress.js:92:22) at Chromium.launchPersistentContext ([Project path]\node_modules\playwright-core\lib\server\browserType.js:75:21) at openTraceViewerApp ([Project path]\node_modules\playwright-core\lib\server\trace\viewer\traceViewer.js:145:19) at showTraceViewer ([Project path]\node_modules\playwright-core\lib\server\trace\viewer\traceViewer.js:40:3) at UIMode.showUI ([Project path]\node_modules\@playwright\test\lib\runner\uiMode.js:125:5) at runUIMode ([Project path]\node_modules\@playwright\test\lib\runner\uiMode.js:222:3) at Runner.uiAllTests ([Project path]\node_modules\@playwright\test\lib\runner\runner.js:101:12) at runTests ([Project path]\node_modules\@playwright\test\lib\cli.js:129:55) at qr.<anonymous> ([Project path]\node_modules\@playwright\test\lib\cli.js:40:7) { errno: -4094, code: 'UNKNOWN', syscall: 'spawn' }

Everything works fine with the following commands

npx playwright test npm playwright test --headed
Issue 1:
I currently have these in my user keybindings.json:

[
{ "key": "ctrl+down", "command": "editor.action.moveLinesDownAction",
"when": "editorTextFocus" },
{ "key": "ctrl+up", "command": "editor.action.moveLinesUpAction",
"when": "editorTextFocus" }
{ "key": "ctrl+i", "command": "expandLineSelection",
"when": "editorTextFocus" },
]

ctrl+up and ctrl+down are standard are used in atom (similar product to vscode) and used as ctrl+shift+up and ctrl+shift+down in sublime text. Any chance these can at least be bound to something?

Also regarding ctrl+l, it is the default for selecting a line in atom editor as well as sublime text. Could this be changed from ctrl+i to match this?

Issue 2:
VSCode Version:1.2

OS Version: Windows10 Chinese Language

Steps to Reproduce:

`Ctrl + `` to open Intergrated Terminal

ipconfig show ipaddress
Issue 1:
See:

This could be confusing to newcomers, who may misinterpret this as julia calling python these python function.

Issue 2:
Hi guys,

I was implementing a algorithm, comparing to MATLAB version, and I found a very strange behavior in Julia. I need to perform the following multiplication:

4.604716014154575e-19*(10000000000)^2 = -46.047160141545149

First, I was using the ^, but it was providing a wrong answer:

julia> 4.604716014154575e-19*10000000000^2
3.5761512189350633

If I drop the ^ and multiply two times, then the result is correct:

julia> 4.604716014154575e-19*10000000000*10000000000
46.04716014154576

I tested it in Julia v0.6.2 and v0.6.3 in macOS and Linux with the same behavior. I think the operation 10000000000^2 is overflowing Int64 and with ^ this is computed first. On the other hand, using the multiplication, the first operation is 4.604716014154575e-19*10000000000, which does not cause any overflow.

However, I think Julia should be able to handle that just as MATLAB can. At least a warning about the overflow should be printed. Otherwise, sometimes can be very difficult to debug this. What do you think?
Issue 1:
Hi, I seem to be running into a Flask specific issue, here are the details:

operating system:

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 14.04.1 LTS
Release: 14.04
Codename: trusty

structure of package:

$ tree pantry
pantry
├── db.py
├── __init__.py
├── models
│ ├── food.py
│ └── __init__.py
└── run.py

The __init__.py files are empty.

error received:

$ pwd
/home/sam

$ python3.4 -m pantry.run
* Running on http://127.0.0.1:5000/
* Restarting with reloader
Traceback (most recent call last):
File "/home/sam/pantry/run.py", line 2, in <module>
from pantry.models.food import Food
ImportError: No module named 'pantry'

db.py:

from flask.ext.sqlalchemy import SQLAlchemy

db = SQLAlchemy()

food.py

from pantry.db import db

class Food(db.Model):

id = db.Column(db.Integer, primary_key=True)
name = db.Column(db.String(80), unique=True)
amount = db.Column(db.Integer, unique=False)

def __repr__(self):
return '<Food %r>' % self.name

run.py

from flask import Flask, jsonify
from pantry.models.food import Food
from pantry.db import db
import json

app = Flask(__name__)
app.config['SQLALCHEMY_DATABASE_URI'] = 'sqlite:////tmp/test.db'
db.init_app(app)

@app.route('/food', methods=['GET'])
def list_food():
items = []
for food in Food.query.all():
item = {
"name": food.name,
"amount": food.amount,
}
items.append(item)
return jsonify(items)

if __name__ == '__main__':
app.run(debug=True)

Issue 2:
See Kozea/WeasyPrint#133

What’s going on is:

python -m weasyprint.navigator is run

[sys.executable] + sys.argv is ['…/python', '…/weasyprint/navigator.py']

The reloader spawns a subprocess that way

The child process does not have -m, so Python add’s the .py file’s parent directory to sys.path

Werkzeug tries to import stdlib’s html.entities

This incorrectly imports weasyprint/html.py

Stuff breaks

Nobody here is doing anything obviously wrong. How do you suggest dealing with this situation? What do you think of having …/weasyprint/navigator.py (which is expected to be mostly used with python -m) remove its parent directory from sys.path if it’s there?
Issue 1:
Consider the following example (live at http://www.webpackbin.com/Vk0Q_FqmZ with React 15.0.1):

const MySelect = (props) => (
<select value={this.props.value} onChange={this.props.onChange}>
<option value="fruit">banana</option>
<option value="vegetable">broccoli</option>
<option value="fruit">orange</option>
<option value="vegetable">tomato</option>
</select>
);

class App extends React.Component {
constructor() {
super()
this.state = {}
this.onSelectChange = this.onSelectChange.bind(this)
}

onSelectChange(e) {
this.setState({ selectedValue: e.target.value })
}

render() {
return <MySelect
value={this.state.selectedValue}
onChange={this.onSelectChange}
/>
}
}

HTML itself doesn't seem to have any problems with duplicate values in the <select> tag. As you can see in the example above, there are semantically valid reasons you might want to do this.

But this controlled component example makes it impossible to select e.g. "orange" or "tomato": the selection will be forced to the first matching value.

I thought about a solution that stores both the selectedValue and the selectedIndex, but react-dom's <select> does not take any sort of index prop, so I'd have to manipulate the internal DOM node, which I'm sure is bad form.

React could be enhanced to take a selectedIndex, but I foresee problems with single source of truth.

The fruit/vegetable example is a bit contrived, and there may not be many real-world scenarios you would want to do this in. My gut feeling is this should be a warning so developers (like me) don't paint themselves into a corner trying to support this case.

Issue 2:
It seems the ref callback isn't behaving as I expected it to, based on the docs.

The docs say that ref is called when the component is mounted (and all the other times it's called, it's called with null as a parameter). However, when I put a console.log in componentDidMount, and one in the ref callback, the one in the ref callback is called on every render(), whereas the componentDidMount is only called once. The component i'm reffing isn't even changing props.

Am I misunderstanding something? I'm using React 0.14.

var Value = React.createClass({
componentDidMount() {
console.log("Mounted");
},
render() {
return <div>Dummy</div>;
}
});

var Hello = React.createClass({
getInitialState() {
return { value: 0 };
},

componentDidMount () {
setInterval(() => { this.setState({value: this.state.value + 1})}, 1000);
},

render: function() {
return (
<div>
<span>{this.state.value}</span>
<Value ref={(e) => { if (e) { console.log("ref", e); }}} />
</div>
);
}
});

ReactDOM.render(<Hello/>, document.getElementById('container'));
Issue 1:
I get clipping errors when I use fill_between(), set ylim such that not all of the graph is inside the plotting area, and export to PGF. See code below:

Python:

import numpy as np
from matplotlib import pyplot as plt

np.random.seed(3)
n = 100
m = np.random.random(n)
M = m + np.random.random(n)
M[80] = 3
plt.fill_between(np.arange(n), m, M)
plt.ylim(0,2.1)
plt.savefig('test.pgf')

LaTeX:

\documentclass{standalone}
\usepackage{tikz}
\begin{document}
\input{test.pgf}
\end{document}

System:

matplotlib: 1.3.1

Python: 2.7.6

numpy: 1.8.2

OS: 64bit Linux (Ubuntu 14.04.1)

Issue 2:
It appears that when there is a path outside the plotting limits then not all the path coordinates get plotted. When I run the code below with xmax=1.1 versus xmax=1.0, the axvspan is plotted wrong in latex. Inspection of the pgf file for the two versions of xmax indicates that a \pgfpathlineto command is missing in the xmax=1.1 version. I've traced it to _print_pgf_path() in the backend and the line for points, code in path.iter_segments(transform, clip=clip): which is asking for clipped points.

Python Code

import matplotlib.pyplot as plt

fig = plt.figure()
ax = fig.add_subplot(111)

ax.plot([0,1],[0,1],'-k')
ax.set_xlim(0,1)
ax.axvspan(xmin=0.5, xmax=1.1)

fig.savefig('test.pgf')

Latex code

\documentclass {article}
\usepackage{pgf}

\begin{document}
\begin{figure}
\centering
\input{test.pgf}
\end{figure}
\end{document

Here is a pic of the result after compiled with latex (pdflatex or xelatex)

However, saving to .pdf produces the right result
Issue 1:
julia> versioninfo()
Julia Version 1.6.0-DEV.1537
Commit c36cf8cbc1 (2020-11-20 21:16 UTC)
Platform Info:
OS: Linux (x86_64-linux-gnu)
CPU: Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz
WORD_SIZE: 64
LIBM: libopenlibm
LLVM: libLLVM-11.0.0 (ORCJIT, skylake)
Environment:
JULIA_NUM_THREADS = 4

I have a terminal with solarized colorscheme, and in 1.6.0 stacktrace is unreadable.

I've tried to circumvent it with overriding :light_black color in startup.jl

atreplinit() do repl
try
Base.text_colors[:light_black] = Base.text_colors[241]
catch
end
end

But it helped only partially. Now I can see most of the messages except the number of the line where an error has happened.

Issue 2:
That's how it looks in my terminal, can read the text only after highlighting them!

The color of the text is gray!
Issue 1:
I don't know why I cannot cast FooBar back to Foo or Bar.

I tried this code:

trait Foo {}

trait Bar {}

trait FooBar: Foo + Bar {}

impl <T: Foo + Bar> FooBar for T {}

struct A;

impl Foo for A {}
impl Bar for A {}

fn test(fb: &FooBar) -> &Foo {
fb as &Foo
}

fn main() {
let a = A;
test(&a);
}

I expected it to compile.

Instead, this happened:

<anon>:15:5: 15:15 error: cast to fat pointer: `&FooBar` as `&Foo`
<anon>:15 fb as &Foo
^~~~~~~~~~
error: aborting due to previous error
playpen: application terminated with error code 101

Meta

I used playpen with the stable channel.

Issue 2:
This is using "rustc 1.0.0-nightly (458a6a2 2015-01-25 21:20:37 +0000)".

Code:

#![start]
#[no_mangle]
fn main() {}

Command line:

rustc test.rs

Error:

test.rs:1:1: 1:10 warning: unused attribute, #[warn(unused_attributes)] on by default
test.rs:1 #![start]
^~~~~~~~~
rustc: /home/rustbuild/src/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/llvm/include/llvm/Support/Casting.h:237: typename llvm::cast_retty<X, Y*>::ret_type llvm::cast(Y*) [with X = llvm::Function; Y = llvm::Value; typename llvm::cast_retty<X, Y*>::ret_type = llvm::Function*]: Assertion `isa<X>(Val) && "cast<Ty>() argument of incompatible type!"' failed.
Aborted