vDSP FFT2d Swift неправильная мнимая часть результата

Я использую vDSP из инфраструктуры Accelerate для выполнения операции fft2d в двумерном массиве, полученном из сетчатой ​​сетки.

Проблема в том, что я получаю массив 0 в мнимой части, который не соответствует той же операции в python с использованием pylab.fft2.

Если я увеличиваю размер массива, результаты не равны нулю, но все равно не совпадают, поэтому я делаю что-то плохое.

Кто-нибудь может дать мне руку? Это мой первый вопрос о переполнении стека, но я застрял на нем уже две недели.

Это сетка сетки (4x8 для этого примера)

[
    [1.80485138784544e-35, 2.61027906966774e-23, 1.26641655490943e-14, 2.06115362243857e-09, 1.1253517471926e-07, 2.06115362243857e-09, 1.26641655490943e-14, 2.61027906966774e-23],
    [2.93748211171084e-30, 4.24835425529162e-18, 2.06115362243857e-09, 0.000335462627902512, 0.0183156388887342, 0.000335462627902512, 2.06115362243857e-09, 4.24835425529162e-18],
    [1.60381089054866e-28, 2.31952283024359e-16, 1.1253517471926e-07, 0.0183156388887342, 1.0, 0.0183156388887342, 1.1253517471926e-07, 2.31952283024359e-16],
    [2.93748211171084e-30, 4.24835425529162e-18, 2.06115362243857e-09, 0.000335462627902512, 0.0183156388887342, 0.000335462627902512, 2.06115362243857e-09, 4.24835425529162e-18]
]

Вот функция fft2:

func fft2(arr: [[Complex<Double>]]) -> [[Complex<Double>]] {
    let nRows = arr.count
    let nCols = arr[0].count
    let N = nRows * nCols

    let radix = FFTRadix(FFT_RADIX2)
    let pass = vDSP_Length(Int(log2(Double(N))))

    // Create FFTSetup
    let setup = vDSP_create_fftsetupD(pass, radix)

    // Direction
    let dir = FFTDirection(FFT_FORWARD)

    // Get real and imag doubles from the [Complex]
    // (all imag parts are 0.0 on this example)
    let (real, imag) = complex2DArrayToDouble(arr)

    // Pack 2d arrays as 1d (function bellow)
    var realArray = pack2dArray(real, rows: nRows, cols: nCols)
    var imagArray = pack2dArray(imag, rows: nRows, cols: nCols)

    // Create the split complex with the packed arrays
    var splitComplex = DSPDoubleSplitComplex(
        realp: &realArray,
        imagp: &imagArray)

    let log2n0c = vDSP_Length(Int(log2(Double(nCols))))
    let log2n1r = vDSP_Length(Int(log2(Double(nRows))))

    let rowStride = vDSP_Stride(nRows)
    let colStride = vDSP_Stride(1) // Use all cols

    // Perform the fft2d
    vDSP_fft2d_zipD(setup, &splitComplex, rowStride, colStride, log2n0c, log2n1r, dir)

    // Destroy setup
    vDSP_destroy_fftsetupD(setup)

    // Pack the 1d arrays on 2d arrays again
    let resultReal = unpack2dArray(realArray, rows: nRows, cols: nCols)
    let resultImag = unpack2dArray(imagArray, rows: nRows, cols: nCols)

    // Ignore this...
    return complexFrom2DArray([[Double]](), imag: [[Double]]())
}

И, наконец, вот функции, которые я использую для упаковки и распаковки массивов из/в 2d в 1d.

func pack2dArray(arr: [[Double]], rows: Int, cols: Int) -> [Double] {
    var resultArray = zeros(rows * cols)
    for Iy in 0...cols-1 {
        for Ix in 0...rows-1 {
            let index = Iy * rows + Ix
            resultArray[index] = arr[Ix][Iy]
        }
    }
    return resultArray
}

func unpack2dArray(arr: [Double], rows: Int, cols: Int) -> [[Double]] {
    var resultArray = [[Double]](count: rows, repeatedValue: zeros(cols))
    for Iy in 0...cols-1 {
        for Ix in 0...rows-1 {
            let index = Iy * rows + Ix
            resultArray[Ix][Iy] = arr[index]
        }
    }
    return resultArray
}

Я буду признателен за любую информацию об этом, и я могу изменить это на C или Objective-C, если проще всего заставить его работать, как в python.

Быстрые результаты:

[
    [(1.07460475603902+0.0.i), (-1.06348244974363+0.0.i), (1.03663115699765+0.0.i), (-1.00978033088166+0.0.i), (0.998658491216246+0.0.i), (-1.00978033088166+0.0.i), (1.03663115699765+0.0.i), (-1.06348244974363+0.0.i)],
    [(-1.03663138619031+0.0.i), (1.02590210946989+0.0.i), (-0.999999662394501+0.0.i), (0.974097665459761+0.0.i), (-0.963368838879988+0.0.i), (0.974097665459761+0.0.i), (-0.999999662394501+0.0.i), (1.02590210946989+0.0.i)],
    [(0.998658482971633+0.0.i), (-0.988322230996495+0.0.i), (0.963368617931946+0.0.i), (-0.938415438518917+0.0.i), (0.928079620195301+0.0.i), (-0.938415438518917+0.0.i), (0.963368617931946+0.0.i), (-0.988322230996495+0.0.i)],
    [(-1.03663138619031+0.0.i), (1.02590210946989+0.0.i), (-0.999999662394501+0.0.i), (0.974097665459761+0.0.i), (-0.963368838879988+0.0.i), (0.974097665459761+0.0.i), (-0.999999662394501+0.0.i), (1.02590210946989+0.0.i)]
]

Результаты Python:

[
    [ 1.07460476 +0.00000000e+00j, -1.06348245 +1.98409020e-17j, 1.03663116 +0.00000000e+00j -1.00978033 -1.97866921e-17j, 0.99865849 +0.00000000e+00j -1.00978033 -1.98409020e-17j, 1.03663116 +0.00000000e+00j -1.06348245 +1.97866921e-17j]
    [-1.03663139 +0.00000000e+00j, 1.02590211 -1.90819560e-17j, -0.99999966 +0.00000000e+00j, 0.97409767 +1.90819558e-17j, -0.96336884 +0.00000000e+00j, 0.97409767 +1.90819560e-17j, -0.99999966 +0.00000000e+00j, 1.02590211 -1.90819558e-17j]
    [ 0.99865848 +0.00000000e+00j, 0.98832223 +1.83230190e-17j, 0.96336862 +0.00000000e+00j, 0.93841544 -1.83772293e-17j, 0.92807962 +0.00000000e+00j, 0.93841544 -1.83230190e-17j, 0.96336862 +0.00000000e+00j, 0.98832223 +1.83772293e-17j]
    [-1.03663139 +0.00000000e+00j, 1.02590211 -1.90819560e-17j, -0.99999966 +0.00000000e+00j, 0.97409767 +1.90819558e-17j, -0.96336884 +0.00000000e+00j, 0.97409767 +1.90819560e-17j, -0.99999966 +0.00000000e+00j, 1.02590211 -1.90819558e-17j]
]

С уважением и заранее большое спасибо!!


Изменить 1

Вот версия того же кода на C: http://pastebin.com/C9RPgu68

А вот код Python: http://pastebin.com/rr4e6rku


person Daniel Rogi    schedule 08.11.2015    source источник
comment
Вы говорите о различиях, таких как 0.0.i (Swift) и +1.98409020e-17j (Python) во второй записи? Кажется, это вполне соответствует точности 64-битного числа с плавающей запятой. Различный вывод может быть даже вызван тем фактом, что Swift использует представление с фиксированной точкой, а Python использует научное представление.   -  person Martin R    schedule 08.11.2015
comment
Я думал об этом раньше, но если я создаю массив 4x32, например, я получаю значения для мнимой части, но они неверны (не 0, а неверны). В любом случае, большое спасибо за информацию, я проверю это еще раз.   -  person Daniel Rogi    schedule 08.11.2015
comment
Возможно, мне нужно использовать vDSP_fft2d_zripD вместо vDSP_fft2d_zipD, так как входные данные в реальном, а не в сложном формате, но у меня проблемы с их правильной упаковкой для vDSP.   -  person Daniel Rogi    schedule 08.11.2015
comment
Мммм, может быть, я просто глуп, и ты прав, @Martin R... ха-ха. Напишите это как ответ, и я отмечу его как действительный. Может быть, моя вина была в том, что я был очень одержим получением точно таких же результатов, что и в питоне, и не думал, что 1,984...-17j - это действительно очень тонкое число. Спасибо   -  person Daniel Rogi    schedule 09.11.2015


Ответы (1)


Различные выходные данные, такие как

Swift:  (-1.06348244974363+0.0.i)
Python: -1.06348245 +1.98409020e-17j

не указывает на неверный результат. Во-первых, код Swift, очевидно, использует представление с фиксированной точкой, так что 1,98409020 10-17 округляется до 0.0. Во-вторых, даже если вы ожидаете, что результат будет точно равен нулю, следует ожидать небольшого ненулевого значения из-за ограниченной точности двоичных чисел с плавающей запятой (около 16 десятичных цифр для 64-битного Double).

person Martin R    schedule 09.11.2015