I wrote the program that process graphs where each node is represented as record containing two lists of other nodes. It seems there is some problem with that concept. Here is the code that causes problem:

###############################
record double_list(sublist,superlist)
procedure main()

  first_double_list:=double_list()
  first_double_list.sublist:=[]
  first_double_list.superlist:=[]
  List_of_lists:=[first_double_list]
  j:=0
  repeat
    { j:=j+1
      new_double_list:=double_list()
      new_double_list.sublist:=[]
      new_double_list.superlist:=[]

      every 1 to 2 do # every 1 to 1
        {  random_old_double_list:=?List_of_lists #
           put(new_double_list.sublist, random_old_double_list)
           put(random_old_double_list.superlist, new_double_list)
        }
      put(List_of_lists,new_double_list)

      if j/1000*1000=j then write ("First ",j," are OK.")
   }
end
#######################################################

Compile and executed (on 9.3.2 version of Icon for Windows or on Unicon for Windows - I think it is last version) it allocates ~37 000 nodes (records double_list) and then suddenly crushes. Although 37 000 might look good enough, it really isn't:

with very simple changes, for example, 'every 1 to 1' instead "every 1 to 2" or deleting line "put(random_old_double...", program will happily allocate 566 000 objects (in both cases), and even then, it will not crush but hang attempting to write something on the disk, as typical for Windows. Anycase, that is satisfactory. Note that in both cases, circular references still exist, and even if "every 1 to 100" is used in combination with single list, program still allocates 100 000+ records before it hangs.

Problem increases if such double lists records contain some additional fields that make records bigger. In context where I noticed that problem, program was able to allocate only ~4000 records, and then crushed, while with analogous changes, it still happily allocated 200 000+ records (and perhaps more if I decided to wait).

There is relatively simple practical way I can work around that problem - I can use only one list in each node, and understand elements with index 2n as elements of "superlist", and elements with index 2n+1 as elements of "sublist." But it is - I think you'll agree - ugly practical solution, and fact that solution is so simple suggests that problem could be easily fixed on language implementation level.

Any comments? Did anyone already solved that problem on prettier way? Does it happen on other systems beside Windows?

Thank you,


--------------
Kazimir Majorinc, Zagreb, Croatia




-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
_______________________________________________
Unicon-group mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/unicon-group

Reply via email to