Re: [fpc-pascal] Super Large Integer Math Calculations

[Bart]

On 7/7/17, nore...@z505.com  wrote:

> For integers beyond 64 bit, or even beyond 32 bit on a 64 bit machine,
> why can't the math be broken down into peices the way a human does it on
> paper, and then theoretically any number can be added and subtracted,
> even if it is beyond 32/64 bit?
>
> Example:
>
> type TSuperLargeInt = string;
>
> var
>i, j: TSuperLargeInt;
>output: TSuperLargeInt;
> begin
>i := '10009';
>j := '10001';
>output := AddLargeInts(i,j);
>writeln(output);
> end.

http://svn.code.sf.net/p/flyingsheep/code/trunk/wtf/ncalc.pp does exactly that
(all dependenies are also found at
http://svn.code.sf.net/p/flyingsheep/code/trunk/wtf).

It can handle integers (and only integers) up to 2GB digits with
absolut precision.
It can handle GoogolPlex.

Calculate 9^99 with absolute precision:
29512665430652752148753480226197736314359272517043832886063884637676943433478020332709411004889

Fac(100)?
9332621544394415268169923885626670049071596826438162146859296389521753229915608941463976156518286253697920827223758251185210916864

It's not lightning fast, but there is room for optimization I guess.

Bart
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Super Large Integer Math Calculations

[noreply]

For integers beyond 64 bit, or even beyond 32 bit on a 64 bit machine, 
why can't the math be broken down into peices the way a human does it on 
paper, and then theoretically any number can be added and subtracted, 
even if it is beyond 32/64 bit?


Example:

type TSuperLargeInt = string;

var
  i, j: TSuperLargeInt;
  output: TSuperLargeInt;
begin
  i := '10009';
  j := '10001';
  output := AddLargeInts(i,j);
  writeln(output);
end.

The function AddLargeInts simply breaks the math into peices and adds 9 
plus one, carries the one, then adds 1 plus 1, and writes the total as a 
string,, that the computer can output as a string, instead of an integer 
the cpu can handle directly. Strings allow concatenations of numbers to 
virtually any length (with the limit of the max string length, which is 
quite long) so when you use math to write numbers as strings, the number 
can be written any length you want.


And it doesn't have to be strings that are used, but some compiler magic 
that uses strings internally (concatenating numbers and writing 
numbers). Strings can be used as a prototype to prove the concept 
works... (I can provide a demo if needed).


Am I reinventing something that already exists somewhere in, the Math 
unit, or elsewhere, to have math operations on super large numbers 
beyond 32/64 bit?


This just covers addition/subtraction, which can be broken down into 
small pieces an int32 can easily handle (you are simply doing math from 
0-9 numbers, so its byte sized math!) - multiplication can likely be 
broken down into small pieces too but I haven't thought about it.


Surely someone has already thought of this and it exists somewhere?

To add the two large numbers above, simple write a function that:
 - adds the last number (9) and 1 in the string, and carries any 
remainder

 - adds the second last number, with the remainder, so result is 1
 - adds the third last...
 -  etc..
 - up until the first number (1)
 - write the output result as a concatenated/constructed string (not 
int32)


AFAICT any large number to ridiculous size limits can be added by 
breaking the math into small pieces that 32 bit numbers can handle (or 
rather byte sized numbers actually since you are doing 0-9 math 
addition).


This has got to be reinventing the wheel though: someone must have 
already invented this in Fortran or the math unit, or somewhere...?


And then the question becomes, what math cannot be done, by breaking 
down into small byte sized pieces.


Loops: not sure if these super large integers are any good in loops 
unless you loop an int32 around several times (compiler magic?).


The reason I use a simple case of adding 10009 with 
another number is for simple test case that doesn't require much 
thought.. obviously 9 plus 1 means 10, so you carry the 1. then the rest 
is easy since you skip all the zeros and add the first 1 and 1 = 2. But 
the point is, addition on paper by humans is broken down to 0-9 
additions, so why not a CPU can do this too? Then output the result as a 
concatenated string even if the cpu cannot hold this number directly 
since it is bigger than int32.


Possibly I may be reinventing this:
http://www.delphiforfun.org/Programs/Library/big_integers.htm
Quote "All operations are performed pretty much the way you would do 
them with pencil and paper."


And:
http://rvelthuis.de/programs/bigintegers.html

A compiler could have magic inside it, or a unit could use operator 
overloading, to make it more built in and not use strings, but some 
custom type (maybe implemented as a string underneath, or array of 
bytes). Surely fortran or a number crunching language must have thought 
of this already, or the freepascal Math unit, or some BigInteger unit 
out there already.


Interesting Turing test: can all math be done up until infinity, on an 
int32 computer, if you just implement compiler magic to work around your 
int32 limitation, and break it down to byte sized (or int32 sized) 
pieces...

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Food for thought - language string improvement

[noreply]

On 2017-07-06 09:13, Graeme Geldenhuys wrote:

Ever had a problem like this?  You have some SQL, say:

SELECT Customers.CustomerName, Orders.OrderID
FROM Customers
FULL OUTER JOIN Orders
ON Customers.CustomerID = Orders.CustomerID
ORDER BY Customers.CustomerName;


and you want to add that SQL to the SQL property of a query at
runtime. You end up either having to turn this into a string like
this:

'SELECT Customers.CustomerName, Orders.OrderID' +
'FROM Customers' +
'FULL OUTER JOIN Orders' +
'ON Customers.CustomerID = Orders.CustomerID' +
'ORDER BY Customers.CustomerName;'

or manually in each line like this (oh please NEVER do this!):

FDQuery1.SQL.Add('SELECT Customers.CustomerName, Orders.OrderID');
FDQuery1.SQL.Add('FROM Customers');
FDQuery1.SQL.Add('FULL OUTER JOIN Orders');
FDQuery1.SQL.Add('ON Customers.CustomerID = Orders.CustomerID');
FDQuery1.SQL.Add('ORDER BY Customers.CustomerName;');


Now this has normally not been much of a problem for me, because part
of tiOPF's support tools, there is a tool name tiSQLEditor  that does
bi-directional conversions for you - to and from quoted strings for
SQL. And even straight from/to the clipboard. This tool has been
around for 17+ years. But why must this be a tool problem or a IDE
problem? Why can't the Object Pascal language solve this for us!

[the following part quoted from a online discussion by somebody else -
I fully agree with his thoughts though]

Imagine if FPC had type inference and multi-line strings, neither very
exotic features. The code then becomes:

=
var query := '''SELECT Customers.CustomerName, Orders.OrderID
FROM Customers
FULL OUTER JOIN Orders
ON Customers.CustomerID = Orders.CustomerID
ORDER BY Customers.CustomerName;'''

FDQuery1.SQL.Add(query);
=


Easier to read, easier to edit, no need for a IDE wizard or external 
tools.


Language features like this is what increases productivity. But
unfortunately it seems we all rather rely on a specific tool or IDE to
improve our productivity - thus also locking us into using those tools
only.


Regards,
  Graeme


This multiline string issue also helps with HTML:

s := '' +
   '' +
   '' +
   '' +

Instead it should be a multiline string:

s := '''
  



'''

There is also the backquote character, as an option..
`some string
on multiple
lines`


GoLang has multiline strings that work pretty good. AFAIR php has them 
too, especially for html work - but that is likely because PHP is for 
web programming and needed that feature more than Pascal did, so the 
strong need caused them to implement it more than other langauges.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] If vs case or something else?

[James Richters]

Thank you Sven and Stefan for the advice and examples, I really appreciate it.  
I'll to some time tests with some sample programs and figure out which way to 
go with it.  It seems at first glance that the array of procedures would be 
more complicated, but the more I think about it, the more I think it would 
actually be easier to manage and easier to follow than the insane list of if, 
then, else statements, and also easier to manage than a huge long case 
statement, I do have several other conditional statements within the big long 
if then else structure and sometime I mess up the entire thing by misplacing an 
end, or leaving one out...  this would never be a problem with the array of 
procedures as the conditional statements inside the procedures would be well 
defined as they would not be mixed in with a huge list of if statements, and I 
might be able to combine many of the procedures and just pass them related 
arguments.  It might also help organization with Units.  Also thanks to Ched 
for the idea using a case statement on just the first character in a string 
then smaller case statements within that.  I do have another situation where I 
needed to use string input and figure out what to do based on the string value 
and it seems this would save a lot of time.

James

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal