Skip to content

Conversation

@KDr2
Copy link
Member

@KDr2 KDr2 commented Dec 29, 2020

No description provided.

Most of the newly added methods are from Tracker.jl's TrackedArray.
src/tarray.jl Outdated
Comment on lines 164 to 168
for F in (:iterate, :eltype, :length, :size,
:firstindex, :lastindex, :ndims, :axes,
:collect)
@eval Base.$F(a::TArray, args...) = $F(get(a), args...)
end
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here, I would assume that ndims and eltype are defined automatically. I think one has only to define size and similar(::TArray, ::Type{T}, dims), and probably should define IndexStyle and axes to exploit the structure of the underlying array. Additionally, maybe length is useful, but it is not needed since the default is length(x) = prod(size(x)). See https://docs.julialang.org/en/v1/manual/interfaces/#man-interface-array for more explanations.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

removed:

  • eltype
  • length
  • ndims
  • collect

src/tarray.jl Outdated
Comment on lines 236 to 242
Base.hcat(x::TArray, rest...) = hcat(get(x), _get.(rest)...) |> localize
Base.hcat(x::AbstractArray, y::TArray, rest...) = hcat(x, get(y), _get.(rest)...) |> localize
Base.vcat(x::TArray, rest...) = vcat(get(x), _get.(rest)...) |> localize
Base.vcat(x::AbstractArray, y::TArray, rest...) = vcat(x, get(y), _get.(rest)...) |> localize
Base.cat(x::TArray, rest...; dims) = cat(get(x), _get.(rest)...; dims = dims) |> localize
Base.cat(x::AbstractArray, y::TArray, rest...; dims) =
cat(x, get(y), _get.(rest)...; dims = dims) |> localize
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am a bit worried that some of these dispatches cause method invalidations (it happened before in MCMCChains).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think in that case the issue was more because we were dispatching on Array instead of AbstractArray, but I may be misremembering.

Comment on lines 147 to 150
function Base.summary(io::IO, x::TArray)
print(io, "Task Local Array: ")
summary(io, get(x))
end
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The default should be fine here, I guess? According to the documentation

  For arrays, returns a string of size and type info, e.g. 10-element
  Array{Int64,1}.

  Examples
  ≡≡≡≡≡≡≡≡≡≡

  julia> summary(1)
  "Int64"

  julia> summary(zeros(2))
  "2-element Array{Float64,1}"

So the default "2-element TArray{Float64,2}" would be consistent with Base.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I overwrote this just to remind the user this is a task-local array, IMHO, it's a trivial improvement, let me know if you strongly think it is not necessary :)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't have a strong opinion here, I mainly thought that the type TArray printed in the summary already contains this information.

Copy link
Member

@yebai yebai left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, @KDr2 - the PR looks good to me. The performance regression between TArray and Array issue likely requires some careful optimisation but can be done in a separate PR as we discussed.

@yebai yebai merged commit fc8afbf into master Jan 5, 2021
@delete-merged-branch delete-merged-branch bot deleted the tarray-api branch January 5, 2021 15:36
@devmotion
Copy link
Member

Maybe it would be nice to separate the implementations for different packages in different files to make the code easier to read. Probably it would be good to add more tests as well. BTW why did the PR re-add a deps folder?

@yebai
Copy link
Member

yebai commented Jan 6, 2021

Probably it would be good to add more tests as well

I should probably wait a bit longer before merging. Overall I think this PR is correct and further improvements can be done in future PRs.

why did the PR re-add a deps folder?

I think the script in deps is only for finding all the functions in standard lib that has at least one of the arguments of type AbstractArrays. This is for ubility purpose and is not actually used by Libtask. @KDr2 Maybe we can move this to src/utilities.jl ?

@devmotion
Copy link
Member

I think the script in deps is only for finding all the functions in standard lib that has at least one of the arguments of type AbstractArrays. This is for ubility purpose and is not actually used by Libtask. @KDr2 Maybe we can move this to src/utilities.jl ?

Ah, I see. Maybe one could just keep it at the top level or in a separate utils directory? I was mainly surprised since I associate the deps folder with building of binary dependencies by BinaryBuilder. Similarly, I would expect all files in src to be included in the Julia package.

@KDr2
Copy link
Member Author

KDr2 commented Jan 7, 2021

OK, I will move it to utils directory.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants