BTW, your table got me thinking that in my mind there was always 1 line/ tag. And you showed that it doesn't have to be so... mmm... interesting. :)
Thanks again. 🙏
Discussion
Loading...
Discussion
@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))Example of use:
(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))#tem25 #elisp
@span edumerco I would leverage babel to use a dedicated data analysis language (in my case R). I attach a picture. That will also allow you to produce figures with ease, etc.
BTW, your table got me thinking that in my mind there was always 1 line/ tag. And you showed that it doesn't have to be so... mmm... interesting. :)
Thanks again. 🙏
@span edumerco the original data structure is not that important, as you can reshape as needed programmatically. I just usually prefer the long over wide format for my raw data.
I found gnuplot (many years ago) to be limited for publication quality plots. The #RStats community is great and helpful, and I'd wager probably bigger than the elisp community. That said, the approach above is language agnostic. You should be able to feed the data table into elisp the same way.
@span schuemaa
You are totally right about the format. It is only that seeing things in a different perspective can open possibilities. :)
I am reading your comments about #gnuplot with care since I'm a but stuck with something simple as horizontal bars and it seems they are not supported...
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
@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
With a gentle ping to those that showed interest in this thesis #tem25
@span birdgoose
@span civodul
@span csantosb
@span jamie
@span jay
@span marc
@span miguel
@span nonzerosumjames
@span oantolin
@span riley
@span schuemaa
@span szpon
@span yala
(please tell me if you don't want to be notified again, and sorry in that case for pinging now). 😊 /
bonfire.cafe
A space for Bonfire maintainers and contributors to communicate
Automatic federation enabled