Java 8 est-il un bon moyen de répéter une valeur ou une fonction?

Dans de nombreuses autres langues, par exemple. Haskell, il est facile de répéter une valeur ou une fonction plusieurs fois, par exemple. pour obtenir une liste de 8 copies de la valeur 1:

take 8 (repeat 1)

mais je ne l'ai pas encore trouvé dans Java 8. Existe-t-il une telle fonction dans le JDK de Java 8?

Ou bien quelque chose d'équivalent à une gamme comme

[1..8]

Cela semblerait un remplacement évident pour une déclaration verbeuse en Java comme

for (int i = 1; i <= 8; i++) {
    System.out.println(i);
}

avoir quelque chose comme

Range.from(1, 8).forEach(i -> System.out.println(i))

bien que cet exemple particulier ne semble pas beaucoup plus concis en fait ... mais j'espère qu'il est plus lisible.

Pour cet exemple spécifique, vous pouvez faire:

IntStream.rangeClosed(1, 8)
         .forEach(System.out::println);

Si vous avez besoin d'une étape différente de 1, vous pouvez utiliser une fonction de mappage, par exemple, pour une étape de 2:

IntStream.rangeClosed(1, 8)
         .map(i -> 2 * i - 1)
         .forEach(System.out::println);

Ou créez une itération personnalisée et limitez la taille de l'itération:

IntStream.iterate(1, i -> i + 2)
         .limit(8)
         .forEach(System.out::println);

Voici une autre technique que j'ai utilisée l'autre jour:

Collections.nCopies(8, 1)
           .stream()
           .forEach(i -> System.out.println(i));

L' Collections.nCopiesappel crée une copie Listcontenant la nvaleur que vous fournissez. Dans ce cas, c'est la Integervaleur encadrée 1. Bien sûr, cela ne crée pas réellement une liste avec des néléments; il crée une liste «virtualisée» qui ne contient que la valeur et la longueur, et tout appel à l' getintérieur de la plage renvoie simplement la valeur. La nCopiesméthode existe depuis que le Framework de collections a été introduit dans le JDK 1.2. Bien sûr, la possibilité de créer un flux à partir de son résultat a été ajoutée dans Java SE 8.

Gros problème, une autre façon de faire la même chose dans à peu près le même nombre de lignes.

Cependant, cette technique est plus rapide que l' approche IntStream.generateet IntStream.iterate, et étonnamment, elle est également plus rapide que l' IntStream.rangeapproche.

Car iterateet generatele résultat n'est peut-être pas trop surprenant. Le framework de flux (en fait, les Spliterators pour ces flux) est construit sur l'hypothèse que les lambdas généreront potentiellement des valeurs différentes à chaque fois, et qu'ils généreront un nombre illimité de résultats. Cela rend la division parallèle particulièrement difficile. La iterateméthode est également problématique dans ce cas car chaque appel nécessite le résultat du précédent. Ainsi, les flux utilisant generateet iteratene fonctionnent pas très bien pour générer des constantes répétées.

La performance relativement médiocre de rangeest surprenante. Cela aussi est virtualisé, donc les éléments n'existent pas tous en mémoire et la taille est connue à l'avance. Cela devrait conduire à un séparateur rapide et facilement parallélisable. Mais étonnamment, cela n'a pas très bien fonctionné. Peut-être que la raison est qu'il rangefaut calculer une valeur pour chaque élément de la plage, puis appeler une fonction dessus. Mais cette fonction ignore simplement son entrée et renvoie une constante, donc je suis surpris que cela ne soit pas incorporé et tué.

La Collections.nCopiestechnique doit faire du boxing / unboxing afin de gérer les valeurs, car il n'y a pas de spécialisations primitives de List. Puisque la valeur est la même à chaque fois, elle est essentiellement encadrée une fois et cette boîte est partagée par toutes les ncopies. Je soupçonne que la boxe / unboxing est hautement optimisée, voire intrinsèque, et qu'elle peut être bien intégrée.

Voici le code:

    public static final int LIMIT = 500_000_000;
    public static final long VALUE = 3L;

    public long range() {
        return
            LongStream.range(0, LIMIT)
                .parallel()
                .map(i -> VALUE)
                .map(i -> i % 73 % 13)
                .sum();
}

    public long ncopies() {
        return
            Collections.nCopies(LIMIT, VALUE)
                .parallelStream()
                .mapToLong(i -> i)
                .map(i -> i % 73 % 13)
                .sum();
}

Et voici les résultats JMH: (2.8GHz Core2Duo)

Benchmark                    Mode   Samples         Mean   Mean error    Units
c.s.q.SO18532488.ncopies    thrpt         5        7.547        2.904    ops/s
c.s.q.SO18532488.range      thrpt         5        0.317        0.064    ops/s

Il y a une bonne quantité de variance dans la version ncopies, mais dans l'ensemble, cela semble confortablement 20 fois plus rapide que la version de gamme. (Je serais tout à fait prêt à croire que j'ai fait quelque chose de mal, cependant.)

Je suis surpris de voir à quel point la nCopiestechnique fonctionne. En interne, cela ne fait pas grand-chose de spécial, le flux de la liste virtualisée étant simplement implémenté en utilisant IntStream.range! Je m'attendais à ce qu'il soit nécessaire de créer un séparateur spécialisé pour que cela aille rapidement, mais cela semble déjà être assez bon.

Par souci d'exhaustivité, et aussi parce que je ne pouvais pas m'en empêcher :)

La génération d'une séquence limitée de constantes est assez proche de ce que vous verriez dans Haskell, uniquement avec un niveau de verbosité Java.

IntStream.generate(() -> 1)
         .limit(8)
         .forEach(System.out::println);

Une fois qu'une fonction de répétition est quelque part définie comme

public static BiConsumer<Integer, Runnable> repeat = (n, f) -> {
    for (int i = 1; i <= n; i++)
        f.run();
};

Vous pouvez l'utiliser de temps en temps de cette façon, par exemple:

repeat.accept(8, () -> System.out.println("Yes"));

Pour obtenir et équivalent à Haskell

take 8 (repeat 1)

Tu pourrais écrire

StringBuilder s = new StringBuilder();
repeat.accept(8, () -> s.append("1"));

C'est ma solution pour implémenter la fonction times. Je suis un junior donc j'admets que cela pourrait ne pas être idéal, je serais heureux d'apprendre si ce n'est pas une bonne idée pour une raison quelconque.

public static <T extends Object, R extends Void> R times(int count, Function<T, R> f, T t) {
    while (count > 0) {
        f.apply(t);
        count--;
    }
    return null;
}

Voici quelques exemples d'utilisation:

Function<String, Void> greet = greeting -> {
    System.out.println(greeting);
    return null;
};

times(3, greet, "Hello World!");