-
Notifications
You must be signed in to change notification settings - Fork 152
setindex! with StaticArrays of a non-isbits type #39
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
Comments
Did you have a look at #27 ? It seems a little difficult to support this at the moment. In theory what was there before could end it up with garbage collection safety issues and we can actually work around that with a GC lock. However, there seemed to be a strong disagreement about this and I couldn't figure out why (I think the compiler makes assumptions about immutable references to mutable objects and could get into an inconsistent state). On the other hand we can make it a bit slower by replacing the entire tuple - would a small speed penalty be a big problem to you? |
No. I think the overall speedup of working with fixed size arrays far outweighs the small speed penalty. |
Just so you know, you can now use (on the master branch, for now) a In Julia 0.6, if they introduce Finally, quite often an immutable container like |
thanks |
Fix JuliaArrays#39 : document undef initializer
Nice.
My ArbFloats, while an immutable type, are not strictly isbits types because one of their static fields may be either an immediate value or an offset into preallocated memory that holds a fixed length BigNum.
They share some isibits type's behavior: changing a value does not alter the bit patterns of a value's fields, instead a new realization of the type is constructed and used in place of the original value.
I would like them to play well with StaticArrays. Please let me know the fuctional signatures to provide (and what they are doing, if there is any subtilty -- I have not learned that part of Julia yet). Feel free to abbreviate the types ArbFloat{ bits_of_precision } as AFloat.
If some of the linear algebra that you support gets passed along to C routines, at the algorithmic point where that transition occur, there would need to be me dispatching over the handoff. And this is a larger issue for ArbFloats (it is a corner of v0.5 where BigFloats sink).
The text was updated successfully, but these errors were encountered: