friendica (DFRN) - Link to source

Turns out I've been pruning my #BorgBackup archives wrong. There's a second step involved that actually deletes the "removed" data rather than just (presumably) removing the refrences to that data from the index. While I knew about this second step, I assumed that it was like how it works when you delete a file: the data technically remains intact, but gets overwritten by subsequent writes. Apparently I was wrong about this. I've been pruning—but not compacting—my daily backups monthly for years.

Long story short: I just spent an entire day compacting my backups. My backup storage just went from 71% full to 38%.

#borgbackup

friendica (DFRN) - Link to source

I have an unnamed family member who insists climate change is a hoax. A few days ago, we got an emergency alert about a tornado. I've lived through tornado watches in the past, but this was the first actual tornado I've ever encountered. He insists that this was fake news because he never saw it.

There was a funnel cloud sighting (with photos) on the major road that runs closest to his home.

I just didn't have it in me to argue.

friendica (DFRN) - Link to source

In the late 90s, I remember everyone freaking out about Y2K. I knew how to write software, and I thought I understood the problem (and from a purely technical standpoint, I did). I wrote the whole thing off as people making a mountain of a molehill because surely no competent modern programmer would make a mistake like that, right? This opinion seemed validated when the year 2000 came and went without any apparent major incident.

Thing is, I was young, inexperienced, and naïve. I didn't understand a few things:

  1. How often hastily-written good-enough-for-now code finds its way into production systems in order to meet a deadline (also, how long legacy code tends to stick around (I'm looking at you, COBOL)).
  2. How much work went on behind the scenes scrambling to fix the problem before it happened.

Now, with LLMs, we have a way to generate such code at scale, and I can't help but wonder about the price we're going to pay for it down the line, all in the name of shipping code on an arbitrary deadline.

in reply to Jonathan Lamothe

friendica (DFRN) - Link to source

Jonathan Lamothe

So I was able to commit to codeberg last night (technically this morning) at about 2AM. This made me strongly consider setting up a cron job that checks for un-pushed updates every hour or so and just automatically tries to push them if they haven't been.

This, unfortunately, would require me to leave an unencrypted copy of my private key on disk, which I'd rather not do. I know that openssl does this to facilitate TLS on my web site, but still...

Maybe I can create a special key just for codeberg and revoke it when this issue is resolved?

@Codeberg

friendica (DFRN) - Link to source

I have noticed that a lot of verified accounts on gaza-verified.org—particularly those on mastodon dot social—have been muted or otherwise hidden hidden by their servers. As much as I would like to help, my resources are extremely constrained of late. Since I want to help, but am not in a position to contribute financially, I figured the least I could do was to try to provide some additional visibility.

If you have the means, and are so inclined, I would like to remind everyone that they can always find a random profile on gaza-verified.org/people/ and donate directly to someone who could really use the help.

Contrary to my usual policy, I'm not CWing this post, but I will use ample hashtags that anyone who choses to can opt to filter. Boosts welcome.

#gaza #GazaVerified #MutualAid

#Gaza #mutualaid #gazaverified

friendica (DFRN) - Link to source

So my project where I'm trying to reverse engineer the charm stat in @SDF.ORG's Legion of the Rare Dragoon game has had some progress and some setbacks. I'm keeping a record of my in-game "purchases" along with my charm stat at the time to see how my charm affects my discount rate. I'm then building a table to try to project an estimated discount rate at various different charm levels.

Where I've succeeded: being able to automatically compute an equation that perfectly fits the collected data.

Where I've failed: The resulting discount table looks reasonable up until it gets to charm levels larger than the ones I've already recorded. Then it gets real whacky real quick.

I'm hoping that as I gather more data points, I'll end up with better predictions.

#emacs #lisp

Edit: Here's the calculated table: codeberg.org/jlamothe/lord-cha…

#emacs #lisp @SDF.ORG

Sean Riley reshared this.

friendica (DFRN) - Link to source
subpost about "AI"

I've said this before, but it bears repeating.

I hear a lot of people expressing their dislike for all things "AI" and in general, I agree with them, but...

The problem I have is that "AI" is an ill-defined term. It's used as a hand-wavey buzzword to mean a whole bunch of different things. Mostly these days, it's pretty synonymous with LLMs and similar technologies, but it's actually a broader term than that. It's much like how the cryptocurrency industry appropriated the word "crypto", but I digress...

I've been dabbling with digital art lately. The idea of using "AI" to generate my art is extremely distasteful to me. That said, I do digital art because it affords me tools that I wouldn't have available to me otherwise. For instance, I, as a human, could not replicate the various filters I've applied, or the liquefy tool. That said, those tools don't need to destroy the planet and plunder the commons to be created. That's an important distinction to me.

The thing is, those tools could be argued to be a form of "AI" given the squishiness of the term to begin with. Also, I don't feel right about calling my art something like "100% human created", because a computer has (under my explicit direction) enhanced the work I've done.

There's a lot of nuance here that's difficult to express in a single post. At what point does the use of a tool overshadow the human involvement in an endeavour? To be honest, I don't exactly know.

I guess my issue, as is frequently the case, is that I get hung up on the precise meaning of words, and I lack a precise definition.

friendica (DFRN) - Link to source
So I'm working on an #OrgMode document that's probably about 2/3 #emacs #lisp code. I'm planning on releasing it shortly, but I'm not sure what to do about the licensing. Normally I use the #AGPL for my code, but since this isn't strictly code, I'm wondering if some version of the #CreativeCommons license might be a better fit. Do they have a #copyleft variant?
#creativecommons #copyleft #emacs #orgmode #lisp #agpl

friendica (DFRN) - Link to source
Just spent a day and a half hunting down a bug that was making me question my sanity. As it turns out, #emacs #lisp's / function silently drops the decimal in its result if both of its inputs are integers... so (/ 1 2) evaluates to 0, not 0.5. Granted, this is also the way that C does it, but in my defense, #CommonLisp does not do this.
#emacs #lisp #commonlisp
in reply to Jonathan Lamothe

mastodon - Link to source

Vassil Nikolov | Васил Николов

As a first approximation, I suggest thinking of Emacs Lisp as closer to MacLisp than to Common Lisp.

A precise description of "closer" would be fairly long.
For example, Emacs Lisp acquired things like bignums and lexical bindings fairly late.

Again as an approximation, the descendancies are:
MacLisp → Emacs Lisp
MacLisp and others → Common Lisp
(Those others include, in alphabetical order, Interlisp, Scheme, Zeta Lisp, etc., but not Emacs Lisp.)

And then an important aspect of these approximations is the `cl' package, also a late addition that evolved quite a bit.

Transferring knowledge about C to Emacs Lisp is rather tricky, even though the implementation of a part of Emacs (including the Emacs Lisp virtual machine) is written in C.

#CommonLisp
#Elisp
#Emacs
#EmacsLisp

@me

#emacs #commonlisp #elisp #EmacsLisp @Jonathan Lamothe
in reply to Jonathan Lamothe

diaspora - Link to source

Greg A. Woods

yup of course, but that's integer math, not floating point math

GNU Clisp and SBCL don't show decimals for integer division, but return fractions instead!

* (/ 1 2)
1/2

But of course if you use floating point representation for the parameters then the result is a floating point number as expected:
[1]> (/ 1.0 2.0)
0.5

Elisp, with floating point parameters, also works as expected:
(/ 1.0 2.0)
0.5

In C, with IEEE 754 double values, then 1.0/2.0 = 0.50, exactly, no rounding or epsilon comparison needed.

friendica (DFRN) - Link to source

Spent several hours today trying to figure out why my #elisp code was misbehaving. Turns out, I made a mistake while trying to be clever. Instead of doing:

(when (and cond1 cond2)
  stuff
  ...)

I did:
(and cond1 cond2
  stuff
  ...)

...which would only work if every instruction in stuff returned a non-nil value.

I should stop trying to be clever.

#emacs

Edit: when, not while

#emacs #elisp

Dave Marquardt reshared this.

in reply to Jonathan Lamothe

friendica (DFRN) - Link to source

Jonathan Lamothe

For the morbidly curious, this is the (now corrected) code:
(defun jrl-collect-data (table input output)
  "Collect table data into lists of outputs per input"
  (let (res record in-val out-val collection)
    (while table
      (setq record (car table)
            in-val (assoc input record)
            out-val (assoc output record))
      (when (and in-val out-val)
        (pop in-val)
        (pop out-val)
        (setq collection (assoc in-val res))
        (if collection
            (push out-val (cdr collection))
          (push (list in-val out-val) res)))
      (pop table))
    res))

I should probably throw some comments in here, but essentially the assoc in the when block always returns nil on the first iteration of the loop, and if it can't progress past that point, it'll always return nil on subsequent loops and nothing will ever happen. As a result, any list I might feed into this function is always going to result in a nil output.

friendica (DFRN) - Link to source

So, I think I might be a nerd.

@SDF.ORG is running a BBS called bitzone. On this BBS they have a door game called LORD (League of the Rare Dragoon (not to be confused with Legend of the Red Dragon, of which it is clearly a knock-off)).

The fact that I'm playing this game in the first place is kind of nerdy, but wait, there's more.

In said game you have a character with various stats. One of these stats is "charm", which seems to get you discounts in the shops. Unfortunately, there's nothing to say exactly how this relationship works. So I've decided to try to reverse-engineer it with #emacs #org-mode.

I've created a table to track my purchases. It tracks my charm at the time of purchase, the list price for the item, and the price I actually paid. There's also an additional colum that calculates the actual discount, but that's trivial.

Anyhoot, I'm adding some code to this file that reads the values in the table and computes the simplest polynomial function that satisfies the equation:
$$price_{actual}=f(charm,price_{list})$$

This is done with the aim of predicting how much I'd actually spend on an item before actually buying it. It of course assumes that the equation being used is a polynomial equation, but I'm hoping it'll at least be able to approximate with a large enough set of data points.

Am I doing this because it's reasonable?

No.

I'm doing it because it's an interesting challenge... and I'm a nerd.

CC: @tob

#emacs #org-mode @SDF.ORG @tob
in reply to Jonathan Lamothe

friendica (DFRN) - Link to source

Jonathan Lamothe

So it occurs to me that the approach I was considering is probably not going to work for a couple reasons:

  1. I thought the technique I use for curve fitting a single input function could be adapted to multi-dimensional functions. I realize now that it can't (at least not in the way I was thinking).
  2. Even if I do sonetning like calculating the discount value based on the list price and actual price and fitting a curve between that and the charisma stat, the discount is going to have to be constrained within a range between zero and the list price. A polynomial function with a finite series of terms just isn't going to be able to cut it.

I'll continue collecting data to see if any patterns start to emerge, though.

friendica (DFRN) - Link to source

Gave myself a bit of a scare. My aNONradio stream cut out on me and when I went to investigate, I found the router dead. No lights. Nothing. Disconnectd the power cable from the back and re-attached.

Still nothing.

When I followed the power cord, I found that the wall wart seemed to have come mostly unplugged from the power bar. I have no idea what caused it to spontaneously disconnect, but I'm back now.

friendica (DFRN) - Link to source

This question doesn't lend itself well to plain text, so I LaTeX'd and screenshotted it. I'll do my best with the alt text.
Is there a way of writing the expression<br>\[ \sum_{n=1}^m f(n) \]<br>in a way that omits the term where $n=a$?</p><p>I know it could be written as<br>\[ \left( \sum_{n=1}^m f(n) \right) - f(a) \]<br>but this doesn't work when $f(a)$ is undefined.

#math #maths #mathstodon #AskFedi

Edit: It turns out that Friendica has a MathJax addon. Who knew?

Also, it seems like there are a number of options. The one I like best is:
$$\sum_{\begin{matrix}1 \le n \le m\\n \ne a\end{matrix}} f(n)$$

Edit 2: It looks like this doesn't render properly when federated to a server without MathJax support. I suppose I should've seen that coming.

#askfedi #math #maths #mathstodon

Mathematics Channel reshared this.

friendica (DFRN) - Link to source

Here's a big part of the reason* I don't use so-called #AI to write code for me: I actually enjoy writing code. I wouldn't offload this task to AI for the same reason I wouldn't use it to go for a walk in the woods, or eat a delicious meal for me. Why would any sane** person do this?

* It's not the only reason, but this is a fedi post, not an essay.

** This post should in no way be considered as me claiming to be sane. 🙃

#AI

𝚛𝚊𝚝 reshared this.

This website uses cookies. If you continue browsing this website, you agree to the usage of cookies.

⇧