Спасибо за ссылки, выглядит действительно интересно. В целом проект и является gradle плагином для генерации DTO сущностей на основе документации AsyncAPI. Т.е. у нас один сервис публикует сообщения в брокер, соответственно в другом сервисе-консьюмере надо заводить DTO для получения этих сообщений. Вот и пришла мысль прикрутить нормальную документацию к сервису-источнику а в остальных сервисах генерить эти DTO по документации, избавиться от ручного копирования кода между сервисами. Особенно полезно когда сервисами занимаются разные команды.
Спасибо за замечание. Конечно можно компилировать из памяти, но если вы хотите все таки генерировать код, который сможете глазами посмотреть и добавить в git, то без сохранения никак. А так, да, в общем случае не важно где хранится исходник.
А вот при удаленных вычислениях довольно важно передавать исходный код или bytecode. У Java нет прямой совместимости, поэтому если на стороне клиента собирать bytecode в версии выше чем на узле, то будут проблемы. В этом случае надежнее передавать именно исходники, для исключения зависимостей в версиях Java между клиентом и узлом.
Приходилось реализовывать Hierarchical k-mean на Java. Задача кластеризации SIFT-дескрипторов. Стандартный k-means довольно медленный и не параллельный (есть в Apache Math), но вот иерархического так и не смогли найти, пришлось писать.
Извиняюсь, это я не сразу понял, что вы назвали целевой переменной. Я подумал, что целевая переменная — это одна из компонент дескриптора фичи. Если рассмотреть область поиска изображений, то в случае с SIFT это одна из 128 компонент.
Вот такой подход меня всегда смущает. Насколько корректно оценивать качество отбора по результатам классификации? Ведь результат классификации очень сильно зависит от самого классификатора. И при выборе неподходящего метода классификации можно получить результаты далекие от правды.
А разве перед отбором фич их не надо получить? Вы же в любом случае будете применять feature extraction методы.
По какому принципу выбирается целевая переменная, что делать в случае высокой размерности фич?
Как оценивается точность отбора фич?
Довольно часто после выделения фич применяется не классификация, а кластеризация. Как от этого может поменяться выбор метода и как оценить качество кластеризации?
Для примера приводится такой расчёт: если книга объёмом в сто страниц будет прочитана сто раз, то её автор заработает $1000. В то же самое время, если 200-страничное произведение будет прочитано только 100 раз, то его автор получит такой же доход в $1000, как и автор книги более скромного размера.
Если взглянуть со стороны верстальщика, то непонятно какие границы должны быть у блоков «Слайд» и «Краткое пояснение к слайду».
Как должны вести себя эти блоки при наличии более длинного текста? Есть какая-то максимальная ширина блока (например 30% ширины слайдера) и далее текст переносится на следующую строку или блок растягивается на весь слайдер?
Чтобы не увидеть потом слайдер накрытый слоем текста, стоит такие моменты предусматривать и показывать в макетах, как выглядят блоки с текстом в несколько строк.
Здесь должен быть класс ServerImpl. Брал код из своего проекта, забыл заменить. Сейчас исправлю. RMIHttpServerImpl отличается от ServerImpl тем, что в super() вызывается этот конструктор, используя фабрику RMIHttpToPortSocketFactory. Она и позволяет организовать RMI over HTTP.
Конструктор выглядит так:
public RMIHttpServerImpl(int port) throws RemoteException {
super(port, new RMIHttpToPortSocketFactory(), new RMIHttpToPortSocketFactory());
}
Спасибо за ссылки, выглядит действительно интересно. В целом проект и является gradle плагином для генерации DTO сущностей на основе документации AsyncAPI. Т.е. у нас один сервис публикует сообщения в брокер, соответственно в другом сервисе-консьюмере надо заводить DTO для получения этих сообщений. Вот и пришла мысль прикрутить нормальную документацию к сервису-источнику а в остальных сервисах генерить эти DTO по документации, избавиться от ручного копирования кода между сервисами. Особенно полезно когда сервисами занимаются разные команды.
Спасибо за замечание. Конечно можно компилировать из памяти, но если вы хотите все таки генерировать код, который сможете глазами посмотреть и добавить в git, то без сохранения никак. А так, да, в общем случае не важно где хранится исходник.
А вот при удаленных вычислениях довольно важно передавать исходный код или bytecode. У Java нет прямой совместимости, поэтому если на стороне клиента собирать bytecode в версии выше чем на узле, то будут проблемы. В этом случае надежнее передавать именно исходники, для исключения зависимостей в версиях Java между клиентом и узлом.
Верно, в итоге же и сделал через дифференцирование.
p.s. Сам заказал такой из Китая, жду уже 2 месяца. Китайцы потеряли товар, сказали будут высылать повторно.
Возникли следующие вопросы:
наверное количество раз должно быть разным?
p.s. С этого года библиотека стала open source. Интересно, кто-то пользуется этой библиотекой, кроме нашей компании?
Они тут очевидно есть.
Как должны вести себя эти блоки при наличии более длинного текста? Есть какая-то максимальная ширина блока (например 30% ширины слайдера) и далее текст переносится на следующую строку или блок растягивается на весь слайдер?
Чтобы не увидеть потом слайдер накрытый слоем текста, стоит такие моменты предусматривать и показывать в макетах, как выглядят блоки с текстом в несколько строк.
Конструктор выглядит так: