Is that an easy way to sort an array in TCL?
han...@gmail.com
each element orderly.
I can compare them one by one, but it's too complex.
lsort command need me to list all element, it seems that it cann't
user an array name as parameter.
I don't know if there is a function which can use an Array name as
parameter and sort the Array to create another array with orderly
elementes.
Is there a good way?
Any help will be very appreciated!
Rgds,
Admin of NWcheck (Hans Yin)
Email: nwche...@yahoo.ca
Web: wym.oursci.com (china) www.geocities.com/nwcheck2005
(international)
MSN: han...@hotmail.com
David Gravereaux
>Is there a good way?
set listOfNames [lsort [array names arrayVarName]]
foreach element $listOfNames {
puts "element $element = $arrayVarName($element)"
}
where arrayVarName is the name of the array.
--
David Gravereaux <davy...@pobox.com>
[species: human; planet: earth,milkyway(western spiral arm),alpha sector]
Cameron Laird
David Gravereaux <davy...@pobox.com> wrote:
>han...@gmail.com wrote:
>
>>Is there a good way?
>
>set listOfNames [lsort [array names arrayVarName]]
>foreach element $listOfNames {
> puts "element $element = $arrayVarName($element)"
>}
>
>where arrayVarName is the name of the array.
.
.
... and, for amusement, after having executed that, write
parray arrayVarName
Krzysztof Hrebeniuk
proc qsort {arr l p} {
upvar $arr tab
set x $tab($l)
set i $l
set j $p
while {$j > $i} {
while {$x > $tab($i)} {
incr i
}
while {$x < $tab($j)} {
incr j -1
}
if {$i <= $j} {
set w $tab($i)
set tab($i) $tab($j)
set tab($j) $w
incr i
incr j -1
}
}
if {$l < $j} {qsort tab $l $j}
if {$i < $p} {qsort tab $i $p}
}
where:
- arr is the name of the array to sort
- l is the lowest array index
- p is the highest array index
If, for example, you have the "myarray" array indexed from 0 to 999, you
can "quick-sort" it like this:
qsort myarray 0 999
But try to avoid using some very large arrays in your program.
Tcl processes lists much more efficiently.
Krzysztof
--
-----------------------------------------------------------------
Krzysztof Hrebeniuk
e-mail: K.Hre...@opole.pios.gov.pl
Wojewodzki Inspektorat Ochrony Srodowiska
45-035 Opole, ul. Nysy Luzyckiej 42
tel. (48)(077) 454 22 89, 453 99 06
fax (48)(077) 453 00 69
Poland
Donal K. Fellows
> But try to avoid using some very large arrays in your program.
> Tcl processes lists much more efficiently.
Interestingly, the implementation of [lsort] used to use the qsort()
function from the standard C library. We don't any more because there
are a number of situations (which come up fairly often) where the
quicksort algorithm is horribly ill-conditioned. Instead, it uses
mergesort (slightly slower sometimes, but doesn't degrade on near-sorted
input and it's also a stable sort, i.e. it keeps the input order of
identical elements).
Sorting a Tcl array? It's really not designed to work that way, since
the keys are arbitrary strings and not just numbers and Tcl makes no
attempt to guarantee any kind of array element ordering. (It's a hash
table internally, and not a vector or a tree.)
Donal.
Krzysztof Hrebeniuk
> the keys are arbitrary strings and not just numbers and Tcl makes no
> attempt to guarantee any kind of array element ordering. (It's a hash
> table internally, and not a vector or a tree.)
You are right of course. It's the price we pay for the ease of use of
TCL, I think. And it is worth of it eventually. But in many situations
you yearn for a "usual" array where indices are numbers :-)
Donal K. Fellows
> You are right of course. It's the price we pay for the ease of use of
> TCL, I think. And it is worth of it eventually. But in many situations
> you yearn for a "usual" array where indices are numbers :-)
Here's the trick: that's what a list is. ;)
(OK, there's also BLT vector for certain kinds of uses, and that is
numerically indexed and works on arrays. I've also got a
still-half-baked plan to do something more general in the way of
pluggable array implementations, but I'm a bit too busy to finish the
idea off at the moment.)
Donal.
Krzysztof Hrebeniuk
>> of TCL, I think. And it is worth of it eventually. But in many
>> situations you yearn for a "usual" array where indices are numbers
>> :-)
>
>
> Here's the trick: that's what a list is. ;)
Ha, ha... ;-). Not quite as you know. For example you want to collect
some measurements data in a structure where the measurement date is
bound up with the measurement value. The most natural solution would be
an array where indices are dates (in seconds from the beginning of the
day or year) and elements are measurement values. You can't use a one
simple list instead of the array here. The solution in this case would be:
- the list of the two elements lists {date value}
- a keyed list with TclX extension used
- the two independent lists with dates and values with the same indices
Once I found the third solution the most comfortable, but I wish to be
able to use the array here. It was not possible because of the sizes of
the arrays (about 100000 elements each).
> (OK, there's also BLT vector for certain kinds of uses, and that is
> numerically indexed and works on arrays.
Yes, once I tried to use it. It works fast on linux but for some unknown
reason is very slow on SCO OpenServer where I needed it (apart this BLT
works quickly on SCO).
Cameron Laird
Krzysztof Hrebeniuk <K.Hre...@opole.pios.gov.pl> wrote:
.
.
.
>You are right of course. It's the price we pay for the ease of use of
>TCL, I think. And it is worth of it eventually. But in many situations
>you yearn for a "usual" array where indices are numbers :-)
.
.
Do you realize that Tcl's lists have much the same semantics
as the arrays of Fortran and C?
Donald Arseneau
> >> situations you yearn for a "usual" array where indices are numbers
> > Here's the trick: that's what a list is. ;)
>
> Ha, ha... ;-). Not quite as you know.
I disagree. The list *is* just like a traditional "usual" array.
> For example you want to collect some
> measurements data in a structure where the measurement date is bound up with
> the measurement value. The most natural solution would be an array where
> indices are dates (in seconds from the beginning of the day or year)
Is that the most natural? An array like that probably has
mostly empty elements, just like a list would. Unless you are
talking about a Tcl "array", which is not the "usual" type of
array found in most computer languages.
> to use the array here. It was not possible because of the sizes of the arrays
> (about 100000 elements each).
So was there an increased overhead that allowed you to use two 100000 element
lists but not one 100000 element array?
If so, maybe the equivalent dict takes up less resources?
--
Donald Arseneau as...@triumf.ca
Krzysztof Hrebeniuk
Yes? How do you create 2 element list where the first element has index
equal 500 and the second one 1000?
> Is that the most natural? An array like that probably has
> mostly empty elements, just like a list would. Unless you are
> talking about a Tcl "array", which is not the "usual" type of
> array found in most computer languages.
Yes, I'm talking about a Tcl array.
> So was there an increased overhead that allowed you to use two 100000 element
> lists but not one 100000 element array?
Yes, there was such a case. Please look here:
for details on subject "Tcl and large arrays"
Donald Arseneau
> > I disagree. The list *is* just like a traditional "usual" array.
>
> Yes? How do you create 2 element list where the first element has index equal
> 500 and the second one 1000?
You can't. That's exactly my point! In a traditional array -- not the
hash "array" of Tcl -- you can't do that either. But it is the ability
to do this with hashes that forces the deficiencies, like the senselessness
of "sort an array in TCL".
I would welcome some array-like syntax for list access, performing
the actions of lset and lindex.
> Yes, I'm talking about a Tcl array.
Maybe now, but you yearned for a "usual" array where indices are numbers,
which is where I replied.
> http://www.google.pl/groups?hl=pl&lr=&frame=right&th=3e643d423a945192&seekm=3AC47B4D.E432A111%40opole.pios.gov.pl#link1
>
> for details on subject "Tcl and large arrays"
Interesting. That thread ended saying it would be better with Tcl 8.4.
I take it the excess memory allocation is still bad? I find it strange
that generic memory allocation performs differently for lists and
arrays.
--
Donald Arseneau as...@triumf.ca