-
Notifications
You must be signed in to change notification settings - Fork 2
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
feat: add content types #62
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #62 +/- ##
==========================================
+ Coverage 74.06% 75.29% +1.22%
==========================================
Files 4 4
Lines 1666 1623 -43
==========================================
- Hits 1234 1222 -12
+ Misses 432 401 -31 ☔ View full report in Codecov by Sentry. |
sorry I should have left a comment earlier. I wonder if this is the best way to go about it. I suppose this is a way to fix things, I don't know the performance implication. An alternative way is to fix: AwkwardArray.jl/src/all_implementations.jl Line 101 in d11e61d
by adding one more parametric type into it, so that it can be properly |
yeah looking into it right now, I opened #66 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I'm understanding the eltype
correctly—that it's the type of an element in the array (the return type of getindex
)—then some of these have been set incorrectly. See below.
@@ -9,5 +9,9 @@ include("./tables.jl") | |||
include("./AwkwardPythonCallExt.jl") | |||
using .AwkwardPythonCallExt: convert | |||
|
|||
Base.eltype(::RecordArray{FIELDS,CONTENTS,BEHAVIOR}) where {FIELDS,CONTENTS,BEHAVIOR} = Record{FIELDS,CONTENTS,BEHAVIOR} | |||
Base.eltype(::Record{FIELDS,CONTENTS,BEHAVIOR}) where {FIELDS,CONTENTS,BEHAVIOR} = CONTENTS |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does a Record
(a scalar object, not an array) even have an eltype
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it depends on if you model the Record
as an indexable thing. For me at least, I think event-based table semantically as a row table, so the eltype
is whatever the type an "event" would give you
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure if it makes sense to separate FIELDS
and CONTENTS
, but perhaps there is a usecase for it?
julia> typeof(layout[3])
AwkwardArray.Record{(:a, :b), Tuple{AwkwardArray.PrimitiveArray{Int64, Vector{Int64}, :default}, AwkwardArray.ListOffsetArray{Vector{Int64}, AwkwardArray.PrimitiveArray{Float64, Vector{Float64}, :default}, :default}}, :default}
julia> r = layout[3]
{a: 3, b: [4.4, 5.5]}
julia> eltype(r)
Tuple{AwkwardArray.PrimitiveArray{Int64, Vector{Int64}, :default}, AwkwardArray.ListOffsetArray{Vector{Int64}, AwkwardArray.PrimitiveArray{Float64, Vector{Float64}, :default}, :default}}
Co-authored-by: Jim Pivarski <jpivarski@users.noreply.github.com>
Co-authored-by: Jim Pivarski <jpivarski@users.noreply.github.com>
Co-authored-by: Jim Pivarski <jpivarski@users.noreply.github.com>
Co-authored-by: Jim Pivarski <jpivarski@users.noreply.github.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've added some more tests unrelated to this PR to make the coverage requirement pass.
|
||
function EmptyArray(; behavior::Symbol = :default) | ||
new{behavior}(behavior) | ||
end | ||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jpivarski - I changed that to allow a copy beneath. The need for the behavior::Symbol
showed in a new test.
No description provided.