hpgcc decnumber matrix solver call for betatesters
in [HP48]
|
Prev: HP 48gii Keyboard
Next: 50G Cable Survey
From: Gjermund Skailand on 16 Aug 2006 17:17 Hi all I have made a longfloat matrix library for + - * invrt, det, and solver in hpgcc for the hp49g+ and also hp50g I suppose.. It is based on the decNumber library with longfloat numbers. The solver is a standard LU solver ported to hpgcc using decNumber. The interface to the hpgcc is based on textstrings in sysrpl / ml, so it is relatively slow. It is required to have my longfloat library installed. Performance: With digits set to 12 digits, it solves a 10x10 matrix with one right hand side in about 1.6 secs. With 100 digits it solves same system in 2 sec. With 200 digits it solves similar system in about 3 sec. The hp 49g+ solves same system with reals (12 digits only..) in about 1 sec. The memory handling is based on Ingo Blank's help with pointers, so you get proper out-of memory handling. The library seems to be stable, however, it is not straight forward, and I appreciate if somebody could help with beta testing and some C issues, please send an email to gjermund _ skailand @ yahoo no best regards Gjermund Skailand
From: Ville Koskinen on 18 Aug 2006 01:02 Hello, I',m curious, what about performance with really large matrices? Regards, Ville Koskinen Gjermund Skailand wrote: > Hi all > I have made a longfloat matrix library for + - * invrt, det, and solver in > hpgcc for the hp49g+ and also hp50g I suppose.. > > It is based on the decNumber library with longfloat numbers. The solver is a > standard LU solver ported to hpgcc using decNumber. > The interface to the hpgcc is based on textstrings in sysrpl / ml, so it is > relatively slow. It is required to have my longfloat library installed. > > Performance: > With digits set to 12 digits, it solves a 10x10 matrix with one right hand > side in about 1.6 secs. > With 100 digits it solves same system in 2 sec. > With 200 digits it solves similar system in about 3 sec. > > The hp 49g+ solves same system with reals (12 digits only..) in about 1 > sec. > > The memory handling is based on Ingo Blank's help with pointers, so you get > proper out-of memory handling. > > The library seems to be stable, however, it is not straight forward, and I > appreciate if somebody could help with beta testing and some C issues, > please send an email to > gjermund _ skailand @ yahoo no > > > best regards > Gjermund Skailand
From: Veli-Pekka Nousiainen on 18 Aug 2006 03:26 Think about it as this: Calculator free RAM is about 240KB (binary) LastArg is Off, LastStack is Off A C program could use Port 1 RAM for intermediate calculations and for the program and it should do the system solving "in-place" if possible 100x100 matrix needs 10K elements, each 1 nibble eg. 5KB (dec) for each digit 50 digits is about 250KB (dec) which just might fit into the calc A PDA with larger memory should be used instead Linux and Parisse's Xiac-CAS could be enhanced Also a new version of the WinCE will be introduced 2007 Veli-Pekka (from Finland, too) Ville Koskinen wrote: > Hello, > > I',m curious, what about performance with really large matrices? > > Regards, > Ville Koskinen > > Gjermund Skailand wrote: >> Hi all >> I have made a longfloat matrix library for + - * invrt, det, and >> solver in hpgcc for the hp49g+ and also hp50g I suppose.. >> >> It is based on the decNumber library with longfloat numbers. The >> solver is a standard LU solver ported to hpgcc using decNumber. >> The interface to the hpgcc is based on textstrings in sysrpl / ml, >> so it is relatively slow. It is required to have my longfloat >> library installed. >> >> Performance: >> With digits set to 12 digits, it solves a 10x10 matrix with one >> right hand side in about 1.6 secs. >> With 100 digits it solves same system in 2 sec. >> With 200 digits it solves similar system in about 3 sec. >> >> The hp 49g+ solves same system with reals (12 digits only..) in >> about 1 sec. >> >> The memory handling is based on Ingo Blank's help with pointers, so >> you get proper out-of memory handling. >> >> The library seems to be stable, however, it is not straight forward, >> and I appreciate if somebody could help with beta testing and some C >> issues, please send an email to >> gjermund _ skailand @ yahoo no >> >> >> best regards >> Gjermund Skailand
From: Gjermund Skailand on 19 Aug 2006 19:03 Hi, "Veli-Pekka Nousiainen" <DROP_vpn(a)dlc.fi> wrote in message news:NUdFg.6066$aY6.5989(a)reader1.news.jippii.net... > Think about it as this: > > Calculator free RAM is about 240KB (binary) > LastArg is Off, LastStack is Off > > A C program could use Port 1 RAM > for intermediate calculations and for the program > and it should do the system solving "in-place" if possible > > 100x100 matrix needs 10K elements, each 1 nibble > eg. 5KB (dec) for each digit > 50 digits is about 250KB (dec) > which just might fit into the calc > > A PDA with larger memory should be used instead > Linux and Parisse's Xiac-CAS could be enhanced > Also a new version of the WinCE will be introduced 2007 > > Veli-Pekka (from Finland, too) > > Ville Koskinen wrote: >> Hello, >> >> I',m curious, what about performance with really large matrices? >> >> Regards, >> Ville Koskinen depends on what you mean by large matrices with 239 kB free IRAM, 126kB free ERAM, LASTARG, UNDO disabled librarys installed in port 2, Solving Ax=b for x with A[n,n] and one righthandside, converting to standard reals, solving same system with standard HPreals and calculating abs norm of difference. All timings as reported by " MEM DROP << >>TEVAL". n time HPReals D16 abserror 25D 50D 100D 10 1.0s 1.5s 0. 1.6s 1.7s 1.9s 20 5.8s 4.6s 0. 4.7s 5.2s 6.5s 30 15.6s 9.5s 2.0E-11 9.9s 11.5s 15.2s 40 34.3s 16.6s 1.02E-11 17.5s 20.9s err 50 63.3s 26.6s 1.0E-11 28.0s err 60 104.5s 40.0s 1.02E-11 47.2s 70 160.7s 81.7s 1.5E-11 err 80 231.6s err err denote out of memory error. All conversion from hp-land to arm land is done by exploding the matrix on the stack then using non-optimized string conversion functions.This gives a large overhead, as can be seen on the small time differences for different precision. Thus during conversion back to longfloat matrixes you need at least about three times size of the matrix itself. The largest matrix of those above is matrix25 [60,60] (bytes returns 84615) With this matrix on the stack and one exploded and converted to text strings on the stack the free memory reported by MEM is 21.9kB only. In addition you would have the B matrix as well. Thus the hpgcc is really able to utilize the memory. However, the complete matrix object converted to one string object is 104kb, so there can possibly some improvement, espesially if the matrix is saved on the SD-card during conversion. What can also be seen is that multiprecision aritmetic with hpgcc is actually faster than the hp reals. Best regards Gjermund Skailand PS Note to Steen, I have sent you the library, but it may have been stopped in your spam traps.
From: Steen Schmidt on 20 Aug 2006 06:12
Gjermund Skailand wrote: > All conversion from hp-land to arm land is done by exploding the > matrix on the stack then using non-optimized string conversion > functions.This gives a large overhead, as can be seen on the small > time differences for different precision. How about reading and writing it directly from Saturn memory? I do that with zints, and it's very fast. I can send you an example of how to return a zint directly on the stack (I build the Saturn object nibble by nibble) - you can convert this into reading a Saturn object (matrix or array), directly from memory, nibble by nibble. > PS Note to Steen, I have sent you the library, but it may have been > stopped in your spam traps. Thanks, I didn't receive it. Weird. Did you just zip it all up and mail it to me? Cheers, Steen |