Rocksolid Light

Welcome to Rocksolid Light

mail  files  register  newsreader  groups  login

Message-ID:  

It's currently a problem of access to gigabits through punybaud. -- J. C. R. Licklider


devel / comp.lang.tcl / element-wise union of lists

SubjectAuthor
* element-wise union of listsEduard Zozulya
+* element-wise union of listsHelmut Giese
|`* element-wise union of listsEduard Zozulya
| `- element-wise union of listsSchelte
`* element-wise union of listsRich
 +* element-wise union of listsAndreas Leitgeb
 |`* element-wise union of listsEduard Zozulya
 | `* element-wise union of listsMole Cool
 |  `- element-wise union of listsHelmut Giese
 `* element-wise union of listsheinrichmartin
  `* element-wise union of listsbriang
   `* element-wise union of listsMole Cool
    `* element-wise union of listsbriang
     `* element-wise union of listsbriang
      `* element-wise union of listsheinrichmartin
       `- element-wise union of listsbriang

1
element-wise union of lists

<cea64616-b039-4268-b0a7-23bf314a49b6n@googlegroups.com>

  copy mid

https://news.novabbs.org/devel/article-flat.php?id=12578&group=comp.lang.tcl#12578

  copy link   Newsgroups: comp.lang.tcl
X-Received: by 2002:a05:620a:8e13:b0:770:f19d:d6ac with SMTP id re19-20020a05620a8e1300b00770f19dd6acmr375018qkn.0.1697198424367;
Fri, 13 Oct 2023 05:00:24 -0700 (PDT)
X-Received: by 2002:a05:6870:9e42:b0:1e9:73d6:5cd8 with SMTP id
pt2-20020a0568709e4200b001e973d65cd8mr3686459oab.1.1697198424127; Fri, 13 Oct
2023 05:00:24 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!1.us.feeder.erje.net!feeder.erje.net!usenet.blueworldhosting.com!diablo1.usenet.blueworldhosting.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.tcl
Date: Fri, 13 Oct 2023 05:00:23 -0700 (PDT)
Injection-Info: google-groups.googlegroups.com; posting-host=95.133.226.215; posting-account=M8vRywoAAAAgFxHGzKhR41mP_Vc-pztE
NNTP-Posting-Host: 95.133.226.215
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <cea64616-b039-4268-b0a7-23bf314a49b6n@googlegroups.com>
Subject: element-wise union of lists
From: ed.zozulya@gmail.com (Eduard Zozulya)
Injection-Date: Fri, 13 Oct 2023 12:00:24 +0000
Content-Type: text/plain; charset="UTF-8"
X-Received-Bytes: 1297
 by: Eduard Zozulya - Fri, 13 Oct 2023 12:00 UTC

Need union two list as
set l1 "1 2 3"
set l2 "a s d"

Result list as "1 a 2 s 3 d"

This procedure
proc UnionList { l1 l2 } {
foreach e1 $l1 e2 $l2 {
lappend lret $e1 $e2
}
return $lret
} working very slowly because lists l1 and l2 very big (100000 elements)

How to optimize list merging?

Re: element-wise union of lists

<39fiii55djs57d7c6d4cjvka7qno1cal33@4ax.com>

  copy mid

https://news.novabbs.org/devel/article-flat.php?id=12579&group=comp.lang.tcl#12579

  copy link   Newsgroups: comp.lang.tcl
Path: i2pn2.org!i2pn.org!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: hgiese@ratiosoft.com (Helmut Giese)
Newsgroups: comp.lang.tcl
Subject: Re: element-wise union of lists
Date: Fri, 13 Oct 2023 14:52:07 +0200
Organization: ratiosoft
Lines: 25
Message-ID: <39fiii55djs57d7c6d4cjvka7qno1cal33@4ax.com>
References: <cea64616-b039-4268-b0a7-23bf314a49b6n@googlegroups.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Injection-Info: dont-email.me; posting-host="8eb065c904cac77e05b34c5306546b99";
logging-data="3355676"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/AlWohE1yk5vugseiIrq8b"
Cancel-Lock: sha1:PI9O/MHNza1U0GdcICYaRfblk1E=
X-Newsreader: Forte Free Agent 1.93/32.576 English (American)
 by: Helmut Giese - Fri, 13 Oct 2023 12:52 UTC

Eduard Zozulya <ed.zozulya@gmail.com> schrieb:

>Need union two list as
>set l1 "1 2 3"
>set l2 "a s d"
>
>Result list as "1 a 2 s 3 d"
>
>This procedure
>proc UnionList { l1 l2 } {
> foreach e1 $l1 e2 $l2 {
> lappend lret $e1 $e2
> }
> return $lret
>}
>working very slowly because lists l1 and l2 very big (100000 elements)
>
>How to optimize list merging?
Try a dict?
set d [dict create]
foreach e1 $l1 e2 $l2 {
dict set d $e1 $e2
} HTH
Helmut

Re: element-wise union of lists

<72a0b0a4-633e-4ffa-9760-3ced212d216cn@googlegroups.com>

  copy mid

https://news.novabbs.org/devel/article-flat.php?id=12580&group=comp.lang.tcl#12580

  copy link   Newsgroups: comp.lang.tcl
X-Received: by 2002:a05:620a:141:b0:774:1c49:2d6b with SMTP id e1-20020a05620a014100b007741c492d6bmr437784qkn.12.1697202609353;
Fri, 13 Oct 2023 06:10:09 -0700 (PDT)
X-Received: by 2002:a05:6808:158f:b0:3ae:1f9:eb47 with SMTP id
t15-20020a056808158f00b003ae01f9eb47mr13659569oiw.10.1697202609165; Fri, 13
Oct 2023 06:10:09 -0700 (PDT)
Path: i2pn2.org!rocksolid2!news.neodome.net!weretis.net!feeder6.news.weretis.net!border-2.nntp.ord.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.tcl
Date: Fri, 13 Oct 2023 06:10:08 -0700 (PDT)
In-Reply-To: <39fiii55djs57d7c6d4cjvka7qno1cal33@4ax.com>
Injection-Info: google-groups.googlegroups.com; posting-host=95.133.226.215; posting-account=M8vRywoAAAAgFxHGzKhR41mP_Vc-pztE
NNTP-Posting-Host: 95.133.226.215
References: <cea64616-b039-4268-b0a7-23bf314a49b6n@googlegroups.com> <39fiii55djs57d7c6d4cjvka7qno1cal33@4ax.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <72a0b0a4-633e-4ffa-9760-3ced212d216cn@googlegroups.com>
Subject: Re: element-wise union of lists
From: ed.zozulya@gmail.com (Eduard Zozulya)
Injection-Date: Fri, 13 Oct 2023 13:10:09 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Lines: 29
 by: Eduard Zozulya - Fri, 13 Oct 2023 13:10 UTC

пʼятниця, 13 жовтня 2023 р. о 15:52:12 UTC+3 Helmut Giese пише:
> Eduard Zozulya <ed.zo...@gmail.com> schrieb:
> >Need union two list as
> >set l1 "1 2 3"
> >set l2 "a s d"
> >
> >Result list as "1 a 2 s 3 d"
> >
> >This procedure
> >proc UnionList { l1 l2 } {
> > foreach e1 $l1 e2 $l2 {
> > lappend lret $e1 $e2
> > }
> > return $lret
> >}
> >working very slowly because lists l1 and l2 very big (100000 elements)
> >
> >How to optimize list merging?
> Try a dict?
> set d [dict create]
> foreach e1 $l1 e2 $l2 {
> dict set d $e1 $e2
> }
> HTH
> Helmut
A little faster.
Thank you!

Re: element-wise union of lists

<ugbmrn$38akq$1@dont-email.me>

  copy mid

https://news.novabbs.org/devel/article-flat.php?id=12582&group=comp.lang.tcl#12582

  copy link   Newsgroups: comp.lang.tcl
Path: i2pn2.org!i2pn.org!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: rich@example.invalid (Rich)
Newsgroups: comp.lang.tcl
Subject: Re: element-wise union of lists
Date: Fri, 13 Oct 2023 15:14:00 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 32
Message-ID: <ugbmrn$38akq$1@dont-email.me>
References: <cea64616-b039-4268-b0a7-23bf314a49b6n@googlegroups.com>
Injection-Date: Fri, 13 Oct 2023 15:14:00 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="2be75457b47745114b85fb2b1ea74ad0";
logging-data="3418778"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX198og9V61UnSWAEBOYQ/LDs"
User-Agent: tin/2.6.1-20211226 ("Convalmore") (Linux/5.15.117 (x86_64))
Cancel-Lock: sha1:LpFPN6iHVgX7ZQGRXl4IZix+pzc=
 by: Rich - Fri, 13 Oct 2023 15:14 UTC

Eduard Zozulya <ed.zozulya@gmail.com> wrote:
> Need union two list as
> set l1 "1 2 3"
> set l2 "a s d"
>
> Result list as "1 a 2 s 3 d"
>
> This procedure
> proc UnionList { l1 l2 } {
> foreach e1 $l1 e2 $l2 {
> lappend lret $e1 $e2
> }
> return $lret
> }
> working very slowly because lists l1 and l2 very big (100000 elements)
>
> How to optimize list merging?

The common name for this is "zipping" lists (see
https://wiki.tcl-lang.org/page/lzip) and unfortunately, no matter how
hard you try to 'hide' the fact, ultimately any abstraction will expand
into iterating over both lists one element at a time and creating a
result from each element one pair of elements at a time.

There simply is not any other way to perform the operation.

The only speedup possibility might be to code a C extension to actually
perform the zip, which removes Tcl interpreter overhead, but it would
still have to iterate one by one building up the result, so there is a
lower bound below which the operation simply will not reach performace
wise.

Re: element-wise union of lists

<nnd$3fab41d7$70e4be8a@0ac03f960f496b68>

  copy mid

https://news.novabbs.org/devel/article-flat.php?id=12584&group=comp.lang.tcl#12584

  copy link   Newsgroups: comp.lang.tcl
Date: Fri, 13 Oct 2023 18:26:28 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: element-wise union of lists
Newsgroups: comp.lang.tcl
References: <cea64616-b039-4268-b0a7-23bf314a49b6n@googlegroups.com>
<39fiii55djs57d7c6d4cjvka7qno1cal33@4ax.com>
<72a0b0a4-633e-4ffa-9760-3ced212d216cn@googlegroups.com>
Content-Language: nl-NL, en-US
From: nospam@wanadoo.nl (Schelte)
In-Reply-To: <72a0b0a4-633e-4ffa-9760-3ced212d216cn@googlegroups.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <nnd$3fab41d7$70e4be8a@0ac03f960f496b68>
Organization: KPN B.V.
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!news.mixmin.net!feed.abavia.com!abe004.abavia.com!abp003.abavia.com!news.kpn.nl!not-for-mail
Lines: 40
Injection-Date: Fri, 13 Oct 2023 18:26:28 +0200
Injection-Info: news.kpn.nl; mail-complaints-to="abuse@kpn.com"
 by: Schelte - Fri, 13 Oct 2023 16:26 UTC

On 13/10/2023 15:10, Eduard Zozulya wrote:
> пʼятниця, 13 жовтня 2023 р. о 15:52:12 UTC+3 Helmut Giese пише:
>> Eduard Zozulya <ed.zo...@gmail.com> schrieb:
>>> How to optimize list merging?
>> Try a dict?
>> set d [dict create]
>> foreach e1 $l1 e2 $l2 {
>> dict set d $e1 $e2
>> }
>> HTH
>> Helmut
> A little faster.
> Thank you!

In my testing, the dict version takes about twice as long as the
original version. It also doesn't produce the same results if there are
duplicates in l1. That may or may not be a problem.

One factor that slows down the original is that lret needs to be
reallocated every time it runs out of space when elements are added. A
possible optimization is to allocate the needed number of elements in
advance:

proc UnionList {l1 l2} {
set lret [lrepeat [expr {[llength $l1] * 2}] {}]
set i -1
foreach e1 $l1 e2 $l2 {
lset lret [incr i] $e1
lset lret [incr i] $e2
}
return $lret
}

I get a slight speed increase (about 5%) on two lists of 100000 elements
that way.

Schelte.

Re: element-wise union of lists

<slrnuiirvg.akff.avl@logic.at>

  copy mid

https://news.novabbs.org/devel/article-flat.php?id=12585&group=comp.lang.tcl#12585

  copy link   Newsgroups: comp.lang.tcl
Path: i2pn2.org!i2pn.org!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: avl@logic.at (Andreas Leitgeb)
Newsgroups: comp.lang.tcl
Subject: Re: element-wise union of lists
Date: Fri, 13 Oct 2023 16:27:28 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 23
Message-ID: <slrnuiirvg.akff.avl@logic.at>
References: <cea64616-b039-4268-b0a7-23bf314a49b6n@googlegroups.com>
<ugbmrn$38akq$1@dont-email.me>
Reply-To: avl@logic.at
Injection-Date: Fri, 13 Oct 2023 16:27:28 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="9edd2c69b91ee54aafb739b1cbcaf26a";
logging-data="3449129"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+RGPO4t1DO6g5KpZrdzB5t"
User-Agent: slrn/1.0.3 (Linux)
Cancel-Lock: sha1:rEtypzf4rOPCAiiiCLEwkrCERV8=
 by: Andreas Leitgeb - Fri, 13 Oct 2023 16:27 UTC

Rich <rich@example.invalid> wrote:
> Eduard Zozulya <ed.zozulya@gmail.com> wrote:
>> How to optimize list merging?
> The only speedup possibility might be to code a C extension to actually
> perform the zip, which removes Tcl interpreter overhead, but it would
> still have to iterate one by one building up the result, so there is a
> lower bound below which the operation simply will not reach performace
> wise.

according to another followup in this thread, building a dict gave a
slight improvement over building a list.

There might be two reasons for that:

- the list originally created was used as a dict afterwards,
so building a dict in first place is of course better,
than creating a list and having it converted to dict.

- maybe the first list contains certain elements a multiple times,
e.g. list1 is {a a a a}, then the dict created would only
contain key "a" with last value of second list. That may
or may not be OP's intention.

Re: element-wise union of lists

<2568ad96-3a8d-481e-8a1c-e658936ec87fn@googlegroups.com>

  copy mid

https://news.novabbs.org/devel/article-flat.php?id=12587&group=comp.lang.tcl#12587

  copy link   Newsgroups: comp.lang.tcl
X-Received: by 2002:a05:6214:41a0:b0:66d:2f83:980e with SMTP id ld32-20020a05621441a000b0066d2f83980emr64079qvb.10.1697268039509;
Sat, 14 Oct 2023 00:20:39 -0700 (PDT)
X-Received: by 2002:a05:6871:322a:b0:1e9:9202:20cc with SMTP id
mo42-20020a056871322a00b001e9920220ccmr2975727oac.0.1697268039318; Sat, 14
Oct 2023 00:20:39 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.tcl
Date: Sat, 14 Oct 2023 00:20:38 -0700 (PDT)
In-Reply-To: <slrnuiirvg.akff.avl@logic.at>
Injection-Info: google-groups.googlegroups.com; posting-host=95.133.226.215; posting-account=M8vRywoAAAAgFxHGzKhR41mP_Vc-pztE
NNTP-Posting-Host: 95.133.226.215
References: <cea64616-b039-4268-b0a7-23bf314a49b6n@googlegroups.com>
<ugbmrn$38akq$1@dont-email.me> <slrnuiirvg.akff.avl@logic.at>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <2568ad96-3a8d-481e-8a1c-e658936ec87fn@googlegroups.com>
Subject: Re: element-wise union of lists
From: ed.zozulya@gmail.com (Eduard Zozulya)
Injection-Date: Sat, 14 Oct 2023 07:20:39 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
 by: Eduard Zozulya - Sat, 14 Oct 2023 07:20 UTC

пʼятниця, 13 жовтня 2023 р. о 19:27:56 UTC+3 Andreas Leitgeb пише:
> Rich <ri...@example.invalid> wrote:
> > Eduard Zozulya <ed.zo...@gmail.com> wrote:
> >> How to optimize list merging?
> > The only speedup possibility might be to code a C extension to actually
> > perform the zip, which removes Tcl interpreter overhead, but it would
> > still have to iterate one by one building up the result, so there is a
> > lower bound below which the operation simply will not reach performace
> > wise.
> according to another followup in this thread, building a dict gave a
> slight improvement over building a list.
>
> There might be two reasons for that:
>
> - the list originally created was used as a dict afterwards,
> so building a dict in first place is of course better,
> than creating a list and having it converted to dict.
>
> - maybe the first list contains certain elements a multiple times,
> e.g. list1 is {a a a a}, then the dict created would only
> contain key "a" with last value of second list. That may
> or may not be OP's intention.

Mergin based on lappend or dict almost equal.
Sometimes, depending on the data in the lists, the version on the base lappend is ahead, and sometimes on the base dict.
..
I am tried another:
proc UnionList { l1 l2 } {
return [join [lmap e1 $l1 e2 $l2 { list $e1 $e2 }]]
}

it is 30 percent faster without "join", but with "join" - it is almost twice as slow.
Therefore, if it is necessary to get the lists of the type
{1 a} {2 s} {3 d}
then the last variant based on lmap is the best solution.

Re: element-wise union of lists

<6f60091c-973f-410b-9be2-ada309ef90ccn@googlegroups.com>

  copy mid

https://news.novabbs.org/devel/article-flat.php?id=12588&group=comp.lang.tcl#12588

  copy link   Newsgroups: comp.lang.tcl
X-Received: by 2002:a05:6214:184d:b0:66d:3384:1b with SMTP id d13-20020a056214184d00b0066d3384001bmr49946qvy.5.1697276540508;
Sat, 14 Oct 2023 02:42:20 -0700 (PDT)
X-Received: by 2002:a05:6808:2a62:b0:3af:c13c:b442 with SMTP id
fu2-20020a0568082a6200b003afc13cb442mr10286796oib.10.1697276540298; Sat, 14
Oct 2023 02:42:20 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.goja.nl.eu.org!weretis.net!feeder8.news.weretis.net!feeder1.feed.usenet.farm!feed.usenet.farm!peer02.ams4!peer.am4.highwinds-media.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.tcl
Date: Sat, 14 Oct 2023 02:42:19 -0700 (PDT)
In-Reply-To: <2568ad96-3a8d-481e-8a1c-e658936ec87fn@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=2003:ee:972c:400:116d:b2b2:634a:78c3;
posting-account=IpC1pwoAAACCAmF-qbg4PWxvUAd-j7Tc
NNTP-Posting-Host: 2003:ee:972c:400:116d:b2b2:634a:78c3
References: <cea64616-b039-4268-b0a7-23bf314a49b6n@googlegroups.com>
<ugbmrn$38akq$1@dont-email.me> <slrnuiirvg.akff.avl@logic.at> <2568ad96-3a8d-481e-8a1c-e658936ec87fn@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <6f60091c-973f-410b-9be2-ada309ef90ccn@googlegroups.com>
Subject: Re: element-wise union of lists
From: molecool1058@googlemail.com (Mole Cool)
Injection-Date: Sat, 14 Oct 2023 09:42:20 +0000
Content-Type: text/plain; charset="UTF-8"
X-Received-Bytes: 4074
 by: Mole Cool - Sat, 14 Oct 2023 09:42 UTC

It is interesting, I though call by name/ref would be faster, because you don't need to copy so much data in memory, but it was only faster for small strings. And lset is comparable slow.

time0 {8733.72 microseconds per iteration}
time1 {9645.48 microseconds per iteration}
time2 {9336.58 microseconds per iteration}
time3 {9219.38 microseconds per iteration}
time4 {11611.38 microseconds per iteration}
time5 {15875.34 microseconds per iteration}

proc Task {} {
set n 100000
set t 50

set time0 [time {Test0 $n} $t]
set time1 [time {Test1 $n} $t]
set time2 [time {Test2 $n} $t]
set time3 [time {Test3 $n} $t]
set time4 [time {Test4 $n} $t]
set time5 [time {Test5 $n} $t]
} # std call by value
proc Test0 {n} {
set L1 [Get_List1 $n ]
set L2 [Get_List2 $n ]
set LR [LMergeByVal0 $L1 $L2]
} proc LMergeByVal0 {L1 L2} {
foreach I1 $L1 I2 $L2 {
lappend LR $I1 $I2
}
return $LR
} # in call by ref
proc Test1 {n} {
set L1 [Get_List1 $n ]
set L2 [Get_List2 $n ]
set LR [LMergeByRef1 L1 L2]
}

proc LMergeByRef1 {cbrL1 cbrL2} {
upvar $cbrL1 L1
upvar $cbrL2 L2
foreach I1 $L1 I2 $L2 {
lappend LR $I1 $I2
}
}

# all by ref
proc Test2 {n} {
set L1 [Get_List1 $n ]
set L2 [Get_List2 $n ]
set Lr [list]
LMergeByRef2 L1 L2 LR

}
proc LMergeByRef2 {cbrL1 cbrL2 cbrRes} {
upvar $cbrL1 L1
upvar $cbrL2 L2
upvar $cbrRes LR
foreach I1 $L1 I2 $L2 {
lappend LR $I1 $I2
}
}

# result by ref
proc Test3 {n} {
set L1 [Get_List1 $n ]
set L2 [Get_List2 $n ]
set LR [list]
LMergeByRef3 $L1 $L2 LR
}

proc LMergeByRef3 {L1 L2 cbrRes} {
upvar $cbrRes LR
foreach I1 $L1 I2 $L2 {
lappend LR $I1 $I2
}
return $LR
} # by ref and index
proc Test4 {n} {
set L1 [Get_List1 $n ]
set L2 [Get_List2 $n ]
set LR [list]
LMergeByRef4 L1 L2 LR
}

proc LMergeByRef4 {cbrL1 cbrL2 cbrRes} {
upvar $cbrL1 L1
upvar $cbrL2 L2
upvar $cbrRes LR
set LR [list]
set n [llength $L1]
for {set i 0} {$i < $n} {incr i} {
lappend LR [lindex $L1 $i] [lindex $L2 $i]
}
return $LR
} # use lmap
proc Test5 {n} {
set L1 [Get_List1 $n ]
set L2 [Get_List2 $n ]
set LR [LMergeByRef5 L1 L2]
} proc LMergeByRef5 {cbrL1 cbrL2} {
upvar $cbrL1 L1
upvar $cbrL2 L2
return [lmap a $L1 b $L2 {list $a $b}]
}

proc Get_List1 {n} {
return [lrepeat $n {3 2 5 1 9 4} ]
}

proc Get_List2 {n} {
return [lrepeat $n {A B C d e F} ]
}

Re: element-wise union of lists

<9kdliil7eer15b3baluodkeb1bpfh9rohd@4ax.com>

  copy mid

https://news.novabbs.org/devel/article-flat.php?id=12590&group=comp.lang.tcl#12590

  copy link   Newsgroups: comp.lang.tcl
Path: i2pn2.org!i2pn.org!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: hgiese@ratiosoft.com (Helmut Giese)
Newsgroups: comp.lang.tcl
Subject: Re: element-wise union of lists
Date: Sat, 14 Oct 2023 17:48:40 +0200
Organization: ratiosoft
Lines: 143
Message-ID: <9kdliil7eer15b3baluodkeb1bpfh9rohd@4ax.com>
References: <cea64616-b039-4268-b0a7-23bf314a49b6n@googlegroups.com> <ugbmrn$38akq$1@dont-email.me> <slrnuiirvg.akff.avl@logic.at> <2568ad96-3a8d-481e-8a1c-e658936ec87fn@googlegroups.com> <6f60091c-973f-410b-9be2-ada309ef90ccn@googlegroups.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Injection-Info: dont-email.me; posting-host="f29be70e6dee01956cbea03ac83c0446";
logging-data="4135217"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18RsE7eeqY2L6AFFKooz0z2"
Cancel-Lock: sha1:48k6LRp6gw5sVpqJ+vk7Z7PxmNE=
X-Newsreader: Forte Free Agent 1.93/32.576 English (American)
 by: Helmut Giese - Sat, 14 Oct 2023 15:48 UTC

Hi Mole,
my 'dict'version doesn't seem too bad
Taking your example and adding thisversion like so
proc Test6 {n} {
set L1 [Get_List1 $n ]
set L2 [Get_List2 $n ]
set d [dict create]
foreach e1 $L1 e2 $L2 {
dict set d $e1 $e2
}
set d
}
(and of course adding it to 'Task') I got the following results on my
machine:
time0 15875.12 microseconds per iteration
time1 15884.836000000001 microseconds per iteration
time2 15795.996000000001 microseconds per iteration
time3 15926.432000000003 microseconds per iteration
time4 22394.828 microseconds per iteration
time5 15459.424 microseconds per iteration
time6 6233.11 microseconds per iteration

Interesting result. Have a nice weekend
Helmut

>It is interesting, I though call by name/ref would be faster, because you don't need to copy so much data in memory, but it was only faster for small strings. And lset is comparable slow.
>
> time0 {8733.72 microseconds per iteration}
> time1 {9645.48 microseconds per iteration}
> time2 {9336.58 microseconds per iteration}
> time3 {9219.38 microseconds per iteration}
> time4 {11611.38 microseconds per iteration}
> time5 {15875.34 microseconds per iteration}
>
>proc Task {} {
> set n 100000
> set t 50
>
> set time0 [time {Test0 $n} $t]
> set time1 [time {Test1 $n} $t]
> set time2 [time {Test2 $n} $t]
> set time3 [time {Test3 $n} $t]
> set time4 [time {Test4 $n} $t]
> set time5 [time {Test5 $n} $t]
>}
># std call by value
>proc Test0 {n} {
> set L1 [Get_List1 $n ]
> set L2 [Get_List2 $n ]
> set LR [LMergeByVal0 $L1 $L2]
>}
>proc LMergeByVal0 {L1 L2} {
> foreach I1 $L1 I2 $L2 {
> lappend LR $I1 $I2
> }
> return $LR
>}
># in call by ref
>proc Test1 {n} {
> set L1 [Get_List1 $n ]
> set L2 [Get_List2 $n ]
> set LR [LMergeByRef1 L1 L2]
>}
>
>proc LMergeByRef1 {cbrL1 cbrL2} {
> upvar $cbrL1 L1
> upvar $cbrL2 L2
> foreach I1 $L1 I2 $L2 {
> lappend LR $I1 $I2
> }
>}
>
># all by ref
>proc Test2 {n} {
> set L1 [Get_List1 $n ]
> set L2 [Get_List2 $n ]
> set Lr [list]
> LMergeByRef2 L1 L2 LR
>
>}
>proc LMergeByRef2 {cbrL1 cbrL2 cbrRes} {
> upvar $cbrL1 L1
> upvar $cbrL2 L2
> upvar $cbrRes LR
> foreach I1 $L1 I2 $L2 {
> lappend LR $I1 $I2
> }
>}
>
># result by ref
>proc Test3 {n} {
> set L1 [Get_List1 $n ]
> set L2 [Get_List2 $n ]
> set LR [list]
> LMergeByRef3 $L1 $L2 LR
>}
>
>proc LMergeByRef3 {L1 L2 cbrRes} {
> upvar $cbrRes LR
> foreach I1 $L1 I2 $L2 {
> lappend LR $I1 $I2
> }
> return $LR
>}
># by ref and index
>proc Test4 {n} {
> set L1 [Get_List1 $n ]
> set L2 [Get_List2 $n ]
> set LR [list]
> LMergeByRef4 L1 L2 LR
>}
>
>proc LMergeByRef4 {cbrL1 cbrL2 cbrRes} {
> upvar $cbrL1 L1
> upvar $cbrL2 L2
> upvar $cbrRes LR
> set LR [list]
> set n [llength $L1]
> for {set i 0} {$i < $n} {incr i} {
> lappend LR [lindex $L1 $i] [lindex $L2 $i]
> }
> return $LR
>}
># use lmap
>proc Test5 {n} {
> set L1 [Get_List1 $n ]
> set L2 [Get_List2 $n ]
> set LR [LMergeByRef5 L1 L2]
>}
>proc LMergeByRef5 {cbrL1 cbrL2} {
> upvar $cbrL1 L1
> upvar $cbrL2 L2
> return [lmap a $L1 b $L2 {list $a $b}]
>}
>
>proc Get_List1 {n} {
> return [lrepeat $n {3 2 5 1 9 4} ]
>}
>
>proc Get_List2 {n} {
> return [lrepeat $n {A B C d e F} ]
>}

Re: element-wise union of lists

<33e00fa0-dc2f-4a2f-aa5e-eb7eee40566dn@googlegroups.com>

  copy mid

https://news.novabbs.org/devel/article-flat.php?id=12592&group=comp.lang.tcl#12592

  copy link   Newsgroups: comp.lang.tcl
X-Received: by 2002:ac8:71d6:0:b0:419:b68f:df5 with SMTP id i22-20020ac871d6000000b00419b68f0df5mr102143qtp.1.1697316587653;
Sat, 14 Oct 2023 13:49:47 -0700 (PDT)
X-Received: by 2002:a9d:7dcf:0:b0:6c4:7e6c:cb4e with SMTP id
k15-20020a9d7dcf000000b006c47e6ccb4emr9019437otn.5.1697316587360; Sat, 14 Oct
2023 13:49:47 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!border-2.nntp.ord.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.tcl
Date: Sat, 14 Oct 2023 13:49:46 -0700 (PDT)
In-Reply-To: <ugbmrn$38akq$1@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=84.115.226.216; posting-account=Od2xOAoAAACEyRX3Iu5rYt4oevuoeYUG
NNTP-Posting-Host: 84.115.226.216
References: <cea64616-b039-4268-b0a7-23bf314a49b6n@googlegroups.com> <ugbmrn$38akq$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <33e00fa0-dc2f-4a2f-aa5e-eb7eee40566dn@googlegroups.com>
Subject: Re: element-wise union of lists
From: martin.heinrich@frequentis.com (heinrichmartin)
Injection-Date: Sat, 14 Oct 2023 20:49:47 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Lines: 41
 by: heinrichmartin - Sat, 14 Oct 2023 20:49 UTC

On Friday, October 13, 2023 at 5:14:04 PM UTC+2, Rich wrote:
> Eduard Zozulya wrote:
> > Need union two list as
> > set l1 "1 2 3"
> > set l2 "a s d"
> >
> > Result list as "1 a 2 s 3 d"
> >
> > This procedure
> > proc UnionList { l1 l2 } {
> > foreach e1 $l1 e2 $l2 {
> > lappend lret $e1 $e2
> > }
> > return $lret
> > }
> > working very slowly because lists l1 and l2 very big (100000 elements)
> >
> > How to optimize list merging?
> The common name for this is "zipping" lists (see
> https://wiki.tcl-lang.org/page/lzip) and unfortunately, no matter how
> hard you try to 'hide' the fact, ultimately any abstraction will expand
> into iterating over both lists one element at a time and creating a
> result from each element one pair of elements at a time.
>
> There simply is not any other way to perform the operation.
>
> The only speedup possibility might be to code a C extension to actually
> perform the zip, which removes Tcl interpreter overhead, but it would
> still have to iterate one by one building up the result, so there is a
> lower bound below which the operation simply will not reach performace
> wise.

That might be fun. A few constraints should help, e.g. if the original lists won't be used after the merge, then one could keep the reference count of their members. (Imagine how Eduard might be incrementing all counters just to decrement them when abandoning the original lists afterwards.)

https://core.tcl-lang.org/tips/doc/trunk/tip/625.md should be a good read on the internals of lists in general.

Re: element-wise union of lists

<49361f12-9d6d-4a5a-84cf-3ddcf735fe9en@googlegroups.com>

  copy mid

https://news.novabbs.org/devel/article-flat.php?id=12594&group=comp.lang.tcl#12594

  copy link   Newsgroups: comp.lang.tcl
X-Received: by 2002:a05:622a:34b:b0:417:fe9c:6dbf with SMTP id r11-20020a05622a034b00b00417fe9c6dbfmr541725qtw.11.1697328062517;
Sat, 14 Oct 2023 17:01:02 -0700 (PDT)
X-Received: by 2002:a05:6808:152a:b0:3ad:f860:b315 with SMTP id
u42-20020a056808152a00b003adf860b315mr14901567oiw.2.1697328062187; Sat, 14
Oct 2023 17:01:02 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!1.us.feeder.erje.net!feeder.erje.net!usenet.blueworldhosting.com!diablo1.usenet.blueworldhosting.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.tcl
Date: Sat, 14 Oct 2023 17:01:01 -0700 (PDT)
In-Reply-To: <33e00fa0-dc2f-4a2f-aa5e-eb7eee40566dn@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=192.183.219.24; posting-account=f4QznQoAAAAjupLEpV87s_G-96g1Io1w
NNTP-Posting-Host: 192.183.219.24
References: <cea64616-b039-4268-b0a7-23bf314a49b6n@googlegroups.com>
<ugbmrn$38akq$1@dont-email.me> <33e00fa0-dc2f-4a2f-aa5e-eb7eee40566dn@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <49361f12-9d6d-4a5a-84cf-3ddcf735fe9en@googlegroups.com>
Subject: Re: element-wise union of lists
From: bgriffinfortytwo@gmail.com (briang)
Injection-Date: Sun, 15 Oct 2023 00:01:02 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Received-Bytes: 3581
 by: briang - Sun, 15 Oct 2023 00:01 UTC

On Saturday, October 14, 2023 at 1:49:49 PM UTC-7, heinrichmartin wrote:
> On Friday, October 13, 2023 at 5:14:04 PM UTC+2, Rich wrote:
> > Eduard Zozulya wrote:
> > > Need union two list as
> > > set l1 "1 2 3"
> > > set l2 "a s d"
> > >
> > > Result list as "1 a 2 s 3 d"
> > >
> > > This procedure
> > > proc UnionList { l1 l2 } {
> > > foreach e1 $l1 e2 $l2 {
> > > lappend lret $e1 $e2
> > > }
> > > return $lret
> > > }
> > > working very slowly because lists l1 and l2 very big (100000 elements)
> > >
> > > How to optimize list merging?
> > The common name for this is "zipping" lists (see
> > https://wiki.tcl-lang.org/page/lzip) and unfortunately, no matter how
> > hard you try to 'hide' the fact, ultimately any abstraction will expand
> > into iterating over both lists one element at a time and creating a
> > result from each element one pair of elements at a time.
> >
> > There simply is not any other way to perform the operation.
> >
> > The only speedup possibility might be to code a C extension to actually
> > perform the zip, which removes Tcl interpreter overhead, but it would
> > still have to iterate one by one building up the result, so there is a
> > lower bound below which the operation simply will not reach performace
> > wise.
> That might be fun. A few constraints should help, e.g. if the original lists won't be used after the merge, then one could keep the reference count of their members. (Imagine how Eduard might be incrementing all counters just to decrement them when abandoning the original lists afterwards.)
>
> https://core.tcl-lang.org/tips/doc/trunk/tip/625.md should be a good read on the internals of lists in general.

This would be an excellent candidate for a Tcl 9 Abstract List. The AL would simply hold a reference to the 2 original lists, and then index into the the even or odd list as needed. The initial construction would have a constant creation time (practically zero), regardless of list length. The string creation would be the same cost as with a traditional list. There are other optimizations possible for the various other list operations.

-Brian

Re: element-wise union of lists

<86b8aa4c-76cc-4392-a557-59245c952affn@googlegroups.com>

  copy mid

https://news.novabbs.org/devel/article-flat.php?id=12597&group=comp.lang.tcl#12597

  copy link   Newsgroups: comp.lang.tcl
X-Received: by 2002:a05:6214:2e07:b0:66c:eec1:4be4 with SMTP id mx7-20020a0562142e0700b0066ceec14be4mr311731qvb.3.1697380081995;
Sun, 15 Oct 2023 07:28:01 -0700 (PDT)
X-Received: by 2002:a05:6830:4121:b0:6bc:ac3d:2b77 with SMTP id
w33-20020a056830412100b006bcac3d2b77mr3026448ott.2.1697380081794; Sun, 15 Oct
2023 07:28:01 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!1.us.feeder.erje.net!2.eu.feeder.erje.net!feeder.erje.net!border-1.nntp.ord.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.tcl
Date: Sun, 15 Oct 2023 07:28:01 -0700 (PDT)
In-Reply-To: <49361f12-9d6d-4a5a-84cf-3ddcf735fe9en@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=2003:ee:9734:9100:34bf:bb72:91c2:3cfc;
posting-account=IpC1pwoAAACCAmF-qbg4PWxvUAd-j7Tc
NNTP-Posting-Host: 2003:ee:9734:9100:34bf:bb72:91c2:3cfc
References: <cea64616-b039-4268-b0a7-23bf314a49b6n@googlegroups.com>
<ugbmrn$38akq$1@dont-email.me> <33e00fa0-dc2f-4a2f-aa5e-eb7eee40566dn@googlegroups.com>
<49361f12-9d6d-4a5a-84cf-3ddcf735fe9en@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <86b8aa4c-76cc-4392-a557-59245c952affn@googlegroups.com>
Subject: Re: element-wise union of lists
From: molecool1058@googlemail.com (Mole Cool)
Injection-Date: Sun, 15 Oct 2023 14:28:01 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Lines: 161
 by: Mole Cool - Sun, 15 Oct 2023 14:28 UTC

Sorry Helmut, your result was unfair :-) , because you may have worked with one index only. And if you have no idea what data you get, this may dangerous. List creation is now out, done in 'Task', only with call by values, and sorry dict is not the fastest :-), but it is very fast for few indicies. And you did it in one proc, this was not fair either :-)

And as mentioned it seems to be 30% slower

Now the start scenario is the same for each test, I hope :-)

time1 {10133.08 microseconds per iteration}
time2 {10808.5 microseconds per iteration}
time3 {10865.56 microseconds per iteration}
time4 {13078.14 microseconds per iteration}
time5 {20947.82 microseconds per iteration}
time6 {20225.42 microseconds per iteration}
time7 {13771.64 microseconds per iteration}

proc Task {} {
set n 100000
set t 50

# L1 has now uniquid indicines
set L1 [Get_List1 $n ]
set L2 [Get_List2 $n ]

set time0 [time {ZIP_Main0 $L1 $L2} $t]
set time1 [time {ZIP_Main1 $L1 $L2} $t]
set time2 [time {ZIP_Main2 $L1 $L2} $t]
set time3 [time {ZIP_Main3 $L1 $L2} $t]
set time4 [time {ZIP_Main4 $L1 $L2} $t]
set time5 [time {ZIP_Main5 $L1 $L2} $t]
set time6 [time {ZIP_Main6 $L1 $L2} $t]
set time7 [time {ZIP_Main7 $L1 $L2} $t]

}

# std call by value
proc ZIP_Main0 {L1 L2} {
set LR [ZIP_Action0 $L1 $L2]
}

proc ZIP_Action0 {L1 L2} {
foreach I1 $L1 I2 $L2 {
lappend LR $I1 $I2
}
return $LR
}

# in args by ref
proc ZIP_Main1 {L1 L2} {
set LR [ZIP_Action1 L1 L2]
}

proc ZIP_Action1 {cbrL1 cbrL2} {
upvar $cbrL1 L1
upvar $cbrL2 L2
foreach I1 $L1 I2 $L2 {
lappend LR $I1 $I2
}
return $LR
}

# all by ref
proc ZIP_Main2 {L1 L2} {
set LR [list]
ZIP_Action2 L1 L2 LR
}

proc ZIP_Action2 {cbrL1 cbrL2 cbrRes} {
upvar $cbrL1 L1
upvar $cbrL2 L2
upvar $cbrRes LR
foreach I1 $L1 I2 $L2 {
lappend LR $I1 $I2
}
} # result by ref
proc ZIP_Main3 {L1 L2} {
set LR [list]
ZIP_Action3 $L1 $L2 LR
}

proc ZIP_Action3 {L1 L2 cbrRes} {
upvar $cbrRes LR
foreach I1 $L1 I2 $L2 {
lappend LR $I1 $I2
}
}

# # by ref and index
proc ZIP_Main4 {L1 L2} {
set LR [list]
ZIP_Action4 L1 L2 LR
}

proc ZIP_Action4 {cbrL1 cbrL2 cbrRes} {
upvar $cbrL1 L1
upvar $cbrL2 L2
upvar $cbrRes LR
set LR [list]
set n [llength $L1]
for {set i 0} {$i < $n} {incr i} {
lappend LR [lindex $L1 $i] [lindex $L2 $i]
}
return $LR
} # use lmap by val
proc ZIP_Main5 {L1 L2} {
set LR [ZIP_Action5 $L1 $L2]
}

proc ZIP_Action5 {L1 L2} {
return [lmap a $L1 b $L2 {list $a $b}]
}

# use lmap by ref
proc ZIP_Main6 {L1 L2} {
set LR [ZIP_Action6 L1 L2]
}

proc ZIP_Action6 {cbrL1 cbrL2} {
upvar $cbrL1 L1
upvar $cbrL2 L2
return [lmap a $L1 b $L2 {list $a $b}]
}

# use dict with unique ID's in L1
# use lmap by ref
proc ZIP_Main7 {L1 L2} {
set LR [ZIP_Action7 $L1 $L2]
}

proc ZIP_Action7 {L1 L2} {
set d [dict create]
foreach I1 $L1 I2 $L2 {
dict set d $I1 $I2
}
return [set d]
}

proc Get_List1 {n} {
set bl [list]
for {set i 0} {$i < $n} {incr i} {
lappend bl $i
}
return $bl
}

proc Get_List2 {n} {
return [lrepeat $n {A B C d e F} ]
}

Re: element-wise union of lists

<26c2dbaf-5bf2-4f19-acbe-644bb2d2ac44n@googlegroups.com>

  copy mid

https://news.novabbs.org/devel/article-flat.php?id=12603&group=comp.lang.tcl#12603

  copy link   Newsgroups: comp.lang.tcl
X-Received: by 2002:ac8:4f96:0:b0:418:fed:c02 with SMTP id j22-20020ac84f96000000b004180fed0c02mr81502qtw.8.1697601855706;
Tue, 17 Oct 2023 21:04:15 -0700 (PDT)
X-Received: by 2002:a05:6808:2208:b0:3b2:e46e:448c with SMTP id
bd8-20020a056808220800b003b2e46e448cmr732203oib.3.1697601855469; Tue, 17 Oct
2023 21:04:15 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!diablo1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.tcl
Date: Tue, 17 Oct 2023 21:04:14 -0700 (PDT)
In-Reply-To: <86b8aa4c-76cc-4392-a557-59245c952affn@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=192.183.219.24; posting-account=f4QznQoAAAAjupLEpV87s_G-96g1Io1w
NNTP-Posting-Host: 192.183.219.24
References: <cea64616-b039-4268-b0a7-23bf314a49b6n@googlegroups.com>
<ugbmrn$38akq$1@dont-email.me> <33e00fa0-dc2f-4a2f-aa5e-eb7eee40566dn@googlegroups.com>
<49361f12-9d6d-4a5a-84cf-3ddcf735fe9en@googlegroups.com> <86b8aa4c-76cc-4392-a557-59245c952affn@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <26c2dbaf-5bf2-4f19-acbe-644bb2d2ac44n@googlegroups.com>
Subject: Re: element-wise union of lists
From: bgriffinfortytwo@gmail.com (briang)
Injection-Date: Wed, 18 Oct 2023 04:04:15 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Received-Bytes: 6695
 by: briang - Wed, 18 Oct 2023 04:04 UTC

On Sunday, October 15, 2023 at 7:28:04 AM UTC-7, Mole Cool wrote:
> Sorry Helmut, your result was unfair :-) , because you may have worked with one index only. And if you have no idea what data you get, this may dangerous. List creation is now out, done in 'Task', only with call by values, and sorry dict is not the fastest :-), but it is very fast for few indicies.. And you did it in one proc, this was not fair either :-)
>
> And as mentioned it seems to be 30% slower
>
> Now the start scenario is the same for each test, I hope :-)
>
> time1 {10133.08 microseconds per iteration}
> time2 {10808.5 microseconds per iteration}
> time3 {10865.56 microseconds per iteration}
> time4 {13078.14 microseconds per iteration}
> time5 {20947.82 microseconds per iteration}
> time6 {20225.42 microseconds per iteration}
> time7 {13771.64 microseconds per iteration}
> proc Task {} {
> set n 100000
> set t 50
> # L1 has now uniquid indicines
> set L1 [Get_List1 $n ]
> set L2 [Get_List2 $n ]
> set time0 [time {ZIP_Main0 $L1 $L2} $t]
> set time1 [time {ZIP_Main1 $L1 $L2} $t]
> set time2 [time {ZIP_Main2 $L1 $L2} $t]
> set time3 [time {ZIP_Main3 $L1 $L2} $t]
> set time4 [time {ZIP_Main4 $L1 $L2} $t]
> set time5 [time {ZIP_Main5 $L1 $L2} $t]
> set time6 [time {ZIP_Main6 $L1 $L2} $t]
> set time7 [time {ZIP_Main7 $L1 $L2} $t]
> }
>
> # std call by value
> proc ZIP_Main0 {L1 L2} {
> set LR [ZIP_Action0 $L1 $L2]
> }
>
> proc ZIP_Action0 {L1 L2} {
> foreach I1 $L1 I2 $L2 {
> lappend LR $I1 $I2
> }
> return $LR
> }
> # in args by ref
> proc ZIP_Main1 {L1 L2} {
> set LR [ZIP_Action1 L1 L2]
> }
>
>
> proc ZIP_Action1 {cbrL1 cbrL2} {
> upvar $cbrL1 L1
> upvar $cbrL2 L2
> foreach I1 $L1 I2 $L2 {
> lappend LR $I1 $I2
> }
> return $LR
> }
>
> # all by ref
> proc ZIP_Main2 {L1 L2} {
> set LR [list]
> ZIP_Action2 L1 L2 LR
> }
>
> proc ZIP_Action2 {cbrL1 cbrL2 cbrRes} {
> upvar $cbrL1 L1
> upvar $cbrL2 L2
> upvar $cbrRes LR
> foreach I1 $L1 I2 $L2 {
> lappend LR $I1 $I2
> }
> }
> # result by ref
> proc ZIP_Main3 {L1 L2} {
> set LR [list]
> ZIP_Action3 $L1 $L2 LR
> }
>
>
> proc ZIP_Action3 {L1 L2 cbrRes} {
> upvar $cbrRes LR
> foreach I1 $L1 I2 $L2 {
> lappend LR $I1 $I2
> }
> }
> # # by ref and index
> proc ZIP_Main4 {L1 L2} {
> set LR [list]
> ZIP_Action4 L1 L2 LR
> }
>
> proc ZIP_Action4 {cbrL1 cbrL2 cbrRes} {
> upvar $cbrL1 L1
> upvar $cbrL2 L2
> upvar $cbrRes LR
> set LR [list]
> set n [llength $L1]
> for {set i 0} {$i < $n} {incr i} {
> lappend LR [lindex $L1 $i] [lindex $L2 $i]
> }
> return $LR
> }
> # use lmap by val
> proc ZIP_Main5 {L1 L2} {
> set LR [ZIP_Action5 $L1 $L2]
> }
>
> proc ZIP_Action5 {L1 L2} {
> return [lmap a $L1 b $L2 {list $a $b}]
> }
> # use lmap by ref
> proc ZIP_Main6 {L1 L2} {
> set LR [ZIP_Action6 L1 L2]
> }
>
> proc ZIP_Action6 {cbrL1 cbrL2} {
> upvar $cbrL1 L1
> upvar $cbrL2 L2
> return [lmap a $L1 b $L2 {list $a $b}]
> }
> # use dict with unique ID's in L1
> # use lmap by ref
> proc ZIP_Main7 {L1 L2} {
> set LR [ZIP_Action7 $L1 $L2]
> }
>
> proc ZIP_Action7 {L1 L2} {
> set d [dict create]
> foreach I1 $L1 I2 $L2 {
> dict set d $I1 $I2
> }
> return [set d]
> }
>
> proc Get_List1 {n} {
> set bl [list]
> for {set i 0} {$i < $n} {incr i} {
> lappend bl $i
> }
> return $bl
> }
>
> proc Get_List2 {n} {
> return [lrepeat $n {A B C d e F} ]
> }

I've implemented "ZIP" as an abstract list. It is implemented as the command [lweave] which takes 1 or more lists as arguments and returns the zippered (or weaved) list.

Added the following test procs:

package require lweave
# use lweave
proc ZIP_Main8 {L1 L2} {
set LR [ZIP_Action8 $L1 $L2]
}

proc ZIP_Action8 {L1 L2} {
lweave $L1 $L2
}

proc ZipCheck {0 1 zip} {
set i 0
set errors 0
foreach a $0 b $1 {
if {$a ne [lindex $zip $i]} {
puts "Mismatch($i) $a ne [lindex $zip $i]"
incr errors
}
incr i
if {$b ne [lindex $zip $i]} {
puts "Mismatch($i) $b ne [lindex $zip $i]"
incr errors
}
incr i
}
puts "Errors=$errors"
}

And here are the results. (Note: I'm using a virtual machine running on an older laptop, so the times are about double+ those reported above.)

$ tclsh9.0 weave_test.tcl
Start Task
Errors=0
Errors=0
timeL1->19785 microseconds per iteration
timeL2->1034 microseconds per iteration
time0->31293.82 microseconds per iteration
time1->32768.96 microseconds per iteration
time2->31919.48 microseconds per iteration
time3->31927.18 microseconds per iteration
time4->40238.34 microseconds per iteration
time5->34435.24 microseconds per iteration
time6->34532.44 microseconds per iteration
time7->52551.18 microseconds per iteration
time8->2.88 microseconds per iteration

I will check in the implementation to github in the next couple days, then post a link here.
-Brian

Re: element-wise union of lists

<c3961810-33a3-437e-bf85-0a837f689e93n@googlegroups.com>

  copy mid

https://news.novabbs.org/devel/article-flat.php?id=12612&group=comp.lang.tcl#12612

  copy link   Newsgroups: comp.lang.tcl
X-Received: by 2002:ac8:72cf:0:b0:419:be59:aba0 with SMTP id o15-20020ac872cf000000b00419be59aba0mr16859qtp.13.1697677111819;
Wed, 18 Oct 2023 17:58:31 -0700 (PDT)
X-Received: by 2002:a05:6808:16a0:b0:39c:a74b:81d6 with SMTP id
bb32-20020a05680816a000b0039ca74b81d6mr284080oib.7.1697677111553; Wed, 18 Oct
2023 17:58:31 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!diablo1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.tcl
Date: Wed, 18 Oct 2023 17:58:30 -0700 (PDT)
In-Reply-To: <26c2dbaf-5bf2-4f19-acbe-644bb2d2ac44n@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=192.183.219.24; posting-account=f4QznQoAAAAjupLEpV87s_G-96g1Io1w
NNTP-Posting-Host: 192.183.219.24
References: <cea64616-b039-4268-b0a7-23bf314a49b6n@googlegroups.com>
<ugbmrn$38akq$1@dont-email.me> <33e00fa0-dc2f-4a2f-aa5e-eb7eee40566dn@googlegroups.com>
<49361f12-9d6d-4a5a-84cf-3ddcf735fe9en@googlegroups.com> <86b8aa4c-76cc-4392-a557-59245c952affn@googlegroups.com>
<26c2dbaf-5bf2-4f19-acbe-644bb2d2ac44n@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <c3961810-33a3-437e-bf85-0a837f689e93n@googlegroups.com>
Subject: Re: element-wise union of lists
From: bgriffinfortytwo@gmail.com (briang)
Injection-Date: Thu, 19 Oct 2023 00:58:31 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Received-Bytes: 9063
 by: briang - Thu, 19 Oct 2023 00:58 UTC

On Tuesday, October 17, 2023 at 9:04:18 PM UTC-7, briang wrote:
> On Sunday, October 15, 2023 at 7:28:04 AM UTC-7, Mole Cool wrote:
> > Sorry Helmut, your result was unfair :-) , because you may have worked with one index only. And if you have no idea what data you get, this may dangerous. List creation is now out, done in 'Task', only with call by values, and sorry dict is not the fastest :-), but it is very fast for few indicies. And you did it in one proc, this was not fair either :-)
> >
> > And as mentioned it seems to be 30% slower
> >
> > Now the start scenario is the same for each test, I hope :-)
> >
> > time1 {10133.08 microseconds per iteration}
> > time2 {10808.5 microseconds per iteration}
> > time3 {10865.56 microseconds per iteration}
> > time4 {13078.14 microseconds per iteration}
> > time5 {20947.82 microseconds per iteration}
> > time6 {20225.42 microseconds per iteration}
> > time7 {13771.64 microseconds per iteration}
> > proc Task {} {
> > set n 100000
> > set t 50
> > # L1 has now uniquid indicines
> > set L1 [Get_List1 $n ]
> > set L2 [Get_List2 $n ]
> > set time0 [time {ZIP_Main0 $L1 $L2} $t]
> > set time1 [time {ZIP_Main1 $L1 $L2} $t]
> > set time2 [time {ZIP_Main2 $L1 $L2} $t]
> > set time3 [time {ZIP_Main3 $L1 $L2} $t]
> > set time4 [time {ZIP_Main4 $L1 $L2} $t]
> > set time5 [time {ZIP_Main5 $L1 $L2} $t]
> > set time6 [time {ZIP_Main6 $L1 $L2} $t]
> > set time7 [time {ZIP_Main7 $L1 $L2} $t]
> > }
> >
> > # std call by value
> > proc ZIP_Main0 {L1 L2} {
> > set LR [ZIP_Action0 $L1 $L2]
> > }
> >
> > proc ZIP_Action0 {L1 L2} {
> > foreach I1 $L1 I2 $L2 {
> > lappend LR $I1 $I2
> > }
> > return $LR
> > }
> > # in args by ref
> > proc ZIP_Main1 {L1 L2} {
> > set LR [ZIP_Action1 L1 L2]
> > }
> >
> >
> > proc ZIP_Action1 {cbrL1 cbrL2} {
> > upvar $cbrL1 L1
> > upvar $cbrL2 L2
> > foreach I1 $L1 I2 $L2 {
> > lappend LR $I1 $I2
> > }
> > return $LR
> > }
> >
> > # all by ref
> > proc ZIP_Main2 {L1 L2} {
> > set LR [list]
> > ZIP_Action2 L1 L2 LR
> > }
> >
> > proc ZIP_Action2 {cbrL1 cbrL2 cbrRes} {
> > upvar $cbrL1 L1
> > upvar $cbrL2 L2
> > upvar $cbrRes LR
> > foreach I1 $L1 I2 $L2 {
> > lappend LR $I1 $I2
> > }
> > }
> > # result by ref
> > proc ZIP_Main3 {L1 L2} {
> > set LR [list]
> > ZIP_Action3 $L1 $L2 LR
> > }
> >
> >
> > proc ZIP_Action3 {L1 L2 cbrRes} {
> > upvar $cbrRes LR
> > foreach I1 $L1 I2 $L2 {
> > lappend LR $I1 $I2
> > }
> > }
> > # # by ref and index
> > proc ZIP_Main4 {L1 L2} {
> > set LR [list]
> > ZIP_Action4 L1 L2 LR
> > }
> >
> > proc ZIP_Action4 {cbrL1 cbrL2 cbrRes} {
> > upvar $cbrL1 L1
> > upvar $cbrL2 L2
> > upvar $cbrRes LR
> > set LR [list]
> > set n [llength $L1]
> > for {set i 0} {$i < $n} {incr i} {
> > lappend LR [lindex $L1 $i] [lindex $L2 $i]
> > }
> > return $LR
> > }
> > # use lmap by val
> > proc ZIP_Main5 {L1 L2} {
> > set LR [ZIP_Action5 $L1 $L2]
> > }
> >
> > proc ZIP_Action5 {L1 L2} {
> > return [lmap a $L1 b $L2 {list $a $b}]
> > }
> > # use lmap by ref
> > proc ZIP_Main6 {L1 L2} {
> > set LR [ZIP_Action6 L1 L2]
> > }
> >
> > proc ZIP_Action6 {cbrL1 cbrL2} {
> > upvar $cbrL1 L1
> > upvar $cbrL2 L2
> > return [lmap a $L1 b $L2 {list $a $b}]
> > }
> > # use dict with unique ID's in L1
> > # use lmap by ref
> > proc ZIP_Main7 {L1 L2} {
> > set LR [ZIP_Action7 $L1 $L2]
> > }
> >
> > proc ZIP_Action7 {L1 L2} {
> > set d [dict create]
> > foreach I1 $L1 I2 $L2 {
> > dict set d $I1 $I2
> > }
> > return [set d]
> > }
> >
> > proc Get_List1 {n} {
> > set bl [list]
> > for {set i 0} {$i < $n} {incr i} {
> > lappend bl $i
> > }
> > return $bl
> > }
> >
> > proc Get_List2 {n} {
> > return [lrepeat $n {A B C d e F} ]
> > }
> I've implemented "ZIP" as an abstract list. It is implemented as the command [lweave] which takes 1 or more lists as arguments and returns the zippered (or weaved) list.
>
> Added the following test procs:
>
> package require lweave
> # use lweave
> proc ZIP_Main8 {L1 L2} {
> set LR [ZIP_Action8 $L1 $L2]
> }
>
> proc ZIP_Action8 {L1 L2} {
> lweave $L1 $L2
> }
>
> proc ZipCheck {0 1 zip} {
> set i 0
> set errors 0
> foreach a $0 b $1 {
> if {$a ne [lindex $zip $i]} {
> puts "Mismatch($i) $a ne [lindex $zip $i]"
> incr errors
> }
> incr i
> if {$b ne [lindex $zip $i]} {
> puts "Mismatch($i) $b ne [lindex $zip $i]"
> incr errors
> }
> incr i
> }
> puts "Errors=$errors"
> }
>
> And here are the results. (Note: I'm using a virtual machine running on an older laptop, so the times are about double+ those reported above.)
>
> $ tclsh9.0 weave_test.tcl
> Start Task
> Errors=0
> Errors=0
> timeL1->19785 microseconds per iteration
> timeL2->1034 microseconds per iteration
> time0->31293.82 microseconds per iteration
> time1->32768.96 microseconds per iteration
> time2->31919.48 microseconds per iteration
> time3->31927.18 microseconds per iteration
> time4->40238.34 microseconds per iteration
> time5->34435.24 microseconds per iteration
> time6->34532.44 microseconds per iteration
> time7->52551.18 microseconds per iteration
> time8->2.88 microseconds per iteration
>
> I will check in the implementation to github in the next couple days, then post a link here.
> -Brian

The implementation of "lweave" can be found here:
https://github.com/bgriffinfortytwo/abstractlist-toys/commit/94b0f4addc05e8f777833629847e5dcb685375ca

Here is the comparative results of lweave. Note that although the create time for the weaved (Zipped) list is significantly faster, iterating over the list is about 4x slower. The memory footprint should be smaller though. Also note that string creation is expensive for such large lists.

tclsh9.0 weave_test.tcl
Start Task
timeL1->21252 microseconds per iteration
timeL2->961 microseconds per iteration
time8->2.96 microseconds per iteration
Z8-representation->value is a lweave with a refcount of 2, object pointer at 0x55ad8d4ee960, internal representation 0x55ad8cfbc200:0x55ad8d4ee7b0, no string representation
dict-keys->169024 microseconds per iteration
After-dict->value is a dict with a refcount of 2, object pointer at 0x55ad8d4ee960, internal representation 0x55ad8d02e720:0x0, string representation "0 {A B C d e ..."
time0->32575.44 microseconds per iteration
time1->32297.28 microseconds per iteration
time2->32364.22 microseconds per iteration
time3->32841.46 microseconds per iteration
time4->41252.14 microseconds per iteration
time5->35948.38 microseconds per iteration
time6->35133.78 microseconds per iteration
time7->55273.42 microseconds per iteration
Errors=0
Z0-check->34604 microseconds per iteration
Errors=0
Z8-check->142120 microseconds per iteration
21075 microseconds per iteration

See weave_test.tcl in the abstractlist-toys project to replay the above results.

This implementation will only work in Tcl 9.0.

-Brian

Re: element-wise union of lists

<f3a63010-5636-471b-b852-f7738e95ba52n@googlegroups.com>

  copy mid

https://news.novabbs.org/devel/article-flat.php?id=12616&group=comp.lang.tcl#12616

  copy link   Newsgroups: comp.lang.tcl
X-Received: by 2002:a05:6214:1790:b0:66d:17f:4dd2 with SMTP id ct16-20020a056214179000b0066d017f4dd2mr33791qvb.2.1697715360368;
Thu, 19 Oct 2023 04:36:00 -0700 (PDT)
X-Received: by 2002:a05:6870:e248:b0:1e9:b0fa:de72 with SMTP id
d8-20020a056870e24800b001e9b0fade72mr931629oac.9.1697715360145; Thu, 19 Oct
2023 04:36:00 -0700 (PDT)
Path: i2pn2.org!i2pn.org!paganini.bofh.team!2.eu.feeder.erje.net!feeder.erje.net!feeder1.feed.usenet.farm!feed.usenet.farm!peer02.ams4!peer.am4.highwinds-media.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.tcl
Date: Thu, 19 Oct 2023 04:35:59 -0700 (PDT)
In-Reply-To: <c3961810-33a3-437e-bf85-0a837f689e93n@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=91.217.55.78; posting-account=Od2xOAoAAACEyRX3Iu5rYt4oevuoeYUG
NNTP-Posting-Host: 91.217.55.78
References: <cea64616-b039-4268-b0a7-23bf314a49b6n@googlegroups.com>
<ugbmrn$38akq$1@dont-email.me> <33e00fa0-dc2f-4a2f-aa5e-eb7eee40566dn@googlegroups.com>
<49361f12-9d6d-4a5a-84cf-3ddcf735fe9en@googlegroups.com> <86b8aa4c-76cc-4392-a557-59245c952affn@googlegroups.com>
<26c2dbaf-5bf2-4f19-acbe-644bb2d2ac44n@googlegroups.com> <c3961810-33a3-437e-bf85-0a837f689e93n@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <f3a63010-5636-471b-b852-f7738e95ba52n@googlegroups.com>
Subject: Re: element-wise union of lists
From: martin.heinrich@frequentis.com (heinrichmartin)
Injection-Date: Thu, 19 Oct 2023 11:36:00 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Received-Bytes: 11598
 by: heinrichmartin - Thu, 19 Oct 2023 11:35 UTC

On Thursday, October 19, 2023 at 2:58:34 AM UTC+2, briang wrote:
> On Tuesday, October 17, 2023 at 9:04:18 PM UTC-7, briang wrote:
> > On Sunday, October 15, 2023 at 7:28:04 AM UTC-7, Mole Cool wrote:
> > > Sorry Helmut, your result was unfair :-) , because you may have worked with one index only. And if you have no idea what data you get, this may dangerous. List creation is now out, done in 'Task', only with call by values, and sorry dict is not the fastest :-), but it is very fast for few indicies. And you did it in one proc, this was not fair either :-)
> > >
> > > And as mentioned it seems to be 30% slower
> > >
> > > Now the start scenario is the same for each test, I hope :-)
> > >
> > > time1 {10133.08 microseconds per iteration}
> > > time2 {10808.5 microseconds per iteration}
> > > time3 {10865.56 microseconds per iteration}
> > > time4 {13078.14 microseconds per iteration}
> > > time5 {20947.82 microseconds per iteration}
> > > time6 {20225.42 microseconds per iteration}
> > > time7 {13771.64 microseconds per iteration}
> > > proc Task {} {
> > > set n 100000
> > > set t 50
> > > # L1 has now uniquid indicines
> > > set L1 [Get_List1 $n ]
> > > set L2 [Get_List2 $n ]
> > > set time0 [time {ZIP_Main0 $L1 $L2} $t]
> > > set time1 [time {ZIP_Main1 $L1 $L2} $t]
> > > set time2 [time {ZIP_Main2 $L1 $L2} $t]
> > > set time3 [time {ZIP_Main3 $L1 $L2} $t]
> > > set time4 [time {ZIP_Main4 $L1 $L2} $t]
> > > set time5 [time {ZIP_Main5 $L1 $L2} $t]
> > > set time6 [time {ZIP_Main6 $L1 $L2} $t]
> > > set time7 [time {ZIP_Main7 $L1 $L2} $t]
> > > }
> > >
> > > # std call by value
> > > proc ZIP_Main0 {L1 L2} {
> > > set LR [ZIP_Action0 $L1 $L2]
> > > }
> > >
> > > proc ZIP_Action0 {L1 L2} {
> > > foreach I1 $L1 I2 $L2 {
> > > lappend LR $I1 $I2
> > > }
> > > return $LR
> > > }
> > > # in args by ref
> > > proc ZIP_Main1 {L1 L2} {
> > > set LR [ZIP_Action1 L1 L2]
> > > }
> > >
> > >
> > > proc ZIP_Action1 {cbrL1 cbrL2} {
> > > upvar $cbrL1 L1
> > > upvar $cbrL2 L2
> > > foreach I1 $L1 I2 $L2 {
> > > lappend LR $I1 $I2
> > > }
> > > return $LR
> > > }
> > >
> > > # all by ref
> > > proc ZIP_Main2 {L1 L2} {
> > > set LR [list]
> > > ZIP_Action2 L1 L2 LR
> > > }
> > >
> > > proc ZIP_Action2 {cbrL1 cbrL2 cbrRes} {
> > > upvar $cbrL1 L1
> > > upvar $cbrL2 L2
> > > upvar $cbrRes LR
> > > foreach I1 $L1 I2 $L2 {
> > > lappend LR $I1 $I2
> > > }
> > > }
> > > # result by ref
> > > proc ZIP_Main3 {L1 L2} {
> > > set LR [list]
> > > ZIP_Action3 $L1 $L2 LR
> > > }
> > >
> > >
> > > proc ZIP_Action3 {L1 L2 cbrRes} {
> > > upvar $cbrRes LR
> > > foreach I1 $L1 I2 $L2 {
> > > lappend LR $I1 $I2
> > > }
> > > }
> > > # # by ref and index
> > > proc ZIP_Main4 {L1 L2} {
> > > set LR [list]
> > > ZIP_Action4 L1 L2 LR
> > > }
> > >
> > > proc ZIP_Action4 {cbrL1 cbrL2 cbrRes} {
> > > upvar $cbrL1 L1
> > > upvar $cbrL2 L2
> > > upvar $cbrRes LR
> > > set LR [list]
> > > set n [llength $L1]
> > > for {set i 0} {$i < $n} {incr i} {
> > > lappend LR [lindex $L1 $i] [lindex $L2 $i]
> > > }
> > > return $LR
> > > }
> > > # use lmap by val
> > > proc ZIP_Main5 {L1 L2} {
> > > set LR [ZIP_Action5 $L1 $L2]
> > > }
> > >
> > > proc ZIP_Action5 {L1 L2} {
> > > return [lmap a $L1 b $L2 {list $a $b}]
> > > }
> > > # use lmap by ref
> > > proc ZIP_Main6 {L1 L2} {
> > > set LR [ZIP_Action6 L1 L2]
> > > }
> > >
> > > proc ZIP_Action6 {cbrL1 cbrL2} {
> > > upvar $cbrL1 L1
> > > upvar $cbrL2 L2
> > > return [lmap a $L1 b $L2 {list $a $b}]
> > > }
> > > # use dict with unique ID's in L1
> > > # use lmap by ref
> > > proc ZIP_Main7 {L1 L2} {
> > > set LR [ZIP_Action7 $L1 $L2]
> > > }
> > >
> > > proc ZIP_Action7 {L1 L2} {
> > > set d [dict create]
> > > foreach I1 $L1 I2 $L2 {
> > > dict set d $I1 $I2
> > > }
> > > return [set d]
> > > }
> > >
> > > proc Get_List1 {n} {
> > > set bl [list]
> > > for {set i 0} {$i < $n} {incr i} {
> > > lappend bl $i
> > > }
> > > return $bl
> > > }
> > >
> > > proc Get_List2 {n} {
> > > return [lrepeat $n {A B C d e F} ]
> > > }
> > I've implemented "ZIP" as an abstract list. It is implemented as the command [lweave] which takes 1 or more lists as arguments and returns the zippered (or weaved) list.
> >
> > Added the following test procs:
> >
> > package require lweave
> > # use lweave
> > proc ZIP_Main8 {L1 L2} {
> > set LR [ZIP_Action8 $L1 $L2]
> > }
> >
> > proc ZIP_Action8 {L1 L2} {
> > lweave $L1 $L2
> > }
> >
> > proc ZipCheck {0 1 zip} {
> > set i 0
> > set errors 0
> > foreach a $0 b $1 {
> > if {$a ne [lindex $zip $i]} {
> > puts "Mismatch($i) $a ne [lindex $zip $i]"
> > incr errors
> > }
> > incr i
> > if {$b ne [lindex $zip $i]} {
> > puts "Mismatch($i) $b ne [lindex $zip $i]"
> > incr errors
> > }
> > incr i
> > }
> > puts "Errors=$errors"
> > }
> >
> > And here are the results. (Note: I'm using a virtual machine running on an older laptop, so the times are about double+ those reported above.)
> >
> > $ tclsh9.0 weave_test.tcl
> > Start Task
> > Errors=0
> > Errors=0
> > timeL1->19785 microseconds per iteration
> > timeL2->1034 microseconds per iteration
> > time0->31293.82 microseconds per iteration
> > time1->32768.96 microseconds per iteration
> > time2->31919.48 microseconds per iteration
> > time3->31927.18 microseconds per iteration
> > time4->40238.34 microseconds per iteration
> > time5->34435.24 microseconds per iteration
> > time6->34532.44 microseconds per iteration
> > time7->52551.18 microseconds per iteration
> > time8->2.88 microseconds per iteration
> >
> > I will check in the implementation to github in the next couple days, then post a link here.
> > -Brian
> The implementation of "lweave" can be found here:
> https://github.com/bgriffinfortytwo/abstractlist-toys/commit/94b0f4addc05e8f777833629847e5dcb685375ca
>
> Here is the comparative results of lweave. Note that although the create time for the weaved (Zipped) list is significantly faster, iterating over the list is about 4x slower. The memory footprint should be smaller though. Also note that string creation is expensive for such large lists.
>
> tclsh9.0 weave_test.tcl
> Start Task
> timeL1->21252 microseconds per iteration
> timeL2->961 microseconds per iteration
> time8->2.96 microseconds per iteration
> Z8-representation->value is a lweave with a refcount of 2, object pointer at 0x55ad8d4ee960, internal representation 0x55ad8cfbc200:0x55ad8d4ee7b0, no string representation
> dict-keys->169024 microseconds per iteration
> After-dict->value is a dict with a refcount of 2, object pointer at 0x55ad8d4ee960, internal representation 0x55ad8d02e720:0x0, string representation "0 {A B C d e ..."
> time0->32575.44 microseconds per iteration
> time1->32297.28 microseconds per iteration
> time2->32364.22 microseconds per iteration
> time3->32841.46 microseconds per iteration
> time4->41252.14 microseconds per iteration
> time5->35948.38 microseconds per iteration
> time6->35133.78 microseconds per iteration
> time7->55273.42 microseconds per iteration
> Errors=0
> Z0-check->34604 microseconds per iteration
> Errors=0
> Z8-check->142120 microseconds per iteration
> 21075 microseconds per iteration
>
> See weave_test.tcl in the abstractlist-toys project to replay the above results.
>
> This implementation will only work in Tcl 9.0.
>
> -Brian


Click here to read the complete article
Re: element-wise union of lists

<76d395d0-ea58-4d84-bda6-9627cb83b650n@googlegroups.com>

  copy mid

https://news.novabbs.org/devel/article-flat.php?id=12620&group=comp.lang.tcl#12620

  copy link   Newsgroups: comp.lang.tcl
X-Received: by 2002:a05:620a:3b18:b0:775:8ccf:f084 with SMTP id tl24-20020a05620a3b1800b007758ccff084mr40706qkn.2.1697730005590;
Thu, 19 Oct 2023 08:40:05 -0700 (PDT)
X-Received: by 2002:a05:6808:bc9:b0:3ad:29a4:f542 with SMTP id
o9-20020a0568080bc900b003ad29a4f542mr705782oik.5.1697730005298; Thu, 19 Oct
2023 08:40:05 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.tcl
Date: Thu, 19 Oct 2023 08:40:04 -0700 (PDT)
In-Reply-To: <f3a63010-5636-471b-b852-f7738e95ba52n@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=192.183.219.24; posting-account=f4QznQoAAAAjupLEpV87s_G-96g1Io1w
NNTP-Posting-Host: 192.183.219.24
References: <cea64616-b039-4268-b0a7-23bf314a49b6n@googlegroups.com>
<ugbmrn$38akq$1@dont-email.me> <33e00fa0-dc2f-4a2f-aa5e-eb7eee40566dn@googlegroups.com>
<49361f12-9d6d-4a5a-84cf-3ddcf735fe9en@googlegroups.com> <86b8aa4c-76cc-4392-a557-59245c952affn@googlegroups.com>
<26c2dbaf-5bf2-4f19-acbe-644bb2d2ac44n@googlegroups.com> <c3961810-33a3-437e-bf85-0a837f689e93n@googlegroups.com>
<f3a63010-5636-471b-b852-f7738e95ba52n@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <76d395d0-ea58-4d84-bda6-9627cb83b650n@googlegroups.com>
Subject: Re: element-wise union of lists
From: bgriffinfortytwo@gmail.com (briang)
Injection-Date: Thu, 19 Oct 2023 15:40:05 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
 by: briang - Thu, 19 Oct 2023 15:40 UTC

On Thursday, October 19, 2023 at 4:36:02 AM UTC-7, heinrichmartin wrote:
> On Thursday, October 19, 2023 at 2:58:34 AM UTC+2, briang wrote:
> > On Tuesday, October 17, 2023 at 9:04:18 PM UTC-7, briang wrote:
> > > On Sunday, October 15, 2023 at 7:28:04 AM UTC-7, Mole Cool wrote:
> > > > Sorry Helmut, your result was unfair :-) , because you may have worked with one index only. And if you have no idea what data you get, this may dangerous. List creation is now out, done in 'Task', only with call by values, and sorry dict is not the fastest :-), but it is very fast for few indicies. And you did it in one proc, this was not fair either :-)
> > > >
> > > > And as mentioned it seems to be 30% slower
> > > >
> > > > Now the start scenario is the same for each test, I hope :-)
> > > >
> > > > time1 {10133.08 microseconds per iteration}
> > > > time2 {10808.5 microseconds per iteration}
> > > > time3 {10865.56 microseconds per iteration}
> > > > time4 {13078.14 microseconds per iteration}
> > > > time5 {20947.82 microseconds per iteration}
> > > > time6 {20225.42 microseconds per iteration}
> > > > time7 {13771.64 microseconds per iteration}
> > > > proc Task {} {
> > > > set n 100000
> > > > set t 50
> > > > # L1 has now uniquid indicines
> > > > set L1 [Get_List1 $n ]
> > > > set L2 [Get_List2 $n ]
> > > > set time0 [time {ZIP_Main0 $L1 $L2} $t]
> > > > set time1 [time {ZIP_Main1 $L1 $L2} $t]
> > > > set time2 [time {ZIP_Main2 $L1 $L2} $t]
> > > > set time3 [time {ZIP_Main3 $L1 $L2} $t]
> > > > set time4 [time {ZIP_Main4 $L1 $L2} $t]
> > > > set time5 [time {ZIP_Main5 $L1 $L2} $t]
> > > > set time6 [time {ZIP_Main6 $L1 $L2} $t]
> > > > set time7 [time {ZIP_Main7 $L1 $L2} $t]
> > > > }
> > > >
> > > > # std call by value
> > > > proc ZIP_Main0 {L1 L2} {
> > > > set LR [ZIP_Action0 $L1 $L2]
> > > > }
> > > >
> > > > proc ZIP_Action0 {L1 L2} {
> > > > foreach I1 $L1 I2 $L2 {
> > > > lappend LR $I1 $I2
> > > > }
> > > > return $LR
> > > > }
> > > > # in args by ref
> > > > proc ZIP_Main1 {L1 L2} {
> > > > set LR [ZIP_Action1 L1 L2]
> > > > }
> > > >
> > > >
> > > > proc ZIP_Action1 {cbrL1 cbrL2} {
> > > > upvar $cbrL1 L1
> > > > upvar $cbrL2 L2
> > > > foreach I1 $L1 I2 $L2 {
> > > > lappend LR $I1 $I2
> > > > }
> > > > return $LR
> > > > }
> > > >
> > > > # all by ref
> > > > proc ZIP_Main2 {L1 L2} {
> > > > set LR [list]
> > > > ZIP_Action2 L1 L2 LR
> > > > }
> > > >
> > > > proc ZIP_Action2 {cbrL1 cbrL2 cbrRes} {
> > > > upvar $cbrL1 L1
> > > > upvar $cbrL2 L2
> > > > upvar $cbrRes LR
> > > > foreach I1 $L1 I2 $L2 {
> > > > lappend LR $I1 $I2
> > > > }
> > > > }
> > > > # result by ref
> > > > proc ZIP_Main3 {L1 L2} {
> > > > set LR [list]
> > > > ZIP_Action3 $L1 $L2 LR
> > > > }
> > > >
> > > >
> > > > proc ZIP_Action3 {L1 L2 cbrRes} {
> > > > upvar $cbrRes LR
> > > > foreach I1 $L1 I2 $L2 {
> > > > lappend LR $I1 $I2
> > > > }
> > > > }
> > > > # # by ref and index
> > > > proc ZIP_Main4 {L1 L2} {
> > > > set LR [list]
> > > > ZIP_Action4 L1 L2 LR
> > > > }
> > > >
> > > > proc ZIP_Action4 {cbrL1 cbrL2 cbrRes} {
> > > > upvar $cbrL1 L1
> > > > upvar $cbrL2 L2
> > > > upvar $cbrRes LR
> > > > set LR [list]
> > > > set n [llength $L1]
> > > > for {set i 0} {$i < $n} {incr i} {
> > > > lappend LR [lindex $L1 $i] [lindex $L2 $i]
> > > > }
> > > > return $LR
> > > > }
> > > > # use lmap by val
> > > > proc ZIP_Main5 {L1 L2} {
> > > > set LR [ZIP_Action5 $L1 $L2]
> > > > }
> > > >
> > > > proc ZIP_Action5 {L1 L2} {
> > > > return [lmap a $L1 b $L2 {list $a $b}]
> > > > }
> > > > # use lmap by ref
> > > > proc ZIP_Main6 {L1 L2} {
> > > > set LR [ZIP_Action6 L1 L2]
> > > > }
> > > >
> > > > proc ZIP_Action6 {cbrL1 cbrL2} {
> > > > upvar $cbrL1 L1
> > > > upvar $cbrL2 L2
> > > > return [lmap a $L1 b $L2 {list $a $b}]
> > > > }
> > > > # use dict with unique ID's in L1
> > > > # use lmap by ref
> > > > proc ZIP_Main7 {L1 L2} {
> > > > set LR [ZIP_Action7 $L1 $L2]
> > > > }
> > > >
> > > > proc ZIP_Action7 {L1 L2} {
> > > > set d [dict create]
> > > > foreach I1 $L1 I2 $L2 {
> > > > dict set d $I1 $I2
> > > > }
> > > > return [set d]
> > > > }
> > > >
> > > > proc Get_List1 {n} {
> > > > set bl [list]
> > > > for {set i 0} {$i < $n} {incr i} {
> > > > lappend bl $i
> > > > }
> > > > return $bl
> > > > }
> > > >
> > > > proc Get_List2 {n} {
> > > > return [lrepeat $n {A B C d e F} ]
> > > > }
> > > I've implemented "ZIP" as an abstract list. It is implemented as the command [lweave] which takes 1 or more lists as arguments and returns the zippered (or weaved) list.
> > >
> > > Added the following test procs:
> > >
> > > package require lweave
> > > # use lweave
> > > proc ZIP_Main8 {L1 L2} {
> > > set LR [ZIP_Action8 $L1 $L2]
> > > }
> > >
> > > proc ZIP_Action8 {L1 L2} {
> > > lweave $L1 $L2
> > > }
> > >
> > > proc ZipCheck {0 1 zip} {
> > > set i 0
> > > set errors 0
> > > foreach a $0 b $1 {
> > > if {$a ne [lindex $zip $i]} {
> > > puts "Mismatch($i) $a ne [lindex $zip $i]"
> > > incr errors
> > > }
> > > incr i
> > > if {$b ne [lindex $zip $i]} {
> > > puts "Mismatch($i) $b ne [lindex $zip $i]"
> > > incr errors
> > > }
> > > incr i
> > > }
> > > puts "Errors=$errors"
> > > }
> > >
> > > And here are the results. (Note: I'm using a virtual machine running on an older laptop, so the times are about double+ those reported above.)
> > >
> > > $ tclsh9.0 weave_test.tcl
> > > Start Task
> > > Errors=0
> > > Errors=0
> > > timeL1->19785 microseconds per iteration
> > > timeL2->1034 microseconds per iteration
> > > time0->31293.82 microseconds per iteration
> > > time1->32768.96 microseconds per iteration
> > > time2->31919.48 microseconds per iteration
> > > time3->31927.18 microseconds per iteration
> > > time4->40238.34 microseconds per iteration
> > > time5->34435.24 microseconds per iteration
> > > time6->34532.44 microseconds per iteration
> > > time7->52551.18 microseconds per iteration
> > > time8->2.88 microseconds per iteration
> > >
> > > I will check in the implementation to github in the next couple days, then post a link here.
> > > -Brian
> > The implementation of "lweave" can be found here:
> > https://github.com/bgriffinfortytwo/abstractlist-toys/commit/94b0f4addc05e8f777833629847e5dcb685375ca
> >
> > Here is the comparative results of lweave. Note that although the create time for the weaved (Zipped) list is significantly faster, iterating over the list is about 4x slower. The memory footprint should be smaller though.. Also note that string creation is expensive for such large lists.
> >
> > tclsh9.0 weave_test.tcl
> > Start Task
> > timeL1->21252 microseconds per iteration
> > timeL2->961 microseconds per iteration
> > time8->2.96 microseconds per iteration
> > Z8-representation->value is a lweave with a refcount of 2, object pointer at 0x55ad8d4ee960, internal representation 0x55ad8cfbc200:0x55ad8d4ee7b0, no string representation
> > dict-keys->169024 microseconds per iteration
> > After-dict->value is a dict with a refcount of 2, object pointer at 0x55ad8d4ee960, internal representation 0x55ad8d02e720:0x0, string representation "0 {A B C d e ..."
> > time0->32575.44 microseconds per iteration
> > time1->32297.28 microseconds per iteration
> > time2->32364.22 microseconds per iteration
> > time3->32841.46 microseconds per iteration
> > time4->41252.14 microseconds per iteration
> > time5->35948.38 microseconds per iteration
> > time6->35133.78 microseconds per iteration
> > time7->55273.42 microseconds per iteration
> > Errors=0
> > Z0-check->34604 microseconds per iteration
> > Errors=0
> > Z8-check->142120 microseconds per iteration
> > 21075 microseconds per iteration
> >
> > See weave_test.tcl in the abstractlist-toys project to replay the above results.
> >
> > This implementation will only work in Tcl 9.0.
> >
> > -Brian
> Cool things happen in Tcl 9.0. Looking at the code without any experience with abstract lists, I wonder:


Click here to read the complete article
1
server_pubkey.txt

rocksolid light 0.9.8
clearnet tor