that is strange but with more ,the same ,tests i have no more speed up:
with Racket versions of srfi 171
{unified-minterms-set-2 <+ (filter (λ (x) x) unified-minterms-set-1)} ;;
remove #f results
;; (nodebug
;; {unified-minterms-set-2-length <+ (length unified-minterms-set-2)}
;; (dv unified-minterms-set-2-length))
{unified-minterms-set <+ (remove-duplicates unified-minterms-set-2)} ;;
(remove-duplicates-sorted unified-minterms-set-2)} ;; uniq MODIF
;; C12 in Terminal mode with MacOS Ventura M1 and 32"
;; (nodebug
;; {unified-minterms-set-uniq-length <+ (length unified-minterms-set)}
;; (dv unified-minterms-set-uniq-length))
;;{unified-minterms-set <+ (remove-duplicates (filter (λ (x) x)
unified-minterms-set-1))} ;; C12 in Terminal mode with MacOS Ventura M1 and
32"
;;{unified-minterms-set <+ (list-transduce (compose (tfilter (λ (x) x))
(tdelete-duplicates)) rcons unified-minterms-set-1)} ;; C12 in Terminal
mode with MacOS Ventura M1 and 31"
and Guile:
;; 8'04" MacOS Ventura M1 for C12 ,50" for C11
;;{unified-minterms-set-2 <+ (filter (λ (x) x) unified-minterms-set-1)}
;; remove #f results
;; (nodebug
;; {unified-minterms-set-2-length <+ (length unified-minterms-set-2)}
;; (dv unified-minterms-set-2-length))
;;{unified-minterms-set <+ (remove-duplicates unified-minterms-set-2)}
;;(remove-duplicates-sorted unified-minterms-set-2)} ;; uniq MODIF
;; (nodebug
;; {unified-minterms-set-uniq-length <+ (length unified-minterms-set)}
;; (dv unified-minterms-set-uniq-length))
{unified-minterms-set <+ (remove-duplicates (filter (λ (x) x)
unified-minterms-set-1))} ;; 59" for C11, 8'05" for C12
;; 7'08" ,8'15" MacOS Ventura M1 for C12 and 56" for C11
;;{unified-minterms-set <+ (list-transduce (compose (tfilter (λ (x) x))
(tdelete-duplicates)) rcons unified-minterms-set-1)}
some code is commented because i only run one test at a time.
I suppose the speed up was only because debug mode slowed down other code
but perheaps my test are not reliable, i can only explain some slow down
now due to CPU overloaded by another process in the system at different
moment in tests. I have no idea how to perform more reliable tests.
On Thu, Dec 22, 2022 at 6:32 PM Damien Mattei <damien.mat...@gmail.com>
wrote:
> i'm interested with transducers to speed up code:
>
> ;; 8'21" MacOS Ventura M1
> {unified-minterms-set-2 <+ (filter (λ (x) x) unified-minterms-set-1)} ;;
> remove #f results
> (nodebug
> {unified-minterms-set-2-length <+ (length unified-minterms-set-2)}
> (dv unified-minterms-set-2-length))
>
> {unified-minterms-set <+ (remove-duplicates unified-minterms-set-2)}
> ;;(remove-duplicates-sorted unified-minterms-set-2)} ;; uniq MODIF
> (nodebug
> {unified-minterms-set-uniq-length <+ (length unified-minterms-set)}
> (dv unified-minterms-set-uniq-length))
>
> with transducers:
> ;; 7'08" MacOS Ventura M1
> {unified-minterms-set <+ (list-transduce (compose (tfilter (λ (x) x))
> (tdelete-duplicates)) rcons unified-minterms-set-1)}
>
> it is an interesting 15% speed up in my code.
>
>
> On Thu, Dec 22, 2022 at 3:52 PM Damien Mattei <damien.mat...@gmail.com>
> wrote:
>
>> i just understood the scheme :-)
>>
>> scheme@(guile-user)> (list-transduce (compose (tfilter (λ (x) x))
>> (tdelete-duplicates)) rcons (list 1 2 #f 3 3 4))
>> $12 = (1 2 3 4)
>>
>> sorry...
>>
>>
>> On Thu, Dec 22, 2022 at 3:33 PM Damien Mattei <damien.mat...@gmail.com>
>> wrote:
>>
>>> hello,
>>> just trying transducers before using it, i try to understand.
>>> what is wrong with that:
>>> scheme@(guile-user)> (list-transduce (tfilter (λ (x) x))
>>> (tdelete-duplicates) (list 1 2 #f 3 3 4))
>>> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
>>> Wrong number of arguments to #<procedure 10786aa60 at
>>> srfi/srfi-171.scm:338:2 (reducer)>
>>>
>>> Entering a new prompt. Type `,bt' for a backtrace or `,q' to continue.
>>>
>>> Regards,
>>> Damien
>>>
>>> On Wed, Dec 21, 2022 at 11:01 AM Linus Björnstam <
>>> linus.bjorns...@veryfast.biz> wrote:
>>>
>>>> As the author of both the SRFI and the guile code I am very happy you
>>>> like it. I don't have a computer at the moment, but I looked through the
>>>> code and it looked great.
>>>>
>>>> All additions should have been included in the original SRFI :)
>>>>
>>>> one comment: your code uses define-public, which the rest of SRFI-171
>>>> code does not.
>>>>
>>>> I am not in any position to sign code off for inclusion in guile
>>>> proper, but if the define-public thing is fixed it very much has my
>>>> blessing.
>>>>
>>>> Best regards
>>>> Linus Björnstam
>>>>
>>>> On Wed, 21 Dec 2022, at 01:48, Colin Woodbury wrote:
>>>> > Happy holidays everyone, I hope everything is going well for you.
>>>> >
>>>> > Since discovering SRFI-171 (Transducers) I have fallen in love with
>>>> it.
>>>> > Transducers let me "talk the way I want to talk" while knowing that
>>>> I'm
>>>> > being efficient underneath w.r.t. to iteration and allocation. In
>>>> using
>>>> > Guile's implementation, I noticed a few common idioms missing that
>>>> are
>>>> > otherwise present in other languages, so I've added them in a series
>>>> of
>>>> > patches. I've been using these often for a number of weeks without
>>>> > issue, but of course have added unit tests as well.
>>>> >
>>>> > The full details are in the commit messages, but here are the main
>>>> highlights:
>>>> >
>>>> > * rfold: The fundamental reducer. This allows the user to turn any
>>>> > two-arg function into a valid reducer, so that they don't need to
>>>> worry
>>>> > about hand-writing reducers via case-lambda.
>>>> > * rfind: Yields the first item in the transduction that matches some
>>>> > predicate. Nice for locating some specific value from a potentially
>>>> > large data source (e.g. a port).
>>>> > * twindow: Like tsegment, but yields overlapping slices into the
>>>> data.
>>>> > Cheers, and have a great holiday.
>>>> >
>>>> > Colin
>>>> >
>>>> > Attachments:
>>>> > * 0001-srfi-171-add-twindow-and-various-reducers.patch
>>>> > * 0002-doc-add-new-SRFI-171-reducers-to-the-manual.patch
>>>> > * 0003-srfi-171-add-unit-tests-for-new-functions.patch
>>>>
>>>>
