Может уважаемому профессору просто стоит признать, что никаким интеллектом в нейронных сетях и не пахнет?
Что это просто невероятных размеров вероятностный классификатор, основанный на зубрежке?
Ну так никто же не мешает делать всё по старинке и потом качать изменения. МС просто предлагают логичное продолжение, если мы пулим, пишем, коммитим и пушим через студию, то почему пулл реквесты должны обязательно делаться через другое приложение, которое еще и плохо к этому приспособлено?
В чем смысл использовать ConcurrentQueue + Thread.Yield()?
Исключения вряд ли так часто возникают, может лучше блокировать этот отдельный поток хотя бы через BlockingCollection?
Возможно еще как, просто надо делать строго определенные вещи, а не давить изо всех сил как боты делают. Это сам опенаи дал оценку в 3% шанса, потому что он так и не смог выработать стратегию нормальную для такого пика.
И было явно видно, что боты совсем потерялись, они не знали что им делать на карте, тк внезапно люди стали огрызаться, а терпеть и играть от защиты боты не умеют, это намного сложнее и неочевидней. В таких случаях ты с точки зрения бота наоборот делаешь себе хуже, зажимаясь на своей базе и изредка высовывая из нее нос, но «на скилухе» переворачивая пару стычек. Для этих ботов похоже такая стратегия слишком дальнодействующая, чтобы они могли ее понять.
Не совсем понятно, причем тут вообще селективность. Какой бы идеальной она не была, если фильтр запроса пропустил хоть одну колонку в последовательности индекса, не видать index seek'ов как своих ушей.
В данном случае первый запрос фильтровал по дате, ему только дата и нужна была в индексе, если бы это был SqlServer, то сообщение спокойно можно было бы вообще пихать в инклюды.
Второй же запрос наоборот чхал на дату, и от текущего индекса ему пользы никакой, всё равно условный «бинарный поиск» не может отработать, тк данные отсортированы сначала по дате, и только на следующем уровне уже по сообщению.
Так что поведение более чем ожидаемо. Для таких диаметрально противоположных запросов надо просто два отдельных индекса.
Конечно, если в итоге оказывается, что фильтр по дате никогда и не используется, то и проблема не стоит, но и новый индекс тогда не особо полезен, тк в нем нет типа сообщения, и чтобы его проверить, придется лазить в саму таблицу. Хотя на этом конкретном примере скорее всего тексты сообщений не пересекаются между типами (обратное для логов было бы странно :)), так что фильтр по типу сообщения скорее всего вообще никогда ничего в реальности не фильтрует и его можно спокойно убрать.
Ну а если еще и ищут в 99% случаев только тип 'error' то вообще можно сделать фильтрованный индекс, который был бы маленьким, и позволял бы искать ошибки быстро, а просто логи читать можно было бы как раньше, по дате
Насчет забытых транзакций в SSMS при ошибках, давно привык всегда после открытия транзакции писать set xact_abort on. Не шумит визуально, как try/catch, а делает в общем-то то что и надо в большинстве случаев — как только ошибка, сразу откат транзакции.
Учитывая что FileName в индексе аж на 4 месте, и его влияние на распределение данных в индексе скорее всего будет уже очень маленьким, не лучше ли его просто добавить в инклюд?
Да, работать будет помедленней, тк будет скан листьев индекса (но как я писал, их скорее всего уже очень мало), но никаких падений после этого уже не может быть, а key lookup всё так же исчезнет.
А есть ли хоть какое-то объяснение для дилетантов, что мешает начать аннигилировать кварку из протона и антикварку из соседнего нейтрона? Как я понимаю, расстояние между нейтронами и протонами значительно меньше их размеров. Или всё же оно недостаточно мало, чтобы пары из соседних нуклонов находили друг друга?
Я думаю, если любого вменяемого админа насильно заставят скрещивать ужа с ежом, он будет прыгать от радости, что майкрософт сделали за него всю грязь, и можно просто дернуть пару простых линуксовых приложений из винды или наоборот без написания собственных костылей или переписывания всего и вся.
Тут уже столько написали, что даже как-то неловко добавлять, и так на неделю фиксов.
Но меня довольно сильно раздражает лагающая анимация открытия оффтопиков.
Windows 10 x64, Vivaldi последний.
З.Ы.: и еще междустрочный интервал и отступы в комментариях явно великоваты, слишком большая стена получается даже от небольших комментариев в 2-3 строки.
Абсолютно аналогичное поведение было бы и у человека, который первый раз столкнулся с такой ситуацией.
Этот бот уже научился одной из самых сложных вещей, выигрывать линию в салат. Теперь нужна только гигантская база для обучения взаимодействию каждого условного класса героев с каждым в позиционке, и всё, камбеки людям не светят.
Если вам надо рисовать абстрактного вида схемы, да еще и с коллегами по работе их в реалтайме обсуждать, то да, тут с доской вряд ли что-то сравнится.
Но в чем смысл делать текстовые пометки в на бумаге, когда там нельзя ни исправить, ни найти, ни скопировать туда/оттуда, ни банально вставить что-то между уже написанными пунктами?
Даже notepad.exe лучше с этим справляется
да вроде так же как и раньше, win+r→netplwiz→на юзере снять галку «требовать ввод пароля». При применении спрашивает пароль юзера повторно и дальше будет спрашивать только на локскрине
Что это просто невероятных размеров вероятностный классификатор, основанный на зубрежке?
Осталось добавить лень и надоедание от повторений, и кожаные мешки будут больше не нужны.
Исключения вряд ли так часто возникают, может лучше блокировать этот отдельный поток хотя бы через BlockingCollection?
И было явно видно, что боты совсем потерялись, они не знали что им делать на карте, тк внезапно люди стали огрызаться, а терпеть и играть от защиты боты не умеют, это намного сложнее и неочевидней. В таких случаях ты с точки зрения бота наоборот делаешь себе хуже, зажимаясь на своей базе и изредка высовывая из нее нос, но «на скилухе» переворачивая пару стычек. Для этих ботов похоже такая стратегия слишком дальнодействующая, чтобы они могли ее понять.
В данном случае первый запрос фильтровал по дате, ему только дата и нужна была в индексе, если бы это был SqlServer, то сообщение спокойно можно было бы вообще пихать в инклюды.
Второй же запрос наоборот чхал на дату, и от текущего индекса ему пользы никакой, всё равно условный «бинарный поиск» не может отработать, тк данные отсортированы сначала по дате, и только на следующем уровне уже по сообщению.
Так что поведение более чем ожидаемо. Для таких диаметрально противоположных запросов надо просто два отдельных индекса.
Конечно, если в итоге оказывается, что фильтр по дате никогда и не используется, то и проблема не стоит, но и новый индекс тогда не особо полезен, тк в нем нет типа сообщения, и чтобы его проверить, придется лазить в саму таблицу. Хотя на этом конкретном примере скорее всего тексты сообщений не пересекаются между типами (обратное для логов было бы странно :)), так что фильтр по типу сообщения скорее всего вообще никогда ничего в реальности не фильтрует и его можно спокойно убрать.
Ну а если еще и ищут в 99% случаев только тип 'error' то вообще можно сделать фильтрованный индекс, который был бы маленьким, и позволял бы искать ошибки быстро, а просто логи читать можно было бы как раньше, по дате
И кто на этот раз первый придумал? :)
www.reddit.com/r/deepfakes/comments/7ox5vn/fakeapp_a_desktop_tool_for_creating_deepfakes
Порно как всегда двигает прогресс :)
Да, работать будет помедленней, тк будет скан листьев индекса (но как я писал, их скорее всего уже очень мало), но никаких падений после этого уже не может быть, а key lookup всё так же исчезнет.
Но меня довольно сильно раздражает лагающая анимация открытия оффтопиков.
Windows 10 x64, Vivaldi последний.
З.Ы.: и еще междустрочный интервал и отступы в комментариях явно великоваты, слишком большая стена получается даже от небольших комментариев в 2-3 строки.
Этот бот уже научился одной из самых сложных вещей, выигрывать линию в салат. Теперь нужна только гигантская база для обучения взаимодействию каждого условного класса героев с каждым в позиционке, и всё, камбеки людям не светят.
Но в чем смысл делать текстовые пометки в на бумаге, когда там нельзя ни исправить, ни найти, ни скопировать туда/оттуда, ни банально вставить что-то между уже написанными пунктами?
Даже notepad.exe лучше с этим справляется