Задача N тел или как взорвать галактику не выходя из кухни

Я пользуюсь VEFRL.

Буду благодарен за ссылку на метод. Беглый поиск в гугле не даёт мне результата.

Задача N тел или как взорвать галактику не выходя из кухни

На самом деле с сохранением энергии не всё так просто, даже у метода Верле. Но метод хороший, я его планировал реализовать, но пока руки не дошли.

Задача N тел или как взорвать галактику не выходя из кухни

Думается это вполне можно опубликовать в журнале типа «Вычислительные методы и программирование».

Я однажды хотел опубликоваться в этом журнале, но был ответ, что публикация возможна только для тех, кто учится/работает в университете. А я уже закончил. Пришлось в другом месте публиковать. Сейчас, возможно, правила изменились.

А какие у вас заданы абсолютные размеры/массы/времена, т.е. соответствует ли видео в каком-то виде реальности или не особо?

Из физических констант задаю только G=1, а начальный диаметр 'галактики' задаю равным 100. Массы все одинаковые кроме центрального тела. К реальным величинам пересчитать возможно, но я этого пока не делал.

Задача N тел или как взорвать галактику не выходя из кухни

Посмотрел код примера из CUDA SDK. Вы этот имели ввиду?

CPU код из SDK примерно соответствует моему на стадии 'openmp'. GPU код у нас организован похоже, только у них перед внутренним циклом есть директива 'unroll'.
Таким образом, если сравнивать мои 'openmp' и СUDA реализации, то разница будет примерно в 20 раз. При сравнении с однопоточной версией CUDA реализация быстрее в 120 раз.

В статье, сопропровождающей SDK, есть такие строки:

The result is an algorithm that runs more than 50 times as fast as a highly tuned serial
implementation (Elsen et al. 2006) or 250 times faster than our portable C implemen-
tation.

Непонятно что такое 'portable C implementation', но первая половина хорошо соотносится с моими результатами.

На днях попробую собрать пример из SDK и сравнить более детально.

Трагичная история знакомства с poppler

Можно ещё в сторону libpodofo посмотреть
http://podofo.sourceforge.net/about.html

Даннинг с Крюгером, Сократ и круги знаний

Боюсь, таких людей нельзя отнести к тупицам. Например, нормальный руководитель не будет спорить с узким специалистом, у которого познания в конкретной области могут быть намного больше. Это же не признак тупости.

Ослабляем гайки в правилах Хабра

Мне кажется, что для начала можно сделать механизм необязательного рецензирования статей до публикации.

Бесплатный PVS-Studio для тех, кто развивает открытые проекты

Старые-новые это не так важно. Главное, что для OSS использование бесплатное.
Сейчас на travis-ci основной образ Ubuntu 14.04, в бете 16.04.
А те, кто хотят поновее, могут собрать свой в chroot или docker.
Вот тут собирают 18.04.
Свой сервер это конечно хорошо, но не всегда возможно.

Бесплатный PVS-Studio для тех, кто развивает открытые проекты

Например, на travis-ci каждый получает готовый образ системы, и потом сам устанавливает те пакеты, от которых зависит проект.
Конфигурацию каждый сам описывает.

Бесплатный PVS-Studio для тех, кто развивает открытые проекты

Через apt get

Бесплатный PVS-Studio для тех, кто развивает открытые проекты

Возможно здесь дело в наличии «собственных серверов». При активном OSS сообществе быстро зашкалит их количество, работающих условно бесплатно.
Coverity делает немного по другому. Анализатор отрабатывает на сервисе travis-ci или на своём железе, а на сервера анализатора загружаются только логи. Причём логи запакованы и, видимо, зашифрованы. Без загрузки на сервис coverity они бесполезны.

Бесплатный PVS-Studio для тех, кто развивает открытые проекты

Отличная новость!
С этим ключём можно будет интегрировать PVS в CI процесс на travis?

Повышение качества склейки панорамы с помощью согласования графа проективных преобразований

Интересный метод. Ещё я вам рекомендовал бы посмотреть в сторону Bill Triggs «Bundle Adjustment – A Modern Synthesis»

На сегодняшний день не существует универсального метода оценки качества склейки изображений. Как правило качество склейки оценивается экспертами органолептически

В большинстве фотограмметрических пакетов в качестве этой меры используют ошибку проецирования связующих точек (что есть мера согласования геометрии снимков). Меру оценки согласования яркостей изображений имеет смысл рассматривать только после оценки геометрии.

Continuous integration в Яндексе

Не очень тогда понятно, как разрешаются конфликты, если я и мой сосед исправляем один и тот-же файл и коммитим одновременно.

Continuous integration в Яндексе

А большое количество предкоммитных проверок не затягивают время коммита? Я так понимаю, что на время предкоммитной проверки репозиторий блокируется?

Как я попробовал сделать статический анализатор GLSL (и что пошло не так)

Нехитрая с++ магия

template<class T>
struct v2
{
	T& x;
	T& y;
	v2(T& _x, T& _y) : x(_x), y(_y) {}
	template<class X>
	v2(const X& other) : x(other.x), y(other.y) {}

	template<class X>
	v2<T>& operator = (const X& other)
	{
		T   temp_x(other.x);
		T   temp_y(other.y);
		x = temp_x;
		y = temp_y;
		return *this;
	}
	v2<T>& operator = (const v2<T>& other)
	{
		T   temp_x(other.x);
		T   temp_y(other.y);
		x = temp_x;
		y = temp_y;
		return *this;
	}
};

template<class T>
struct vec2
{
	T       x;
	T       y;
	v2<T>   xx;
	v2<T>   yy;
	v2<T>   xy;
	v2<T>   yx;

	vec2(T _x, T _y) : x(_x), y(_y), xx(x, x), yy(y, y), xy(x, y), yx(y, x) {}

	template<class X>
	vec2(const X& other) : x(other.x), y(other.y) {}

	template<class X>
	vec2<T>& operator = (const X& other)
	{
		x = other.x;
		y = other.y;
		return *this;
	}
};

Позволяет творить невообразимые вещи

void test_swap()
{
	{
		vec2<float> point1(0, 0);
		vec2<float> point2(1, 2);

		point1.xy = point2;
		std::cerr << "point = " << point1.x << " " << point1.y << std::endl;

		point1.yx = point2;
		std::cerr << "point = " << point1.x << " " << point1.y << std::endl;
	}
	{
		vec2<float> point1(0, 0);
		vec2<float> point2(1, 2);

		point1 = point2.xy;
		std::cerr << "point = " << point1.x << " " << point1.y << std::endl;

		point1 = point2.yx;
		std::cerr << "point = " << point1.x << " " << point1.y << std::endl;
	}
	{
		vec2<float> point1(0, 0);
		vec2<float> point2(1, 2);

		point1.yx = point2.xx;
		std::cerr << "point = " << point1.x << " " << point1.y << std::endl;

		point1.xy = point2.yy;
		std::cerr << "point = " << point1.x << " " << point1.y << std::endl;
	}
	{
		vec2<float> point1(3, 4);
		point1.xy = point1.yx;
		std::cerr << "point = " << point1.x << " " << point1.y << std::endl;
	}
}

Как я попробовал сделать статический анализатор GLSL (и что пошло не так)

Например, для шейдера из статьи

uniform float value; //-> [0,1];
void main() {
    float val2 = value - 1.;
    gl_FragColor = vec4(value - val2);
}

Можно сделать так.

#include <iostream>

#define uniform
typedef float vec4;

struct shader_test
{
	vec4   gl_FragColor;
	shader_test():
		gl_FragColor(0) {}
#include "shader.glsl"
};

int main(int, char**)
{
	shader_test tst;
	tst.value = 0.5;
	tst.main();
	std::cerr << "gl_FragColor = " << tst.gl_FragColor << std::endl;
	return 0;
}

Как я попробовал сделать статический анализатор GLSL (и что пошло не так)

Однако это явный false alarm, а для статического анализатора нет ничего хуже ложных срабатываний — если его не отключат после первого крика «волки», то после десятого точно.

Порой это лучше, чем ничего, особенно если есть возможность поставить исключения после первого просмотра.

При этом на других языках можно хотя бы юнит-тесты писать, а тут — никак.

В своём небольшом проекте мы директивой #include включали код шейдеров в код на c++, и с помощью нескольких дефайнов и обёрток превращали шейдеры в обычные функции, которые возможно вызвать.

Разработка интерфейсных классов на С++

Если пользователям интерфейса пришлось узнавать о реализации, то что-то пошло не так…
А константность, на мой взгляд, нужна для облегчения использования интерфейса, а не наоборот. Она только подчёркивает свойства метода, позволяет избежать ошибок ещё во время компиляции.
Злоупотреблять, расставляя const где попало, конечно не стоит.

Разработка интерфейсных классов на С++

Отличная подборка материала про интерфейсы, и подводные камни в реализации и использовании.

Следует с осторожностью объявлять функции-члены интерфейсных классов как const.

Вы могли бы раскрыть здесь подробнее, какие сложности нас могут ожидать на этом пути.