You can subscribe to this list here.
2007 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}
(55) 
_{Oct}
(59) 
_{Nov}
(3) 
_{Dec}
(30) 

2008 
_{Jan}
(59) 
_{Feb}
(22) 
_{Mar}
(55) 
_{Apr}
(4) 
_{May}
(15) 
_{Jun}
(29) 
_{Jul}
(6) 
_{Aug}
(17) 
_{Sep}

_{Oct}
(27) 
_{Nov}
(8) 
_{Dec}
(14) 
2009 
_{Jan}
(6) 
_{Feb}
(26) 
_{Mar}
(48) 
_{Apr}
(11) 
_{May}
(3) 
_{Jun}
(20) 
_{Jul}
(28) 
_{Aug}
(48) 
_{Sep}
(85) 
_{Oct}
(34) 
_{Nov}
(23) 
_{Dec}
(65) 
2010 
_{Jan}
(68) 
_{Feb}
(46) 
_{Mar}
(105) 
_{Apr}
(74) 
_{May}
(167) 
_{Jun}
(118) 
_{Jul}
(179) 
_{Aug}
(170) 
_{Sep}
(513) 
_{Oct}
(113) 
_{Nov}
(41) 
_{Dec}
(52) 
2011 
_{Jan}
(59) 
_{Feb}
(102) 
_{Mar}
(110) 
_{Apr}
(197) 
_{May}
(123) 
_{Jun}
(91) 
_{Jul}
(195) 
_{Aug}
(209) 
_{Sep}
(233) 
_{Oct}
(112) 
_{Nov}
(241) 
_{Dec}
(86) 
2012 
_{Jan}
(138) 
_{Feb}
(151) 
_{Mar}
(326) 
_{Apr}
(154) 
_{May}
(278) 
_{Jun}
(230) 
_{Jul}
(311) 
_{Aug}
(327) 
_{Sep}
(194) 
_{Oct}
(139) 
_{Nov}
(243) 
_{Dec}
(141) 
2013 
_{Jan}
(169) 
_{Feb}
(90) 
_{Mar}
(187) 
_{Apr}
(228) 
_{May}
(150) 
_{Jun}
(328) 
_{Jul}
(287) 
_{Aug}
(199) 
_{Sep}
(288) 
_{Oct}
(199) 
_{Nov}
(310) 
_{Dec}
(214) 
2014 
_{Jan}
(166) 
_{Feb}
(66) 
_{Mar}
(90) 
_{Apr}
(166) 
_{May}
(166) 
_{Jun}
(99) 
_{Jul}
(120) 
_{Aug}
(139) 
_{Sep}
(62) 
_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 






1
(5) 
2
(3) 
3
(5) 
4
(8) 
5
(1) 
6
(1) 
7

8
(2) 
9
(11) 
10
(22) 
11
(16) 
12
(4) 
13
(1) 
14
(7) 
15
(6) 
16
(13) 
17

18
(6) 
19
(4) 
20
(1) 
21
(2) 
22
(15) 
23
(1) 
24

25
(2) 
26
(2) 
27
(16) 
28
(12) 
29
(22) 
30
(9) 
From: James K Beard <beardjamesk@ve...>  20110403 14:08:03

A quick glance through the document seems to tell us that the decimal arithmetic will incorporate checks to ensure that any rounding in binary floating point does not compromise the accuracy of the final decimal result. That’s pretty much what I was suggesting in my message of March 26 below. The JTC1 Committee is apparently considering putting it in the standard. This could be a very good thing for people porting code from COBOL, and useful for new applications in environments previously restricted to COBOL such as the banking and accounting industries. James K Beard From: Jim Michaels [mailto:jmichae3@...] Sent: Sunday, April 03, 2011 2:06 AM To: mingww64public@... Subject: Re: [Mingww64public] mingww64 Decimal Floating Point math take a gander at this.... decimal floating point math is possibly coming to TR2. http://www.openstd.org/JTC1/SC22/WG21/docs/papers/2009/n2849.pdf _____ From: James K Beard <beardjamesk@...> To: Jim Michaels <jmichae3@...>; mingww64public@... Sent: Sat, March 26, 2011 11:33:09 AM Subject: RE: [Mingww64public] mingww64 Decimal Floating Point math If the mantissa has at least seven or eight bits below the binary point, equivalence to the cents level is achieved by xy < 0.005; the halfcent is x’0.0147ae’ which can be done in any decent language. If you do it as a procedure, you can do magnitude checks to ensure that the magnitude of the currency quantity doesn’t bump the exponent too high, possibly with a check on magnitude of the binary exponent. Another aspect to consider is that rounding binary values to cents will do exactly the same thing. Every time a financial program produces output for any people to read this is done as part of the formatting for I/O. But I think that’s almost all moot. The only times we will need to go to the library are for transcendental functions (trigonometric, log, exponential, and other scientific and mathematical functions). Exponentiation to integers is usually done by computing an array of squared quantities and using the bit pattern of the exponent to roll them up into the result. For realworld financial computation where binary floating point is an issue, we are pretty much limited to exponentiations used in interest calculations, which are probably best done in binary floating point and rounded to the nearest cent. Look rationally at alternatives to doing this in decimal and binary arithmetic and you will be dealing with the reasons that all modern computers are binary, in their cores. On the other hand, if you want to do a mathematical library in baseten arithmetic, all you need to worry about is executing them vast quantities of times because practical problems will require this type of computation a limited number of times, so speed isn’t a problem, and, in the age of terabyte HDs, space isn’t either. This may be what someone wants, but you will never make a decisive case for such a library in the context of numerical analysis and computer science. James K Beard From: Jim Michaels [mailto:jmichae3@...] Sent: Friday, March 25, 2011 4:16 PM To: mingww64public@... Subject: Re: [Mingww64public] mingww64 Decimal Floating Point math I can add this: If you are doing accounting apps or anything dealing with money, or doing comparisons with relops, you want decimal, not fp. otherwise, you have problems adding .01+.01+.01, 0 not being +0 and thus you can't compare or something like that, etc. fp is NOT for comparison ops. decimal you can. _____ From: James K Beard <beardjamesk@...> To: JonY <jon_y@...>; Kai Tietz <ktietz70@...> Cc: mingww64public@... Sent: Wed, March 23, 2011 10:40:30 PM Subject: Re: [Mingww64public] mingww64 Decimal Floating Point math It may not be as bad as you might think because trigonometric functions become invalid for arguments with magnitude defined by the mantissa length, not the exponent, and the exponent is removed as part of the process in log and exponentiation operations. James K Beard Original Message From: Jon [mailto:10walls@...] On Behalf Of JonY Sent: Wednesday, March 23, 2011 9:20 PM To: Kai Tietz Cc: jkbeard1@...; mingww64public@...; James K Beard Subject: Re: [Mingww64public] mingww64 Decimal Floating Point math BEGIN PGP SIGNED MESSAGE Hash: SHA1 On 3/24/2011 02:29, Kai Tietz wrote: > 2011/3/23 James K Beard <beardjamesk@...>: >> You don't need to go to BCD to convert DFP to IEEE (regular) floating point. >> A single arithmetic operation directly in DFP will exceed what you do >> to convert to IEEE floating point. I would use double precision for >> anything up to 12 decimals of accuracy, 80bit for another three, and >> simply incorporate the quad precision libraries with credit (or by >> reference, if differences in licensing are a problem) for distribution. >> >> Anything other than binary representation will be less efficient in >> terms of accuracy provided by a given number of bits. By >> illustration, base 10 requires four bits, but provides only 3.32 bits >> (log2(10)) per digit of accuracy. The only relief from this >> fundamental fact is use of less bits for the exponent, and in IEEE >> floating point the size of the exponent field is minimized just about >> to the point of diminishing returns (problems requiring workaround in >> areas such as determinants, series and large >> polynomials) to begin with. >> >> James K Beard > > Well, DFP <> IEEE conversion is already present in libgcc. So you > shouldn't need here any special implementation. I would suggest that > you are using for 32bit and 64bit DFP the double type, and AFAICS > the 80bit IEEE should be wide enough for the 128bit DFP. How big is > its exponent specified? Interesting might be the rounding. > > Regards, > Kai > Long doubles extended precision go up to 4963 (base 10) in exponent, while DECIMAL128 go up 6144, this is assuming I didn't get the docs wrong. BEGIN PGP SIGNATURE Version: GnuPG v2.0.16 (MingW32) iEYEARECAAYFAk2KnFEACgkQp56AKe10wHf30ACeKpD4YvTTR8k8pSO9njpa9pVQ /B8An1s6P6yNV1UcTdIe6evB6VrVz9IV =hBNq END PGP SIGNATURE  Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology  will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/inteldev2devmar _______________________________________________ Mingww64public mailing list Mingww64public@... https://lists.sourceforge.net/lists/listinfo/mingww64public 
From: Jim Michaels <jmichae3@ya...>  20110403 07:17:54

just from scanning a few things related to BOOST and TR2's documents, I got this:  http://www.openstd.org/JTC1/SC22/WG21/docs/papers/2009/n2849.pdf http://www.boost.org/doc/libs/1_31_0/tools/build/v1/mingwtools.html  BOOST is supposed to be integrated into TR2. for now it is a separate library.  decimal floating point is possibly coming to TR2.  numeric_traits in TR2 if it isn't already there I should have put these both into one email. I have posted a lot lately, unless I am responded to, I will shut up for a while. have a look at page 3. floating point is going to change not only in software but in hardware implementation as well. it is going to become more stringent. I think this may mean that if the processors aren't already out on the market, there will be a shift (no pun intended) in the implementation of the FPU (Floating Point Unit) portion of the processor. new hardware means a new code base.  Jim Michaels jmichae3@... JimM@... http://JimsComputerRepairandWebDesign.com http://JesusnJim.com (my personal site, has software) http://DoLifeComputers.JesusnJim.com (group which I lead)  Computer memory/disk size measurements: [KB KiB] [MB MiB] [GB GiB] [TB TiB] [10^3B=1,000B=1KB][2^10B=1,024B=1KiB] [10^6B=1,000,000B=1MB][2^20B=1,048,576B=1MiB] [10^9B=1,000,000,000B=1GB][2^30B=1,073,741,824B=1GiB] [10^12B=1,000,000,000,000B=1TB][2^40B=1,099,511,627,776B=1TiB] Note: disk size is measured in MB, GB, or TB, not in MiB, GiB, or TiB. computer memory (RAM) is measured in MiB and GiB. 
From: Jim Michaels <jmichae3@ya...>  20110403 06:06:05

take a gander at this.... decimal floating point math is possibly coming to TR2. http://www.openstd.org/JTC1/SC22/WG21/docs/papers/2009/n2849.pdf ________________________________ From: James K Beard <beardjamesk@...> To: Jim Michaels <jmichae3@...>; mingww64public@... Sent: Sat, March 26, 2011 11:33:09 AM Subject: RE: [Mingww64public] mingww64 Decimal Floating Point math If the mantissa has at least seven or eight bits below the binary point, equivalence to the cents level is achieved by xy < 0.005; the halfcent is x’0.0147ae’ which can be done in any decent language. If you do it as a procedure, you can do magnitude checks to ensure that the magnitude of the currency quantity doesn’t bump the exponent too high, possibly with a check on magnitude of the binary exponent. Another aspect to consider is that rounding binary values to cents will do exactly the same thing. Every time a financial program produces output for any people to read this is done as part of the formatting for I/O. But I think that’s almost all moot. The only times we will need to go to the library are for transcendental functions (trigonometric, log, exponential, and other scientific and mathematical functions). Exponentiation to integers is usually done by computing an array of squared quantities and using the bit pattern of the exponent to roll them up into the result. For realworld financial computation where binary floating point is an issue, we are pretty much limited to exponentiations used in interest calculations, which are probably best done in binary floating point and rounded to the nearest cent. Look rationally at alternatives to doing this in decimal and binary arithmetic and you will be dealing with the reasons that all modern computers are binary, in their cores. On the other hand, if you want to do a mathematical library in baseten arithmetic, all you need to worry about is executing them vast quantities of times because practical problems will require this type of computation a limited number of times, so speed isn’t a problem, and, in the age of terabyte HDs, space isn’t either. This may be what someone wants, but you will never make a decisive case for such a library in the context of numerical analysis and computer science. James K Beard From:Jim Michaels [mailto:jmichae3@...] Sent: Friday, March 25, 2011 4:16 PM To: mingww64public@... Subject: Re: [Mingww64public] mingww64 Decimal Floating Point math I can add this: If you are doing accounting apps or anything dealing with money, or doing comparisons with relops, you want decimal, not fp. otherwise, you have problems adding .01+.01+.01, 0 not being +0 and thus you can't compare or something like that, etc. fp is NOT for comparison ops. decimal you can. ________________________________ From:James K Beard <beardjamesk@...> To: JonY <jon_y@...>; Kai Tietz <ktietz70@...> Cc: mingww64public@... Sent: Wed, March 23, 2011 10:40:30 PM Subject: Re: [Mingww64public] mingww64 Decimal Floating Point math It may not be as bad as you might think because trigonometric functions become invalid for arguments with magnitude defined by the mantissa length, not the exponent, and the exponent is removed as part of the process in log and exponentiation operations. James K Beard Original Message From: Jon [mailto:10walls@...] On Behalf Of JonY Sent: Wednesday, March 23, 2011 9:20 PM To: Kai Tietz Cc: jkbeard1@...; mingww64public@...; James K Beard Subject: Re: [Mingww64public] mingww64 Decimal Floating Point math BEGIN PGP SIGNED MESSAGE Hash: SHA1 On 3/24/2011 02:29, Kai Tietz wrote: > 2011/3/23 James K Beard <beardjamesk@...>: >> You don't need to go to BCD to convert DFP to IEEE (regular) floating point. >> A single arithmetic operation directly in DFP will exceed what you do >> to convert to IEEE floating point. I would use double precision for >> anything up to 12 decimals of accuracy, 80bit for another three, and >> simply incorporate the quad precision libraries with credit (or by >> reference, if differences in licensing are a problem) for distribution. >> >> Anything other than binary representation will be less efficient in >> terms of accuracy provided by a given number of bits. By >> illustration, base 10 requires four bits, but provides only 3.32 bits >> (log2(10)) per digit of accuracy. The only relief from this >> fundamental fact is use of less bits for the exponent, and in IEEE >> floating point the size of the exponent field is minimized just about >> to the point of diminishing returns (problems requiring workaround in >> areas such as determinants, series and large >> polynomials) to begin with. >> >> James K Beard > > Well, DFP <> IEEE conversion is already present in libgcc. So you > shouldn't need here any special implementation. I would suggest that > you are using for 32bit and 64bit DFP the double type, and AFAICS > the 80bit IEEE should be wide enough for the 128bit DFP. How big is > its exponent specified? Interesting might be the rounding. > > Regards, > Kai > Long doubles extended precision go up to 4963 (base 10) in exponent, while DECIMAL128 go up 6144, this is assuming I didn't get the docs wrong. BEGIN PGP SIGNATURE Version: GnuPG v2.0.16 (MingW32) iEYEARECAAYFAk2KnFEACgkQp56AKe10wHf30ACeKpD4YvTTR8k8pSO9njpa9pVQ /B8An1s6P6yNV1UcTdIe6evB6VrVz9IV =hBNq END PGP SIGNATURE  Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology  will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/inteldev2devmar _______________________________________________ Mingww64public mailing list Mingww64public@... https://lists.sourceforge.net/lists/listinfo/mingww64public 
From: Jim Michaels <jmichae3@ya...>  20110403 06:04:14

I could see that you were putting some effort in to put in boost. thanks for starting. It's I think a muchneeded compiler feature.  Jim Michaels jmichae3@... JimM@... http://JimsComputerRepairandWebDesign.com http://JesusnJim.com (my personal site, has software) http://DoLifeComputers.JesusnJim.com (group which I lead)  Computer memory/disk size measurements: [KB KiB] [MB MiB] [GB GiB] [TB TiB] [10^3B=1,000B=1KB][2^10B=1,024B=1KiB] [10^6B=1,000,000B=1MB][2^20B=1,048,576B=1MiB] [10^9B=1,000,000,000B=1GB][2^30B=1,073,741,824B=1GiB] [10^12B=1,000,000,000,000B=1TB][2^40B=1,099,511,627,776B=1TiB] Note: disk size is measured in MB, GB, or TB, not in MiB, GiB, or TiB. computer memory (RAM) is measured in MiB and GiB. 
From: Jim Michaels <jmichae3@ya...>  20110403 04:53:11

http://stackoverflow.com/questions/11635/caseinsensitivestringcomparisoninc that's a nice suggestion, but I don't see how I can access boost in the sezero compiler. I don't think it's there. it's 4.5.2 20101002 and where boost and algorithms directories and files should be, I see placeholders. I just found this entry too. boost would be a FAR better solution, since I have if I remember right case sensitive and case insensitive compares in my code, and I need to preserve the case of my strings during conversions, and I am unsure if the code example I saw does that. I didn't even see an assignment operator, so I am going to assume that string, basic_string, and this icstring are the same type somehow and that string is not a specialization of basic_string, because right now I am confused by the lack of info. If you read farther down in that post, "The trouble with boost is that you have to link with and depend on boost [I don't care, I need it]. Not easy in some cases (e.g. android). And using char_traits means all your comparisons are case insensitive, which isn't usually what you want. This should suffice. It should be reasonably efficient. Doesn't handle unicode or anything though." I realized this about char_traits when I read the example implementation you see there in the book "The C++ Standard Library" which I have. (same code) the code is copyrighted. is boost in 4.6.0?  Jim Michaels jmichae3@... JimM@... http://JimsComputerRepairandWebDesign.com http://JesusnJim.com (my personal site, has software) http://DoLifeComputers.JesusnJim.com (group which I lead)  Computer memory/disk size measurements: [KB KiB] [MB MiB] [GB GiB] [TB TiB] [10^3B=1,000B=1KB][2^10B=1,024B=1KiB] [10^6B=1,000,000B=1MB][2^20B=1,048,576B=1MiB] [10^9B=1,000,000,000B=1GB][2^30B=1,073,741,824B=1GiB] [10^12B=1,000,000,000,000B=1TB][2^40B=1,099,511,627,776B=1TiB] Note: disk size is measured in MB, GB, or TB, not in MiB, GiB, or TiB. computer memory (RAM) is measured in MiB and GiB. ________________________________ From: Ruben Van Boxem <vanboxem.ruben@...> To: vanboxem.ruben@... Cc: Jim Michaels <jmichae3@...>; jkbeard1@...; mingww64public@... Sent: Thu, March 31, 2011 10:31:35 PM Subject: Re: [Mingww64public] sezero 4.5.2 1002 note: variable tracking size limit exceeded with fvartrackingassignments, retrying without Sorry for the quick followup, but your problem has been previously solved on SO: http://stackoverflow.com/questions/11635/caseinsensitivestringcomparisoninc/2886589#2886589 There are other answers, but this one illustrates a nice c++ style solution. Don't blame Bjarne for missing functionality, because most of the time it's quite easy to get. Op 1 apr. 2011 07:22 schreef "Ruben Van Boxem" <vanboxem.ruben@...> het volgende: > Hi guys, > > I'm just going to throw my thoughts out in the field: > > 1. C++ has a simple way to do case insensitive compares: just use a series > of calls to C's tolower and compare then (assuming nice ASCII contents). > > 2. Ask this question on stackoverflow.com, you're bound to get an answer to > your design problem there. > > Ruben > Op 1 apr. 2011 07:06 schreef "James K Beard" <beardjamesk@...> het > volgende: 