Dear @jamie
Thanks a lot for your time and attention (and code, of course). 😉
I am about to go to a Conference in Helsinki and will be back on the 30th, so no hurry. I will try to move the thesis #tem25 in the in-between times but I'm afraid there won't be much of those in the next days. ;D
And, for sure, will try your code once I'm there and will report back. :)))
Again, thanks a lot. Your sharing helps us all to keep hope in people and work towards a better world in these dark times.
Best.

I'll either rewrite this to be easier to understand or provide more commentary or both in the near future. An org-mode literature program maybe?

#tem25 #elisp

@Eduardo Mercovich (él)

Well, I got this much working, which is sort of the crux of the problem.  It takes a list of pairs and a function and applies the function repeatedly to the cdrs of the pairs that share the same car.

Roger has shown an expanded version of the table where the groups have been put against the values that apply to them.  The last two columns of that table should be able to be turned into an appropriate list easily enough - I have not attempted this yet.

I'm in two minds about this as a solution for you.  

On the one hand it's short, and has some general applicability beyond the stated problem.  

On the other, I may be being a bit too clever - not quite 'week 1 of Lisp' material I suppose. Sticking to explicit iteration and solving the specific problem only would be more digestible.  But this is the concrete thing that I got to first.

On the other other hand - I'm wondering whether there are library functions available to do this with fewer lines that I'm ignorant of.


Plus the use of the lambda in the application is a bit clunky - might be nicer to just pass + in (could just put in another layer of wrapping to do this).  

And the function names might need some further thought...

But I thought I'd table it anyway — might be good to see some progress and perhaps it will inspire others to do better 😄

(defun assoc-replace (new alist)
  "non-destructively replace the alist element with new, where the keys are equal"
  (cl-substitute-if new
            (lambda (x)
              (equal (car x) (car new))) 
            alist))


(defun alist-acummulate-step (f alist pair)
  "lookup alist using car pair and replace the element with f applied to the cdrs of it and pair. Add pair to alist if not found." 
  (let* ((key (car pair))
 (old-pair (assoc key alist)))
    (cond
 (old-pair
      (let ((result (funcall f (cdr old-pair) (cdr pair))))
        (assoc-replace (list key result) alist)))
 (t
      (cons pair alist)))))

(defun alist-reduce (f pairs alist-initial)
  "reduce using f into an alist with keys as the unique cars of pairs"
  (seq-reduce
 (lambda (x y) (alist-acummulate-step f x y))
 pairs alist-initial))

(alist-reduce (lambda (x y) (+ (car x) (car y))) '((a 1) (b 2) (a 3) (c 4) (b 3) (b 4)) nil)
=>
((c 4) (b 9) (a 4))

@Eduardo Mercovich (él)

This particular problem should be straightforward to do using elisp, particularly with Roger's suggestion of an intermediate representation.  I will try later on tonight (right now head is full of other stuff).

Sort of think I can crack out a solution quickly, but experience tells me I am (like everyone else) far too optimistic at how long it takes to code something up & I have limited time until the weekend, which might be a more realistic timeframe.

As problems get more complex or specialized, there's a point at which switching to R would make more sense — e.g. it will be easier to learn some R than try to equip elisp with extensive data reorganization or statistical abilities (which of course would be possible in principle).

But if your problems are mostly of this level of complexity, I think I agree, you may as well avoid having R as a dependency.

@Roger Schürch
#tem25

Dear Roger:
I completely share the Babel idea and R is one of the better options to do this, hands down. :)

However, since I know nothing of R and only a micro bit of elisp, I may need to use elisp. It also helps to keep the whole system as simple and reproducible as possible.

Up to now, only gnuplot is needed outside emacs.

Anyway, I value very much your response and in other circumstance, I would go for it immediately. b(^‿^)d

Thanks! :)
@span schuemaa
#tem25

Dear @span jamie
I completely agree: if we don't have a good reason and/or way to split it now, let's keep it as it is. :)

Thanks a lot... 🙏

#tem25

Dear #emacs and #org-mode comrades.
Given:
+ a table w/ a list of tags + their # of appearances per question 1 & 2.
+ org support for tag groups (https://orgmode.org/manual/Tag-Hierarchy.html)
+ GroupTag1=tagA+tagC+tagD and
+ GroupTag2=tagB+tagE

How can I count the sum of each group per question?
Example:
| tag | Q1 | Q2 |
|------+----+----|
| tagA | 9 | |
| tagB | 4 | 2 |
| tagC | 1 | 4 |
| tagD | | 5 |
| tagE | | 6 |
|------+----+----|
| GT1 | 10 | 9 |
| GT2 | 4 | 9 |
Thanks!
#tem25

@a href="https://social.coop/@edumerco" target="_blank" rel="nofollow noopener" Eduardo Mercovich (él)

I sort of had it in mind that it might be in chapters (or possibly modules?) with the code relevant for that chapter in there too.

The point of literate programming is that there isn't a distinction between 'code' and 'documentation'. I realise your thesis goes beyond code and documentation about the code, but I wonder whether the same line of thought might still apply: perhaps the discursive thesis, the code, the code's documentation, the data, etc. all belong with one another, on a topic or chapter basis?

As I don't have a very concrete suggestion but just some floating ideas, I think my advice is still the same: keep it as one file for now and work it out later. A division that makes sense may arise as you & your collaborators work with it more — let the cowpaths emerge!

I think one file will leave your mind more open to other alternatives too. Generally speaking if you don't have a good basis to make a decision, and there's no real reason to make it right now, it's better to just defer it.

However, I don't think anything very much will go wrong if you decide you like the idea of splitting it into code and non-code. You can always change your mind later.

# tem25 # literateprogramming

I believe I can separate w/o issues the code blocks.
In this way we would have a main thesis file +... 1 for all the code or 1/script?

> I'm also going to suggest that only you should commit updates to your thesis [...]

We thought the same. :)
And I already checked it with my director and it's ok.

#tem25

Hello @schuemaa @jamie

Thanks a lot for sharing your concerns, they are very much on spot.

I am the guardian of the personal data and that is why in the repo there will be only an assigned numerical ID per respondent. Never a link between that ID and the real personal data. The other data present is not usable to identify anyone. So, it is already anonimized.

Just in case I checked with my director and everything is perfectly compliant in this way. :)

Thanks again...

#tem25

@Eduardo Mercovich (él)

I think it probably would be easier & more flexible in the long term to deal with multiple files.

However, as it sounds like you're having difficulty with version control, I'm going to suggest keeping it as one file for now.  You can always split it later once you've got the hang of the version control more.

I'm also going to suggest that only you should commit updates to your thesis - this makes your life easier but also there may be worries about you not actually doing your own work otherwise.
# tem25

Hi @jamie

While I must ask my directors (just in case) I would be delighted to work on it in the open. :)
I've been trying to work with version control systems and I'd love to use them more.

And I already have an account on Codeberg too bcs of a friend. :)

Also, I can happily separate the monolithic document into sections. How could be easier to collaborate? All the scripts in 1 (literate) file, or each on it's own file?
After that, it's only to use #+include in the main file.

#tem25

@ Eduardo Mercovich (él)

Assuming you are prepared to work on it openly to facilitate collaboration, have you thought about how you're going to do that? If not might I suggest a project on codeberg? They will require an open license and I would suggest GPL-3.0-or-later.  

How familiar are you with code repositories and revision control? It's not hard for simple cases and there's plenty of people around to help.

and do you need to check with your thesis supervisor about this?

# tem25

What else can I share to better describe the thesis? Some parts that are not clear?

While #orgmode does 85% out of the box (#LiterateProgramming, tagging, counting, writing, exporting, even interacting with #gnuplot, etc.) #elisp is needed to do some of this calculations, ordering and grouping... :)

[end] #tem25

I have the thesis (text), the sample data, their (tagged) responses and the ongoing analysis all in 1 #org-mode file. So, if you have #emacs, you can reproduce all the research from start to finish.

And now, we are adding another sample of graduates that haven't gone outside academia and will compare where their responses are similar and different (yea, because I have soooo much non-occupied time...). ;DDD

[cont] #tem25

We have 3 different criteria to group this T1:
- the 3 pillars of the UBA; research, teaching and extension (extra-mural involvement?).
- type of teaching; conceptual, procedimental, attitudinal.
- and one that I think it is emerging; scientific (like critical thinking, analyzing data, etc.), and professional (design a project, good communication skills, managing a team, etc.).

[cont] #tem25