The max precision of numbers in Coda is 6. However, BTC (known as satoshis) require a precision of 8 decimal places. I would hope that a tech company would recognize the role of crypto and facilitate accurate recording of a coin. Please increase precision to at least 8.
Thanks.
1 bitcoin is 100,000,000 satoshis. Keep track in Satoshis and it isn’t a problem. You can use whole numbers!
Math is your friend.
Or Instead of 1 bitcoin, move the decimal place two to the right and keep track. Then you can use six decimal places to your heart’s content. If your fiat conversions are the problem, just divide them by 100 before applying the conversion rate to the bitcoin (or whatever else).
The reality is 6 digit precision doesn’t affect one’s ability to use coda to track crypto. Bend the spoon with your mind.
Or, alternatively, Coda could support a higher level of precision – like the spreadsheets they seek to replace.
Your (pedantic) workaround is nothing more than Coda’s limitations forcing me to do things in a way that’s not useful to me. That’s not a plan for success.
Floating point math vs integers
LOL. JAW, you must be a real dream to live with. Your FP vs Int argument is old news, bro. Even 1979 Visicalc accurately-enough supported precision greater than eight decimal places. Here I am, over 30 years later, asking a tool provider to at least support eight decimal places. Shame.
Hi @Joey_Serio,
you are right: having Coda dealing with higher precision would help you with your current issue.
And it’s certainly not an insane topic that you correctly put into the “suggestion box”.
I can understand your frustration.
However, people took some time to read your post and suggest workarounds.
They might not be optimal or even useless or inappropriate to your use-case; and perhaps with an attitude not matching yours.
I think it’s still fair to appreciate that support, though, and not to bend your frustration towards the ones who aren’t actually responsible for the two (or more) missing decimals.
There are several pending features affecting a much wider audience and we are all patiently waiting; judging or blaming hardly speed up the process.
Coming to your issue, I believe @JAW’s suggestion is actually smart and does the job until a higher precision will come: if you see other limitations, Iet’s face them.
Cheers!
One good reason to know max int
Federico, suggestions are better if they’re not surrounded by snark (“Math is your friend”). However, the biggest issue is that JAW’s idea if self-evident to anybody who has ever worked with numbers. The point of my suggestion wasn’t “here’s a problem, give me a work-around.” The point, and why it’s put in as a suggestion, is that this is a big oversight of a platform that fancies themselves as a spreadsheet/light database replacement.
This is not a concern of mine because this isn’t a club and I’m not here to help Coda’s business and I’m not an investor. If they want my business then they need to provide a viable service to me. Integer size and floating point precision limitations are a serious issue if they intend to be taken as a serious solution.
I’m playing with a crypto based doc right now, and I’m using a shares first approach. I specify the base unit of currency, e.g. satoshis or gwei, and then allocate myself my currency in terms of that number.
It turns out that that’s also how Bitcoin and Ethereum implement ownership of tokens under the hood for the exact reason that @JAW pointed out.
I’d agree that “math is your friend” is perhaps not the most diplomatic way to put it. I see how that could upset you. Seeing past that sentence, however, it’s likely the right solution.
I appreciate your input. Again, I recognize that there are plenty of other ways to track this information – which I had previously deployed. My initial comment was to highlight the issue and make the Coda developers aware that at least one person is expecting a level of precision that has been available to micro-computers for over 30 years.
Your use case isn’t the same as mine. We interface with the Coinbase API and have people comparing numbers in our Docs with the Coinbase website (which also displays to 8 decimal places).
It would be useful to me if I didn’t have to make mathematical conversions considering the fact that the Coinbase API transmits precision to 8 decimal places and it’s simply not acceptable that an app, Coda, that considers itself a spreadsheet or light database replacement can’t handle that level of precision.
That was my point. I wasn’t asking for a solution. I was making a point: Coda should have never considered that 6 decimal places is sufficient while also claiming to be a smart spreadsheet or whatever their marketing material is trying to promote themselves to be.
Your observation and question about max Int size is also very important considering how floating points with precision greater than 6 have to be treated.
I can’t imagine trying to use Coda for some of the research we’ve done in the past with large numbers at high precision.
In your pack you can implement your own column formatting like this:
pack.addColumnFormat({
name: "Float",
instructions: "Float value.",
formulaName: "Float",
});
pack.addFormula({
name: "Float",
description: "Generates a float value.",
parameters: [
coda.makeParameter({
type: coda.ParameterType.String,
name: "value",
description: "Input value.",
}),
coda.makeParameter({
type: coda.ParameterType.Number,
name: "digits",
description: "Number of digits after decimal point.",
suggestedValue: 8,
optional: true,
}),
],
resultType: coda.ValueType.Number,
execute: async function ([value, digits = 8], context) {
return Number(parseFloat(value).toFixed(digits));
},
});