WhereIsAI/github-issue-similarity huggingface dataset:
Issue 1:
Hello

As presented here:

http://stackoverflow.com/questions/38454893/error-in-scipy-wilcoxon-signed-rank-test-for-equal-series?noredirect=1#comment64315624_38454893

(without no answer to disprove it as a mistake from me),

I wish to report that maybe there is a problem with the results of scipy.wilcoxon signed rank test;

import scipy as sp

x1=[29.39958, 29.21756, 29.350915, 29.34911, 29.212635]

sp.wilcoxon(x1,x1,zero_method="wilcox",correction=True)

returns statistic=0.0, pvalue=nan

But with zero_method="pratt", it returns statistic=0.0, pvalue=0.043114446783075355 instead.

I think there is a mistake there. The statistics (for z-score, if I am not mistaken) are the same, but the results are different for the p-value, while they should not, actually.

When both series are identical, there should be no good p-value, but this is confident with alpha=0.05.

Maybe "pratt" zero_method is wrongly implemented. It is said to be more conservative, but instead it has also constantly given better /lower p-values on a large array of test values.

Issue 2:
Hello

As presented here:

http://stackoverflow.com/questions/38454893/error-in-scipy-wilcoxon-signed-rank-test-for-equal-series?noredirect=1#comment64315624_38454893

(without no answer to disprove it as a mistake from me),

I wish to report that maybe there is a problem with the results of scipy.wilcoxon signed rank test;

import scipy as sp

x1=[29.39958, 29.21756, 29.350915, 29.34911, 29.212635]

sp.wilcoxon(x1,x1,zero_method="wilcox",correction=True)

returns statistic=0.0, pvalue=nan

But with zero_method="pratt", it returns statistic=0.0, pvalue=0.043114446783075355 instead.

I think there is a mistake there. The statistics (for z-score, if I am not mistaken) are the same, but the results are different for the p-value, while they should not, actually.

When both series are identical, there should be no good p-value, but this is confident with alpha=0.05.

Maybe "pratt" zero_method is wrongly implemented. It is said to be more conservative, but instead it has also constantly given better /lower p-values on a large array of test values.

edit josef

It looks like there are two issues

corner case when all differences are zero needs special handling to return nan p-value

current implementation of Pratt method is wrong if there are "zeros", if (x == y).sum() > 0
Issue 1:
skipchars took a 5x preformance hit (for the benchmark we have in BaseBenchmarks) presumably after the introduction of locks on the write calls.

Perhaps we can lock outside of the loop and write without a lock and finally unlock it when we are done?

Issue 2:
I'm noticing an order-of-magnitude slowdown in a custom function to parse "sample list" files (one ASCII value per line) to Float32 arrays. Any ideas what could be causing this?

Offending function here: https://github.com/jpjones76/SeisIO.jl/blob/master/src/Utils/Parsing/streams.jl

Affects my ASCII readers for SLIST and Lennartz SLIST files.

Before 1.3.0, X[i] = stream_float(io, 0x00) was 2-3x faster than v = readline(io); X[i] = parse(Float32, v). Now stream_float is 4x slower than readline + parse. I actually need the old speeds if possible, so any alternate syntax suggestions would be welcomed.

MWE

using Pkg; Pkg.add("BenchmarkTools"); Pkg.add("SeisIO")
run(`wget https://github.com/jpjones76/SeisIO-TestData/raw/master/SampleFiles/ASCII/0215162000.c00`)
using BenchmarkTools
import SeisIO:stream_float
io = open("0215162000.c00", "r")
nx = 225000
X = zeros(Float32, nx)
@benchmark (seekstart($io); readline($io); @inbounds for i in 1:$nx; $X[i] = stream_float($io, 0x00); end)

Example outputs follow. I benchmarked this on a Dell laptop running Ubuntu 18.04 (bionic), kernel 5.0.0-37-generic, CPU Intel(R) Core(TM) i7-6820HQ CPU @ 2.70GHz, 16 GB RAM.

Julia 1.0.5

BenchmarkTools.Trial:
memory estimate: 272 bytes
allocs estimate: 2
--------------
minimum time: 25.533 ms (0.00% GC)
median time: 25.701 ms (0.00% GC)
mean time: 25.867 ms (0.00% GC)
maximum time: 30.592 ms (0.00% GC)
--------------
samples: 194
evals/sample: 1

Julia 1.2.0:

memory estimate: 272 bytes
allocs estimate: 2
--------------
minimum time: 24.738 ms (0.00% GC)
median time: 24.850 ms (0.00% GC)
mean time: 24.910 ms (0.00% GC)
maximum time: 27.172 ms (0.00% GC)
--------------
samples: 201
evals/sample: 1

Julia 1.3.0:

BenchmarkTools.Trial:
memory estimate: 272 bytes
allocs estimate: 2
--------------
minimum time: 236.738 ms (0.00% GC)
median time: 237.059 ms (0.00% GC)
mean time: 237.833 ms (0.00% GC)
maximum time: 245.997 ms (0.00% GC)
--------------
samples: 22
evals/sample: 1
Issue 1:
I used time series line chart to display the data trending, but the value was shifted by 1 day, e.g. the value on 2016-05-01 was 23801, but actually the value was plotted on 2016-04-30. Will you help to investigate it or give some suggestions. Thanks a lot.

the data exported by caravel:

the plot actually made by caravel:

Issue 2:
It looks like there's an off by one in the month visualization. If i do this kind of query:

select foo, COUNT(distinct bar) from baz and EXTRACT(month FROM "date") =2 and EXTRACT(year FROM "date") = 2015 group by foobar;

I see the count numbers to match the "2015-01" column while i expect it to be "2015-02" instead. If i export the csv i see data correctly with a "2015-02-01" timestamp.

Reproduced both in 0.9.1 and 0.10.0.
Issue 1:
I have searched the issues of this repository and believe that this is not a duplicate.

I have checked the FAQ of this repository and believe that this is not a duplicate.

Environment

Dubbo version: 2.7.7

Operating System version: Window 64x

Java version: 1.8

Tomcat version: 8.0.11

Steps to reproduce this issue

enable Rest Protocol using <dubbo:protocol name="rest" server="tomcat">, the point is using tomcat as WebContainer;

annotate one service's implementation class with @DubboService(protocol = "rest");

start dubbo container and send one http request to it;

Expected Result

I should get http response by PostMan.

Actual Result

PostMan said : the connection is refused。It seems that the Application never listen on the given port .

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

I have checked the FAQ of this repository and believe that this is not a duplicate.

Environment

Dubbo version: 2.6.5

Operating System version: Windows 10 Pro

Java version: 1.8

Steps to reproduce this issue

See into the logs and always get dubbo=2.0.2 in Url format, wrong? design?

I get below code in Version

// Dubbo RPC protocol version, for compatibility, it must not be between 2.0.10 ~ 2.6.2 public static final String DEFAULT_DUBBO_PROTOCOL_VERSION = "2.0.2"; // Dubbo implementation version, usually is jar version. private static final String VERSION = getVersion(Version.class, "");
Issue 1:
It is similar to issue #9553. rank_filter function gives wrong result if input and output parameters are the same.

Reproducing code example:

import numpy as np
import scipy.ndimage as ndi

a = np.zeros((3,3))
a[:,0] = 1
print(ndi.rank_filter(a, rank=6, size=3, mode='constant'))
print(ndi.rank_filter(a, rank=6, size=3, mode='constant', output=a))

[[0. 0. 0.]
[1. 1. 0.]
[0. 0. 0.]]
[[0. 0. 0.]
[0. 0. 0.]
[0. 0. 0.]]

Scipy/Numpy/Python version information:

import sys, scipy, numpy; print(scipy.__version__, numpy.__version__, sys.version_info)
1.1.0 1.15.4 sys.version_info(major=3, minor=7, micro=1, releaselevel='final', serial=0)

Issue 2:
Maybe the problem is following

...

tmp = grey_erosion(tmp, size, footprint, structure, output, mode, cval, origin)

tmp and input is the same now

so

numpy.subtract(tmp, input, out=tmp)

gives zero

Thank you
Issue 1:
I think some times we need to write things like this, but obviously the auto formatting doesn't support this style well enough (actually it destroys manually formatted code):

promise
.then(() => returnAnotherPromise())
.then(() => {
// do something...
})
.then(() => {
// do some other thing...
});

Because the style below doesn't seem to be acceptable.

promise.then(() => returnAnotherPromise()).then(() => returnAnotherPromise()).then(() => {
//...
});

I find there's quite a lot bugs related to auto formatting, maybe a thorough test procedure should be designed?

Issue 2:
I have the following code:

query(id: number) {
return this.$http
.get('/api/Entity/' + id)
.then(function (data) {
return data.data; // (a)
}); // (b)
}

When I type the semi-colon at point (a), it gets correctly indented. When a type a semi-colon at point (b), both lines get 4 columns to the left, which is the same output when a format the whole document.

I must add it gets on my nerves.

Any way to avoid it? Tks
Issue 1:
Consider:

function foo(x)
y = convert(Vector{Float64},x)
y[1] = 10.0
return y
end
julia> x = [1,2,3]
3-element Array{Int64,1}:
1
2
3

julia> foo(x)
3-element Array{Float64,1}:
10.0
2.0
3.0

julia> x
3-element Array{Int64,1}:
1
2
3

julia> x = [1.,2.,3.]
3-element Array{Float64,1}:
1.0
2.0
3.0

julia> foo(x)
3-element Array{Float64,1}:
10.0
2.0
3.0

julia> x
3-element Array{Float64,1}:
10.0
2.0
3.0

The input is modified in one case, and not the other, which is in the realms of "scary". One (The?) solution is to always do a copy, even if the type matches, for mutable types.

Issue 2:
this is an umbrella issue for tracking known issues with switching to LLVM35 as default. please edit this post or add a comment below. close when someone edits deps/Versions.make to 3.6.0 3.7.0

current known issues:

requires editing deps/Versions.make - #14623

#7910 (upstream patch committed to 3.7 -- only an issue on Mac)

figure out performance regression (perhaps only run passes once (requires writing a TargetMachine wrapper and overloading addPassesToEmitMC) (requires changes to LLVM to expose passes))

requires leaving behind LLVM33

would eliminate content from the "fixed in LLVM 3.5" issue label

#8137

#8999

#9280

#9339 (LLVM36-only issue)

#9967 (fixed in LLVM36)

#10377

#10394

#11085 linalg/arnoldi test on win64

#11083

#10806 (afaict, this is a non-fatal issue in valgrind. jwn)

#11003

#13106 (this issue is a non-fatal performance regression. jwn)

re-disable FPO

related:

#7779 coverage flags are broken with LLVM 3.5 on master

@Keno
Issue 1:
Change cadcd534d525 broke the freebsd-amd64 build:
http://godashboard.appspot.com/log/86327d8b97ad440e9c7edcb115129297adf10d52fbad21ef1aa9d0a8f29f7210

gopack grc _test/http.a _gotest_.6
2011/04/06 07:13:54 http: invalid Content-Length of "intentional gibberish"
sent
--- FAIL: http_test.Test304Responses (0.00 seconds)
expected no TransferEncoding; got [chunked]
got unexpected body "127.0.0.1:32341"
FAIL
gotest: "./6.out -test.short=true -test.timeout=120" failed: exit status 1

Except that test never such a reply, suggesting the Get(ts.URL) in that test is re-using
the DefaultTransport and getting a response from the wrong server. :(

Issue 2:
by zhaihj233:

var base int64 = int64(header.IndexLength + 0x01)
for i := 0; i < int(header.Length); i++ {
mbuffer := make([]byte, indexs[i].length)
f.ReadAt(mbuffer, int64(indexs[i].offset)+base)
}

In this example, f is *os.File which point to a localfile. "indexs" is an
index array which records offset and length of the data in f.

What is the expected output?

mbuffer should be collected by GC.

What do you see instead?

Memory usage continues raising, even adding runtime.GC() can not do any help

Which compiler are you using (5g, 6g, 8g, gccgo)?

8g

Which operating system are you using?

Windows 7 x64

Which version are you using? (run 'go version')

GO VER 1.0.2

Please provide any additional information below.

When compiling the same program with 6g, everything seems to be fine.
Issue 1:
According to the documents, as well as the behavior of previous versions, JULIA_LOAD_PATH shall append to LOAD_PATH instead of replace it, however, with Julia 1.0.1, this is not the case. Below is a minimal example, (julia-1.0 is just an alias to my Juila 1.0.1 installation, I have multiple versions on the system).

$ julia-1.0 -e '@show LOAD_PATH'
LOAD_PATH = ["@", "@v#.#", "@stdlib"]

$ JULIA_LOAD_PATH=/usr/local/julia julia-1.0 -e '@show LOAD_PATH'
LOAD_PATH = ["/usr/local/julia"]

Issue 2:
_
_ _ _(_)_ | A fresh approach to technical computing
(_) | (_) (_) | Documentation: http://docs.julialang.org
_ _ _| |_ __ _ | Type "?help" for help.
| | | | | | |/ _` | |
| | |_| | | | (_| | | Version 0.6.0-dev.1116 (2016-10-25 02:18 UTC)
_/ |\__'_|_|_|\__'_| | Commit 9a2f0f1* (10 days old master)
|__/ | x86_64-pc-linux-gnu

julia> (==).(Real[1],[2])
1-element Array{Real,1}:
false

julia> Real[1].==[2]
1-element BitArray{1}:
false

Shouldn't both return the same type? Preferably a BitArray.
Issue 1:
Hello,

I have the same bug as this user.

https://stackoverflow.com/questions/47423172/tensorflow-why-does-avg-pool-ignore-one-stride-dimension

My version is uo-to-date

Have I written custom code: Yes

OS Platform and Distribution: Linux Mint 18.3, codename "Sylvia"

TensorFlow installed from Tensorflow Website

TensorFlow version 14.1.0

Bazel version N/A

CUDA/cuDNN version N/A

GPU model and memory GeForce 940MX

Exact command to reproduce: see link

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):Linux Ubuntu 16.04

TensorFlow installed from (source or binary): binary (conda-tensorflow-gpu)

TensorFlow version (use command below): b'unknown' 1.3.0

Python version: 3.6

Bazel version (if compiling from source): N/A

GCC/Compiler version (if compiling from source): N/A

CUDA/cuDNN version: 9/7

GPU model and memory: GeForce GTX 1050 Ti

Exact command to reproduce:

import tensorflow as tf

x = tf.get_variable('x', shape=(100, 32, 32, 64),
initializer=tf.constant_initializer(5), dtype=tf.float32)
ksize = (1, 2, 2, 2)
strides = (1, 2, 2, 2)
max_pool = tf.nn.max_pool(x, ksize, strides, padding='SAME')
avg_pool = tf.nn.avg_pool(x, ksize, strides, padding='SAME')
print(max_pool.shape)
print(avg_pool.shape)

The unexpected output is

(100, 16, 16, 32)
(100, 16, 16, 64)

It says here that first and last stride dimension must be 1, but apparently it isn't implemented like this. If this is a feature, there should be consistent behaviour and documentation.

Link to StackOverflow question: https://stackoverflow.com/q/47423172/2397253
Issue 1:
Pedro Santos opened SPR-5120 and commented

The spring scanner functionality do not work when I create my ApplicationContext from a EJB managed by JBoss. I do test the same spring application context on diferents enviroments. Just on a managed EJB on a JBoos it is not workin.

EJB code

appContext = new GenericApplicationContext();

ClassPathBeanDefinitionScanner scanner = new ClassPathBeanDefinitionScanner(appContext);

scanner.scan("com");

appContext.refresh();

Annotated class

@Service

public class TransactionService {

Exception

ERROR: org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean named 'transactionService' is defined

Affects: 2.5.5

Attachments:

jboss-as-sprint-int-5.0.0.GA.jar (35.76 kB)

jboss-spring-int-vfs.jar (14.52 kB)

vfs.patch (12.14 kB)

vfs-fixes-2.patch (15.39 kB)

vfs-fixes-3.patch (15.66 kB)

Issue Links:

#10814 JBoss AS 5.0 VFS handling (SPR-5120) backport 2.5.X ("is depended on by")

#11051 Context Scanning doesnt work in Jboss 5 ("is duplicated by")

#10013 PathMatchingResourcePatternResolver.determineRootDir fails for jar on JBoss

#10454 PersistenceUnitReader#determinePersistenceUnitRootUrl returns wrong root url on JBoss 5, causing no detection of entity beans

Referenced from: commits 184f63f, 10c30f0, 64c46d4

24 votes, 34 watchers

Issue 2:
Anton Oparin opened SPR-9409 and commented

RESTTemplate receives JSON response in ISO-8859-1 encoding, and forwards it to MappingJacksonHttpMessageConverter, which can process only UTF-8 encoding.

Looking at other MessageConverters they use encoding from HttpRequest, which should also be done in MappingJacksonHttpMessageConverter.

From my point of view this should be a part of generic logic, and not to be duplicated in every HttpMessageConverter.

Affects: 3.1.1
Issue 1:
julia> @code_typed true ^ -1
CodeInfo(
1 ─ %1 = Base.slt_int(p, 0)::Bool
└── goto #5 if not %1
2 ─ %3 = Base.not_int(x)::Bool
└── goto #4 if not %3
3 ─ invoke Base.throw_domerr_powbysq(_2::Bool, _3::Int64)::Union{}
└── unreachable
4 ─ nothing::Nothing
5 ┄ %8 = (p === 0)::Bool
│ %9 = Base.or_int(%8, x)::Bool
└── goto #6
6 ─ return %9
) => Bool

# as expected
julia> a = true ^ 1; println(a, " ", typeof(a))
true Bool

# ???
julia> a = true ^ -1; println(a, " ", typeof(a))
1.0 Float64

# strangely, these forms work
julia> a = true ^ Int64(-1); println(a, " ", typeof(a))
true Bool
julia> a = true ^ -Int64(1); println(a, " ", typeof(a))
true Bool

Issue 2:
Cross-posting from discourse: https://discourse.julialang.org/t/incorrect-results-from-which-and-code-warntype-for-literal-powers/2630

I'm trying to use the new literal exponent behavior introduced in #20530 and #20889. I think I'm correctly overloading literal_pow, but various macros like @which, @code_warntype and others all seem to be showing me the wrong behavior.

julia> versioninfo()
Julia Version 0.6.0-pre.alpha.136
Commit 6eeabd8 (2017-03-13 00:18 UTC)
Platform Info:
OS: macOS (x86_64-apple-darwin13.4.0)
CPU: Intel(R) Core(TM) i7-2860QM CPU @ 2.50GHz
WORD_SIZE: 64
BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Sandybridge)
LAPACK: libopenblas64_
LIBM: libopenlibm
LLVM: libLLVM-3.9.1 (ORCJIT, sandybridge)

julia> immutable MyType
x::Int
end

julia> import Base: literal_pow

julia> literal_pow(^, m::MyType, ::Type{Val{p}}) where p = m.x + p
literal_pow (generic function with 6 methods)

julia> m = MyType(1)
MyType(1)

julia> m^2
3

That's all good so far. But none of the introspection macros seem to work for m^2:

julia> @which m^2
^(x, p::Integer) in Base at intfuncs.jl:196

julia> @code_warntype m^2
Variables:
#self#::Base.#^
x::MyType
p::Int64

Body:
begin
return $(Expr(:invoke, MethodInstance for power_by_squaring(::MyType, ::Int64), :(Base.power_by_squaring), :(x), :(p)))
end::Any

julia> @code_lowered m^2
CodeInfo(:(begin
nothing
return (Base.power_by_squaring)(x, p)
end))

julia> using Base.Test

julia> @inferred m^2
ERROR: MethodError: no method matching *(::MyType, ::MyType)
Closest candidates are:
*(::Any, ::Any, ::Any, ::Any...) at operators.jl:424
Stacktrace:
[1] power_by_squaring(::MyType, ::Int64) at ./intfuncs.jl:166
[2] ^(::MyType, ::Int64) at ./intfuncs.jl:196

are the special lowering rules not being applied inside these macros?
Issue 1:
Description

I have the same error as indicated on stack overflow (https://stackoverflow.com/questions/43964166/imp-module-is-deprecated-in-favour-of-importlib)

And, Khushhalm's answer on this page does fix the problem; but I'm wondering if this could be fixed permanently. Thanks.

importing sklearn modules ..

from sklearn.base import BaseEstimator, TransformerMixin

generates this error

/usr/local/lib/python3.6/dist-packages/sklearn/externals/joblib/externals/cloudpickle/cloudpickle.py:47: DeprecationWarning: the imp module is deprecated in favour of importlib; see the module's documentation for alternative uses

Steps/Code to Reproduce

starting the Python terminal and entering the following

from sklearn.base import BaseEstimator, TransformerMixin

generates this error

/usr/local/lib/python3.6/dist-packages/sklearn/externals/joblib/externals/cloudpickle/cloudpickle.py:47: DeprecationWarning: the imp module is deprecated in favour of importlib; see the module's documentation for alternative uses

Expected Results

No error is thrown.

Actual Results

/usr/local/lib/python3.6/dist-packages/sklearn/externals/joblib/externals/cloudpickle/cloudpickle.py:47: DeprecationWarning: the imp module is deprecated in favour of importlib; see the module's documentation for alternative uses

Versions

System

python: 3.6.6 (default, Sep 12 2018, 18:26:19) [GCC 8.0.1 20180414 (experimental) [trunk revision 259383]]

executable: /usr/local/bin/python

machine: Linux-4.4.0-137-generic-x86_64-with-Ubuntu-18.04-bionic

BLAS

macros:

lib_dirs:

cblas_libs: cblas

Python deps

pip: 18.1

setuptools: 39.0.1

sklearn: 0.20.0

numpy: 1.15.2

scipy: 1.1.0

Cython: 0.29

pandas: 0.23.4

Issue 2:
Imagine you had a lot of columns, but that some of those columns never changed or were duplicated due to any number of circumstances. You might not even notice that you have these useless columns. It would be nice to have an optional preprocessing function that warns you about columns that would add no new information to the training, and optionally, trim those columns. Algorithms like build_tree still have to consider those columns, and it gets expensive. Apologies if this is not the place for my comment.
Issue 1:
This is a duplicate of #5662 but I'm still creating this issue as it happens with Angular 2.0 RC1.

Here's the error

Chrome 51.0.2704 (Windows 7 0.0.0): Executed 0 of 3 SUCCESS (0 secs / 0 secs)
Chrome 51.0.2704 (Windows 7 0.0.0): Executed 2 of 3 SUCCESS (0 secs / 0.02 secs)
ERROR: 'Potentially unhandled rejection [2] Failed to load /app/app.component.html (WARNING: non-Error used)'

Issue 2:
Suppose you have this class hierarchy

A

|

B

and A implements OnInit but B does not explicitly declare that it implements OnInit, only that it extends A. Then angular will (incorrectly) not call ngOnInit when it creates an instance of B.
Issue 1:
At the package-level, all (non-imported) identifiers are immediately in package scope
which permits self-referential declarations.

This is important for type declarations; e.g.:

type List struct{
elem int
next *List
}

a) For type declarations, certain recursive constructs would lead to
"infinitely" sized types and are obviously impossible and invalid; e.g.:

type T [n]T
type S struct{field S}
type I interface{I}

The spec should specify the exact rules for these (straight-forward) cases.

b) There are pathological cases of self-referential declarations, typically involving
constant expressions referring used as length value of array declarations, whith the
constant expressopns referring to the yet-to-be declared variable/type. E.g.:

http://play.golang.org/p/h9KlMctIqD
http://play.golang.org/p/Ybsig_M8oF
http://play.golang.org/p/akqH5uMoOD
etc.

(see also issue #7525).

It would be nice if we specify if/how these cases are valid/invalid, or perhaps exclude
them more categorically. While these are all pathological cases, a clear rule would
inform how much effort needs to go into a language implementation/compiler. At this
point, all three front-ends (gc, gccgo. go/types) tend to do different things.

Issue 2:
The spec says "An interface type T may not embed itself or any interface type that
embeds T, recursively.", but nothing like this is mentioned for structs.

(A struct containing itself would obviously need infty memory, but the spec should
probably still explicitly mention that these are illegal while a struct containing a
pointer to itself is fine