41–50 of 234 posts
Earlier quoted context omitted.
A string type. As parent says: it completely bypasses the problem. Save the numbers between double quotes and be done with it.
Storing numbers as arrays of u8? That doesn't make sense
Floating-point precision has too many gotchas for being suitable to store Decimal types, especially for the Currency use case.
> Webhooks are the most common way to receive signals from external systems, but processing them safely is not trivial I see webhooks documented all the time, but I have yet to use them in practice, nor have my customers requested them. Is the above not true, or are they widely used in some sectors and not others?
Earlier quoted context omitted.
Do not throw away any precision in finance/money computation, regardless what/ how you are doing it. In C# e.g., there is type decimal for those computations.
You'll definitely have to throw it away at some point. The art is in making those points well-defined and rare enough to not cause large discrepancies, but frequent enough to avoid ballooning arbitrary-precision numbers across databases and services that might not be able to handle them.
Word of advice to anyone considering the "minor-units precision" strategy for representing monetary amounts: Don't (or at least, don't use it as an interchange/API data format). It seems like a clever idea (fast integer math, no rounding problems for addition and subtraction), but it'll bite you incredibly hard if you ever stumble upon an edge case such as working with a partner that has a different implied number of…
Having done HFT / low-latency in C++ with a browser based (read: JavaScript) management front-end: Go ahead and use integer cents everyone. It’s practically an industry standard and it works just fine. Anything else is a worse compromise.
You can have the blockchain team be an expert in converting integer cents, or the forex team be an expert in sub-cent conversions. You don't want to require _every team_ to have expertise in float math, by default.
Word of advice to anyone considering the "minor-units precision" strategy for representing monetary amounts: Don't (or at least, don't use it as an interchange/API data format). It seems like a clever idea (fast integer math, no rounding problems for addition and subtraction), but it'll bite you incredibly hard if you ever stumble upon an edge case such as working with a partner that has a different implied number of…
Having done HFT / low-latency in C++ with a browser based (read: JavaScript) management front-end: Go ahead and use integer cents everyone. It’s practically an industry standard and it works just fine. Anything else is a worse compromise.
Earlier quoted context omitted.
Storing numbers as arrays of u8? That doesn't make sense
For JSON serialization, which doesn't support fixed-point precision it does. Floating-point precision has too many gotchas for being suitable to store Decimal types, especially for the Currency use case.
{
"price": {
"amount": 1000,
"decimal_places": 2,
"currency": "USD"
}
}Anyone know of resources like this but for capital markets? Things that would allow engineers new to trading equities, options, FX, bonds, and commodities to learn about different flows, market structure, common architectures, and other things that normally you learn from years of experience.
To learn how and why these things are traded, however, read this book, the only (good) truly beginners guide to fixed income:
https://www.jdawiseman.com/books/pricing-money/Pricing_Money...