Re: [Gambas-user] About financial program in Gambas
Ricardo Díaz Martín a écrit : Hi to all, I'm use gambas to write ERP applications. At the first, I got the same problem but I decided to use long integer to save currency values. First rigth two digits are always showed to users as decimal values. I'm rewrited all my apps from windows to gambas and they are working now with no problems in customers servers. I allways use a function to show values in controls in app's forms that convert database fields values showed in textboxes whose name started int dbcur (p.e. dbcurVAT) to value div 100 and works with no problems. I use allways the same function to write forms data to database and make the reverse proccess. Hooo, thanks for the ad. Its simple and works Sounds exactly like the commercial about women thin down cream we've got on tv for months (it works!) (sorry, I couldn't resist:) So you're truncating everything to 2 decimals, but as I said VAT (and as a matter of fact almost all french taxes) is *legally* up to 4 decimals; actually only 2 of them are used, but nothing's saying that tomorrow is won't be 3 or 4 really used (especially on those times where our gov morons (pleonasm) are desesperatly looking for money.) BTW, how do you truncate 19.99657? Down to 19.99 or up to 20.00? In my family's company a cent error is worth €100,000 fine... Other PB: most of results could be predictable (as of Nb of decimals), but some can't (ie: 92.95x1.196=111.1682 OR 145x1.196=173.42), maths says decimals should be dN1+dN2=5 but in these cases we only have 4 and 2 because of non-significant right zeroes, so you can't obviously truncate by adding the comma counting 5 from the right. One of the most used manner to get a selling price is to use a coefficient which has many decimals (usually a real), how do you determine where to put the comma in the resultant number?? I see the possibilities, but AFAIK this is a full processor to write based on a complex numbers model, not to mention error possibilities have a tremendous cataclysmic potential in a matter where tax administration will be more than happy to chop your head and piss on your brain (yeah, they're like that here: when they come it is not to search, it is to find; no matter if has real justification or not.) But may be I'm totally mistaking: I always have had PBs with simple things. JY -- God is real, unless declared integer. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] About financial program in Gambas
Jean, You can use numbers of decimal as you want. I you want 4 you only need to divide by 1000. The only you need to decide on before insert data. If you need to add more decimals in future you only have to modify a parameter in your app from 2 to 4 (functions that show from database/write to database currency values must read this values before show/write info) and update your database multiplying cur fields by 100 (to add two digit more of precision) You never need truncate any value if you always use this especial currency type. For example if you set decimals to 4, number 19.99657 is no possible. If you need to get selling prices using four decimal coefficient, define coefficient as a currency type and set your app to use 4 decimal for all currency values I hope this helps you 2009/12/16 Jean-Yves F. Barbier 12u...@gmail.com Ricardo Díaz Martín a écrit : Hi to all, I'm use gambas to write ERP applications. At the first, I got the same problem but I decided to use long integer to save currency values. First rigth two digits are always showed to users as decimal values. I'm rewrited all my apps from windows to gambas and they are working now with no problems in customers servers. I allways use a function to show values in controls in app's forms that convert database fields values showed in textboxes whose name started int dbcur (p.e. dbcurVAT) to value div 100 and works with no problems. I use allways the same function to write forms data to database and make the reverse proccess. Hooo, thanks for the ad. Its simple and works Sounds exactly like the commercial about women thin down cream we've got on tv for months (it works!) (sorry, I couldn't resist:) So you're truncating everything to 2 decimals, but as I said VAT (and as a matter of fact almost all french taxes) is *legally* up to 4 decimals; actually only 2 of them are used, but nothing's saying that tomorrow is won't be 3 or 4 really used (especially on those times where our gov morons (pleonasm) are desesperatly looking for money.) BTW, how do you truncate 19.99657? Down to 19.99 or up to 20.00? In my family's company a cent error is worth €100,000 fine... Other PB: most of results could be predictable (as of Nb of decimals), but some can't (ie: 92.95x1.196=111.1682 OR 145x1.196=173.42), maths says decimals should be dN1+dN2=5 but in these cases we only have 4 and 2 because of non-significant right zeroes, so you can't obviously truncate by adding the comma counting 5 from the right. One of the most used manner to get a selling price is to use a coefficient which has many decimals (usually a real), how do you determine where to put the comma in the resultant number?? I see the possibilities, but AFAIK this is a full processor to write based on a complex numbers model, not to mention error possibilities have a tremendous cataclysmic potential in a matter where tax administration will be more than happy to chop your head and piss on your brain (yeah, they're like that here: when they come it is not to search, it is to find; no matter if has real justification or not.) But may be I'm totally mistaking: I always have had PBs with simple things. JY -- God is real, unless declared integer. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] About financial program in Gambas
For your info only... I always use INT or LONG for accounting and money. So, (here in Canada), $42.87 is 4287 I keep the tax (8%) as a float, therefore 8.25% is 8.25 This is ok for tax because rounding is needed. For example: 4287 * 8.25 = 35367.75 / 100 = 353.6775 add .5 for 5/4 round up down = 354.1775 Plase result into INT var which becomes 354 4287 + 354 = 4641 Using Float for taxes allows for many decimal places. Using 100 for /100 process allows for any currencies where you want more than 2 decimal places. For correct printing without rounding errors, do not do 4287/100. but rather take the STR$(4287), then split the right two off, and place a decimal in that place. Perfect math and exact calculations every single time!!! -Fernando -- Original Message --- From: Ricardo Díaz Martín oceanosoftlapa...@gmail.com To: mailing list for gambas users gambas-user@lists.sourceforge.net Sent: Wed, 16 Dec 2009 10:46:40 + Subject: Re: [Gambas-user] About financial program in Gambas Jean, You can use numbers of decimal as you want. I you want 4 you only need to divide by 1000. The only you need to decide on before insert data. If you need to add more decimals in future you only have to modify a parameter in your app from 2 to 4 (functions that show from database/write to database currency values must read this values before show/write info) and update your database multiplying cur fields by 100 (to add two digit more of precision) You never need truncate any value if you always use this especial currency type. For example if you set decimals to 4, number 19.99657 is no possible. If you need to get selling prices using four decimal coefficient, define coefficient as a currency type and set your app to use 4 decimal for all currency values I hope this helps you 2009/12/16 Jean-Yves F. Barbier 12u...@gmail.com Ricardo Díaz Martín a écrit : Hi to all, I'm use gambas to write ERP applications. At the first, I got the same problem but I decided to use long integer to save currency values. First rigth two digits are always showed to users as decimal values. I'm rewrited all my apps from windows to gambas and they are working now with no problems in customers servers. I allways use a function to show values in controls in app's forms that convert database fields values showed in textboxes whose name started int dbcur (p.e. dbcurVAT) to value div 100 and works with no problems. I use allways the same function to write forms data to database and make the reverse proccess. Hooo, thanks for the ad. Its simple and works Sounds exactly like the commercial about women thin down cream we've got on tv for months (it works!) (sorry, I couldn't resist:) So you're truncating everything to 2 decimals, but as I said VAT (and as a matter of fact almost all french taxes) is *legally* up to 4 decimals; actually only 2 of them are used, but nothing's saying that tomorrow is won't be 3 or 4 really used (especially on those times where our gov morons (pleonasm) are desesperatly looking for money.) BTW, how do you truncate 19.99657? Down to 19.99 or up to 20.00? [WINDOWS-1252?] In my family's company a cent error is worth 100,000 fine... Other PB: most of results could be predictable (as of Nb of decimals), but some can't (ie: 92.95x1.196=111.1682 OR 145x1.196=173.42), maths says decimals should be dN1+dN2=5 but in these cases we only have 4 and 2 because of non-significant right zeroes, so you can't obviously truncate by adding the comma counting 5 from the right. One of the most used manner to get a selling price is to use a coefficient which has many decimals (usually a real), how do you determine where to put the comma in the resultant number?? I see the possibilities, but AFAIK this is a full processor to write based on a complex numbers model, not to mention error possibilities have a tremendous cataclysmic potential in a matter where tax administration will be more than happy to chop your head and piss on your brain (yeah, they're like that here: when they come it is not to search, it is to find; no matter if has real justification or not.) But may be I'm totally mistaking: I always have had PBs with simple things. JY -- God is real, unless declared integer. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] About financial program in Gambas
Sorry - AS for mySQL it also has round() and you use the same as the gambas function. Steven On Wed, 2009-12-16 at 16:13 -0500, nando wrote: For your info only... I always use INT or LONG for accounting and money. So, (here in Canada), $42.87 is 4287 I keep the tax (8%) as a float, therefore 8.25% is 8.25 This is ok for tax because rounding is needed. For example: 4287 * 8.25 = 35367.75 / 100 = 353.6775 add .5 for 5/4 round up down = 354.1775 Plase result into INT var which becomes 354 4287 + 354 = 4641 Using Float for taxes allows for many decimal places. Using 100 for /100 process allows for any currencies where you want more than 2 decimal places. For correct printing without rounding errors, do not do 4287/100. but rather take the STR$(4287), then split the right two off, and place a decimal in that place. Perfect math and exact calculations every single time!!! -Fernando -- Original Message --- From: Ricardo Díaz Martín oceanosoftlapa...@gmail.com To: mailing list for gambas users gambas-user@lists.sourceforge.net Sent: Wed, 16 Dec 2009 10:46:40 + Subject: Re: [Gambas-user] About financial program in Gambas Jean, You can use numbers of decimal as you want. I you want 4 you only need to divide by 1000. The only you need to decide on before insert data. If you need to add more decimals in future you only have to modify a parameter in your app from 2 to 4 (functions that show from database/write to database currency values must read this values before show/write info) and update your database multiplying cur fields by 100 (to add two digit more of precision) You never need truncate any value if you always use this especial currency type. For example if you set decimals to 4, number 19.99657 is no possible. If you need to get selling prices using four decimal coefficient, define coefficient as a currency type and set your app to use 4 decimal for all currency values I hope this helps you 2009/12/16 Jean-Yves F. Barbier 12u...@gmail.com Ricardo Díaz Martín a écrit : Hi to all, I'm use gambas to write ERP applications. At the first, I got the same problem but I decided to use long integer to save currency values. First rigth two digits are always showed to users as decimal values. I'm rewrited all my apps from windows to gambas and they are working now with no problems in customers servers. I allways use a function to show values in controls in app's forms that convert database fields values showed in textboxes whose name started int dbcur (p.e. dbcurVAT) to value div 100 and works with no problems. I use allways the same function to write forms data to database and make the reverse proccess. Hooo, thanks for the ad. Its simple and works Sounds exactly like the commercial about women thin down cream we've got on tv for months (it works!) (sorry, I couldn't resist:) So you're truncating everything to 2 decimals, but as I said VAT (and as a matter of fact almost all french taxes) is *legally* up to 4 decimals; actually only 2 of them are used, but nothing's saying that tomorrow is won't be 3 or 4 really used (especially on those times where our gov morons (pleonasm) are desesperatly looking for money.) BTW, how do you truncate 19.99657? Down to 19.99 or up to 20.00? [WINDOWS-1252?] In my family's company a cent error is worth 100,000 fine... Other PB: most of results could be predictable (as of Nb of decimals), but some can't (ie: 92.95x1.196=111.1682 OR 145x1.196=173.42), maths says decimals should be dN1+dN2=5 but in these cases we only have 4 and 2 because of non-significant right zeroes, so you can't obviously truncate by adding the comma counting 5 from the right. One of the most used manner to get a selling price is to use a coefficient which has many decimals (usually a real), how do you determine where to put the comma in the resultant number?? I see the possibilities, but AFAIK this is a full processor to write based on a complex numbers model, not to mention error possibilities have a tremendous cataclysmic potential in a matter where tax administration will be more than happy to chop your head and piss on your brain (yeah, they're like that here: when they come it is not to search, it is to find; no matter if has real justification or not.) But may be I'm totally mistaking: I always have had PBs with simple things. JY -- God is real, unless declared integer. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer
Re: [Gambas-user] About financial program in Gambas
Just to add my two cents worth, This problem has been around for eons and it does not only apply to Gambas. When I was programming in Access and VB I had the same problem even using the currency type. I just use the Round function Value = Round ( Number [ , Digits ] ) And I use this return variable in my database. This is the only way to make sure that rounding is done right. I found that even with a currency data type it tended to truncate rather than round. By the way you should be able to insert into a stored procedure. I did so in Access. In MySql I found that it has the TRUNCATE() command so you can do this SELECT Truncate( ((YourNumber * 10^dp) + 0.5) / (10^dp) , dp ) *this will round correctly where dp is the number of dp that you need. You will have to check the sql manual to see what command is supported for your database. On Wed, 2009-12-16 at 16:13 -0500, nando wrote: For your info only... I always use INT or LONG for accounting and money. So, (here in Canada), $42.87 is 4287 I keep the tax (8%) as a float, therefore 8.25% is 8.25 This is ok for tax because rounding is needed. For example: 4287 * 8.25 = 35367.75 / 100 = 353.6775 add .5 for 5/4 round up down = 354.1775 Plase result into INT var which becomes 354 4287 + 354 = 4641 Using Float for taxes allows for many decimal places. Using 100 for /100 process allows for any currencies where you want more than 2 decimal places. For correct printing without rounding errors, do not do 4287/100. but rather take the STR$(4287), then split the right two off, and place a decimal in that place. Perfect math and exact calculations every single time!!! -Fernando -- Original Message --- From: Ricardo Díaz Martín oceanosoftlapa...@gmail.com To: mailing list for gambas users gambas-user@lists.sourceforge.net Sent: Wed, 16 Dec 2009 10:46:40 + Subject: Re: [Gambas-user] About financial program in Gambas Jean, You can use numbers of decimal as you want. I you want 4 you only need to divide by 1000. The only you need to decide on before insert data. If you need to add more decimals in future you only have to modify a parameter in your app from 2 to 4 (functions that show from database/write to database currency values must read this values before show/write info) and update your database multiplying cur fields by 100 (to add two digit more of precision) You never need truncate any value if you always use this especial currency type. For example if you set decimals to 4, number 19.99657 is no possible. If you need to get selling prices using four decimal coefficient, define coefficient as a currency type and set your app to use 4 decimal for all currency values I hope this helps you 2009/12/16 Jean-Yves F. Barbier 12u...@gmail.com Ricardo Díaz Martín a écrit : Hi to all, I'm use gambas to write ERP applications. At the first, I got the same problem but I decided to use long integer to save currency values. First rigth two digits are always showed to users as decimal values. I'm rewrited all my apps from windows to gambas and they are working now with no problems in customers servers. I allways use a function to show values in controls in app's forms that convert database fields values showed in textboxes whose name started int dbcur (p.e. dbcurVAT) to value div 100 and works with no problems. I use allways the same function to write forms data to database and make the reverse proccess. Hooo, thanks for the ad. Its simple and works Sounds exactly like the commercial about women thin down cream we've got on tv for months (it works!) (sorry, I couldn't resist:) So you're truncating everything to 2 decimals, but as I said VAT (and as a matter of fact almost all french taxes) is *legally* up to 4 decimals; actually only 2 of them are used, but nothing's saying that tomorrow is won't be 3 or 4 really used (especially on those times where our gov morons (pleonasm) are desesperatly looking for money.) BTW, how do you truncate 19.99657? Down to 19.99 or up to 20.00? [WINDOWS-1252?] In my family's company a cent error is worth 100,000 fine... Other PB: most of results could be predictable (as of Nb of decimals), but some can't (ie: 92.95x1.196=111.1682 OR 145x1.196=173.42), maths says decimals should be dN1+dN2=5 but in these cases we only have 4 and 2 because of non-significant right zeroes, so you can't obviously truncate by adding the comma counting 5 from the right. One of the most used manner to get a selling price is to use a coefficient which has many decimals (usually a real), how do you determine where to put the comma in the resultant number?? I see the possibilities, but AFAIK this is a full processor to write based on a complex numbers model, not to mention error
[Gambas-user] About financial program in Gambas
Wow, what a big talk... I just want to explain a few points. 1) I didn't say that I don't want to implement a currency or fixed decimal datatype in Gambas 3. I just can't. The maximum number of native datatypes has been reached the way the datatype system works. So it needs a good bit of redesign in the interpreter. Think to the datatype conversion functions, that must be able to convert any datatype to any other. Its size is almost proportional to the square of the number of datatypes. All arithmetic functions must deal with all datatypes. And so on... I wanted to keep the interpreter small, so adding these features was never a priority. 2) In some languages, the datatype has a meaning in the way the data in stored in memory *and* in the way the data must be display on the screen. But not in Gambas. This is the reason I don't like declaration of fixed floating point values, that are just integers with a special multiplication and division. 3) Why nobody starts writing a Decimal class whose objects are fixed floating point values, with a lot of financial methods? That beast can be written in Gambas first, and then converted to a C component easily, as no library is needed to perform all the computation. But maybe using a already existing financial library is a better idea then. 4) Floating point values are computed in base 2. And, in base 2, 1/10 is like 1/3 in base 10. You cannot represent it with a finite precision. So: 1.4 - 0.2 = 1.20047684 is perfectly valid with a Single datatype. You get the real value stored in memory. Regards, -- Benoît Minisini -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] About financial program in Gambas
Hi to all, I'm use gambas to write ERP applications. At the first, I got the same problem but I decided to use long integer to save currency values. First rigth two digits are always showed to users as decimal values. I'm rewrited all my apps from windows to gambas and they are working now with no problems in customers servers. I allways use a function to show values in controls in app's forms that convert database fields values showed in textboxes whose name started int dbcur (p.e. dbcurVAT) to value div 100 and works with no problems. I use allways the same function to write forms data to database and make the reverse proccess. Its simple and works 2009/12/15 Benoît Minisini gam...@users.sourceforge.net Wow, what a big talk... I just want to explain a few points. 1) I didn't say that I don't want to implement a currency or fixed decimal datatype in Gambas 3. I just can't. The maximum number of native datatypes has been reached the way the datatype system works. So it needs a good bit of redesign in the interpreter. Think to the datatype conversion functions, that must be able to convert any datatype to any other. Its size is almost proportional to the square of the number of datatypes. All arithmetic functions must deal with all datatypes. And so on... I wanted to keep the interpreter small, so adding these features was never a priority. 2) In some languages, the datatype has a meaning in the way the data in stored in memory *and* in the way the data must be display on the screen. But not in Gambas. This is the reason I don't like declaration of fixed floating point values, that are just integers with a special multiplication and division. 3) Why nobody starts writing a Decimal class whose objects are fixed floating point values, with a lot of financial methods? That beast can be written in Gambas first, and then converted to a C component easily, as no library is needed to perform all the computation. But maybe using a already existing financial library is a better idea then. 4) Floating point values are computed in base 2. And, in base 2, 1/10 is like 1/3 in base 10. You cannot represent it with a finite precision. So: 1.4 - 0.2 = 1.20047684 is perfectly valid with a Single datatype. You get the real value stored in memory. Regards, -- Benoît Minisini -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
