Re: RFR : 8013712 : (XS) Add Objects.nonNull and Objects.isNull
I would say not needed, !isNull() is sufficient. If included isNotNull() is the better name. On 5 May 2013 01:09, Ulf Zibis wrote: > > Am 04.05.2013 04:28, schrieb Mike Duigou: > > I have updated the webrev to include incorporate the feedback I have > received. > > > > http://cr.openjdk.java.net/~mduigou/JDK-8013712/1/webrev/ > > > > Regarding the naming of the "nonNull" method. I originally added this > method in 2011 but I've forgotten since then why it has the name it does. > As best as I can determine the name is either derived from the the name > used by Guava for the same predicate, "notNull", or the names derives from > the name "requireNonNull" in that this method doesn't require that the > reference be non-null. The EG hasn't been concerned that this method > doesn't use the "is" prefix. > > Do we need nonNull/isNotNull() at all, as it's always !isNull()? > Anyway I would prefer isNotNull(). > > -Ulf > > > -- -- Howard.
Re: RFR 8005311: Add Scalable Updatable Variables, DoubleAccumulator, DoubleAdder, LongAccumulator, LongAdder
If you make a binary tree and sum it, the rounding errors aren't that bad and this algorithm is easy to parallelise. Higham, Nicholas J 1993 the accuracy of floating point summation SIAM Sci Comp 14 (4) 783-799 Also see Wikipedia for a description of Kahan summation and a general discussion of this topic. Why not commit to binary tree reductions and that will allow everyone to understand what is going on and design lambdas accordingly. -- Howard. Sent from my iPad On 13/01/2013, at 2:04 AM, Doug Lea wrote: > On 01/11/13 21:37, Joe Darcy wrote: > >> I would prefer to cautionary note along the lines of "if you want numerical >> accuracy, take care to use a summation algorithm with defined worst-case >> behavior." >> >> (Varying magnitude is not so much of a problem if you add things up in the >> right >> order.) > > Thanks. I do not believe such an algorithm exists, because > no ordering control is possible, and all other known accuracy > improvements (like Kahn) require multiword atomicity, which we > explicitly do not provide. > > Which leaves me thinking that the current disclaimer (below) > is the best we can do. > > -Doug > "The order of accumulation within or across threads is not guaranteed. Thus, this class may not be applicable if numerical stability is required, especially when combining values of substantially different orders of magnitude."
Re: Request for Review (#4) : CR#8001634 : Initial set of lambda functional interfaces
Couple of quick comments:
1. I think the naming is inconsistent between class and method, e.g.
IntFunction has an applyAsInt method. Why not either IntFunction and intApply
or FunctionAsInt and applyAsInt?
2. It would be good to have a description of the stream library, perhaps an
expanded for of Brian's State of Streams document referenced throughout the API
like the Collections API has.
Sent from my iPad
On 20/11/2012, at 5:31 PM, David Holmes wrote:
> Hi Mike,
>
> Minor typos and inconsistencies:
>
> DoubleBinaryOperator.java
>
> 28 * Combines two {@code double} operands producing an {@code double}
> result.
>
> an -> a
>
> 51 * @param rightvalue used as the right operand
>
> Need space after right
>
> 52 * @return result value of the operation
>
> "result value" doesn't read right - just "@return the result of ..." -
> as for BinaryOperator.operate
>
> General consistency: all like methods in a family of interfaces should
> use the same wording. Eg BinaryOperator.operate says "upon the provided
> operands" whereas DoubleBinaryOperator.* says "upon the operands". Ditto
> across families ie UnaryOperator and BinaryOperator should use
> consistent terminology for operands and results.
>
> ---
>
> DoubleBlock.java:
>
> 31 * @param The type of input objects to {@code accept}.
>
> DoubleBlock is not a generic type. (Surely this should be generating a
> javadoc warning?)
>
> ---
>
> DoubleFunction.java
>
> 32 * @param the type of input objects to the {@code apply} operation.
>
> You now potentially have multiple operation methods, and T refers to the
> input of all of them.
>
>
>
> General consistency comments across everything:
> - Use of operand versus provided operand versus input value etc
> - Use of result vs computed result vs result value vs output etc
>
> ---
>
> Function.java
>
> 33 * @param the type of output objects from {@code apply} operation.
>
> from -> from the
>
> 43 * @param t the input object to be to which the function will
> be applied.
>
> delete "to be" ? Or else re-word.
>
> ---
>
> UnaryOperator.java
>
> 28 * Operator on a single operand.
>
> Operator -> operate ?
>
> 30 * @param the type of input objects to {@code operate} and of
> the result.
>
> objects -> object
>
> ---
>
> Cheers,
> David
>
>
> On 20/11/2012 2:55 PM, Mike Duigou wrote:
>> I have posted another revision at
>>
>> http://cr.openjdk.java.net/~mduigou/8001634/5/webrev/
>>
>> This version contains some method remaining in the {I|L|D}UnaryOperation and
>> {I|L|D}BinaryOperator and a few Javadoc fixes.
>>
>> The package javadoc ie. package-info.java, is known to be a weak point right
>> now. We're still debating what must be said here and what would be better
>> said attached to the APIs which consume these functional interfaces.
>>
>> We don't anticipate many (any?) further changes to the naming before commit
>> at this point.
>>
>> Mike
>>
>> On Nov 13 2012, at 17:19 , Mike Duigou wrote:
>>
>>> Hello all;
>>>
>>> I apologize for the quick turnaround from the second review request [1] but
>>> I've updated the webrev again:
>>>
>>> http://cr.openjdk.java.net/~mduigou/8001634/4/webrev/
>>>
>>> Blame a busy Paul Sandoz who his making significant progress on the
>>> primitive specializations implementation. ;-)
>>>
>>> This update includes:
>>>
>>> - Block.apply renamed to Block.accept
>>> - {Int|Long|Double}Block specializations added.
>>> - Commented out "extends Combiner" in BinaryOperator was removed for
>>> now since Combiner is out of scope for this review.
>>> - The {Int|Long|Double} specializations of BinaryOperator and UnaryOperator
>>> now show commented out extends of the generic version along with commented
>>> out default methods. This change will not be part of the commit but is
>>> meant to show where the implementation will be going.
>>> - The {Int|Long|Double} specializations of Supplier now extend generic
>>> Supplier, have getAs{Int|Long|Double} as their abstract method and provide
>>> a commented out default get() method to satisfy the need for a get
>>> implementation.
>>> - The {Int|Long|Double} specializations of Function now extend generic
>>> Function, have applyAs{Int|Long|Double} as their abstract method and
>>> provide a commented out default apply() method to satisfy the need for an
>>> apply implementation.
>>>
>>> Mike
>>>
>>> [1]
>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-November/012225.html
>
Re: Review Request: CR#8001634 : Initial set of lambda functional interfaces
General Comment
=
For the collections framework there is a description of the whole framework
(http://docs.oracle.com/javase/7/docs/technotes/guides/collections/index.html);
why not do the same for the lambda framework and put a reference to the
description in all the interfaces' and classes' Javadoc. This description would
be a good place to talk about concurrency and side effects and to show
suggested usage idioms.
Overall Structure
=
I will preface this comment saying that you might be considering doing this
suggestion; but it isn't included at this stage because you are previewing a
subset that excludes default methods etc.
With the Collections Framework there are root interfaces, Collection and Map,
and progressively there are more specific interfaces. This structure is very
handy because it allows collections to be treated abstractly. Likewise it would
be handy if the functions had Combiner at the top of the hierarchy. In
particular:
public interface Combiner {
V operate(L left, R right);
}
public interface BinaryOperator extends Combiner {
T operate(T left, T right);
}
public interface UnaryOperator extends Combiner {
default T operate(T left, Void notUsed) { return operate(left); }
T operate(T operand);
}
public interface ZerothOperator extends Combiner {
default T operate(Void notUsed1, Void notUsed2) { return operate(); }
T operate();
}
public interface IntBinaryOperator extends BinaryOperator {
default Integer operate(Integer left, Integer right) { return
intOperate(left, right); }
int intOperate(int left, int right);
}
Similarly long and double versions.
public interface IntUnaryOperator extends UnaryOperator {
default Integer operate(Integer operand) { return intOperate(operand); }
int intOperate(int operand);
}
Similarly long and double versions.
public interface Mapper extends Combiner {
default R operate(T t, Void notUsed) { return map(T t); }
R map(T t);
}
public interface IntMapper extends Mapper {
default Integer map(T t) { return intMap(t); }
int intMap(T t);
}
Similarly long and double versions.
public interface Predicate extends Mapper {
default Boolean map(T t) { return test(t); }
boolean test(T t);
}
public interface Block extends Mapper {
default Void map(T t) { apply(t); return null; }
void apply(T t);
}
public interface Factory extend ZerothOperator {
default T operate() { return make(); }
T make();
}
Float Variation
===
There are int, long, and double specialisations; float specialisations would
also be useful (particularly for graphics). Also, some day maybe the JVM will
use the graphics co-processor (which are much faster for float than double).
Typo
The last section of package-info "All functional interface implementations are
expected to:" seems to be a typo. Presumably this file was only partially
completed.
Keep up the good work,
-- Howard.
Sent from my iPad
On 01/11/2012, at 7:16 AM, Mike Duigou wrote:
> There's a large set of library changes that will be coming with Lambda. We're
> getting near the end of the runway and there's lots left to do so we want to
> start the process of getting some of the more stable pieces put back to the
> JDK8 repositories. We've spent a some time slicing things into manageable
> chunks. This is the first bunch. We'd like to time-box this review at one
> week, since there are many more pieces to follow.
>
> The first chunk is the basic set of functional interface types. While this
> set is not complete, it is enough to be able to proceed on some other pieces.
> This set contains no extension methods (we'll do those separately) and does
> not contain all the specializations we may eventually need.
>
> The specification is limited; most of the interesting restrictions
> (side-effect-freedom, idempotency, stability) would really be imposed not by
> the SAM itself by by how the SAM is used in a calculation. However, some
> common doc for "how to write good SAMs" that we can stick in the package doc
> would be helpful. Suggestions welcome.
>
> Elements of this naming scheme include:
> - Each SAM type has a unique (arity, method name) pair. This allows SAMs to
> implement other SAMs without collision.
> - The argument lists are structured so that specializations act on the first
> argument(s), so IntMapper is a specialization of Mapper, and
> IntBinaryOperator is a specialization of BinaryOperator.
>
> In order to get the most useful feedback out of this review, we'd like to ask
> you follow the following guidelines for the review:
>
> - We are time-boxed at one week. (until Nov. 7th)
>
> - Please review the whole bunch in a single message if possible, rather than
> in bits and pieces. It is far easier to extract useful feedback from one
> complete review than from a dozen partial ones.
>
> - Please wait a few days before replying to other people's reviews! We want
Re: Request for Review (#3) : CR#8001634 : Initial set of lambda functional interfaces
Great rate of progress on this - well done.
The package Javadoc still needs some work.
Sent from my iPad
On 14/11/2012, at 1:19 AM, Mike Duigou wrote:
> Hello all;
>
> I apologize for the quick turnaround from the second review request [1] but
> I've updated the webrev again:
>
> http://cr.openjdk.java.net/~mduigou/8001634/4/webrev/
>
> Blame a busy Paul Sandoz who his making significant progress on the primitive
> specializations implementation. ;-)
>
> This update includes:
>
> - Block.apply renamed to Block.accept
> - {Int|Long|Double}Block specializations added.
> - Commented out "extends Combiner" in BinaryOperator was removed for
> now since Combiner is out of scope for this review.
> - The {Int|Long|Double} specializations of BinaryOperator and UnaryOperator
> now show commented out extends of the generic version along with commented
> out default methods. This change will not be part of the commit but is meant
> to show where the implementation will be going.
> - The {Int|Long|Double} specializations of Supplier now extend generic
> Supplier, have getAs{Int|Long|Double} as their abstract method and provide a
> commented out default get() method to satisfy the need for a get
> implementation.
> - The {Int|Long|Double} specializations of Function now extend generic
> Function, have applyAs{Int|Long|Double} as their abstract method and provide
> a commented out default apply() method to satisfy the need for an apply
> implementation.
>
> Mike
>
> [1]
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-November/012225.html
