World: r3wp

bah... not so painfull

it's a little incoherent to use sort on lists

it was slower than using blocks

there is someone using list!? I wonder if there is any advantage 
of list! over hash! and block!

No lists are faster than blocks for inserting data.

lists are fast with insertion and deletion, i use them sometimes

Oldes, yes there is an advantage to each.  Lists are faster for inserting 
and traversal.  Hash is faster for find operations.

by the way, some times ago, i made an algorhitm to simulate hash 
with blocks, it's quite fast and use much less memory than hash.

But it works only with integers key. i could search for it if someone 
is interested...

>> b: make list! 10001 tm 100 [clear head b repeat i 10000 [b: insert 
b i]]
0:00:00.25
== 0:00:00.25

>> b: make block! 10001 tm 100 [clear head b repeat i 10000 [b: insert 
b i]]
0:00:00.25
== 0:00:00.25

Oldes, you do appends not insertion

Anyway.. list! and hash! are no longer in R3

I see.. interesting.

>> b: make list! 10001 tm 100 [clear head b repeat i 10000 [insert 
b i]]
0:00:00.203
== 0:00:00.203

>> b: make block! 10001 tm 100 [clear head b repeat i 10000 [insert 
b i]]
0:00:13.031
== 0:00:13.031

I don't know much about vector or map but I hope that we haven't 
loss the functionality of list and hash in R3.

Or at least have something better.

I used list! once in list-view, but found that it had too much overhead, 
when needing to use it as a block, so it had to be converted.

Yeah that is what made list less desirable for me as well  Henrik.

Should to-block work on vector!?

I think so.

>> c: make vector! [32 100]
== vector!

>> c/1
== 0

>> c/1: 100000
== 100000

>> c/2: 200000
== 200000

>> c/1
== 100000

>> c/2
== 200000

>> to-block c
== [vector!]

the last piece seems abnormal to me.

I don't think is't ready already. Also map! still has some issues.

Map! has issues for now (see CureCode), and the traversal thing is 
being worked on. Vector! is almost completely nonfunctional now.

There are plans to extend FOREACH to map! and object!, and MAP could 
make sense too I suppose, but no plans for that. What did you use 
hash! for that wasn't keyed search, Doc, and what advantages did 
it give you over block! aside from a different datatype?

Also, don't forget user-defined datatypes. We are only including 
the most useful datatypes by default - you will be able to add your 
own later once we have user-defined datatypes.

Multiple keys pointing on the same data (I'm using traversal to locate 
the value once the key is found). I guess that using map!, it would 
require to duplicate the value for each key?

No, just duplicate *references* to the same value.

Paul if I understand documentation Vector must be one type (homogenous) 
ie good for file pointer, bad for records (multiple type)

It only becomes duplicate values if the value is not a reference 
type (numbers, characters, etc.).

Brian: Good to know.

Pavel, yes, the homogenous type is the only main difference relative 
to blocks. Only use vectors if you need that, else use blocks.

So, if I understand correctly, map! offers a superset of hash! features 
(without giving up anything)?

Not bad if the performance would be good (especially for quite large 
pointer table to database file), save in size was already mentioned

You give up position and persistent ordering, and in theory you also 
give up duplicate keys though there is a bug ticket about that.

You also have to conform to the key/value pattern. Map! is more comparable 
to object! nowadays.

Doc question arise when large insert into large table comes, in hash 
inserting is the slower the bigger is table (maybe even nonlinear)

It can be key/[block of values] though.

We are extending support of many of the functions that people traditionally 
associated with series to objects and maps, without making them into 
series. So that means that APPEND works, but INSERT doesn't because 
of the position stuff.

For Map also limit about 500000 items was mentioned, it suggest an 
idea use Map in pagged manner. Ie for larger set use multiple Maps 
rather fixed size in the manner of cache.

Pavel: is map! any better in that case?

I have no exact comparison all mentioned is only ideas

SELECT works on object! and map! but FIND doesn't. PICK and POKE 
work, but they take keys rather than indexes. There are some (at 
this point undocumented) limits on what can be used as keys too (at 
least you can't use a block as a key in practice), but that may be 
a bug.

Lot of new exceptions to remember...

Brian Block as key would be good for reversed index IMO. Question 
if it would be usefull.

Well, in some cases to fix, but yes, lots of exceptions. The guideline 
is that maps and objects don't have position, but series do. So the 
position-dependent functions don't work but their non-position-dependent 
counterparts do. Ports don't work like series either, so there is 
another whole set of differences to remember.

Good point Pavel, how does map! handle the key/key case? (being able 
to exchange the role of key<=>value). Would it require to use two 
map! to being able to do fast lookups in both cases? So n-tuple stored 
=> n map! value to hash everything?

Pavel, the problem is that we can't hash complex structures (for 
now) so there is no advantage to using them as keys. I want a keys-of 
function though that returns a block of the keys that reference a 
value (by same? semantics for the value, perhaps).

The words-of function already returns *all* of the keys of a map!, 
just like it does for objects.

I dont want to use keys in this way (difficult keys) the opposite 
is true, keys should be simplest possible.

Well then you have no problem then :)

Doc I think so