Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Type does not equal itself? #32135

Closed
ChrisRackauckas opened this issue May 24, 2019 · 6 comments
Closed

Type does not equal itself? #32135

ChrisRackauckas opened this issue May 24, 2019 · 6 comments
Labels
bug Indicates an unexpected problem or unintended behavior compiler:inference Type inference types and dispatch Types, subtyping and method dispatch

Comments

@ChrisRackauckas
Copy link
Member

From SciML/OrdinaryDiffEq.jl#737, https://travis-ci.org/JuliaDiffEq/OrdinaryDiffEq.jl/jobs/536089349#L808,

TypeError: in new, expected NTuple{49,Int64}, got NTuple{49,Int64}

Cannot reproduce locally, just on Travis. I am lost, because I used to believe that T == T for all types 😅 .

@iamed2
Copy link
Contributor

iamed2 commented May 24, 2019

This is called by https://github.com/JuliaArrays/StaticArrays.jl/blob/master/src/convert.jl#L4 so it might be some issue with Tuple{Vararg{Int64, 49}} vs NTuple{49, Int64}?

@JeffBezanson
Copy link
Member

Tuple{Vararg{Int64, 49}} is === to NTuple{49, Int64}. This seems more like some kind of data corruption.

@StephenVavasis
Copy link
Contributor

This may be unrelated, but I recently encountered an error message that a function expected a SparseMatrixCSC{Float64,Int} but received a SparseMatrixCSC{Float64,Int} instead. After some digging, I concluded that the JLD2 package was assigning the wrong type (even though the name was correct) to an object read from a JLD2 file. The workaround was to issue the commands using SparseArrays and import SparseArrays.SparseMatrixCSC before loading any modules (i.e., at the beginning of the script).

@timholy
Copy link
Member

timholy commented Jun 2, 2019

It is unrelated.

JLD2 will create a new type, with the same name, if it doesn't know the official one. That way you can at least load the data. JLD has addrequire, adding that to JLD2 might eliminate such problems, as long as the person saving the file remembers to use it.

@KristofferC
Copy link
Member

Another case where something like this happened (PkgEval for 1.3-RC3):

history_recorder: Test Failed at /root/.julia/packages/POMDPSimulators/61Pgi/test/test_history_recorder.jl:145
  Expression: exception(exhist) !== nothing
   Evaluated: nothing !== nothing
Stacktrace:
 [1] top-level scope at /root/.julia/packages/POMDPSimulators/61Pgi/test/test_history_recorder.jl:145
 [2] include at ./boot.jl:328 [inlined]
 [3] include_relative(::Module, ::String) at ./loading.jl:1105
 [4] include(::Module, ::String) at ./Base.jl:31
 [5] include(::String) at ./client.jl:432
 [6] top-level scope at /root/.julia/packages/POMDPSimulators/61Pgi/test/runtests.jl:19
 [7] top-level scope at /workspace/srcdir/julia/usr/share/julia/stdlib/v1.3/Test/src/Test.jl:1107
 [8] top-level scope at /root/.julia/packages/POMDPSimulators/61Pgi/test/runtests.jl:19

@KristofferC KristofferC added the bug Indicates an unexpected problem or unintended behavior label Sep 23, 2019
@StefanKarpinski StefanKarpinski added compiler:inference Type inference types and dispatch Types, subtyping and method dispatch labels May 10, 2021
@vtjnash
Copy link
Member

vtjnash commented Mar 29, 2022

Possibly fixed by #32605

@vtjnash vtjnash closed this as completed Mar 29, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Indicates an unexpected problem or unintended behavior compiler:inference Type inference types and dispatch Types, subtyping and method dispatch
Projects
None yet
Development

No branches or pull requests

8 participants