Sorry for the many posts from my side, but: After reading, and re-reading, though, I don’t quite understand. How could hyperedges touch at most one element of each base set? I obviously have a wrong picture of what is being referred to by the term “base sets”. I thought they correspond to sequences of digits without any 0s. And the way I understand the system, as soon as those numbers are given, the set of possible hyperedges is fixed. So what is meant by “new hyperedges” then?
I feel I am the one being obtuse. Could you elaborate on how this translates to sets of lines in the CREDO example? Am 10.01.21 um 07:46 schrieb Justin Paston-Cooper: > Error: Base sets of nodes, and not base hyperedges. Each hyperedge touches > at most one element of each base set. > > On Sun, 10 Jan 2021 at 09:35, Justin Paston-Cooper <[email protected]> > wrote: > >> Can we summarise all of this as: >> >> A representation of hypergraphs ordered in a certain way, with nodes >> represented by numbers, and tuples of numbers for representing the >> hyperedges. Node values are ordered sets of strings. >> >> There is a number of base hyperedges (columns), whose disjoint union gives >> the set of starting nodes. Over the nodes in each base hyperedge is defined >> an ordering. There is an ordering defined between the base hyperedges also. >> This gives an ordering over all base nodes. >> >> Define new values for possibly new hyperedges at will by taking unions of >> subsets from each base hyperedge, and adding a node to the ordered set >> corresponding to this hyperedge if it exists, or creating a new one if it >> doesn’t. >> >> The orders of these hyperedges and the nodes within are defined using the >> orders of the constituent base hyperedges, and the orders of the ordered >> sets of the new added nodes. >> >> Queries are hypergraph traversals. >> >> Sorry if I’m being obtuse again. >> >> On Sat, 9 Jan 2021 at 23:11, 'Bo Jacoby' via Programming < >> [email protected]> wrote: >> >>> Justin wrote: "Quite an interesting paper. What were the reasons for its >>> rejection?" >>> Thank you! The referee wrote that he did not consider me serious. He >>> thought I was joking. >>> I wrote an article to en.wikipedia.org, but as original research is not >>> allowed on wikipedia the article was deleted. However in the >>> meantime someone copied it to StateMaster.com Encyclopedia, but by now it >>> is not to be found. Most of my research turns out not to be original >>> research, but the theory of ordinal fractions seems to be original >>> research. >>> The CREDO example was published in Danish in the NordDATA 89 conference >>> procedings, volume 3, page 779-785. About one out of thousand read Danish. >>> The example is in Latin. About one out of thousand read Latin. The program >>> is in BASIC. About one out of thousand read BASIC. So about one out of a >>> billion can read the paper. I think I do know the other 6. The title is >>> 'ULTRA-FLEKSIBEL DATABASESTRUKTUR OG KUNSTIG KATOLICISME' meaning: ultra >>> flexible data base structure and artificial catholicism. >>> Hauke is suggesting improvements. I have worked with ordinal fractions >>> for forty years. Understand before improving. >>> The ordinal fraction data base may be a tree, or a wood, or an array, or >>> a relational data base, or any combination of these. Knowing ordinal >>> fractions you do no longer need trees, woods, arrays, or relational data >>> bases. The CREDO example is neither a tree, a wood, an array, nor a >>> relational data base. >>> The CREDO file is not sorted. ' AMEN' is the last word, even if it has >>> line number 0 because is is included in every prayer. In a sorted file AMEN >>> would come first. >>> J programs are compact. I love it! So I expect that 8 lines of BASIC can >>> be converted into an even shorter J program. >>> Thank you all ! >>> Bo >>> >>> >>> Den lørdag den 9. januar 2021 18.49.14 CET skrev Justin Paston-Cooper >>> <[email protected]>: >>> >>> On Sat, 9 Jan 2021 at 15:59, Hauke Rehr <[email protected]> wrote: >>>> >>>> My two comments (or, my 2¢): >>>> >>>> >>>> concerning the aleph numbers >>>> >>>> is this related to my concern about dependence on order? >>>> I understand the fractional digits to be meant to encode >>>> both (semantic) structure and order >>>> (or else the prayer wouldn’t be the best kind of example). >>> >>> Yes I think so. >>> >>>> >>>> After all, that’s why they’re doing ‘more’ than their >>>> relational counterparts where all columns are considered >>>> independent of each other and applicable to all of the data. >>>> >>>> >>>> concerning people’s workflows >>>> >>>> now that’s why I had been talking about the LEO editor >>>> because the discussion had been originated by a question >>>> about structuring one’s research; and I wanted to offer >>>> concrete suggestions as to how to actually get to using >>>> a system like this without the need of setting up a kind >>>> of database first. >>> >>> I didn't have time to look into it the first time, but Leo looks >>> really interesting for the document management part. It got me >>> thinking about Xanadu: https://xanadu.com/xUniverse-D6. Thank you. >>> >>>> >>>> The ordinal fractions could then be implicit in the tree >>>> structure of the nodes (you only have to have a convention >>>> for which node will be considered the 0 (aka ANY) node; >>>> and maybe another one on if/how an empty node is to be >>>> represented). >>>> >>>> The query script could then ask for digits and after each >>>> one give the list of subordinate valid digits and their >>>> meanings (semantics will be documented at each level); >>>> this will get a bit more complicated with queries with >>>> early 0s but then again, they should make sense mostly >>>> when the semantic structure at subordinate levels agrees >>>> which could result in a merge of the respective display >>>> of subordinate digits’ meanings. >>>> >>>> but this would require the fractions to be used >>>> the way I first understood it: the data is to be stored >>>> in “leaf” nodes only. I guess this would be the easiest >>>> and most easily manageable – also in terms of maintenance – >>>> approach. >>>> >>>> >>>> Hauke >>>> >>>> >>>> >>>> Am 09.01.21 um 07:50 schrieb Justin Paston-Cooper: >>>>> On Sat, 9 Jan 2021 at 00:13, 'Bo Jacoby' via Programming < >>>>> [email protected]> wrote: >>>>> >>>>>> Answering Justin's questions. >>>>>> 01 question >>>>>> 02 answer >>>>>> 11. The data in your solution seems to be similar to the data in >>>>>> relational databases, but the query space seems to be the same. >>>>>> Cyclic relations seem to be ruled out, but this maybe isn't a >>> problem. Am >>>>>> I wrong, and is either stronger than the other? >>>>>> >>>>>> 12. The relations between two ordinal fractions are: equality (a=b), >>>>>> subordination (a<b), superordination (a>b), compatibility (a<>b) and >>>>>> incompatility (a><b). You are right, no cyclic relation. The browser >>> omits >>>>>> the records incompatible with the query ordinal fraction from the >>> answer. >>>>>> (in another browser I painted an answer (a) to a query (b) white if >>> a=b, >>>>>> green if a<b, red if a>b, yellow if a<>b, and invisible if a><b.) >>>>>> 21. Is it possible to provide a well-performing ordinal fraction >>>>>> interface to multiple separate files (hopefully memory mapped) in >>>>>> an intuitive way in J? For instance, if we are looking at a subset of >>>>>> columns which does not intersect with the set of columns of a given >>> table, >>>>>> then we would like to skip reading the rows in that table seamlessly. >>>>> >>>>> >>>>>> >>>>>> 22. Two files are merged into one by prefixing the line numbers of >>> the >>>>>> first file by "1" and the line numbers of the second file by "2". The >>>>>> resulting merged file is then another ordinal fraction file to >>> replace the >>>>>> original two files. Well-performing means fast. If the data base is >>> big it >>>>>> is conveniently stored as an indexed sorted file and the browser is >>> made to >>>>>> skip lines before a possible match. >>>>> >>>>> >>>>> See aleph numbers comment below. >>>>> >>>>> >>>>>> 31. I am not fully convinced that this is easier to manage than a >>>>>> relational database. >>>>>> >>>>>> 32. How to fit the credo text into a relational data base? I don't >>> think >>>>>> it is at all feasible. >>>>> >>>>> >>>>> You are right. I spoke too early. >>>>> >>>>> >>>>>> 41. If we did need to define explicit tables (sets of columns), then >>>>>> this could happen in a separate schema table. What are your thoughts? >>>>>> >>>>>> 42. No, there is no need for a separate schema table. A table (like >>> this >>>>>> one) with rows 10 20 30 40 50 60 and columns 01 02 has elements 11 >>> 12 13 14 >>>>>> 15 16 21 22 23 24 25 26. There is but one file containing everything. >>>>> >>>>> >>>>> Yes this makes sense. I was worrying more about associating tables >>> names >>>>> and column names to digits, but this doesn’t seem to be such an issue. >>>>> >>>>> >>>>>> 51. This doesn't fully solve the issue of coordinating the updating >>> of all >>>>>> resources and the dependencies between them for updating. I guess >>> Make >>>>>> would help. >>>>> >>>>> >>>>>> 52. What is the problem? >>>>> >>>>> >>>>> I am trying to figure out what people’s workflows are. Anyway, maybe >>> not >>>>> the best topic for the programming forum. >>>>> >>>>> >>>>>> >>>>>> 61. I wonder how Jd could contribute. >>>>>> 62. So do I! >>>>>> Thank you very much! >>>>>> I will comment on Hauke's contribution tomorrow. Now only this: I am >>> very >>>>>> impressed. Hauke's is the most qualified response I have ever >>> received. >>>>>> Note that a line number in the data base may be extended by zeroes. >>> " AMEN" >>>>>> = "0000000 AMEN". So "AMEN" is unavoidable in the answer to any >>> query. >>>>>> Thank you everyone! >>>>>> Bo. >>>>> >>>>> >>>>> I think AMEN and ET should be assigned to Aleph 1 the appropriate >>>>> positions. BASIC should also incorporate this. This allows seamless >>> updates >>>>> of sub-tables. If one aleph bigger than next after update of >>> sub-table, >>>>> simply increment next. >>>>> >>>>> >>>>>> Den fredag den 8. januar 2021 10.36.26 CET skrev Justin >>> Paston-Cooper < >>>>>> [email protected]>: >>>>>> >>>>>> Quite an interesting paper. What were the reasons for its rejection? >>>>>> >>>>>> The mathematics is quite simple and well defined, however it doesn't >>>>>> go too much into the application aspect. >>>>>> >>>>>> I don't have the time to actually explore this in depth right now, >>> but: >>>>>> >>>>>> 1. The data in your solution seems to be similar to the data in >>>>>> relational databases, but the query space seems to be the same. >>> Cyclic >>>>>> relations seem to be ruled out, but this maybe isn't a problem. Am I >>>>>> wrong, and is either stronger than the other? >>>>>> >>>>>> 2. Is it possible to provide a well-performing ordinal fraction >>>>>> interface to multiple separate files (hopefully memory mapped) in an >>>>>> intuitive way in J? For instance, if we are looking at a subset of >>>>>> columns which does not intersect with the set of columns of a given >>>>>> table, then we would like to skip reading the rows in that table >>>>>> seamlessly. >>>>>> >>>>>> 3. I am not fully convinced that this is easier to manage than a >>>>>> relational database. >>>>>> >>>>>> 4. If we did need to define explicit tables (sets of columns), then >>>>>> this could happen in a separate schema table. What are your thoughts? >>>>>> >>>>>> 5. This doesn't fully solve the issue of coordinating the updating of >>>>>> all resources and the dependencies between them for updating. I guess >>>>>> Make would help. >>>>>> >>>>>> 6. I wonder how Jd could contribute. >>>>>> >>>>>> On Fri, 8 Jan 2021 at 00:08, 'Bo Jacoby' via Programming >>>>>> <[email protected]> wrote: >>>>>>> >>>>>>> "I am looking for a way to better organise my research. If not >>>>>>> spreadsheets, do you have some advice on how to coordinate all this >>>>>>> separate data in one place?" >>>>>>> I have used ordinal fractions for structuring data since 1980. >>> ORDINAL >>>>>> FRACTIONS - the algebra of data >>>>>>> >>>>>>> | >>>>>>> | >>>>>>> | >>>>>>> | | | >>>>>>> >>>>>>> | >>>>>>> >>>>>>> | >>>>>>> | >>>>>>> | | >>>>>>> ORDINAL FRACTIONS - the algebra of data >>>>>>> >>>>>>> This paper was submitted to the 10th World Computer Congress, IFIP >>> 1986 >>>>>> conference, but rejected by the referee.... >>>>>>> | >>>>>>> >>>>>>> | >>>>>>> >>>>>>> | >>>>>>> >>>>>>> >>>>>>> >>>>>>> I wrote software for processing this kind of data in fortran, >>> BASIC, and >>>>>> pascal, but not (yet) in J. >>>>>>> A BASIC program for browsing the data base is this. >>>>>>> 1 INPUT;C$: IF C$="" THEN END >>>>>>> 2 OPEN"CREDO" FOR INPUT AS 1: PRINT":"; >>>>>>> 3 IF EOF(1) THEN CLOSE:PRINT:GOTO 1 >>>>>>> 4 LINE INPUT#1,A$: B$=C$ >>>>>>> 5 IF A$=""THEN A%=-1 ELSE A%=ASC(A$)-48:A$=MID$(A$,2) >>>>>>> 6 IF B$=""THEN B%=-1 ELSE B%=ASC(B$)-48:B$=MID$(B$,2) >>>>>>> 7 IF A%<0 THEN PRINT" ";A$;:GOTO 3 >>>>>>> 8 IF A%=0 OR B%=0 OR A%=B% THEN 5 ELSE 3 >>>>>>> >>>>>>> The test data base for illustrating the possibilities is this. >>>>>>> 1 CREDO >>>>>>> 11 IN >>>>>>> 111 UNUM >>>>>>> 11 DEUM >>>>>>> 112 PATREM >>>>>>> 1121 OMNIPOTENTEM >>>>>>> 113 FACTOREM >>>>>>> 1131 CÆLI >>>>>>> 1139 ET >>>>>>> 1132 TERRÆ >>>>>>> 11331 VISIBILIUM >>>>>>> 1133 OMNIUM >>>>>>> 11339 ET >>>>>>> 11332 INVISIBILIUM >>>>>>> 19 ET >>>>>>> 12 IN >>>>>>> 1211 UNUM >>>>>>> 1211 DOMINUM >>>>>>> 12 JESUM >>>>>>> 1211 CHRISTUM >>>>>>> 1212 FILIUM >>>>>>> 1212 DEI >>>>>>> 12121 UNIGENITUM >>>>>>> 1219 ET >>>>>>> 1213 EX >>>>>>> 1213 PATRE >>>>>>> 1213 NATUM >>>>>>> 12131 ANTE >>>>>>> 121311 OMNIA >>>>>>> 12131 SÆCULA >>>>>>> 1221 DEUM >>>>>>> 12211 DE >>>>>>> 12211 DEO >>>>>>> 1222 LUMEN >>>>>>> 12221 DE >>>>>>> 12221 LUMINE >>>>>>> 1223 DEUM >>>>>>> 12231 VERUM >>>>>>> 12232 DE >>>>>>> 12232 DEO >>>>>>> 122321 VERO >>>>>>> 1231 GENITUM >>>>>>> 12311 NON >>>>>>> 12311 FACTUM >>>>>>> 1232 CONSUBSTANTIALEM >>>>>>> 1232 PATRI >>>>>>> 12321 PER >>>>>>> 12321 QUEM >>>>>>> 12321 OMNIA >>>>>>> 12321 FACTA >>>>>>> 12321 SUNT >>>>>>> 124 QUI >>>>>>> 124101 PROPTER >>>>>>> 124101 NOS >>>>>>> 12410101 HOMINES >>>>>>> 124109 ET >>>>>>> 124102 PROPTER >>>>>>> 12410201 NOSTRAM >>>>>>> 124102 SALUTEM >>>>>>> 12411 DESCENDIT >>>>>>> 1241101 DE >>>>>>> 1241101 CÆLIS >>>>>>> 12419 ET >>>>>>> 12412 INCARNATUS EST >>>>>>> 1241201 DE >>>>>>> 1241201 SPIRITU 124120101 SANCTO >>>>>>> 1241202 EX >>>>>>> 1241202 MARIA >>>>>>> 124120201 VIRGINE >>>>>>> 12419 ET >>>>>>> 1241301 HOMO >>>>>>> 12413 FACTUS EST >>>>>>> 124211 CRUCIFIXUS >>>>>>> 1242101 ETIAM >>>>>>> 1242101 PRO >>>>>>> 1242101 NOBIS >>>>>>> 1242102 SUB >>>>>>> 1242102 PONTIO >>>>>>> 1242102 PILATO >>>>>>> 124212 PASSUS >>>>>>> 124219 ET >>>>>>> 124213 SEPULTUS >>>>>>> 12421 EST >>>>>>> 12429 ET >>>>>>> 12422 RESURREXIT >>>>>>> 124221 TERTIA >>>>>>> 124221 DIE >>>>>>> 124222 SECUMDUM >>>>>>> 124222 SCRIPTURAS >>>>>>> 12429 ET >>>>>>> 12423 ASCENDIT >>>>>>> 124231 IN >>>>>>> 124231 CÆLUM >>>>>>> 12424 SEDET >>>>>>> 124241 AD >>>>>>> 124241 DEXTERAM >>>>>>> 124241 PATRIS >>>>>>> 12429 ET >>>>>>> 124251 ITERUM >>>>>>> 12425 VENTURUS EST >>>>>>> 124252 CUM >>>>>>> 124252 GLORIA >>>>>>> 124253 JUDICARE >>>>>>> 1242531 VIVOS >>>>>>> 1242539 ET >>>>>>> 1242532 MORTUOS >>>>>>> 125 CUJUS >>>>>>> 125 REGNI >>>>>>> 125 NON ERIT >>>>>>> 125 FINIS >>>>>>> 19 ET >>>>>>> 13 IN >>>>>>> 13 SPIRITUM >>>>>>> 131 SANCTUM >>>>>>> 132 DOMINUM >>>>>>> 139 ET >>>>>>> 133 VIVIFICANTEM >>>>>>> 134 QUI >>>>>>> 134 EX >>>>>>> 1341 PATRE >>>>>>> 1342 FILIO >>>>>>> 1349 QUE >>>>>>> 134 PROCEDIT >>>>>>> 135 QUI >>>>>>> 135 CUM >>>>>>> 13501 PATRE >>>>>>> 13509 ET >>>>>>> 13502 FILIO >>>>>>> 13509 SIMUL >>>>>>> 1351 ADORATUR >>>>>>> 1359 ET >>>>>>> 1352 GLORIFICATUR >>>>>>> 136 QUI >>>>>>> 136 LOCUTUS EST >>>>>>> 1361 PER >>>>>>> 1361 PROPHETAS >>>>>>> 19 ET >>>>>>> 141 UNAM >>>>>>> 142 SANCTAM >>>>>>> 143 CATHOLICAM >>>>>>> 149 ET >>>>>>> 144 APOSTOLICAM >>>>>>> 14 ECCLESIAM >>>>>>> 2 CONFITEOR >>>>>>> 211 UNUM >>>>>>> 21 BAPTISMA >>>>>>> 212 IN >>>>>>> 212 REMISSIONEM >>>>>>> 2121 PECCATORUM >>>>>>> 9 ET >>>>>>> 3 EXPECTO >>>>>>> 31 RESURRECTIONEM >>>>>>> 311 MORTUORUM >>>>>>> 39 ET >>>>>>> 32 VITAM >>>>>>> 3211 VENTURI >>>>>>> 321 SÆCULI >>>>>>> AMEN >>>>>>> >>>>>>> Some test runs of the program look like this. >>>>>>> 13510: CREDO IN SPIRITUM QUI CUM PATRE ET FILIO SIMUL ADORATUR AMEN >>>>>>> 13520: CREDO IN SPIRITUM QUI CUM PATRE ET FILIO SIMUL GLORIFICATUR >>> AMEN >>>>>>> 13501: CREDO IN SPIRITUM QUI CUM PATRE ADORATUR ET GLORIFICATUR AMEN >>>>>>> 13502: CREDO IN SPIRITUM QUI CUM FILIO ADORATUR ET GLORIFICATUR AMEN >>>>>>> 13511: CREDO IN SPIRITUM QUI CUM PATRE ADORATUR AMEN >>>>>>> 13512: CREDO IN SPIRITUM QUI CUM FILIO ADORATUR AMEN >>>>>>> 13521: CREDO IN SPIRITUM QUI CUM PATRE GLORIFICATUR AMEN >>>>>>> 13522: CREDO IN SPIRITUM QUI CUM FILIO GLORIFICATUR AMEN >>>>>>> >>>>>>> I realize that this is not easy to understand, but I know that it is >>>>>> worth while. >>>>>>> Good luck! >>>>>>> Bo. Den torsdag den 7. januar 2021 21.35.12 CET skrev Justin >>>>>> Paston-Cooper <[email protected]>: >>>>>>> >>>>>>> Thanks. I have been meaning to look at that. >>>>>>> >>>>>>> On Thu, 7 Jan 2021 at 23:33, Joe Bogner <[email protected]> >>> wrote: >>>>>>>> >>>>>>>> Jupyter notebooks may help you with organizing your research - >>>>>>>> https://code.jsoftware.com/wiki/Guides/Jupyter >>>>>>>> >>>>>>>> This has been my preferred tool - far above Excel. >>>>>>>> >>>>>>>> On Thu, Jan 7, 2021 at 2:39 PM Justin Paston-Cooper < >>>>>> [email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> I am open to suggestions. Right now I'm researching a lot of >>> related >>>>>>>>> things concurrently. I'm storing some of the results in TSV files. >>>>>>>>> Some of the scripts are Python, some are curl | jq | awk. Some of >>> the >>>>>>>>> results I am storing as variables in J scripts. I am constantly >>> going >>>>>>>>> back and forth between differing representations, differing >>>>>>>>> environments, recalculating things needlessly, and so on. >>>>>>>>> >>>>>>>>> I am looking for a way to better organise my research. If not >>>>>>>>> spreadsheets, do you have some advice on how to coordinate all >>> this >>>>>>>>> separate data in one place? A Make file could be a start, but this >>>>>>>>> doesn't satisfy the requirement of having a nice editable GUI to >>>>>>>>> arrange and display all the separate sources of data. Maybe wd >>> would >>>>>>>>> be a start in that direction. I haven't researched the >>> alternatives. >>>>>>>>> >>>>>>>>> How do you organise your research? >>>>>>>>> >>>>>>>>> Application: Researching interactions between prices of a set of >>>>>>>>> things in each of a set of places. There are many different >>> analyses >>>>>>>>> that can be made. I am finding it hard to keep track of all the >>>>>> angles >>>>>>>>> I have looked at. These angles all reside in separate directories, >>>>>>>>> which is not ideal. I have hand-written notes, but those need to >>> be >>>>>>>>> updated by hand. >>>>>>>>> >>>>>>>>> By the way, I wasn't envisioning doing any calculation in the >>>>>>>>> spreadsheet. The idea of the spreadsheet was simply to coordinate >>>>>>>>> communication and (re)calculation between various calculation >>>>>>>>> processes, display the results, and allow the display of the >>> results >>>>>>>>> to be edited. >>>>>>>>> >>>>>>>>> Imagine an actor system with the spreadsheet being the >>> coordinator. >>>>>>>>> >>>>>>>>> On Thu, 7 Jan 2021 at 20:23, Devon McCormick <[email protected]> >>>>>> wrote: >>>>>>>>>> >>>>>>>>>> It would be remiss of me not to mention that you really ought to >>>>>>>>>> re-consider making a spreadsheet an integral part of your design, >>>>>> not the >>>>>>>>>> least due to the historically high rates of error that have been >>>>>> measured >>>>>>>>>> in spreadsheets - 1 to 5%: >>>>>>>>>> https://arxiv.org/ftp/arxiv/papers/1602/1602.02601.pdf . It >>> seems >>>>>>>>>> incongruous to worry about the sixth decimal place in numbers >>> with >>>>>> many >>>>>>>>>> digits before the decimal point but ignoring error rates that >>>>>> dwarf this >>>>>>>>>> imprecision. >>>>>>>>>> >>>>>>>>>> By way of comparison, in most code-bases where people measure >>>>>> errors, an >>>>>>>>>> error rate of 10 bad lines per 1000 lines of code would be >>>>>> considered >>>>>>>>>> unacceptably high. >>>>>>>>>> >>>>>> >>> ---------------------------------------------------------------------- >>>>>>>>>> For information about J forums see >>>>>> http://www.jsoftware.com/forums.htm >>>>>>>>> >>>>>> >>> ---------------------------------------------------------------------- >>>>>>>>> For information about J forums see >>>>>> http://www.jsoftware.com/forums.htm >>>>>>>>> >>>>>>>> >>> ---------------------------------------------------------------------- >>>>>>>> For information about J forums see >>> http://www.jsoftware.com/forums.htm >>>>>>> >>> ---------------------------------------------------------------------- >>>>>>> For information about J forums see >>> http://www.jsoftware.com/forums.htm >>>>>>> >>>>>>> >>> ---------------------------------------------------------------------- >>>>>>> For information about J forums see >>> http://www.jsoftware.com/forums.htm >>>>>> >>> ---------------------------------------------------------------------- >>>>>> For information about J forums see >>> http://www.jsoftware.com/forums.htm >>>>>> >>>>>> >>> ---------------------------------------------------------------------- >>>>>> For information about J forums see >>> http://www.jsoftware.com/forums.htm >>>>>> >>>>> ---------------------------------------------------------------------- >>>>> For information about J forums see >>> http://www.jsoftware.com/forums.htm >>>>> >>>> >>>> -- >>>> ---------------------- >>>> mail written using NEO >>>> neo-layout.org >>>> >>>> ---------------------------------------------------------------------- >>>> For information about J forums see http://www.jsoftware.com/forums.htm >>> ---------------------------------------------------------------------- >>> For information about J forums see http://www.jsoftware.com/forums.htm >>> >>> ---------------------------------------------------------------------- >>> For information about J forums see http://www.jsoftware.com/forums.htm >>> >> > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > -- ---------------------- mail written using NEO neo-layout.org ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
