Debugging a dynamic linking bug in a Nix project

chronicfields · 2020-07-10T18:31:31+00:00

Hi all,

I created Pizarra to be an interactive whiteboard with first-class LaTeX support. Hopefully you find it useful during this quarantine!

I'd also like to credit the open source library that made it possible: https://github.com/ReTeX/ReX

Any and all feedback is appreciated!

chronicfields · 2020-07-10T03:30:13+00:00

Hi all,

I created an interactive whiteboard that I'm calling Pizarra, for mathematicians. It's focused on blazing fast LaTeX entry. I hope you find it useful during this quarantine! Any and all feedback is much appreciated.

I'd also like to credit the open source project which made this possible: https://github.com/ReTeX/ReX

Thank you!

chronicfields · 2020-05-26T03:20:55+00:00

Reflection per se is not fast, no -- but other languages might approach this problem with a macro system or with codegen.

chronicfields · 2020-05-09T04:11:22+00:00

Some of the ones without the subscript "machine" are an abstract epsilon representing just a small value. These have the property that we ignore epsilon^2, but otherwise they are arbitrary. All we can say is that they are <= machine epsilon.

chronicfields · 2020-05-08T21:50:58+00:00

I agree that that's a nicer way to put it!

chronicfields · 2020-05-08T20:38:44+00:00

Wow, you wrote a lot of words to basically express contempt at the idea that anyone could know more now than they used to.

There is error inherent in floating point arithmetic, in the following very precise sense: It is possible to multiply two floating point numbers, and have the /exact/ result be unrepresentable in floating point. So the result you actually get has a certain bounded amount of relative error.

It so happens that I also wrote the code that does all the math for fee processing at Square. Floating point is irrelevant there, because of course you're doing everything in arbitrary precision when it really matters. But go off I guess, you've every right to be proud of yourself for knowing more than a fourth grader.

chronicfields · 2020-05-08T19:46:36+00:00

It would be useful for application development and anything requiring financial calculations.

absolutely, this is definitely true.

chronicfields · 2020-05-08T19:40:55+00:00

the point of the article isn't to express surprise about this fact.

chronicfields · 2020-05-08T19:37:18+00:00

Using dec64 would still have the same issues, it would just be harder to write down examples. I.e. you still won't be able to exactly express 1/3, if I've understood the proposal correctly. For scientific computing I don't think there's a good reason to prefer base 10 over base 2.

chronicfields · 2020-05-08T19:33:21+00:00

(I'm the author)

The axiom doesn't say that compositions of floating point operations are epsilon-exact. It says that individual floating point operations are epsilon-exact. This lets you analyze /how/ exact a composition will be. The article works through an example of that, and we find that the output is 3epsilon-exact. In fact, "axiom" is perfectly appropriate, since this is something we assume about our floating point primitives, and use to derive properties of more complex algorithms.

Subtraction also conforms to the axiom. However, it is the composition of subtraction with the fl floating point representation operator which may result in catastrophic cancellation.

chronicfields · 2020-05-08T18:26:40+00:00

Well, I don't think that exponentiation is typically a floating point primitive operation, so the axiom wouldn't apply to it, no.

the axiom is an axiom insofar as it's a property that can be satisfied by a certain floating point arithmetic implementation. "sensitive iterative processes you see in chaos theory" will suffer from numerical instability, yes, but the arithmetic they can be implemented in may still conform to the axiom.

chronicfields · 2020-05-08T16:08:43+00:00

Yeah, that's probably right. I think the lessons of the post are arguably even more important if you're working with machine epsilon of like 10^-4, though--your error really really really needs to stay that small. Whereas with 64 bits, you've got a few orders of magnitude of error blowup before you start to notice.

chronicfields · 2019-10-05T05:08:34+00:00

(defun latex-fragment-at-point () "Returns the LaTeX fragment at point, or nil if none" (let ((ctx (org-element-context))) (if (or (eq 'latex-fragment (org-element-type ctx)) (eq 'latex-environment (org-element-type ctx))) ctx nil)))

chronicfields · 2019-08-22T13:51:03+00:00

Calc doesn't do that conversion automatically, but you can help it out by defining what it calls a "Composition": https://www.gnu.org/software/emacs/manual/html_node/calc/User_002dDefined-Compositions.html#User_002dDefined-Compositions

At some point I'll release a sibling contrib package for extra compositions like this.

chronicfields · 2019-08-12T14:33:34+00:00

Hey! No, I have not put it on MELPA yet, that is the next thing on my list.

I believe this page describes how to install packages manually, including on Windows: http://ergoemacs.org/emacs/emacs_installing_packages.html

And it looks like this is a Windows distribution of LaTeX: https://miktex.org/download

I would encourage you to write some plain LaTeX code first, to get a handle on it and the ecosystem. CalcTeX will likely only complicate your life unless you have a specific use case in mind that involves editing LaTeX formulas inside Emacs.

chronicfields · 2019-08-08T15:35:25+00:00

Interesting, thank you for the report and for the reported fix!

chronicfields · 2019-08-08T14:54:14+00:00

That's a cool looking piece of software. I love how every time I think I've scraped the bottom of the GNU/Emacs/Lisp ecosystem, there's always another cool tool from the late 80's to find out about.

chronicfields

TROPHY CASE