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

Saving array length for undef array issues #47

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

Codyk12
Copy link

@Codyk12 Codyk12 commented Jun 13, 2019

Changed saving format to save array length as item in the sparse dict when writing arrays. Uses the length key while reading the array to allocate the necessary length of the array. Backwards compatible with existing BSON dumps. #8

Codyk12 and others added 2 commits June 13, 2019 18:03
… when writing arrays. Uses the lengthkey while reading the array to allocate the neccessary length of the array. Backwards compatible with existing BSON dumps.
@DilumAluthge
Copy link
Member

This looks fine to me.

@MikeInnes what do you think?

@Codyk12
Copy link
Author

Codyk12 commented Jun 25, 2019

How does this look? @MikeInnes

@freddycct
Copy link

can you merge this pullrequest? FluxML/Flux.jl#737 is broken because of this.

@jondeuce
Copy link

I'm also running into this issue. Would be good to get this merged, if it looks good to @MikeInnes

@AzamatB
Copy link

AzamatB commented Feb 1, 2020

Bump. Was bitten by this

@AzamatB
Copy link

AzamatB commented Feb 1, 2020

Please merge this PR

@DilumAluthge
Copy link
Member

We will need @MikeInnes to review this before it can be merged.

@DilumAluthge
Copy link
Member

Also, @Codyk12 can you rebase on master?

Copy link
Collaborator

@MikeInnes MikeInnes left a comment

Choose a reason for hiding this comment

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

Nice patch, thanks!

Is the length storage just a performance optimisation? I don't think we should do that this way because the low-level read and write code is meant to deal with the pure BSON spec. As it stands the change means that BSON.jl will disagree with other BSON readers about what's in a file.

@@ -2,6 +2,29 @@ using BSON
using Test

roundtrip_equal(x) = BSON.roundtrip(x) == x
function roundtrip_equal(x::AbstractArray)
Copy link
Collaborator

Choose a reason for hiding this comment

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

Special casing roundtrip_equal for just these couple of types seems like it could lead to confusion. I think it'd be better to define an undef_equal(x, y) for arrays and explicitly test undef_equal(BSON.roundtrip(x), x) or similar.

Copy link
Member

Choose a reason for hiding this comment

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

Bump @Codyk12 can you address this comment?

@freddycct
Copy link

freddycct commented Mar 4, 2020

Flux is almost perfect, just waiting on this... @Codyk12 @MikeInnes

without this, adam optim cannot be saved FluxML/Flux.jl#737

@CarloLucibello
Copy link
Collaborator

CarloLucibello commented Apr 21, 2020

Since the problem with saving Adam optimizer was fixed by #70, do we still need this PR?

I guess the answer is yes, it would be generally nice to be able to save undef arrays. @Codyk12 could you address Mike's comment so that we can get this merged?

@DhairyaLGandhi
Copy link
Collaborator

Saving extra metadata which needs to be acted upon while reading means a departure from the specification. We should avoid that.

@DilumAluthge
Copy link
Member

Since the problem with saving Adam optimizer was fixed by #70, do we still need this PR?

I guess the answer is yes, it would be generally nice to be able to save undef arrays. @Codyk12 could you address Mike's comment so that we can get this merged?

Yeah we still need this to be able to save regular Dicts.

@DhairyaLGandhi
Copy link
Collaborator

Regular dicts can be saved fine, the core issue is to be able to express undefs properly

@DilumAluthge
Copy link
Member

Regular dicts can be saved fine, the core issue is to be able to express undefs properly

Ah, I see.

It is good that we are now able to save regular dicts properly.

I think that there is still value in being able to save an array that contains undefined values.

@MikeInnes
Copy link
Collaborator

Note that it's possible for someone to grab the commits here and carry on work in a new PR, which might be a good option if people need the patch soon.

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.

9 participants