Это вполне нормальное явление, когда наука не поспевает за практикой. Поэтому отсутствие математически выверенного ответа не делает текущий подход каким-то плохим. Более того человечество видит объективные (для кого-то даже впечатляющие) результаты развития так вами ненавистных моделей с десятками слоев. Однако чем могут похвастаться модели с одним обучающим слоем? Уж вполне достаточно времени прошло, чтобы они могли раскрыть свой потенциал.
Совершенно излишне говорить, что это полное вранье, а авторы статьи даже не потрудились открыть эту статью, чтобы её прочитать
А вы не потрудились ваши слова подкрепить даже хотя бы какой-нибудь статьей (не вашего авторства).
Все вокруг непонимающие идиоты, кроме, конечно же, вас. А в чем собственно ваше предложение/решение заключается?
Но тогда я спрашиваю: а что дает два, три и больше скрытых слоев?
Насколько я знаю и понимаю наличие больше 1 слоя позволяет аппроксимировать нелинейные функции. И на одном слое, например, не получится решить задачу классификации линейно неразделимых объектов.
Отдается тоже в UTC. По крайней мере это справедливо для драйвера PostgreSQL в Java. При касте в текст он меняет на другую зону, но и это не проблема, так как она указывается на конце.
Хранит даты в непонятно какой таймзоне настроенной где-то там на стороне сервера безо всякого твоего контроля
Что за бред? Значения хранятся в UTC. При сохранении значения можно явно указать к какому часовому поясу оно относится и настройки сервера, на котором БД, ни на что не повлияют
Если у добавленных значений совпадает хэш, они попадут в один бакет в формате связного списка. Работа со списком как раз и даёт O(N). Но, при достижении определенного размера, список будет преобразован в дерево, где сложность уже O(logN), в целях оптимизации.
Такая ситуация возможна, если функция хэширования реализована плохо и, как следствие, имеет много коллизий
В случае отсутствия ключа в мапе возвращается null, поэтому стоит предварительно проверять наличие пары через containsKey(Object key), иначе можем получить NullPointerException в дальнейшем.
Вредительский совет. Зачем для получения значения 2 раза осуществлять его поиск? Просто результат получения значения на null проверять и всё
А чем была обоснована такая необходимость запрашивать данные сразу для 1000 гуидов в одном запросе, если не секрет?
Можно, например, применить пагинацию со стороны клиента и разбить эти 1000 гуидов на группы, кинуть несколько запросов асинхронно. Плюс будет удобно в разных потоках данные обработать, если захочется
Пример с монеткой кажется неоднозначным. Согласно классическому подходу, вероятность выпадения орла или решки всегда будет составлять 0,5, независимо от предыдущих результатов. Возможно, автор просто не до конца раскрыл свою мысль.
Правильно понимаю, что в данном случае эксперимент с монеткой рассматривается как «чёрный ящик» и мы делаем вывод, что если орел выпал 10 раз подряд, то и в дальнейшем он будет выпадать чаще, так как мы просто не знаем условий проведения эксперимента?
Плюс Мульти выгоднее базового тарифа и стоит меньше в расчёте на одного человека, а также позволяет максимально использовать все возможности подписки.
Насчет использовать все возможности, конечно, притянуто за уши. В стандартную подписку итак весь функционал входит. Разница только в количестве возможных пользователей
Так речь не об этом. Автор явно же описал, что под обратимостью имеется в виду.
Это вполне нормальное явление, когда наука не поспевает за практикой. Поэтому отсутствие математически выверенного ответа не делает текущий подход каким-то плохим. Более того человечество видит объективные (для кого-то даже впечатляющие) результаты развития так вами ненавистных моделей с десятками слоев. Однако чем могут похвастаться модели с одним обучающим слоем? Уж вполне достаточно времени прошло, чтобы они могли раскрыть свой потенциал.
А вы не потрудились ваши слова подкрепить даже хотя бы какой-нибудь статьей (не вашего авторства).
Все вокруг непонимающие идиоты, кроме, конечно же, вас. А в чем собственно ваше предложение/решение заключается?
Насколько я знаю и понимаю наличие больше 1 слоя позволяет аппроксимировать нелинейные функции. И на одном слое, например, не получится решить задачу классификации линейно неразделимых объектов.
Отдается тоже в UTC. По крайней мере это справедливо для драйвера PostgreSQL в Java. При касте в текст он меняет на другую зону, но и это не проблема, так как она указывается на конце.
Что за бред? Значения хранятся в UTC. При сохранении значения можно явно указать к какому часовому поясу оно относится и настройки сервера, на котором БД, ни на что не повлияют
Если у добавленных значений совпадает хэш, они попадут в один бакет в формате связного списка. Работа со списком как раз и даёт O(N). Но, при достижении определенного размера, список будет преобразован в дерево, где сложность уже O(logN), в целях оптимизации.
Такая ситуация возможна, если функция хэширования реализована плохо и, как следствие, имеет много коллизий
Вредительский совет. Зачем для получения значения 2 раза осуществлять его поиск? Просто результат получения значения на null проверять и всё
Слова "FetchType EAGER" в заголовке статьи явно лишние
А чем была обоснована такая необходимость запрашивать данные сразу для 1000 гуидов в одном запросе, если не секрет?
Можно, например, применить пагинацию со стороны клиента и разбить эти 1000 гуидов на группы, кинуть несколько запросов асинхронно. Плюс будет удобно в разных потоках данные обработать, если захочется
Само наличие санкционного списка. Оказаться в нём можно в любую секунду.
Это само собой.
Я имел ввиду Google Workspace. Стоило уточнить
Это все, конечно, очень интересно. Но кто-то до сих пор в России пользуется сервисами Google, кроме YouTube, на полном серьёзе?
Пример с монеткой кажется неоднозначным. Согласно классическому подходу, вероятность выпадения орла или решки всегда будет составлять 0,5, независимо от предыдущих результатов. Возможно, автор просто не до конца раскрыл свою мысль.
Правильно понимаю, что в данном случае эксперимент с монеткой рассматривается как «чёрный ящик» и мы делаем вывод, что если орел выпал 10 раз подряд, то и в дальнейшем он будет выпадать чаще, так как мы просто не знаем условий проведения эксперимента?
Насчет использовать все возможности, конечно, притянуто за уши. В стандартную подписку итак весь функционал входит. Разница только в количестве возможных пользователей