-
Notifications
You must be signed in to change notification settings - Fork 370
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
@views annotation affect how elements are printed #1893
Comments
The quick solution: please use Regarding the core of the problem I will have to discuss it with @mbauman (I hope I will get a chance to do this). Essentially Base now disallows the following:
In data frames we allow it:
I am not clear which is better (but this is related to other 0-dimensional broadcasting cases that were uncovered here #1890). The fix is easy and quick to do (so hopefully all can be cleaned up during JuliaCon and a patch release tagged), but I want to make an informed decision before I move forward. |
Thanks @bkamins ! In fact, in my specific case, it turns out that I do not need |
The loop that creates the strings to be printed was using `@views` annotation. This introduced the issue #16, which is related to JuliaData/DataFrames.jl#1893. However, it turns out that such annotation was not providing any improvements in the performance. Thus, it was removed. Closes #16
Thank you for reporting this. Actually this is a crucial part of consistency with Base regarding broadcasting for DataFrames.jl (i.e. how do we handle 0-dimensional containers and if/and how to materialize them). These are corner cases, but when you have hundreds of users they pop up quite fast 😄. |
Actually we should change the DataFrames.jl behavior to mimic what happens here:
I will add it to #1890. |
fixed on 0.19.1 |
Hi guys!
The print behavior of string in DataFrame changes if the
@view
annotation is used. For example, consider the following code:The output is:
I would expect that the behavior would not change if the
@views
annotation is used. This is caused because of the typedata[1,i]
when@views
is used. In the first case it isString
whereas in the second it isSubArray{String,0,Array{String,1},Tuple{Int64},true}
.I found this bug by analyzing the cause of this one: ronisbr/PrettyTables.jl#16
The text was updated successfully, but these errors were encountered: