-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
Restrict zero and one to Number types. Default to floating points. #6183
Conversation
Okay. Now the pull request actually works. I understand that it is better to start out with integers when converting to other types, but I think it would be useful if |
Minor comment: do you mind defining |
Do you mean to restrict zero and one to subtypes of Number, i.e. scalar quantities. Does this mean there will be no zero for arrays or one for square matrices? |
@tkelman I can see that you wrote the sparse test about "access to undefined error". I don't recall the idea of this test. I have change the array type from |
@andreasnoackjensen I believe so. Since
Now that those sparse functions are using |
I have added Another thing. I found out that |
@tkelman Thank you. Yes, it was a no method error for |
zero(::Type{BigInt}) = BigInt(0) | ||
zero(x::BigInt) = BigInt(0) | ||
one(::Type{BigInt}) = BigInt(1) | ||
one(x::BigInt) = BigInt(1) |
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.
Aren't these handled fine by the general case in number.jl
?
No, because there is no |
I think adding the |
Done. |
Thanks. Is it possible to define |
Sadly no; BigInt has no infinities. How does |
|
…fine new zero and one methods for Rational and Ptr. Update tests.
I have now removed version for |
Restrict zero and one to Number types. Default to floating points.
zero{T}(::Type{Ptr{T}}) = convert(Ptr{T}, 0) | ||
zero{T}(x::Ptr{T}) = convert(Ptr{T}, 0) | ||
one{T}(::Type{Ptr{T}}) = convert(Ptr{T}, 1) | ||
one{T}(x::Ptr{T}) = convert(Ptr{T}, 1) |
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.
Why do we have one(Ptr{Int})
? If I need a zero pointer I use C_NULL, but I can't see any reason to have a one pointer.
They were needed somewhere in Base, but I cannot remember anymore. Try commenting them out and see if they are still needed. |
All tests pass without both |
|
Neither When is it applicable to use |
I'd be curious to know why Easily getting a NULL pointer of a particular type seems useful though. |
But then we can't define |
I guess now that |
I only accidentally discovered that |
Ok, deprecations seems to be in order then. |
They doesen't fullfill the documentation for zero and one about additive and multiplicative identity. See discussion in JuliaLang#6183 (comment)
They doesn't fulfill the documentation for zero and one about additive and multiplicative identity. See discussion in JuliaLang#6183 (comment)
They doesn't fulfill the documentation for zero and one about additive and multiplicative identity. See discussion in JuliaLang#6183 (comment)
They doesn't fulfill the documentation for zero and one about additive and multiplicative identity. See discussion in JuliaLang#6183 (comment)
There is some room for choosing the return type of e.g.
zero(Real)
and right now the default isInt
. By using floating points instead theInexactError
in #4796 could have been avoided. This pr also restrictszero
andone
such thatzero/one(Any)
is no longer defined. It is possible that this change will break some code with type inference problems, but maybe that is a good.