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

Unary + and * promote numbers #7338

Closed
lindahua opened this issue Jun 20, 2014 · 8 comments
Closed

Unary + and * promote numbers #7338

lindahua opened this issue Jun 20, 2014 · 8 comments
Milestone

Comments

@lindahua
Copy link
Contributor

If + and * promote numbers, as follows, writing type stable codes would be more convenient:

+ (x::Number) = x + zero(x)
* (x::Number) = x * one(x)

Specialized methods can be provided so that we don't need to actually do the computation for common numeric types.

@JeffBezanson
Copy link
Member

I rather think we should make x + x be the same type as x more often.

See issues #5806 #5413
Also my comment #6211 (comment)

@StefanKarpinski
Copy link
Member

I agree that we want typeof(x+x) == typeof(x) more often. A good way to approach this might be to reason about what type we want [x] + [x] to produce and then extrapolate back to the scalar case from there. In particular, this is a little more nuanced than always having typeof(x+x) == typeof(x) in that you probably still want true + true == 2.

@JeffBezanson
Copy link
Member

Yes, that's true --- I think we'd have to keep true + true == 2. Fortunately +true already gives 1.

Another possibility is providing a good interface for "promoting reduction", e.g. summing Float32s in double precision, or summing Int8s as Int64s, etc.

@StefanKarpinski
Copy link
Member

sum(widen(eltype(v)), v)?

@johnmyleswhite
Copy link
Member

Is there an open issue with the 0.4-projects tag that subsumes this issue? From some searching, I don't see one.

@pao pao added this to the 0.4-projects milestone Aug 16, 2014
@pao
Copy link
Member

pao commented Aug 16, 2014

Quickest way to find out is probably to add the milestone, then get yelled at if it was a bad idea.

@johnmyleswhite
Copy link
Member

Good strategy.

Might be worth noting that there are bunch of open issues that touch on parts of this issue, but they don't seem to summarize the core issue very well. For example, there's a bunch of good points in #6211, but you wouldn't find it by searching the titles of issues.

@pao
Copy link
Member

pao commented Aug 18, 2014

Is this a dup of #3759 (which now has a PR, #8028)?

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

No branches or pull requests

5 participants