Войти или зарегистрироваться
  • Вы находитесь в сообществе Rubukkit. Мы - администраторы серверов Minecraft, разрабатываем собственные плагины и переводим на различные языки плагины наших коллег из других стран.

Помогите Метод вероятности события

qwerqtyk

Новичок
Пользователь
Баллы
6
Код:
public class Utils {

    static final Random randomNumberGenerator = new Random();

    public static boolean chance(double percent) {
        return randomNumberGenerator.nextDouble(99.0) + 1.0 <= percent;
    }
}
Возник вопрос.. почему никто не использует подобное? В 99% проектах на гите, в каждом классе создают отдельный экземпляр рандома
Также интересно о правильности наименования) Шанс или все таки вероятность?
 
Код:
public class Utils {

    static final Random randomNumberGenerator = new Random();

    public static boolean chance(double percent) {
        return randomNumberGenerator.nextDouble(99.0) + 1.0 <= percent;
    }
}
Возник вопрос.. почему никто не использует подобное? В 99% проектах на гите, в каждом классе создают отдельный экземпляр рандома
Также интересно о правильности наименования) Шанс или все таки вероятность?
Потому что есть штуки по производительнее этой и в них можно указывать bound случайного числа
Допустим ThreadLocalRandom
 
Потому что, как сказал OxLarion1 выше, есть штуки попроизводительнее. И ещё потому, что ГПСЧ нам гарантирует равномерное распределение случайных величин, но в отличие от истинно случайных генераторов, выделение, например каждого второго элемента для одних случайных событий и каждого первого для других случайных событий, не приведёт к тому, что распределение останется равномерным.
Т.е. мы можем получить ситуацию, когда выброс шанса в одном классе будет всегда давать положительный исход, а в другом всегда будет отрицательный, что некорректно.
 
Потому что, как сказал OxLarion1 выше, есть штуки попроизводительнее. И ещё потому, что ГПСЧ нам гарантирует равномерное распределение случайных величин, но в отличие от истинно случайных генераторов, выделение, например каждого второго элемента для одних случайных событий и каждого первого для других случайных событий, не приведёт к тому, что распределение останется равномерным.
Т.е. мы можем получить ситуацию, когда выброс шанса в одном классе будет всегда давать положительный исход, а в другом всегда будет отрицательный, что некорректно.
Почитал немного, но все равно не очень понял) Разве он не должен быть быстрее, только при мультипотоке? Ииии... можно ли юзать метод? Ибо писать каждый раз "nextDouble(0, 100) >= 75" тот еще гемор) + противоречит правилу "не повторяйся"
 
Последнее редактирование:
Почитал немного, но все равно не очень понял) Разве он не должен быть быстрее, только при мультипотоке? Ииии... можно ли юзать метод? Ибо писать каждый раз "nextDouble(0, 100) >= 75" тот еще гемор) + противоречит правилу "не повторяйся"
Самое простое -- он избавляется от синхронизации, которая есть в реализации обычного Random'а, что увеличивает производительность. Как написано, в других реализациях так же изменён алгоритм генерации, что приводит к увеличению производительности.
Да, можно использовать метод, имеющий один источник шансов, если ситуация, когда плагин, отвечающий за дроп, никогда не дропает предмет с шансом в 95% (nextDouble(0,100) >= 5 всегда меньше 5) из-за того, что используется достаточно редко, относительно других вариантов, как пример.
 

Поделиться этой страницей

Назад
Верх