Re: Anyone understand this?

So one error of use seems to be that the type should be :DOUBLE, not :DOUBLE-FLOAT (although no complaints were registered). But using :DOUBLE does not fix anything. The routine FLI:SET-DYNAMIC-LISP-ARRAY-POINTER still produces identical results, regardless of the :START argument.



> On Jan 22, 2025, at 12:15, David McClain (as dbm at refined-audiometrics dot com) <[email protected]> wrote:
> 
> Indeed, going back to the examples in the LW Manual,
> 
> This produces 10.0 instead of 30.0.
> 
> (let* ((arr (make-array 3
>                         :element-type 'double-float
>                         :allocation :pinnable
>                         :initial-contents '(10d0 20d0 30d0))))
>   (hcl:with-pinned-objects (arr)
>     (fli:with-dynamic-lisp-array-pointer (parr arr :start 2 :type :double-float)
>       (fli:dereference parr))))
> 
> 
>> On Jan 22, 2025, at 12:11, David McClain (as dbm at refined-audiometrics dot com) <[email protected]> wrote:
>> 
>> More properly, it appears to be a bug in FLI::SET-DYNAMIC-LISP-ARRAY-POINTER, which is part of the macro expansion.
>> 
>> 
>> 
>> 
>>> On Jan 22, 2025, at 12:10, David McClain <[email protected]> wrote:
>>> 
>>> It appears now that the fault actually lies with FLI:WITH-DYNAMIC-LISP-ARRAY-POINTER. 
>>> 
>>> Using this code to produce a dummy second pointer with explicit :START 0, alongside the actual pointer of interest with a non-zero :START parameter, and then stepping through this code with a breakpoint set where the pointers are created, shows that both pointers produce identical FLI:POINTER objects. There is no base + offset in a composite object. The POINTER is expected to have a reduced direct address. And the two pointers do not differ when they ought to be different.
>>> 
>>> So looks like a bug in FLI:WITH-DYNAMIC-LISP-ARRAY-POINTER.
>>> 
>>> (defun vdot (arr1 arr2 &key (start2 0))
>>>   ;; intended for pre-decimation FIR filtering, where:
>>>   ;;   arr1 = FIR filter kernel
>>>   ;;   arr2 = input data buffer
>>>   ;;   nel  = length of FIR filter (ntaps)
>>>   ;;   start2 = starting position in data buffer for filtering,
>>>   ;;            as kernel steps along by ndec
>>>   (declare (array (double-float *) arr1 arr2))
>>>   (fli:with-dynamic-foreign-objects ()
>>>     (let ((ans (fli:allocate-dynamic-foreign-object :type :double-float)))
>>>       (hcl:with-pinned-objects (arr2)
>>>         (fli:with-dynamic-lisp-array-pointer (parr arr2 :type :double-float :start start2)
>>>           (fli:with-dynamic-lisp-array-pointer (parrx arr2 :type :double-float :start 0)
>>>             (_vdsp-dotprd arr1 1 parr 1 ans (length arr1))
>>>             (inspect (list parr parrx))
>>>             (fli:dereference ans)))
>>>         ))))
>>> 
>>> #|
>>> (let* ((arr2 (make-array 5
>>>                          :element-type 'double-float
>>>                          :allocation :pinnable
>>>                          :initial-contents '(1d0 2d0 3d0 4d0 5d0)))
>>>        (arr1 (make-array 3
>>>                          :element-type 'double-float
>>>                          :allocation :pinnable
>>>                          :initial-contents '(10d0 20d0 30d0))))
>>>   (vdot arr1 arr2 :start2 1)) ;; should produce 200.0, but produces 140.0.
>>> |#
>>> 
>>> 
>>>> On Jan 22, 2025, at 11:57, Yuri Davidovsky (as work at disclosure dot ie) <[email protected]> wrote:
>>>> 
>>>> That’s some classy email formatting. 
>>>> 
>>>>> On 22 Jan 2025, at 18:52, David McClain (as dbm at refined-audiometrics dot com) <[email protected]> wrote…
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Lisp Hug - the mailing list for LispWorks users
>>>> [email protected]
>>>> http://www.lispworks.com/support/lisp-hug.html
>>> 
>> 
>