I have been trying to find active interest in a free for all use PostgreSQL extension, complete and available, on the public internet, that will support the following:
High Precision Numeric and Elementary Functions Support
In PostgreSQL v13 and beyond.
HPPM: High Precision PostgreSQL Mathematics.
-Integer Z, or Rational Mixed Decimal Q, numbers support in 64 bit PostgreSQL. Via HPZ, and HPQ, original types. In this specification, they are collectively referred to as HPX types.
There should be no range or multi range types or their supporting functions or special operators included for HPX types, at this point.
-The extension could be based on a library like GMP, written in C, being an appropriate basis to use, for all OS platforms involved. The point being, that there is already some support for this extension, in terms of its logic, publicly available in C that can be apprehended for this extension and its platforms.
-Real numbers are the values of Integer, non-recurring Rational Numbers and recurring, Irrational Numbers. Recurring numbers can be appropriately truncated, via a finite Natural precision value, always at least 1, to obtain an approximating value. The approximating value can really be seen as a finite Rational value, possibly with integer or decimal parts, or both together. These numbers may be positive or negative, or zero, scalar values, may be integers, decimals or mixed numbers, and always do exist on the one dimensional number line.
-A defaulting number of significant figures (precision), stored inside each HPX data or type instance. This gets specified within each type variable before its use, or on data at type casting. Or a default precision is submitted instead. Precision can be accessed and changed later via precision functions.
Precision is set at data casting, type declaration, or from the default, and may be altered again later. Precision is always apprehended before external or internal evaluation begins. Precision is used to control numbers, and operations involving them, and the number output, when numeric manipulation happens.
If an HPX value is data on its own, without a variable or a coded expression, it takes the total default precision, if simply specified alone. If it is inserted into a table column with a different precision, then that precision is applied then. When an HPX calculated value is assigned into an HPX variable, it will try to skip ahead to the assignment variable, and take its precision from the result variable, which can be set up beforehand. If however, an HPX value, in a PostgreSQL code expression is sent straight into a RETURN statement or later, a SELECT statement, for example, then that datum will contain the highest precision value out of any of the previous values in the PostgreSQL expression which lead to it. But before anything is set or specified, a total default precision value of 20 is the beginning point.
precision(HPZ input, BIGINT input) returns HPZ;
precision(HPQ input, BIGINT input) returns HPQ;
precision(HPZ input) returns BIGINT;
precision(HPQ input) returns BIGINT;
expression(HPZ input) returns TEXT;
expression(HPQ input) returns TEXT;
-HPX values, as PostgreSQL data, can be displayed, but they sit on top of a few other phenomena. Forward and inverse accuracy, withstanding truncation, can be achieved by storing, encapsulating and operating with and normalising the mathematical expression (or just one value, via assignment). The expression has one or more links, from value(s) to variable(s) in the expression, via applying of precision adjustment at evaluation time, all internally. This system will uphold any precision, certainly ones within a very large range limit, controlled by the already available type, the BIGINT. It can enumerate digits of a frequency within the range of -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807. Though naturally evaluation will slow down, or not conclude in useful time frames, before these limits. That phenomenon can be allowed, and left to the context of the programmer to deal with or avoid as they may. They may try to minimise the extent of one internal expression by using re-substitution in the body of originating, PostgreSQL, code.
–At the point of PostgreSQL code input and execution:
select pi(1001) as pi;
–Within a table creation command:
create table example_table
(
id BIGSERIAL PRIMARY KEY,
a HPZ,
b HPQ(50)
);
INSERT INTO example_table(a,b) VALUES(0, 0.1);
INSERT INTO example_table(a,b) VALUES(100,1.1);
INSERT INTO example_table(a,b) VALUES(200,2.2);
INSERT INTO example_table(a,b) VALUES(300,3.3);
INSERT INTO example_table(a,b) VALUES(400,4.4);
INSERT INTO example_table(a,b) VALUES(500,5.5);
INSERT INTO example_table(a,b) VALUES(600,6.6);
INSERT INTO example_table(a,b) VALUES(700,7.7);
INSERT INTO example_table(a,b) VALUES(800,8.8);
INSERT INTO example_table(a,b) VALUES(900,9.9);
–Or as variables, in some function:
create or replace function example_function()
returns void
language plpgsql
as
$$
declare
**a HPQ; **
b HPQ;
c HPQ;
begin
BIGINT p=30;
precision(a,p);
precision(b,p);
a = 0.1;
b = 0.1;
precision(c,3);
c=a*b;
precision(c,p^2);
return void
end;
$$
-Value assignment to a typed variable by =.
-Operators. Base 10 Arithmetic and comparisons support on Base 10 HPZ and HPQ, with casting:
+,-,*,/,%,^,=,!=,<>,>,<,>=,<=, ::
These include full division and integer only division (from type inference), with no remainder, and a remainder calculating operator. There should be a defaulting ability of values not within these two types to automatically be cast up to HPZ or HPQ, where specified and appropriate in PostgreSQL expressions.
-Reified support with broader syntax and operations within PostgreSQL. Tables and related phenomena, Array types, Indexing, Variables and related phenomena,the Record type,
direct compatability with Aggregate and Window functions, and Partitions are all parts of a larger subset that should re-interact with HPZ or HPQ successfully.
-Ease of installation support. Particularly for Windows and Linux. *.exe, *.msi or *.rpm, *.deb, *.bin installers.
Upon a PostgreSQL standard installation. Installation and Activation instructions included, if unavoidable. The extension should literally just install and be applicable, with no loading command necessary, inside PostgreSQL. Every time the database process runs, by default.
-Mathematical and Operational functions support:
cast(HPZ as HPQ) returns HPQ;
cast(HPQ as HPZ) returns HPZ;
cast(TEXT as HPZ) returns HPZ;
cast(TEXT as HPQ) returns HPQ;
cast(HPQ as TEXT) returns TEXT;
cast(HPZ as TEXT) returns TEXT;
cast(HPZ as SMALLINT) returns SMALLINT;
cast(SMALLINT as HPZ) returns HPZ;
cast(HPZ as INTEGER) returns INTEGER;
cast(INTEGER as HPZ) returns HPZ;
cast(HPZ as BIGINT) returns BIGINT;
cast(BIGINT as HPZ) returns HPZ;
cast(HPQ as REAL) returns REAL;
cast(REAL as HPQ) returns HPQ;
cast(DOUBLE PRECISION as HPQ) returns HPQ;
cast(HPQ as DOUBLE PRECISION) returns DOUBLE PRECISION;
cast(HPQ as DECIMAL) returns DECIMAL;
cast(DECIMAL as HPQ) returns HPQ;
cast(HPQ as NUMERIC) returns NUMERIC;
cast(NUMERIC as HPQ) returns HPQ;
sign(HPQ input) returns HPZ;
abs(HPQ input) returns HPQ;
ceil(HPQ input) returns HPZ;
floor(HPQ input) returns HPZ;
round(HPQ input) returns HPZ;
recip(HPQ input) returns HPQ;
pi(BIGINT precision) returns HPQ;
e(BIGINT precision) returns HPQ;
power(HPQ base, HPQ exponent) returns HPQ;
sqrt(HPQ input) returns HPQ;
nroot(HPZ theroot, HPQ input) returns HPQ;
log10(HPQ input) returns HPQ;
ln(HPQ input) returns HPQ;
log2(HPQ input) returns HPQ;
factorial(HPZ input) returns HPZ;
nCr(HPZ objects, HPZ selectionSize) returns HPZ;
nPr(HPZ objects, HPZ selectionSize) returns HPZ;
degrees(HPQ input) returns HPQ;
radians(HPQ input) returns HPQ;
sind(HPQ input) returns HPQ;
cosd(HPQ input) returns HPQ;
tand(HPQ input) returns HPQ;
asind(HPQ input) returns HPQ;
acosd(HPQ input) returns HPQ;
atand(HPQ input) returns HPQ;
sinr(HPQ input) returns HPQ;
cosr(HPQ input) returns HPQ;
tanr(HPQ input) returns HPQ;
asinr(HPQ input) returns HPQ;
acosr(HPQ input) returns HPQ;
atanr(HPQ input) returns HPQ;
The End.