Calling object methods within Arrays.reduce(…)











up vote
12
down vote

favorite
3












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.










share|improve this question




















  • 1




    Is it intended that your totalB() method returns an int instead of a float?
    – Joakim Danielson
    Nov 15 at 14:10















up vote
12
down vote

favorite
3












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.










share|improve this question




















  • 1




    Is it intended that your totalB() method returns an int instead of a float?
    – Joakim Danielson
    Nov 15 at 14:10













up vote
12
down vote

favorite
3









up vote
12
down vote

favorite
3






3





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.










share|improve this question















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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 15 at 14:12

























asked Nov 15 at 14:00









newbie

535213




535213








  • 1




    Is it intended that your totalB() method returns an int instead of a float?
    – Joakim Danielson
    Nov 15 at 14:10














  • 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












3 Answers
3






active

oldest

votes

















up vote
10
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);
}





share|improve this answer



















  • 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




















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(...)...






share|improve this answer























  • 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 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






  • 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




















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();
}





share|improve this answer

















  • 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











Your Answer






StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














 

draft saved


draft discarded


















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

























3 Answers
3






active

oldest

votes








3 Answers
3






active

oldest

votes









active

oldest

votes






active

oldest

votes








up vote
10
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);
}





share|improve this answer



















  • 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

















up vote
10
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);
}





share|improve this answer



















  • 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















up vote
10
down vote



accepted







up vote
10
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);
}





share|improve this answer














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);
}






share|improve this answer














share|improve this answer



share|improve this answer








edited Nov 15 at 14:15

























answered Nov 15 at 14:05









Eran

272k35430514




272k35430514








  • 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




    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














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(...)...






share|improve this answer























  • 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 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






  • 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

















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(...)...






share|improve this answer























  • 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 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






  • 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















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(...)...






share|improve this answer














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(...)...







share|improve this answer














share|improve this answer



share|improve this answer








edited Nov 15 at 15:01

























answered Nov 15 at 14:55









Aomine

31.5k52754




31.5k52754












  • 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 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






  • 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




















  • 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 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






  • 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


















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












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();
}





share|improve this answer

















  • 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















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();
}





share|improve this answer

















  • 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













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();
}





share|improve this answer












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();
}






share|improve this answer












share|improve this answer



share|improve this answer










answered Nov 15 at 14:34









Ankur Chrungoo

36116




36116








  • 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




    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


















 

draft saved


draft discarded



















































 


draft saved


draft discarded














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





















































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







Popular posts from this blog

AnyDesk - Fatal Program Failure

How to calibrate 16:9 built-in touch-screen to a 4:3 resolution?

QoS: MAC-Priority for clients behind a repeater