Calling object methods within Arrays.reduce(…)
up vote
13
down vote
favorite
I have the following 3 files,
A.java:
class A {
private float b;
public A(float b) {
this.b = b;
}
public float getB() {
return b;
}
}
C.java:
import java.util.Arrays;
class C {
private A d;
private int i = 0;
public C() {
d = new A[2];
}
public float totalB() {
return Arrays.stream(d).reduce((e, f) -> e.getB() + f.getB()).get();
}
public void addB(A b) {
d[i++] = b;
}
}
D.java:
class D {
public static void main(String args) {
C c = new C();
c.addB(new A(3));
c.addB(new A(5));
System.out.println(c.totalB())
}
}
I was expecting the last line in D.java to output 8, however I get this error:
error: incompatible types: bad return type in lambda expression
return Arrays.stream(d).reduce((e, f) -> e.getB() + f.getB()).get();
^
float cannot be converted to A
Why does this happen? I don't see where I'm converting the floats to the object A.
java oop object java-8
add a comment |
up vote
13
down vote
favorite
I have the following 3 files,
A.java:
class A {
private float b;
public A(float b) {
this.b = b;
}
public float getB() {
return b;
}
}
C.java:
import java.util.Arrays;
class C {
private A d;
private int i = 0;
public C() {
d = new A[2];
}
public float totalB() {
return Arrays.stream(d).reduce((e, f) -> e.getB() + f.getB()).get();
}
public void addB(A b) {
d[i++] = b;
}
}
D.java:
class D {
public static void main(String args) {
C c = new C();
c.addB(new A(3));
c.addB(new A(5));
System.out.println(c.totalB())
}
}
I was expecting the last line in D.java to output 8, however I get this error:
error: incompatible types: bad return type in lambda expression
return Arrays.stream(d).reduce((e, f) -> e.getB() + f.getB()).get();
^
float cannot be converted to A
Why does this happen? I don't see where I'm converting the floats to the object A.
java oop object java-8
1
Is it intended that your totalB() method returns an int instead of a float?
– Joakim Danielson
Nov 15 at 14:10
add a comment |
up vote
13
down vote
favorite
up vote
13
down vote
favorite
I have the following 3 files,
A.java:
class A {
private float b;
public A(float b) {
this.b = b;
}
public float getB() {
return b;
}
}
C.java:
import java.util.Arrays;
class C {
private A d;
private int i = 0;
public C() {
d = new A[2];
}
public float totalB() {
return Arrays.stream(d).reduce((e, f) -> e.getB() + f.getB()).get();
}
public void addB(A b) {
d[i++] = b;
}
}
D.java:
class D {
public static void main(String args) {
C c = new C();
c.addB(new A(3));
c.addB(new A(5));
System.out.println(c.totalB())
}
}
I was expecting the last line in D.java to output 8, however I get this error:
error: incompatible types: bad return type in lambda expression
return Arrays.stream(d).reduce((e, f) -> e.getB() + f.getB()).get();
^
float cannot be converted to A
Why does this happen? I don't see where I'm converting the floats to the object A.
java oop object java-8
I have the following 3 files,
A.java:
class A {
private float b;
public A(float b) {
this.b = b;
}
public float getB() {
return b;
}
}
C.java:
import java.util.Arrays;
class C {
private A d;
private int i = 0;
public C() {
d = new A[2];
}
public float totalB() {
return Arrays.stream(d).reduce((e, f) -> e.getB() + f.getB()).get();
}
public void addB(A b) {
d[i++] = b;
}
}
D.java:
class D {
public static void main(String args) {
C c = new C();
c.addB(new A(3));
c.addB(new A(5));
System.out.println(c.totalB())
}
}
I was expecting the last line in D.java to output 8, however I get this error:
error: incompatible types: bad return type in lambda expression
return Arrays.stream(d).reduce((e, f) -> e.getB() + f.getB()).get();
^
float cannot be converted to A
Why does this happen? I don't see where I'm converting the floats to the object A.
java oop object java-8
java oop object java-8
edited Nov 15 at 14:12
asked Nov 15 at 14:00
newbie
540213
540213
1
Is it intended that your totalB() method returns an int instead of a float?
– Joakim Danielson
Nov 15 at 14:10
add a comment |
1
Is it intended that your totalB() method returns an int instead of a float?
– Joakim Danielson
Nov 15 at 14:10
1
1
Is it intended that your totalB() method returns an int instead of a float?
– Joakim Danielson
Nov 15 at 14:10
Is it intended that your totalB() method returns an int instead of a float?
– Joakim Danielson
Nov 15 at 14:10
add a comment |
3 Answers
3
active
oldest
votes
up vote
11
down vote
accepted
The single argument reduce()
variant expects the final result of the reduce operation to be of the same type as the Stream
elements.
You need a different variant:
<U> U reduce(U identity,
BiFunction<U, ? super T, U> accumulator,
BinaryOperator<U> combiner);
which you can use as follows:
public float totalB() {
return Arrays.stream(d).reduce(0.0f,(r, f) -> r + f.getB(), Float::sum);
}
3
or Arrays.stream(d).reduce(0,(r, f) -> r + (int)f.getB(), Integer::sum);
– Ankur Chrungoo
Nov 15 at 14:08
@AnkurChrungoo good point
– Eran
Nov 15 at 14:10
Thanks, this works. Could you also please link the appropriate documentation for this?
– newbie
Nov 15 at 14:15
1
@newbie You're welcome. Added a link to the Javadoc
– Eran
Nov 15 at 14:17
1
@Eran, yes, but I mean't another way, i.e. probably using map() to map it to int/float based stream, and then using reduce() on it.
– Ankur Chrungoo
Nov 15 at 14:25
|
show 3 more comments
up vote
13
down vote
I prefer utilizing the "sum" method as it's more readable than the general reduce
pattern. i.e.
return (float)Arrays.stream(d)
.mapToDouble(A::getB)
.sum();
This is the more idiomatic, readable and efficient approach as opposed to your approach of Arrays.stream(d).reduce(...)
...
Yeah I was thinking to use it but had to use maptodouble which I didn’t quite like :)
– Ankur Chrungoo
Nov 15 at 15:02
And I hope there was a method mapToFloat, making this more intuitive and probably more efficient.
– Ankur Chrungoo
Nov 15 at 15:17
1
@AnkurChrungoo where’s the problem withmapToDouble
? Doing the arithmetic indouble
instead ofFloat
will be much faster. And no, calculating infloat
is unlikely to be more efficient, as all real life FPUs calculate indouble
(or with even higher precision) and forcing a lower precision (truncating the result after each step) may cost even more time.
– Holger
Nov 15 at 15:17
@Holger oh is it? Is this more efficient space and time complexity wise? Would appreciate if you could share some detailed insight. Thanks!
– Ankur Chrungoo
Nov 15 at 15:20
4
@AnkurChrungoo keep in mind that streams are not about storage, but only calculations. Once the JIT/HotSpot optimizer did its work, all intermediate values reside in CPU registers anyway, and the CPU registers always have the same width. The only drawback is that there is no way to create afloat
array from a stream as a result. But here, we get only one final value which we can just cast anyway. One of the API developers once said in a comment on SO that they even considered omitting theIntStream
in favor ofLongStream
but felt that “the developers are not ready for that (yet)”…
– Holger
Nov 15 at 15:23
|
show 1 more comment
up vote
3
down vote
As mentioned in my comment above, posting another alternative where you don't need the second version of the reduce method.
public float totalB() {
return Arrays.stream(d).map(i -> i.getB()).reduce(Float::sum).get();
}
4
or better -->return Arrays.stream(d).map(A::getB).reduce(Float::sum).orElse(0f);
– Aomine
Nov 15 at 14:56
4
@Aomine or… .reduce(0f, Float::sum)
– Holger
Nov 15 at 17:05
add a comment |
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
11
down vote
accepted
The single argument reduce()
variant expects the final result of the reduce operation to be of the same type as the Stream
elements.
You need a different variant:
<U> U reduce(U identity,
BiFunction<U, ? super T, U> accumulator,
BinaryOperator<U> combiner);
which you can use as follows:
public float totalB() {
return Arrays.stream(d).reduce(0.0f,(r, f) -> r + f.getB(), Float::sum);
}
3
or Arrays.stream(d).reduce(0,(r, f) -> r + (int)f.getB(), Integer::sum);
– Ankur Chrungoo
Nov 15 at 14:08
@AnkurChrungoo good point
– Eran
Nov 15 at 14:10
Thanks, this works. Could you also please link the appropriate documentation for this?
– newbie
Nov 15 at 14:15
1
@newbie You're welcome. Added a link to the Javadoc
– Eran
Nov 15 at 14:17
1
@Eran, yes, but I mean't another way, i.e. probably using map() to map it to int/float based stream, and then using reduce() on it.
– Ankur Chrungoo
Nov 15 at 14:25
|
show 3 more comments
up vote
11
down vote
accepted
The single argument reduce()
variant expects the final result of the reduce operation to be of the same type as the Stream
elements.
You need a different variant:
<U> U reduce(U identity,
BiFunction<U, ? super T, U> accumulator,
BinaryOperator<U> combiner);
which you can use as follows:
public float totalB() {
return Arrays.stream(d).reduce(0.0f,(r, f) -> r + f.getB(), Float::sum);
}
3
or Arrays.stream(d).reduce(0,(r, f) -> r + (int)f.getB(), Integer::sum);
– Ankur Chrungoo
Nov 15 at 14:08
@AnkurChrungoo good point
– Eran
Nov 15 at 14:10
Thanks, this works. Could you also please link the appropriate documentation for this?
– newbie
Nov 15 at 14:15
1
@newbie You're welcome. Added a link to the Javadoc
– Eran
Nov 15 at 14:17
1
@Eran, yes, but I mean't another way, i.e. probably using map() to map it to int/float based stream, and then using reduce() on it.
– Ankur Chrungoo
Nov 15 at 14:25
|
show 3 more comments
up vote
11
down vote
accepted
up vote
11
down vote
accepted
The single argument reduce()
variant expects the final result of the reduce operation to be of the same type as the Stream
elements.
You need a different variant:
<U> U reduce(U identity,
BiFunction<U, ? super T, U> accumulator,
BinaryOperator<U> combiner);
which you can use as follows:
public float totalB() {
return Arrays.stream(d).reduce(0.0f,(r, f) -> r + f.getB(), Float::sum);
}
The single argument reduce()
variant expects the final result of the reduce operation to be of the same type as the Stream
elements.
You need a different variant:
<U> U reduce(U identity,
BiFunction<U, ? super T, U> accumulator,
BinaryOperator<U> combiner);
which you can use as follows:
public float totalB() {
return Arrays.stream(d).reduce(0.0f,(r, f) -> r + f.getB(), Float::sum);
}
edited Nov 15 at 14:15
answered Nov 15 at 14:05
Eran
274k35439521
274k35439521
3
or Arrays.stream(d).reduce(0,(r, f) -> r + (int)f.getB(), Integer::sum);
– Ankur Chrungoo
Nov 15 at 14:08
@AnkurChrungoo good point
– Eran
Nov 15 at 14:10
Thanks, this works. Could you also please link the appropriate documentation for this?
– newbie
Nov 15 at 14:15
1
@newbie You're welcome. Added a link to the Javadoc
– Eran
Nov 15 at 14:17
1
@Eran, yes, but I mean't another way, i.e. probably using map() to map it to int/float based stream, and then using reduce() on it.
– Ankur Chrungoo
Nov 15 at 14:25
|
show 3 more comments
3
or Arrays.stream(d).reduce(0,(r, f) -> r + (int)f.getB(), Integer::sum);
– Ankur Chrungoo
Nov 15 at 14:08
@AnkurChrungoo good point
– Eran
Nov 15 at 14:10
Thanks, this works. Could you also please link the appropriate documentation for this?
– newbie
Nov 15 at 14:15
1
@newbie You're welcome. Added a link to the Javadoc
– Eran
Nov 15 at 14:17
1
@Eran, yes, but I mean't another way, i.e. probably using map() to map it to int/float based stream, and then using reduce() on it.
– Ankur Chrungoo
Nov 15 at 14:25
3
3
or Arrays.stream(d).reduce(0,(r, f) -> r + (int)f.getB(), Integer::sum);
– Ankur Chrungoo
Nov 15 at 14:08
or Arrays.stream(d).reduce(0,(r, f) -> r + (int)f.getB(), Integer::sum);
– Ankur Chrungoo
Nov 15 at 14:08
@AnkurChrungoo good point
– Eran
Nov 15 at 14:10
@AnkurChrungoo good point
– Eran
Nov 15 at 14:10
Thanks, this works. Could you also please link the appropriate documentation for this?
– newbie
Nov 15 at 14:15
Thanks, this works. Could you also please link the appropriate documentation for this?
– newbie
Nov 15 at 14:15
1
1
@newbie You're welcome. Added a link to the Javadoc
– Eran
Nov 15 at 14:17
@newbie You're welcome. Added a link to the Javadoc
– Eran
Nov 15 at 14:17
1
1
@Eran, yes, but I mean't another way, i.e. probably using map() to map it to int/float based stream, and then using reduce() on it.
– Ankur Chrungoo
Nov 15 at 14:25
@Eran, yes, but I mean't another way, i.e. probably using map() to map it to int/float based stream, and then using reduce() on it.
– Ankur Chrungoo
Nov 15 at 14:25
|
show 3 more comments
up vote
13
down vote
I prefer utilizing the "sum" method as it's more readable than the general reduce
pattern. i.e.
return (float)Arrays.stream(d)
.mapToDouble(A::getB)
.sum();
This is the more idiomatic, readable and efficient approach as opposed to your approach of Arrays.stream(d).reduce(...)
...
Yeah I was thinking to use it but had to use maptodouble which I didn’t quite like :)
– Ankur Chrungoo
Nov 15 at 15:02
And I hope there was a method mapToFloat, making this more intuitive and probably more efficient.
– Ankur Chrungoo
Nov 15 at 15:17
1
@AnkurChrungoo where’s the problem withmapToDouble
? Doing the arithmetic indouble
instead ofFloat
will be much faster. And no, calculating infloat
is unlikely to be more efficient, as all real life FPUs calculate indouble
(or with even higher precision) and forcing a lower precision (truncating the result after each step) may cost even more time.
– Holger
Nov 15 at 15:17
@Holger oh is it? Is this more efficient space and time complexity wise? Would appreciate if you could share some detailed insight. Thanks!
– Ankur Chrungoo
Nov 15 at 15:20
4
@AnkurChrungoo keep in mind that streams are not about storage, but only calculations. Once the JIT/HotSpot optimizer did its work, all intermediate values reside in CPU registers anyway, and the CPU registers always have the same width. The only drawback is that there is no way to create afloat
array from a stream as a result. But here, we get only one final value which we can just cast anyway. One of the API developers once said in a comment on SO that they even considered omitting theIntStream
in favor ofLongStream
but felt that “the developers are not ready for that (yet)”…
– Holger
Nov 15 at 15:23
|
show 1 more comment
up vote
13
down vote
I prefer utilizing the "sum" method as it's more readable than the general reduce
pattern. i.e.
return (float)Arrays.stream(d)
.mapToDouble(A::getB)
.sum();
This is the more idiomatic, readable and efficient approach as opposed to your approach of Arrays.stream(d).reduce(...)
...
Yeah I was thinking to use it but had to use maptodouble which I didn’t quite like :)
– Ankur Chrungoo
Nov 15 at 15:02
And I hope there was a method mapToFloat, making this more intuitive and probably more efficient.
– Ankur Chrungoo
Nov 15 at 15:17
1
@AnkurChrungoo where’s the problem withmapToDouble
? Doing the arithmetic indouble
instead ofFloat
will be much faster. And no, calculating infloat
is unlikely to be more efficient, as all real life FPUs calculate indouble
(or with even higher precision) and forcing a lower precision (truncating the result after each step) may cost even more time.
– Holger
Nov 15 at 15:17
@Holger oh is it? Is this more efficient space and time complexity wise? Would appreciate if you could share some detailed insight. Thanks!
– Ankur Chrungoo
Nov 15 at 15:20
4
@AnkurChrungoo keep in mind that streams are not about storage, but only calculations. Once the JIT/HotSpot optimizer did its work, all intermediate values reside in CPU registers anyway, and the CPU registers always have the same width. The only drawback is that there is no way to create afloat
array from a stream as a result. But here, we get only one final value which we can just cast anyway. One of the API developers once said in a comment on SO that they even considered omitting theIntStream
in favor ofLongStream
but felt that “the developers are not ready for that (yet)”…
– Holger
Nov 15 at 15:23
|
show 1 more comment
up vote
13
down vote
up vote
13
down vote
I prefer utilizing the "sum" method as it's more readable than the general reduce
pattern. i.e.
return (float)Arrays.stream(d)
.mapToDouble(A::getB)
.sum();
This is the more idiomatic, readable and efficient approach as opposed to your approach of Arrays.stream(d).reduce(...)
...
I prefer utilizing the "sum" method as it's more readable than the general reduce
pattern. i.e.
return (float)Arrays.stream(d)
.mapToDouble(A::getB)
.sum();
This is the more idiomatic, readable and efficient approach as opposed to your approach of Arrays.stream(d).reduce(...)
...
edited Nov 15 at 15:01
answered Nov 15 at 14:55
Aomine
32.7k62754
32.7k62754
Yeah I was thinking to use it but had to use maptodouble which I didn’t quite like :)
– Ankur Chrungoo
Nov 15 at 15:02
And I hope there was a method mapToFloat, making this more intuitive and probably more efficient.
– Ankur Chrungoo
Nov 15 at 15:17
1
@AnkurChrungoo where’s the problem withmapToDouble
? Doing the arithmetic indouble
instead ofFloat
will be much faster. And no, calculating infloat
is unlikely to be more efficient, as all real life FPUs calculate indouble
(or with even higher precision) and forcing a lower precision (truncating the result after each step) may cost even more time.
– Holger
Nov 15 at 15:17
@Holger oh is it? Is this more efficient space and time complexity wise? Would appreciate if you could share some detailed insight. Thanks!
– Ankur Chrungoo
Nov 15 at 15:20
4
@AnkurChrungoo keep in mind that streams are not about storage, but only calculations. Once the JIT/HotSpot optimizer did its work, all intermediate values reside in CPU registers anyway, and the CPU registers always have the same width. The only drawback is that there is no way to create afloat
array from a stream as a result. But here, we get only one final value which we can just cast anyway. One of the API developers once said in a comment on SO that they even considered omitting theIntStream
in favor ofLongStream
but felt that “the developers are not ready for that (yet)”…
– Holger
Nov 15 at 15:23
|
show 1 more comment
Yeah I was thinking to use it but had to use maptodouble which I didn’t quite like :)
– Ankur Chrungoo
Nov 15 at 15:02
And I hope there was a method mapToFloat, making this more intuitive and probably more efficient.
– Ankur Chrungoo
Nov 15 at 15:17
1
@AnkurChrungoo where’s the problem withmapToDouble
? Doing the arithmetic indouble
instead ofFloat
will be much faster. And no, calculating infloat
is unlikely to be more efficient, as all real life FPUs calculate indouble
(or with even higher precision) and forcing a lower precision (truncating the result after each step) may cost even more time.
– Holger
Nov 15 at 15:17
@Holger oh is it? Is this more efficient space and time complexity wise? Would appreciate if you could share some detailed insight. Thanks!
– Ankur Chrungoo
Nov 15 at 15:20
4
@AnkurChrungoo keep in mind that streams are not about storage, but only calculations. Once the JIT/HotSpot optimizer did its work, all intermediate values reside in CPU registers anyway, and the CPU registers always have the same width. The only drawback is that there is no way to create afloat
array from a stream as a result. But here, we get only one final value which we can just cast anyway. One of the API developers once said in a comment on SO that they even considered omitting theIntStream
in favor ofLongStream
but felt that “the developers are not ready for that (yet)”…
– Holger
Nov 15 at 15:23
Yeah I was thinking to use it but had to use maptodouble which I didn’t quite like :)
– Ankur Chrungoo
Nov 15 at 15:02
Yeah I was thinking to use it but had to use maptodouble which I didn’t quite like :)
– Ankur Chrungoo
Nov 15 at 15:02
And I hope there was a method mapToFloat, making this more intuitive and probably more efficient.
– Ankur Chrungoo
Nov 15 at 15:17
And I hope there was a method mapToFloat, making this more intuitive and probably more efficient.
– Ankur Chrungoo
Nov 15 at 15:17
1
1
@AnkurChrungoo where’s the problem with
mapToDouble
? Doing the arithmetic in double
instead of Float
will be much faster. And no, calculating in float
is unlikely to be more efficient, as all real life FPUs calculate in double
(or with even higher precision) and forcing a lower precision (truncating the result after each step) may cost even more time.– Holger
Nov 15 at 15:17
@AnkurChrungoo where’s the problem with
mapToDouble
? Doing the arithmetic in double
instead of Float
will be much faster. And no, calculating in float
is unlikely to be more efficient, as all real life FPUs calculate in double
(or with even higher precision) and forcing a lower precision (truncating the result after each step) may cost even more time.– Holger
Nov 15 at 15:17
@Holger oh is it? Is this more efficient space and time complexity wise? Would appreciate if you could share some detailed insight. Thanks!
– Ankur Chrungoo
Nov 15 at 15:20
@Holger oh is it? Is this more efficient space and time complexity wise? Would appreciate if you could share some detailed insight. Thanks!
– Ankur Chrungoo
Nov 15 at 15:20
4
4
@AnkurChrungoo keep in mind that streams are not about storage, but only calculations. Once the JIT/HotSpot optimizer did its work, all intermediate values reside in CPU registers anyway, and the CPU registers always have the same width. The only drawback is that there is no way to create a
float
array from a stream as a result. But here, we get only one final value which we can just cast anyway. One of the API developers once said in a comment on SO that they even considered omitting the IntStream
in favor of LongStream
but felt that “the developers are not ready for that (yet)”…– Holger
Nov 15 at 15:23
@AnkurChrungoo keep in mind that streams are not about storage, but only calculations. Once the JIT/HotSpot optimizer did its work, all intermediate values reside in CPU registers anyway, and the CPU registers always have the same width. The only drawback is that there is no way to create a
float
array from a stream as a result. But here, we get only one final value which we can just cast anyway. One of the API developers once said in a comment on SO that they even considered omitting the IntStream
in favor of LongStream
but felt that “the developers are not ready for that (yet)”…– Holger
Nov 15 at 15:23
|
show 1 more comment
up vote
3
down vote
As mentioned in my comment above, posting another alternative where you don't need the second version of the reduce method.
public float totalB() {
return Arrays.stream(d).map(i -> i.getB()).reduce(Float::sum).get();
}
4
or better -->return Arrays.stream(d).map(A::getB).reduce(Float::sum).orElse(0f);
– Aomine
Nov 15 at 14:56
4
@Aomine or… .reduce(0f, Float::sum)
– Holger
Nov 15 at 17:05
add a comment |
up vote
3
down vote
As mentioned in my comment above, posting another alternative where you don't need the second version of the reduce method.
public float totalB() {
return Arrays.stream(d).map(i -> i.getB()).reduce(Float::sum).get();
}
4
or better -->return Arrays.stream(d).map(A::getB).reduce(Float::sum).orElse(0f);
– Aomine
Nov 15 at 14:56
4
@Aomine or… .reduce(0f, Float::sum)
– Holger
Nov 15 at 17:05
add a comment |
up vote
3
down vote
up vote
3
down vote
As mentioned in my comment above, posting another alternative where you don't need the second version of the reduce method.
public float totalB() {
return Arrays.stream(d).map(i -> i.getB()).reduce(Float::sum).get();
}
As mentioned in my comment above, posting another alternative where you don't need the second version of the reduce method.
public float totalB() {
return Arrays.stream(d).map(i -> i.getB()).reduce(Float::sum).get();
}
answered Nov 15 at 14:34
Ankur Chrungoo
43116
43116
4
or better -->return Arrays.stream(d).map(A::getB).reduce(Float::sum).orElse(0f);
– Aomine
Nov 15 at 14:56
4
@Aomine or… .reduce(0f, Float::sum)
– Holger
Nov 15 at 17:05
add a comment |
4
or better -->return Arrays.stream(d).map(A::getB).reduce(Float::sum).orElse(0f);
– Aomine
Nov 15 at 14:56
4
@Aomine or… .reduce(0f, Float::sum)
– Holger
Nov 15 at 17:05
4
4
or better -->
return Arrays.stream(d).map(A::getB).reduce(Float::sum).orElse(0f);
– Aomine
Nov 15 at 14:56
or better -->
return Arrays.stream(d).map(A::getB).reduce(Float::sum).orElse(0f);
– Aomine
Nov 15 at 14:56
4
4
@Aomine or
… .reduce(0f, Float::sum)
– Holger
Nov 15 at 17:05
@Aomine or
… .reduce(0f, Float::sum)
– Holger
Nov 15 at 17:05
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53321133%2fcalling-object-methods-within-arrays-reduce%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
Is it intended that your totalB() method returns an int instead of a float?
– Joakim Danielson
Nov 15 at 14:10