Help: Formulas in Bases

Help
1

What I’m trying to do

I’ve created a base to keep track of an inventory in Obsidian. Individual notes are marked as items that belong to that inventory and the number of items as well as their cost and weight are documented as file properties. In the inventory base itself, I have written a formula that multiplies the number of items with their cost and weight respectively. These are marked as “value” and “load”.
The formula mostly seems to work, but it’s leading to some strange results (see screenshot below). As you can see, some of the multiplications return an answer that is close to correct, but for some reason unknown adds a 1 or a 2 at the 16th decimal point.

image
image815×413 8.31 KB

Unrelated as far as I can tell, another odd thing I’ve noticed is that the number 4 specifically seems to be left aligned in Bases, while all other numbers are right aligned.

image
image129×422 1.18 KB

Things I have tried

I have tried to change the values of cost and weight and rounding the numbers down or up using the round() function, which does return correct answers but obviously this is not the solution I’m looking for. I have also tried limiting the number of decimal digits to 1 or 2 with the toFixed() function but this seems to have no effect.

2

Open one of the notes where 4 is on the left, and toggle the view to source mode. Does the 4 have quotation marks (single or double) around it?

---
Level: "4"
---

If so, then does deleting the quotation marks make the 4 appear on the right in your Base table?

Quotation marks indicate a string in YAML. Bases left aligns strings but right aligns numbers.

I have no guesses why the up rounding or inclusion of decimals places. But you can use .toFixed(2) to bring them down to two.

3

The issue with those strange decimals is due to how computers store non-integer numbers. Because they use a binary system, only fractions that are powers of 1/2 (or sums of them) can be represented perfectly. For example, 0.5 (1/2), 0.25 (1/4), and 0.75 (1/2+1/4) can be stored with perfect accuracy.

However, decimals like 0.1, 0.2, and many others cannot be represented exactly in binary. Instead, the computer stores a very close approximation that’s good enough for most purposes (except, perhaps, for dealing with currencies or cryptocurrencies).

For instance, 0.9 can’t be represented as a finite sum of powers of 1/2. The computer would need infinite storage for that. So instead, it stores a number like 0.8999999999999999, which is the closest possible representation in a standard 64-bit float.

We usually don’t notice this because when the computer needs to display the number, it often rounds it to show 0.9. But the small error is still there internally, and it can accumulate and affect calculations.

Some programming languages offer special decimal types to avoid these precision errors (e.g., for banking applications), but most of the time, the standard IEEE-754 format is used, which is what causes these kinds of issues.

Specifically, Obsidian is built on Electron, which uses Javascript, and Javascript numbers use the IEEE-754 standard. It’s interesting, however, that the Bases plugin chooses to show the “actual” stored number instead of a more user-friendly rounded version in its formula fields.

Note: I noticed that in the Cost and Weight columns, numbers like “0,2” are shown. This particular number is not exactly representable in binary, which puzzled me at first. Then I realized that these columns use a comma as a decimal separator, while Value and Load use a dot. It seems the Bases plugin uses special formatting for its number properties (hiding the IEEE-754 representation errors), but the formula columns do not get this treatment.

1 Like
4

This turned out to be the issue, thank you!

5

Thanks for the detailed and clear explanation, I understand the underlying issue. I’ve tried using the toFixed(2) function as suggested, which didn’t seem to do anything yesterday but does solve the problem today for some reason. May have been a syntax error on my part after all.