arbitrary precision decimal float opcodes #79
Conversation
|
fixed ~ width input is unsigned, but the representation needs it signed ~ add a stack uint param to indicate sign of width |
|
concerning opcode pollution, blog2, blog10 are easy to replace in TEAL (multiply by a constant), so both can easily be left out of the PR. bexp and bln are what is absolutely needed. these are fundamental in Math/Science/Finance. the above two build bpow and could be combined by anyone aware of the decomposition: a^b = exp(b*ln(a)) but then, what about everyone else? adding "super charged" functionality via opcodes vs smart contracts is a topic to be had. to me, it seems, that IF the most basic computing entity (AVM, CPU) is ABLE to provide a "super charged" functionality without performance loss anywhere, then offering that feature or not, is a matter of demand. i think the performance per energy (replenished by the user via ALGO) should work well, since we can charge (opcode budget) in relation to the precision/computation length required) since exp and ln are universally fundamental functions, i am claiming there is demand and that devs will use those opcodes a lot, rather than calling another smart contract to calculate the third root of something, e.g. edit: added performance per energy is constant |
|
some ppl might be hesitant to add highly complex functionality at the very base level (assembly) of a computer. the AVM is a computer and the opcodes are the most basic functions that this computer can perform. normally, given any hardware, the opcodes of the assembly language of that computer, correspond as possible to the hardware abilities of that computer, which are mostly basic, from a mathematical perspective. the AVM, however, is a virtual computer and as such does not suffer from the limitations from hardware. this allows the AVM, in theory, to provide opcodes with high complexity, such as e.g. arbitrary precision power (a^b). as long as the resource consumption is correctly covered, there is no downside to having complex opcodes, which was covered in the prev comment. |
|
why is adding these opcodes beneficial, considering that the AVM is Turing complete and we could implement the same mathematical functions (exp, ln, sin) as a library, in TEAL or Python or whatever? the difference is energy (gas) cost. this change has now been proposed in the EVM world as well, where it won the largest web3 competition ever (1) and now exists as an EIP (2). in the EVM, the difference in energy is between 1 and 3 magnitudes. that is, running the arbitrary precision decimal exp as an opcode vs implementing the same using the existing opcodes (3), we get multiple magnitudes of energy savings. since these are functions that would be used a lot in numerical code, the gas savings are significant links |
|
btw, our decimal float definition has true arbitrary precision vs the decimal float as usually defined by the IEEE standard, which is not perfectly precise. the modeling here is arbitrary precision and simple to understand, at the cost of using double the storage |
this PR defines the specs for opcodes
bexp, bln, bsin
that run the respective mathematical functions on decimals
decimals are defined as follows: (-1)^A * B * 10^w
B is interpreted from a []byte as a big-endian unsigned integer, A and width are uint64, A on stack, width as an immediate
the following opcodes are changed for basic arithmetic on decimals and for consistency
b+, b-, b/, b*, b<, b>, b<=, b>=, b==, b!=
use case are Financial, Math and Science apps ~ these are universal functions required by lots of apps ~ and would e.g. enable a https://balancer.fi style smart treasury on Algorand ~ it would also make Algorand the first DLT (afaik) to support arbitrary precision high level math
this PR serves to exactly define the proposed change, with the potential to form the basis of an ARC, if required
the golang implementation will use only math/big, allows arbitrary precision and a 1st working version for exp is available here: https://github.com/1m1-github/bpow_bexp_blog_specs/blob/main/decimalfloatmath.go
edit:
this PR is being discussed here: https://discord.com/channels/491256308461207573/1032309870982074410
todo: instead of target precision, let users choose carried precision and steps of numerical approximation. this means makes our code simpler and users can calc how much precision and steps they need for their app offline. both precision and steps add to energy cost.