Restrict zero and one to Number types. Default to floating points. #6183

andreasnoack · 2014-03-16T11:08:20Z

There is some room for choosing the return type of e.g. zero(Real) and right now the default is Int. By using floating points instead the InexactError in #4796 could have been avoided. This pr also restricts zero and one such that zero/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.

andreasnoack · 2014-03-16T15:05:07Z

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 one(Real)=1.0 and one(Complex)=1.0+1.0im.

andrioni · 2014-03-17T01:00:37Z

Minor comment: do you mind defining zero(BigInt) and one(BigInt) in gmp.jl instead of mpfr.jl?

Jutho · 2014-03-17T06:20:18Z

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?

andreasnoack · 2014-03-17T07:05:20Z

@andrioni No of course not. I'll change that. For some reason, I thought that all the big stuff was in mpfr.jl now.

@Jutho You can still get

julia> one(randn(3,3))
3x3 Array{Float64,2}:
 1.0  0.0  0.0
 0.0  1.0  0.0
 0.0  0.0  1.0

but not one(Any)=1, which was the main thing I'd like to restrict.

andreasnoack · 2014-03-17T07:24:38Z

@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 Any to Number. Does that make sense?

tkelman · 2014-03-17T15:27:57Z

@andreasnoackjensen I believe so. Since Array(Any,n) and Array(Number,n) both get allocated as arrays of #undef, they would both trigger the issue in the way sparse matmul and sparse diff formerly used splice! (PR was #5852).

splice!(Array(Number,5),5) gives the same error that splice!(Array(Any,5),5) does.

deleteat!(Array(Number,5),5) and deleteat!(Array(Any,5),5) both work fine.

Now that those sparse functions are using deleteat! instead of splice! the error is fixed, so the test just makes sure sparse matmul can still be used with abstract element types in the future. What did the error look like, something like no method zero(Any)?

andreasnoack · 2014-03-17T15:29:28Z

I have added zero and one methods for Ptr. It shows that the definition in operators.jl was convenient because I have defined zero/one four times instead of the single definition in operators.jl. I don't like zero(Any)=0 and would prefer floating point for zero(Real) but the cons are about to outweigh the pros.

Another thing. I found out that zero(Ptr{None}) was needed when I started an IJulia notebook. Is it possible to have some tests for IJulia or is it not feasible?

andreasnoack · 2014-03-17T15:30:39Z

@tkelman Thank you. Yes, it was a no method error for zero(Any).

JeffBezanson · 2014-03-17T16:34:53Z

base/gmp.jl

+zero(::Type{BigInt}) = BigInt(0)
+zero(x::BigInt) = BigInt(0)
+one(::Type{BigInt}) = BigInt(1)
+one(x::BigInt) = BigInt(1)


Aren't these handled fine by the general case in number.jl?

andreasnoack · 2014-03-17T16:37:44Z

No, because there is no convert(BigInt,Float64) method. It could be added, of course.

StefanKarpinski · 2014-03-17T17:13:53Z

I think adding the convert(BigInt,Float64) method would be preferable.

JeffBezanson · 2014-03-17T17:18:06Z

Done.

andreasnoack · 2014-03-17T17:30:29Z

Thanks. Is it possible to define typemin/max(BigInt)? I think that would make the rational versions redundant.

JeffBezanson · 2014-03-18T22:18:15Z

Sadly no; BigInt has no infinities. How does typemin enter into this?

andreasnoack · 2014-03-19T08:45:11Z

one(Rational{BigInt}) calls convert(Rational{BigInt},1.0) which calls rationalize(BigInt,1.0) and that function calls typemin.

…fine new zero and one methods for Rational and Ptr. Update tests.

andreasnoack · 2014-03-20T21:54:06Z

I have now removed version for BigInt which are no longer needed with @JeffBezanson's update, but I have kept the specific versions of zero and one for rationals because rationalize(::Type{BigInt},FloatingPoint) doesn't work.

Restrict zero and one to Number types. Default to floating points.

ivarne · 2014-11-05T18:04:16Z

base/pointer.jl

+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)


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.

andreasnoack · 2014-11-05T18:06:45Z

They were needed somewhere in Base, but I cannot remember anymore. Try commenting them out and see if they are still needed.

ivarne · 2014-11-05T18:47:54Z

All tests pass without both zero and one for Ptr{T}. I'll open a PR so that others will have some time to disagree before merging.

jakebolewski · 2014-11-05T18:49:53Z

one is arguable but please don't get rid of zero(Ptr{T}), it is used in many packages outside of Base. I don't really see the value in removing either to be honest.

ivarne · 2014-11-05T18:56:25Z

Neither one nor zero for Ptr fulfills the documentation for one and zero about multiplicative and additive identity. Maybe I should fix the doc instead?

When is it applicable to use zero(Ptr{T}) instead of C_NULL?

JeffBezanson · 2014-11-05T18:58:29Z

I'd be curious to know why one was added. Either just for completeness, or something to do with multiplication and arithmetic, but I'm not sure what. It might be for ranges of pointers, left over from before Range had good support for ordinal types.

Easily getting a NULL pointer of a particular type seems useful though.

ivarne · 2014-11-05T19:01:55Z

But then we can't define zero as additive identity, because +(::Ptr{T}, ::Ptr{T}) isn't defined.

jakebolewski · 2014-11-05T19:05:15Z

I guess now that Ptr{T}(0) works zero(Ptr{T}) is not that useful any more.

andreasnoack · 2014-11-05T19:06:13Z

I only accidentally discovered that zero(Ptr{T}) was used when I restricted zero and one in this pr. Hence, I just added one to avoid breaking anything so I think it is safe to remove it.

ivarne · 2014-11-05T19:11:12Z

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)

stevengj added the decision label Mar 16, 2014

JeffBezanson reviewed Mar 17, 2014
View reviewed changes

JeffBezanson added a commit that referenced this pull request Mar 17, 2014

add conversions from float to BigInt. ref #6183

13d621a

Restrict zero and one to Number types. Default to floating points. De…

764e11f

…fine new zero and one methods for Rational and Ptr. Update tests.

JeffBezanson added a commit that referenced this pull request Apr 4, 2014

Merge pull request #6183 from JuliaLang/anj/zeroone

bc1ea97

Restrict zero and one to Number types. Default to floating points.

JeffBezanson merged commit bc1ea97 into master Apr 4, 2014

tkelman mentioned this pull request Apr 5, 2014

Converting an array of Any to Float : float() -> no method one(Type{Any}) #6422

Closed

ivarne mentioned this pull request Apr 7, 2014

dot(a,b) fails for Array{Any} #6450

Closed

andreasnoack mentioned this pull request Apr 8, 2014

modint example is broken #6461

Closed

andreasnoack deleted the anj/zeroone branch April 9, 2014 06:08

ivarne reviewed Nov 5, 2014
View reviewed changes

ivarne added a commit to ivarne/julia that referenced this pull request Nov 5, 2014

Deprecate zero and one for Ptr{T}

223de5e

They doesen't fullfill the documentation for zero and one about additive and multiplicative identity. See discussion in JuliaLang#6183 (comment)

ivarne added a commit to ivarne/julia that referenced this pull request Nov 5, 2014

Deprecate zero and one for Ptr{T}

a3c22f4

They doesn't fulfill the documentation for zero and one about additive and multiplicative identity. See discussion in JuliaLang#6183 (comment)

ivarne mentioned this pull request Nov 5, 2014

Deprecate zero and one for Ptr{T} #8909

Merged

ivarne added a commit to ivarne/julia that referenced this pull request Nov 5, 2014

Deprecate zero and one for Ptr{T}

47348ec

They doesn't fulfill the documentation for zero and one about additive and multiplicative identity. See discussion in JuliaLang#6183 (comment)

waTeim pushed a commit to waTeim/julia that referenced this pull request Nov 23, 2014

Deprecate zero and one for Ptr{T}

c80ce83

They doesn't fulfill the documentation for zero and one about additive and multiplicative identity. See discussion in JuliaLang#6183 (comment)

jiahao mentioned this pull request Dec 12, 2014

Improve zero checks in sparse and reduce #9325

Closed

nalimilan mentioned this pull request Jun 19, 2016

promote_op() fixes #16995

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Restrict zero and one to Number types. Default to floating points. #6183

Restrict zero and one to Number types. Default to floating points. #6183

andreasnoack commented Mar 16, 2014

andreasnoack commented Mar 16, 2014

andrioni commented Mar 17, 2014

Jutho commented Mar 17, 2014

andreasnoack commented Mar 17, 2014

andreasnoack commented Mar 17, 2014

tkelman commented Mar 17, 2014

andreasnoack commented Mar 17, 2014

andreasnoack commented Mar 17, 2014

JeffBezanson Mar 17, 2014

andreasnoack commented Mar 17, 2014

StefanKarpinski commented Mar 17, 2014

JeffBezanson commented Mar 17, 2014

andreasnoack commented Mar 17, 2014

JeffBezanson commented Mar 18, 2014

andreasnoack commented Mar 19, 2014

andreasnoack commented Mar 20, 2014

ivarne Nov 5, 2014

andreasnoack commented Nov 5, 2014

ivarne commented Nov 5, 2014

jakebolewski commented Nov 5, 2014

ivarne commented Nov 5, 2014

JeffBezanson commented Nov 5, 2014

ivarne commented Nov 5, 2014

jakebolewski commented Nov 5, 2014

andreasnoack commented Nov 5, 2014

ivarne commented Nov 5, 2014

Restrict zero and one to Number types. Default to floating points. #6183

Restrict zero and one to Number types. Default to floating points. #6183

Conversation

andreasnoack commented Mar 16, 2014

andreasnoack commented Mar 16, 2014

andrioni commented Mar 17, 2014

Jutho commented Mar 17, 2014

andreasnoack commented Mar 17, 2014

andreasnoack commented Mar 17, 2014

tkelman commented Mar 17, 2014

andreasnoack commented Mar 17, 2014

andreasnoack commented Mar 17, 2014

JeffBezanson Mar 17, 2014

Choose a reason for hiding this comment

andreasnoack commented Mar 17, 2014

StefanKarpinski commented Mar 17, 2014

JeffBezanson commented Mar 17, 2014

andreasnoack commented Mar 17, 2014

JeffBezanson commented Mar 18, 2014

andreasnoack commented Mar 19, 2014

andreasnoack commented Mar 20, 2014

ivarne Nov 5, 2014

Choose a reason for hiding this comment

andreasnoack commented Nov 5, 2014

ivarne commented Nov 5, 2014

jakebolewski commented Nov 5, 2014

ivarne commented Nov 5, 2014

JeffBezanson commented Nov 5, 2014

ivarne commented Nov 5, 2014

jakebolewski commented Nov 5, 2014

andreasnoack commented Nov 5, 2014

ivarne commented Nov 5, 2014