Блог

Я нашел следующую парадигму весьма полезной, и мне бы хотелось как-то воспроизвести ее в Julia, чтобы воспользоваться преимуществами скорости Julia и возможностями переноса C.

Обычно я поддерживаю набор объектов в Python / Matlab, которые представляют блоки (алгоритмы) конвейера. Настройте модульные тесты и т. Д.

Затем разработайте эквивалентный код на C / C , используя эквивалентные объекты python / Matlab (тот же API), которые обертывают C / C для реализации той же функциональности и должны проходить те же тесты (под этим я подразумеваю точно такие же тесты, написанные на python / Matlab, где либо я генерирую синтетические данные, либо язагрузить записанные данные).

Я буду параллельно поддерживать объекты с полным python и python / C , обеспечивая четность с помощью обширных наборов тестов. Версии только для python и python / C полностью взаимозаменяемы.

Каждый раз, когда мне нужно изменить поведение конвейера или отладить проблему, я сначала использую полностью pythonic версию конкретного объекта / блока, который мне нужно изменить, обычно в сочетании с другими блоками, работающими в режиме python / C для ускорения, затем обновляю тесты, чтобы они соответствовали поведениюмодифицированный блок python и, наконец, обновляет версию C , пока она не достигнет четности и не пройдет обновленные тесты.

Каждый раз, когда я создаю экземпляр версии Python / C в блоке, в конструкторе я запускаю «make», который перестраивает код C , если были какие-либо изменения. Чтобы убедиться, что я всегда тестирую последнюю версию C .

Есть ли какой-нибудь элегантный способ воспроизвести ту же парадигму с помощью комбинации Julia / C ? Параллельное поддержание версий julia / C с помощью автоматического тестирования. Т.е. Как мне проверить / перестроить C только один раз, когда я создаю экземпляр объекта, а не для каждого вызова функции (это было бы слишком медленно).

Я думаю, я мог бы вызвать «make» один раз на уровне набора тестов, прежде чем запускать все тесты разных блоков. Но тогда мне придется вызывать его вручную, если я пишу быстрый скрипт на python для сеанса отладки.

Давайте рассмотрим пример небольшого объекта filter с методом configure, который изменяет параметры фильтра, и методом filter, который фильтрует входящие данные.

У нас будет что-то вроде:

 f1 = filter('python');
f2 = filter('C  '); % rebuild C   as needed

f1.configure(0.5);
f2.configure(0.5);

x1 = data;
x2 = data;

xf1 = f1.filter(x1);
xf2 = f2.filter(x2);

assert( xf1 == xf2 )
  

В общем, будет множество тестов, которые создают экземпляры объектов как в режиме только для python, так и в режиме python / C и тестируют их.

Я думаю, я пытаюсь сказать, что, поскольку в Julia парадигма заключается в том, чтобы иметь тип фильтра, а затем «внешние» методы, которые изменяют / используют тип фильтра, централизованного способа проверки / перестройки всех его методов, которые переносят код C. Если только тип не содержит список переменных, которые отслеживают соответствующие методы. Кажется неудобным.

Я был бы признателен за комментарии / идеи.

Есть ли причина, по которой вы не можете обернуть свои функции в подобную структуру?

 struct Filter 

    FilterStuff::String
    Param::Int

    function Filter(stuff::String, param::Int)

        # Make the C   code here

        # Return the created object here
        obj = new(stuff, param)

    end

end