[Gambas-user] Financial program

[Ron_1st]

On Monday 14 December 2009, Jean-Yves F. Barbier wrote:
> Benoît Minisini a écrit :
> ...
> > I think you are mixing a lot of different things:
> > 
> > - When storing a amount of money in memory, you store it in a Long integer in 
> > 1/10th of cents. For example, storing 1234,56€ will be stored as 123456
> 
> I'm gonna test that, but it implies more load of the DB server side to
> convert from one format to the other.

It is not a matter of the DB server to calculate.
Its the presentation only, the matter of the frontend program.
Adding integers a amount in 1/10th of cents stored is more quick then
adding floating point numbers that must be handled to and back from the co-processor. 

In fact your gambas program does not use that co-proc but a library to do
the job in software in most cases. 
Only special programs handle this arithmetic direct to the co-proc.


> 
> > - When displaying an amount of money, you use Format$(), or your own function.
> > 
> > - When getting an amount of money from the user, you have to convert a string 
> > into an amount of 1/10th of cents.
> > 
> > - When getting an amount of money from the outside, or exporting an amount of 
> > money to the outside, you must use an standard exchange format based on a 
> > string.
> 
> This is not acceptable: DB must be able to directly process numbers, 
> not to loose 95% of the time to convert a string to a number and
> vice versa (many of my process aren't done by GB but into stored 
> procedures)

A DB server is _just_ losing time if the numbers are in floats and not in integer.
It have to first normalize the numbers before it can do the arithmetics.
And I'm almost on safe that it also _just_ use a slow library instead of the co-proc.

> 
> > So I don't see any problem with that. Why are you talking about telephone 
> > seconds? We are talking about money, aren't we? Or there is something I didn't 
> > understand?
> 
> Yep, but some amounts can have many more decimals than others (in telephony,
> seconds are usually invoiced with @ least 6 decimals and sometimes 8), so 
> mixing that with other number of decimals isn't easy.

Almost every accounting program works with at least 8 decimals for the fractional part.
Only at the last step, the presentation the rounding to 2 decimals for currency is/should done.

> 
> This is why definable decimals numbers are so important.
> 
I do agree it can be handy to have but there is no absolute need. 
However if we talking about scientific calculations then it would/can 
be a complete different case.

In my view a database is for storage  of information/numbers. 
The handling/calculation of the stored data is the job for the end application.

In my good old times I made some floating point programs on a Z80 CPU.
No support for floats or co-procs available (or acceptable price).
I did just what Benoit suggest and worked with 1/100 of a cent and
at the last step the round to 2 decimals in Dutch Giuilder. 
Later I got a request to implement the co-proc and the customer 
was disapointed about the drop in speed as result.
The max bit size was 16 bit for add/subtract so I had to make
my own routines for 4 times 16 bit wide. Was interesting job to do.


Anyway I feel a bit with your for the request. 
It can make simple apps more ease to develop.

Best regards,

Ron_1st

-- 

111.111111 x 111.111111 = 12345.678987654321