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

in reply to 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.

Is there a way in #emacs #org-mode to next quote blocks? The following doesn't seem to work.

#+begin_quote
This is a quote.

#+begin_quote
This is a quote within the quote.
#+end_quote
#+end_quote

Emacs is ignoreing the second #+begin_quote and just closing the quote block at the first #+end_quote.

Edit: So the solution I settled on was putting the nested quote in a drawer named :quote:. it's not an ideal solution, but for my purposes in this case it's... fine, I guess.

God help me if I ever need three levels of nesting.

I use a giant #org-mode repisitory to keep myself organized. I synchronize this repisitory between multiple devices using #git because occasionally I'll find myself out without an internet connection and it's useful for merging when they fall out of sync.

To that end, I frequently find myself issuing the command git commit -am stuff, which makes me feel kind of dirty, but it's just the easiest thing to do.

Luckily no one but me will ever see this repisitory.

#VersionControlCrimes

notoriousGIT reshared this.

in reply to Jonathan Lamothe

Per the help doc for org-agenda

"If the current buffer is in Org mode and visiting a file, you can also
first press ‘<’ once to indicate that the agenda should be temporarily
(until the next use of ‘SPC o a’) restricted to the current file.
Pressing ‘<’ twice means to restrict to the current subtree or region
(if active).
"

In other words, execute org-agenda then press "<" before the command you want to run against the agenda.

This entry was edited (Saturday, August 30, 2025, 7:19 PM)

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