1 CREDO
11 IN
111 UNUM
11 DEUM
112 PATREM
1121 OMNIPOTENTEM
113 FACTOREM
Set_1 = <<CREDO>>
Set_2 = <<IN, DEUM>>
Set_3 = <<UNUM>, <PATREM>, <FACTOREM>>
Set_4 = <<OMNIPONTEM>>
Forall i >= j, a >= b: (Union Set_i)_a >= (Union Set_j)_b
V = DisjointUnion {Set_i}.
The vertices are ordered multisets like <CREDO>, <IN, DEUM> and <PATREM>.
E = <<<CREDO>, <IN, DEUM>>,
<<CREDO>, <IN, DEUM>, <UNUM>>,
<<CREDO>, <IN, DEUM>, <PATREM>>,
<<CREDO>, <IN, DEUM>, <PATREM>, <ONMIPOTENTEM>>,
<<CREDO>, <IN, DEUM>, <FACTOREM>>>
I'm not quite sure what is implied by 11 DEUM coming after 111 UNUM,
and not next to 11 IN. I don't know enough latin to comment.
I was wrong about needing to add new nodes. All values and nodes are
defined at the beginning. Which base set a value is added to is
defined by the number of digits. Which node (set of values) a value is
added to, is determined by the final digit. For instance, 11 IN and 11
DEUM live in the same subset of base set Set_2. 1 CREDO lives in a
singleton set; that set lives within Set_1.
This representation assumes that values are unique.
On Sun, 10 Jan 2021 at 11:14, Hauke Rehr <[email protected]> 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 <[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
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
