Now this is beginning to make much more sense to me.
Regarding base sets, I /meant/ what you wrote, only
confused terminology of significant and significate.
I now understand your first E, but I think the second
one is not an improvement. <FACTOREM> is not subordinate
to <UNUM>. And I think subordination/containment is key
to the whole structure, so
I would rather have edges represent subordination
E = <<<<CREDO>>, <<IN, DEUM>>>,
<<<IN, DEUM>>, <<UNUM>, <PATREM>, <FACTOREM>>>,
<<PATREM>, <<OMNIPOTENTEM>>>>
The transitive closure I’d defer to the graph walking
algorithm rather than having the edge set explode.
Does this make sense?
Am 10.01.21 um 10:17 schrieb Justin Paston-Cooper:
> To be honest, I don't know why you shouldn't be able to make edges
> over more than one vertex of a given base set. The base sets should
> also be hyperedges. For the values corresponding to an edge, take the
> cartesian product over the corresponding subsets of base edges using
> the order defined.
>
> E = <<<CREDO>, <IN, DEUM>>,
> <<CREDO>, <IN, DEUM>, <UNUM>>,
> <<CREDO>, <IN, DEUM>, <PATREM>>,
> <<CREDO>, <IN, DEUM>, <PATREM>, <ONMIPOTENTEM>>,
> <<CREDO>, <IN, DEUM>, <FACTOREM>>>
>
> becomes
>
> E = <<<CREDO>, <IN, DEUM>>,
> <<CREDO>, <IN, DEUM>, <UNUM>, <FACTOREM>>,
> <<CREDO>, <IN, DEUM>, <PATREM>>,
> <<CREDO>, <IN, DEUM>, <PATREM>, <ONMIPOTENTEM>>>
>
> <FACTOREM> now lives with <UNUM>, which both live in the same base
> set. Therefore an hyperedge may be defined as a union of subsets of
> base sets.
>
> On Sun, 10 Jan 2021 at 11:14, Hauke Rehr <hauke.r...@uni-jena.de> wrote:
>>
>> 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 <paston.coo...@gmail.com>
>>> 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 <
>>>> programm...@jsoftware.com> 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
>>>>> <paston.coo...@gmail.com>:
>>>>>
>>>>> On Sat, 9 Jan 2021 at 15:59, Hauke Rehr <hauke.r...@uni-jena.de> 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 <
>>>>>>> programm...@jsoftware.com> 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 <
>>>>>>>> paston.coo...@gmail.com>:
>>>>>>>>
>>>>>>>> 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
>>>>>>>> <programm...@jsoftware.com> 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 <paston.coo...@gmail.com>:
>>>>>>>>>
>>>>>>>>> Thanks. I have been meaning to look at that.
>>>>>>>>>
>>>>>>>>> On Thu, 7 Jan 2021 at 23:33, Joe Bogner <joebog...@gmail.com>
>>>>> 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 <
>>>>>>>> paston.coo...@gmail.com>
>>>>>>>>>> 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 <devon...@gmail.com>
>>>>>>>> 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
> ----------------------------------------------------------------------
> 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
