Hi Everybody,
I have been serching for algorithms for the date/time unit, and found some webpages by Peter Baum. I have contacted him regarding the copyrigth of the algorithms, in ordre to make them free for the FSF/GNU. Peter Baum would like to donate the algorithms to the FSF/GNU, but where should the webpages with the descriptions, further development ect. be hosted, under GPC home page or a new?
Can any body help with some answares,
Thanks
Klaus F. Ãstergaard
www.capecod.net/~pbaum
Dear Peter,
I am not so familiar with the GNU organisation my self, but I think your idea is good.
To your info I am only programming a couple of hours a week. I am not the normal programmer/"hacker" that sits by his computer several hours a day doing programming just for fun.
But I would like to help building a lib/unit for date and time calculations for the GNU Pascal compiler, as I enjoy using this compiler for small programs.
I will try to contact development list of the pascal development team and hear how to get your algorithms into/under the FSF/GNU, and hosted on a official FSF/GNU homepage.
Kind regards,
Klaus
----- Original Message ----- From: Peter Baum pbaum@capecod.net To: Pernille Bech & Klaus F. Ãstergaard farremosen@mail.tele.dk Sent: Wednesday, March 28, 2001 6:24 PM Subject: an additional thought Re: Date & time calculations
Dear Klaus,
I thought of another possibility - would gnu.org be interested in hosting the documentation for these date algorithms? Then the detailed references within the source code would be back to your organization. That would probably be a more stable location than my current website.
Best Wishes, -Peter
----- Original Message ----- From: Pernille Bech & Klaus F. Ãstergaard farremosen@mail.tele.dk To: pbaum@capecod.net Sent: Tuesday, March 27, 2001 3:03 PM Subject: Date & time calculations
Mr. Peter Baum,
While searching for algorithms for date and time calculations, which I need for a general unit in GNU Pascal, I did find your home page.
My question to you is how much is protected by copyright of the algorithms on your home page? The reason is that should be possible to make the unit as a part of the free software under GNU organisation. www.gnu.org
Thanks for your answer.
Kind regards,
Klaus F. Ãstergaard Farremosen@mail.tele.dk
Dear Klaus,
I would be greatly pleased if the algorithms were offered under the GNU organization which I whole heartedly support. I would only ask that if this is done for any of the algorithms that are not known to be fully documented elsewhere, a reference be made to the date document on my home page and that a request be made in the source code requesting that any copies made include this information. Doing so will assure full and consistent documentation, minimize the propagation of any errors that might be discovered, and provide a central location for any improvements that are made in the future.
Best Wishes, -Peter
Klaus F. Ãstergaard wrote:
I have been serching for algorithms for the date/time unit, and found some webpages by Peter Baum. I have contacted him regarding the copyrigth of the algorithms, in ordre to make them free for the FSF/GNU. Peter Baum would like to donate the algorithms to the FSF/GNU, but where should the webpages with the descriptions, further development ect. be hosted, under GPC home page or a new?
You can certainly get an account of agnes (if you don't have one already) which provides a FTP and HTTP server.
Another possibility (in particular if you need more infrastructure) might be to set it up as a sourceforge project. (Note, I haven't done this myself, but AFAIK, the goal is to make things as easy as possible for the developers, relieving them from most administration work)...
In any case, we can make a link to it on the (new) "Resources" manual chapter and web page (formerly: "Misc" web page).
Frank
Hello everybody: I am planning to use a few PASCAL programs for certain matrix manipulations. In the past, these subroutines were run in Turbo Pascal 6 or 7, with good numerical accuracy. Because the manual says that gpc doesn't pass the "paranoia" test, I have become a bit wary about running them in gpc. All subroutines are written in ISO PASCAL, and perform things such as: Cholesky decomposition, singular value decomposition, inversion etc. All variables are declared either as INTEGER or REAL. If memory serves me, in TP this means a 10-11 decimal digit mantissa for real numbers. Does anybody have experience in this regard? Am I being too "paranoid"? Thanks in advance, Francisco S. Wechsler Anim. Prod. Dep. Coll. Vet. Med. and Anim. Sci. São Paulo St. Univ. C.P. 560 18618-000 Botucatu, SP Brazil
Say no to monopoly: use Gnu-Linux. Message sent through Pine 4.33.
Francisco Wechsler wrote:
Hello everybody: I am planning to use a few PASCAL programs for certain matrix manipulations. In the past, these subroutines were run in Turbo Pascal 6 or 7, with good numerical accuracy. Because the manual says that gpc doesn't pass the "paranoia" test, I have become a bit wary about running them in gpc. All subroutines are written in ISO PASCAL, and perform things such as: Cholesky decomposition, singular value decomposition, inversion etc. All variables are declared either as INTEGER or REAL. If memory serves me, in TP this means a 10-11 decimal digit mantissa for real numbers. Does anybody have experience in this regard? Am I being too "paranoid"?
I have only experience with gpc under djgpp (i.e. DOS). Djgpp has no extended precision libc or libm (long double in C, longreal in gpc, extended in BP: 10 bytes ), so that sin, cos, tan, exp, ln etc are only in double precision (8 bytes). In some case I had accuracy problems with respect to BP, for which all is computed internally in extended. To circumvent this I used the cephes "long double" library http://people.ne.mediaone.net/moshier/cephes28.zip
and the following import unit:
UNIT libml;
INTERFACE
function sqrt(x:LongestReal):LongestReal; Asmname 'sqrtl'; function exp(x:LongestReal):LongestReal; Asmname 'expl'; function ln(x:LongestReal):LongestReal; Asmname 'logl'; {operator pow(x:LongestReal,i:integer) r:LongestReal; Asmname 'powil';} {operator **(x,y:LongestReal) r:LongestReal; Asmname 'powl';} function sin(x:LongestReal):LongestReal; Asmname 'sinl'; function cos(x:LongestReal):LongestReal; Asmname 'cosl'; function tan(x:LongestReal):LongestReal; Asmname 'tanl'; function asin(x:LongestReal):LongestReal; Asmname 'asinl'; function acos(x:LongestReal):LongestReal; Asmname 'acosl'; function arctan(x:LongestReal):LongestReal; Asmname 'atanl'; function sinh(x:LongestReal):LongestReal; Asmname 'sinhl'; function cosh(x:LongestReal):LongestReal; Asmname 'coshl'; function tanh(x:LongestReal):LongestReal; Asmname 'tanhl'; function asinh(x:LongestReal):LongestReal; Asmname 'asinhl'; function acosh(x:LongestReal):LongestReal; Asmname 'acoshl'; function atanh(x:LongestReal):LongestReal; Asmname 'atanhl';
IMPLEMENTATION
{$L ml}
end.
Of course all variables are declared LongReal, identical to LongestReal in gpc/djgpp: to minimalize porting effort you may declare type real = LongReal at the beginning of the import library. (pow and ** are commented out because there are currently problems with redefining these operators in gpc. There is also a bunch of higher trancendental functions in this library which I have never used up to now) This library succeeds in the paranoia test and is superior to BP in all cases I have checked.
Notice that linux has built in long double library, which is used in gpc, but that there is also a cephes library for this case. I have made no check to compare them.
So it is certainly wise to switch to gpc.
Hope this helps
Maurice
On Tue, 3 Apr 2001, Maurice Lombardi wrote:
Francisco Wechsler wrote:
Hello everybody: I am planning to use a few PASCAL programs for certain matrix manipulations. In the past, these subroutines were run in Turbo Pascal 6 or 7, with good numerical accuracy. Because the manual says that gpc doesn't pass the "paranoia" test, I have become a bit wary about running them in gpc. All subroutines are written in ISO PASCAL, and perform things such as: Cholesky decomposition, singular value decomposition, inversion etc. All variables are declared either as INTEGER or REAL. If memory serves me, in TP this means a 10-11 decimal digit mantissa for real numbers. Does anybody have experience in this regard? Am I being too "paranoid"?
Thank you for the various hints that came in during the last 36 hours. I will try running some matrix benchmarks using gpc's libraries. I also intend to give the cephes libraries a try. A report will then be posted. Francisco
Use Gnu-Linux Message sent through Pine 4.33
Francisco Wechsler wrote:
Hello everybody: I am planning to use a few PASCAL programs for certain matrix manipulations. In the past, these subroutines were run in Turbo Pascal 6 or 7, with good numerical accuracy. Because the manual says that gpc doesn't pass the "paranoia" test, I have become a bit wary about running them in gpc. All subroutines are written in ISO PASCAL, and perform things such as: Cholesky decomposition, singular value decomposition, inversion etc. All variables are declared either as INTEGER or REAL. If memory serves me, in TP this means a 10-11 decimal digit mantissa for real numbers. Does anybody have experience in this regard? Am I being too "paranoid"?
I have been using gpc to do calculations where the important step is the diagonalization of some very large matrices. Though for our production problems I currently do this much faster by linking in optimized Lapack/BLAS libraries on an Alpha, running True64, I have no complaints about the accuracy using Intel/Linux systems (using double precision---I can't comment on whether the TP-sized reals are supported).
I'm currently using quite an old version (gpc version 19990118, based on gcc-2.8.1) which works fine for me. Since I have absolutely no interest in language extensions I have not updated since then.
Mike
Mike Reid wrote:
I have been using gpc to do calculations where the important step is the diagonalization of some very large matrices. Though for our production problems I currently do this much faster by linking in optimized Lapack/BLAS libraries on an Alpha, running True64, I have no complaints about the accuracy using Intel/Linux systems (using double precision---I can't comment on whether the TP-sized reals are supported).
They're not (not really, anyway). From the manual (`Real Types'):
type name alternative name GNU C equivalent size in bits (typically) ShortReal Single float 32 Real Double double 64 LongReal Extended long double 80
The "alternative names" are like in BP (and are the same types on IA32). BP's `Comp' is an integer type in GPC (64 bits, like in BP).
BP's 6 byte `Real' is not available in GPC. Since it uses software emulation and is therefore slower than any of the other types on a hardware coprocessor (i.e. anything >= 486DX or 386+387), it's not really not recommendable to use it anymore (not even in BP). To work with legacy data files in this format, GPC has conversion routines RealToBPReal and BPRealToReal in the System unit.
Frank
Hi
BP 7.0 Language Guide lists 5 floating-point types:
type range significant size digits bytes -39 38 Real 2.9 x 10 .. 1.7 x 10 11-12 8
-45 38 Single 1.5 x 10 .. 3.4 x 10 7-8 4
-324 308 Double 5.0 x 10 .. 1.7 x 10 15-16 8
-4932 3932 Extended 3.4 x 10 .. 1.1 x 10 19-20 10
63 63 Comp -2 + 1 .. 2 + 1 19-20 8
(note: their book lists comp as a floating-point type. to me it looks like a signed 64 bit integer.)
*****************
glibc-2.1.3 lists support for 3 floating-point types:
DoubleWord ( 64 bits ) TripleWord ( 96 bits ) QuadWord (128 bits )
Hope this helps Russ
4932 oops: Extended should read ".. 1.1 x 10 "
sorry
Russ Whitaker wrote:
BP 7.0 Language Guide lists 5 floating-point types:
[...]
63 63Comp -2 + 1 .. 2 + 1 19-20 8
(note: their book lists comp as a floating-point type. to me it looks like a signed 64 bit integer.)
It is (technically) an Integer, but BP treats it like FP. Quite crazy, IMHO (maybe they were too lazy to write code to handle such values in the compiler -- e.g., in constant expressions) or the built-in integer operations (e.g. `mod' which doesn't exist in FP)...
glibc-2.1.3 lists support for 3 floating-point types:
DoubleWord ( 64 bits ) TripleWord ( 96 bits ) QuadWord (128 bits )
Really? This must be software emulation then, since (on IA32 and many other processors), only the last one is supported by the FP hardware.
Where did you find out about it (didn't see it on a quick glance in the manual)?
Frank
On Wed, 4 Apr 2001, Frank Heckenbach wrote:
Russ Whitaker wrote:
glibc-2.1.3 lists support for 3 floating-point types:
DoubleWord ( 64 bits ) TripleWord ( 96 bits ) QuadWord (128 bits )
Really? This must be software emulation then, since (on IA32 and many other processors), only the last one is supported by the FP hardware.
Where did you find out about it (didn't see it on a quick glance in the manual)?
Don't remember *exactly* where I saw it, but here's two excerpts that should do the trick:
from libc.info: " File: libc.info, Node: Mathematics, Next: Arithmetic, Prev: Low-Level Terminal Interface, Up: Top
Mathematics ***********
This chapter contains information about functions for performing mathematical computations, such as trigonometric functions. Most of these functions have prototypes declared in the header file `math.h'. The complex-valued functions are defined in `complex.h'.
All mathematical functions which take a floating-point argument have three variants, one each for `double', `float', and `long double' arguments. The `double' versions are mostly defined in ISO C 89. The `float' and `long double' versions are from the numeric extensions to C included in ISO C 9X.
Which of the three versions of a function should be used depends on the situation. For most calculations, the `float' functions are the fastest. On the other hand, the `long double' functions have the highest precision. `double' is somewhere in between. It is usually wise to pick the narrowest type that can accommodate your data. Not all machines have a distinct `long double' type; it may be the same as `double'. "
( I think the order should be 'float', 'double', and 'long double' )
from glibc-2.1.3/math/math.h:
" /* Some useful constants. */
[..]
# define M_PI 3.14159265358979323846 /* pi */
/* The above constants are not adequate for computation using `long double's. Therefore we provide as an extension constants with similar names as a GNU extension. Provide enough digits for the 128-bit IEEE quad. */
#ifdef __USE_GNU
[..]
# define M_PIl 3.1415926535897932384626433832795029L /* pi */
[..]
#endif "
Hope this helps Russ
Russ Whitaker wrote:
On Wed, 4 Apr 2001, Frank Heckenbach wrote:
Russ Whitaker wrote:
glibc-2.1.3 lists support for 3 floating-point types:
DoubleWord ( 64 bits ) TripleWord ( 96 bits ) QuadWord (128 bits )
Really? This must be software emulation then, since (on IA32 and many other processors), only the last one is supported by the FP hardware.
Where did you find out about it (didn't see it on a quick glance in the manual)?
Don't remember *exactly* where I saw it, but here's two excerpts that should do the trick:
All mathematical functions which take a floating-point argument have three variants, one each for `double', `float', and `long double' arguments. The `double' versions are mostly defined in ISO C 89. The `float' and `long double' versions are from the numeric extensions to C included in ISO C 9X.
Which of the three versions of a function should be used depends on the situation. For most calculations, the `float' functions are the fastest. On the other hand, the `long double' functions have the highest precision. `double' is somewhere in between. It is usually wise to pick the narrowest type that can accommodate your data. Not all machines have a distinct `long double' type; it may be the same as `double'.
This is what I know and which is the same as for GPC (with float = Single). However, it doesn't mention the type sizes you gave, except for the following quote:
/* The above constants are not adequate for computation using `long double's. Therefore we provide as an extension constants with similar names as a GNU extension. Provide enough digits for the 128-bit IEEE quad. */
But AFAIUI, it only means that the (long double version of) the constant pi is defined with enough decimal digits for systems where long double is 128 bits, and does not imply that it actually has this size on any given processor (like 80 bits on IA32).
Frank
Hi
try this: sizes.c
#include <stdio.h> main() { printf("\ttype sizes:\n"); printf("char\tint\tlong\tfloat\tdouble\tlong double\n"); printf("%3d\t%3d\t%3d\t%3d\t%3d\t%3d\n", sizeof( char ), sizeof( int ), sizeof( long ), sizeof( float ), sizeof( double ), sizeof( long double ) ); }
results here:
type sizes: char int long float double long double 1 4 4 4 8 12
hope this helps Russ
Russ Whitaker wrote:
Hi
try this: sizes.c
#include <stdio.h> main() { printf("\ttype sizes:\n"); printf("char\tint\tlong\tfloat\tdouble\tlong double\n"); printf("%3d\t%3d\t%3d\t%3d\t%3d\t%3d\n", sizeof( char ), sizeof( int ), sizeof( long ), sizeof( float ), sizeof( double ), sizeof( long double ) ); }
results here:
type sizes: char int long float double long double 1 4 4 4 8 12
Yes, that's what I've expected on IA32.
I'm not sure what we're aguing about, or if we are arguing about anything. I think we agree on that. ;-)
Frank
On Thu, 5 Apr 2001, Frank Heckenbach wrote:
Russ Whitaker wrote:
Hi
try this: sizes.c
#include <stdio.h> main() { printf("\ttype sizes:\n"); printf("char\tint\tlong\tfloat\tdouble\tlong double\n"); printf("%3d\t%3d\t%3d\t%3d\t%3d\t%3d\n", sizeof( char ), sizeof( int ), sizeof( long ), sizeof( float ), sizeof( double ), sizeof( long double ) ); }
results here:
type sizes: char int long float double long double 1 4 4 4 8 12
Yes, that's what I've expected on IA32.
I'm not sure what we're aguing about, or if we are arguing about anything. I think we agree on that. ;-)
That's the default settings for gcc and glibc.
In the source for glibc there's a line which sets length double to 12 with a comment that it can be changed to 16.
In "Usuing and Porting GNU CC" page 290: The RTL has a "TFmode" (Tetra Floating, 16 bytes) page 412: Target Description Macros has a "LONG_DOUBLE_TYPE_SIZE" (size in bits)
And the gcc source has a "float-i128.h"
With this in mind downloaded the latest glibc ( 2.2.2 ). Noted that they reccommend gcc-2.95.2.1 which is 2.95.2 with a patch. Didn't have a copy of the patch so tried 2.95.3
Without changing the length of the long double it compiled ok. Unlike gpc the testing is done before installation and also unlike gpc it quit before all the tests were done.
If I can get glibc to compile, test and install correctly will try changing long double to 16 bytes and see what happens. Will post the results.
It seems the more I know, the less I know ;-) Russ
-
Francisco Wechsler -
Frank Heckenbach -
Maurice Lombardi -
Mike Reid -
Pernille Bech & Klaus F. Østergaard -
Russ Whitaker