Dear all,
I want to do multiprecision floating point, i.e. I want
to go beyond single precision, double precision and have
quadruple precision, octuple precision and the like,
and possibly with high speed.
What would be the possible alternatives?
Thanks for any help
Mathieu
137  6547  ma************@gmail.com wrote:
Dear all,
I want to do multiprecision floating point, i.e. I want
to go beyond single precision, double precision and have
quadruple precision, octuple precision and the like,
and possibly with high speed.
What would be the possible alternatives?
Thanks for any help
Mathieu
lcc-win proposes qfloat precision (352 bits, 107 digits)
and bignums, that can be arbitrarily big.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique http://www.cs.virginia.edu/~lcc-win32
jacob navia wrote:
ma************@gmail.com wrote:
>Dear all,
I want to do multiprecision floating point, i.e. I want
to go beyond single precision, double precision and have
quadruple precision, octuple precision and the like,
and possibly with high speed.
What would be the possible alternatives?
Thanks for any help
Mathieu
lcc-win proposes qfloat precision (352 bits, 107 digits)
and bignums, that can be arbitrarily big.
A whole three minutes to advertise your compiler, jacob? You're getting
slow.
To the OP: jacob's compiler does indeed provide this feature. If you
simply want to use 352-bit floating point, and only ever envisage using
your code on a platform which jacob implements his compiler on, and are
happy with sticking with one compiler for the lifetime of your project,
then by all means go ahead.
If, on the other hand, you want to write multiple-precision
floating-point as a learning exercise, or you forsee ever needing to use
your code on an implementation other than jacob's, or you simply want to
keep the choice of switching vendors, then it is perfectly possible to
write multiple-precision floating-point in Standard C.
Philip
Philip Potter wrote:
jacob navia wrote:
>ma************@gmail.com wrote:
>>Dear all,
I want to do multiprecision floating point, i.e. I want
to go beyond single precision, double precision and have
quadruple precision, octuple precision and the like,
and possibly with high speed.
What would be the possible alternatives?
Thanks for any help
Mathieu
lcc-win proposes qfloat precision (352 bits, 107 digits)
and bignums, that can be arbitrarily big.
A whole three minutes to advertise your compiler, jacob? You're getting
slow.
To the OP: jacob's compiler does indeed provide this feature. If you
simply want to use 352-bit floating point, and only ever envisage using
your code on a platform which jacob implements his compiler on, and are
happy with sticking with one compiler for the lifetime of your project,
then by all means go ahead.
If, on the other hand, you want to write multiple-precision
floating-point as a learning exercise, or you forsee ever needing to use
your code on an implementation other than jacob's, or you simply want to
keep the choice of switching vendors, then it is perfectly possible to
write multiple-precision floating-point in Standard C.
Philip
If you are interested in portability of your code
you do
#ifdef __LCC__
typedef qfloat FLOAT_TYPE;
#else
typedef long double FLOAT_TYPE;
#endif
and you see that all your float types are declared accordingly.
Within lcc-win qfloat are just another floating point type:
qfloat a = 122333223332323.778887787766656544e7987Q;
Note the "Q" at the end.
In other libraries, the initialization of big numbers is done using
strings, and not at the global level. You may want to do that if you
use another library.
From all the other libraries, most do not fit well within C due to the
standard language lack of operator overloading.
lcc-win offers operator overloading, and it allows integrating
a large number of libraries within it to do what you want.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique http://www.cs.virginia.edu/~lcc-win32
jacob navia wrote:
Philip Potter wrote:
>jacob navia wrote:
>>ma************@gmail.com wrote:
Dear all,
I want to do multiprecision floating point, i.e. I want
to go beyond single precision, double precision and have
quadruple precision, octuple precision and the like,
and possibly with high speed.
What would be the possible alternatives?
Thanks for any help
Mathieu
lcc-win proposes qfloat precision (352 bits, 107 digits)
and bignums, that can be arbitrarily big.
A whole three minutes to advertise your compiler, jacob? You're getting
slow.
To the OP: jacob's compiler does indeed provide this feature. If you
simply want to use 352-bit floating point, and only ever envisage using
your code on a platform which jacob implements his compiler on, and are
happy with sticking with one compiler for the lifetime of your project,
then by all means go ahead.
If, on the other hand, you want to write multiple-precision
floating-point as a learning exercise, or you forsee ever needing to use
your code on an implementation other than jacob's, or you simply want to
keep the choice of switching vendors, then it is perfectly possible to
write multiple-precision floating-point in Standard C.
Philip
If you are interested in portability of your code
you do
#ifdef __LCC__
typedef qfloat FLOAT_TYPE;
#else
typedef long double FLOAT_TYPE;
#endif
and you see that all your float types are declared accordingly.
This only provides portability to implementations where 'long double'
has the required precision. These are remarkably few.
Within lcc-win qfloat are just another floating point type:
qfloat a = 122333223332323.778887787766656544e7987Q;
Note the "Q" at the end.
In other libraries, the initialization of big numbers is done using
strings, and not at the global level. You may want to do that if you
use another library.
That is because those are libraries, whereas qfloat is a language
extension, which adds to the C syntax - something libraries cannot do.
>
From all the other libraries, most do not fit well within C due to the
standard language lack of operator overloading.
lcc-win offers operator overloading, and it allows integrating
a large number of libraries within it to do what you want.
And for this reason it may be difficult to port a qfloat program to
another platform.
I have to say, I actually agree that operator overloading provides a
nicer interface for dealing with floating-point numbers (or complex, or
fixed-point, or whatever); but C doesn't allow operator overloading, so
if you want your program to be C, you must eschew it. ma************@gmail.com wrote:
Dear all,
I want to do multiprecision floating point, i.e. I want
to go beyond single precision, double precision and have
quadruple precision, octuple precision and the like,
and possibly with high speed.
What would be the possible alternatives?
Thanks for any help
If you can, think about using tested existing packages instead of
writing yet another implementation. Something like GMP is a good
candidate:
<http://gmplib.org/>
You compiler might also offer extended precision types as an extension.
Coding a MP library is not too difficult but coding a _good_ one is.
Often the low level arithmetic routines have to be done in optimised
assembler and rewritten for each target.
santosh wrote:
ma************@gmail.com wrote:
>Dear all,
I want to do multiprecision floating point, i.e. I want
to go beyond single precision, double precision and have
quadruple precision, octuple precision and the like,
and possibly with high speed.
What would be the possible alternatives?
Thanks for any help
If you can, think about using tested existing packages instead of
writing yet another implementation. Something like GMP is a good
candidate:
<http://gmplib.org/>
You compiler might also offer extended precision types as an extension.
Coding a MP library is not too difficult but coding a _good_ one is.
Often the low level arithmetic routines have to be done in optimised
assembler and rewritten for each target.
GMP is without doubt one of the best around, if not the best period.
Its big problem (from a windows user perspective) is that well...
it is very difficult to build under windows. From the site where the
above link points, there is NO mention of windows, nor how to build it
under windows. It uses a lot of machinery available under linux,
specifically m4, autoconf, and all that stuff, and supposes a
gcc makefile, and the gcc toolchain.
I have heard that some people have gotten GMP to build under MSVC, but
there is no hint from that effort in the GMP pages, and as far as I
remember, the efforts are not supported by the GMP team.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique http://www.cs.virginia.edu/~lcc-win32
jacob navia wrote:
santosh wrote:
>ma************@gmail.com wrote:
>>Dear all,
I want to do multiprecision floating point, i.e. I want
to go beyond single precision, double precision and have
quadruple precision, octuple precision and the like,
and possibly with high speed.
What would be the possible alternatives?
Thanks for any help
If you can, think about using tested existing packages instead of
writing yet another implementation. Something like GMP is a good
candidate:
<http://gmplib.org/>
You compiler might also offer extended precision types as an
extension. Coding a MP library is not too difficult but coding a
_good_ one is. Often the low level arithmetic routines have to be
done in optimised assembler and rewritten for each target.
GMP is without doubt one of the best around, if not the best period.
Its big problem (from a windows user perspective) is that well...
it is very difficult to build under windows. From the site where the
above link points, there is NO mention of windows, nor how to build it
under windows. It uses a lot of machinery available under linux,
specifically m4, autoconf, and all that stuff, and supposes a
gcc makefile, and the gcc toolchain.
I have heard that some people have gotten GMP to build under MSVC, but
there is no hint from that effort in the GMP pages, and as far as I
remember, the efforts are not supported by the GMP team.
MinGW and/or Cygwin might be better candidates for building GMP under
Windows.
The GMP manual has a small amount of information:
<http://gmplib.org/manual/Notes-for-Particular-Systems.html>
jacob navia wrote:
GMP is without doubt one of the best around, if not the best period.
Its big problem (from a windows user perspective) is that well...
it is very difficult to build under windows. From the site where the
above link points, there is NO mention of windows, nor how to build it
under windows. It uses a lot of machinery available under linux,
specifically m4, autoconf, and all that stuff, and supposes a
gcc makefile, and the gcc toolchain.
The whole cruft to build libtoolized packages is available under windows
since *years*.
- mingw+msys, build a dll and use it with MSVC++.
- cygwin, passing "-mno-cygwin" as CFLAGS (to be true, I don't remember
exactly) to the configure script should also build a .dll which can be
used from MSVC++ or Borland C++ or Delphi...
>
I have heard that some people have gotten GMP to build under MSVC, but
there is no hint from that effort in the GMP pages, and as far as I
remember, the efforts are not supported by the GMP team.
A lot of people maintain diffs to allow gmp to build under various
versions of MSVC++. For example: http://fp.gladman.plus.com/computing/gmp4win.htm
Given the the options in existance, it is understandable that the gmp
team isn't bothered with the lack of a configuration that builds right
out the box on MSVC.
--
IYesNo yes=YesNoFactory.getFactoryInstance().YES;
yes.getDescription().equals(array[0].toUpperCase());
Marco Manfredini wrote:
jacob navia wrote:
>GMP is without doubt one of the best around, if not the best period.
Its big problem (from a windows user perspective) is that well...
it is very difficult to build under windows. From the site where the
above link points, there is NO mention of windows, nor how to build it
under windows. It uses a lot of machinery available under linux,
specifically m4, autoconf, and all that stuff, and supposes a
gcc makefile, and the gcc toolchain.
The whole cruft to build libtoolized packages is available under windows
since *years*.
- mingw+msys, build a dll and use it with MSVC++.
- cygwin, passing "-mno-cygwin" as CFLAGS (to be true, I don't remember
exactly) to the configure script should also build a .dll which can be
used from MSVC++ or Borland C++ or Delphi...
>I have heard that some people have gotten GMP to build under MSVC, but
there is no hint from that effort in the GMP pages, and as far as I
remember, the efforts are not supported by the GMP team.
A lot of people maintain diffs to allow gmp to build under various
versions of MSVC++. For example:
http://fp.gladman.plus.com/computing/gmp4win.htm
Given the the options in existance, it is understandable that the gmp
team isn't bothered with the lack of a configuration that builds right
out the box on MSVC.
Thats good information, but if you do not have it, it is difficult to find.
The problem with mingw is that it just doesn't work in 64 bit vista,
and I could not test it at all. There are big installation problems
under 32 bits too.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique http://www.cs.virginia.edu/~lcc-win32
On Nov 28, 8:24 am, mathieu.dut...@gmail.com wrote:
Dear all,
I want to do multiprecision floating point, i.e. I want
to go beyond single precision, double precision and have
quadruple precision, octuple precision and the like,
and possibly with high speed.
What would be the possible alternatives?
http://pari.math.u-bordeaux.fr/benchs/timings-mpfr.html
jacob navia wrote, On 28/11/07 18:50:
Marco Manfredini wrote:
>jacob navia wrote:
>>GMP is without doubt one of the best around, if not the best period.
Its big problem (from a windows user perspective) is that well...
it is very difficult to build under windows. From the site where the
above link points, there is NO mention of windows, nor how to build it
under windows. It uses a lot of machinery available under linux,
specifically m4, autoconf, and all that stuff, and supposes a
gcc makefile, and the gcc toolchain.
The whole cruft to build libtoolized packages is available under windows
since *years*. - mingw+msys, build a dll and use it with MSVC++. -
cygwin, passing "-mno-cygwin" as CFLAGS (to be true, I don't remember
exactly) to the configure script should also build a .dll which can be
used from MSVC++ or Borland C++ or Delphi...
>>I have heard that some people have gotten GMP to build under MSVC, but
there is no hint from that effort in the GMP pages, and as far as I
remember, the efforts are not supported by the GMP team.
A lot of people maintain diffs to allow gmp to build under various
versions of MSVC++. For example:
http://fp.gladman.plus.com/computing/gmp4win.htm
Given the the options in existance, it is understandable that the gmp
team isn't bothered with the lack of a configuration that builds right
out the box on MSVC.
Thats good information, but if you do not have it, it is difficult to find.
That's strange, I typed in "GMP Windows" in Google and got loads of hits
with pre-build versions for Windows (including headers for use with
MSVC++) and build instructions for Windows. The only reason I can think
of for considering it hard to find is to not be aware of Google or the
many other web search engines.
The problem with mingw is that it just doesn't work in 64 bit vista,
and I could not test it at all. There are big installation problems
under 32 bits too.
I've not tried 64 bit Vista, but Cygwin runs fine under 32 bit Vista
(I'm using it on my company notebook a lot) and can build a dll
compatible with MSVC++.
--
Flash Gordon
In article <fi**********@aioe.org ja***@nospam.org writes:
....
ma************@gmail.com wrote:
....
>I want to do multiprecision floating point, i.e. I want
to go beyond single precision, double precision and have
quadruple precision, octuple precision and the like,
and possibly with high speed.
....
lcc-win proposes qfloat precision (352 bits, 107 digits)
and bignums, that can be arbitrarily big.
....
If you are interested in portability of your code
you do
#ifdef __LCC__
typedef qfloat FLOAT_TYPE;
#else
typedef long double FLOAT_TYPE;
#endif
And what do you do with the octuple precision and so on?
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
Dik T. Winter wrote:
In article <fi**********@aioe.orgja***@nospam.org writes:
...
ma************@gmail.com wrote:
...
>I want to do multiprecision floating point, i.e. I want
>to go beyond single precision, double precision and have
>quadruple precision, octuple precision and the like,
>and possibly with high speed.
...
lcc-win proposes qfloat precision (352 bits, 107 digits)
and bignums, that can be arbitrarily big.
...
If you are interested in portability of your code
you do
>
#ifdef __LCC__
typedef qfloat FLOAT_TYPE;
#else
typedef long double FLOAT_TYPE;
#endif
And what do you do with the octuple precision and so on?
You typedef your FLOAT_TYPE to the type you are using in the external
library you are linking with, what else?
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique http://www.cs.virginia.edu/~lcc-win32
In article <fi**********@aioe.org ja***@nospam.org writes:
Dik T. Winter wrote:
....
If you are interested in portability of your code
you do
>
#ifdef __LCC__
typedef qfloat FLOAT_TYPE;
#else
typedef long double FLOAT_TYPE;
#endif
And what do you do with the octuple precision and so on?
You typedef your FLOAT_TYPE to the type you are using in the external
library you are linking with, what else?
And that single typedef solves all discrepancies?
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
This only provides portability to implementations where 'long double'
has the required precision. These are remarkably few.
Yes that is somewhat more what I had in mind.
Actually, the intel fortran compiler version 10 has support for
quadruple precision of IEEE754r.
Does there exist some C compiler supporting quadruple precision?
The wikipedia page says that "long double" can be the 80-bits of
the x86 or sometimes the 128 bits of quadruple precision. What are
those "remarkably few" compilers? Also, how could we interface
fortran and C for quadruple precision?
That's the extend of my problem. I have an existing C library
depending on lapack/blas, which I need to extend to computing
in higher precision, and quadruple might not be enough.
Otherwise, thanks to all and to Jacob for lcc-win, which I did
not knew about. But this work is supposed to be on linux x86
computers. ma************@gmail.com wrote:
>This only provides portability to implementations where 'long double'
has the required precision. These are remarkably few.
Yes that is somewhat more what I had in mind.
Actually, the intel fortran compiler version 10 has support for
quadruple precision of IEEE754r.
Does there exist some C compiler supporting quadruple precision?
The wikipedia page says that "long double" can be the 80-bits of
the x86 or sometimes the 128 bits of quadruple precision. What are
those "remarkably few" compilers? Also, how could we interface
fortran and C for quadruple precision?
Have you investigated the excellent Intel C/C++ compilers? They should
provide 128 bit floating point support.
<http://www.intel.com/cd/software/products/asmo-na/eng/compilers/284132.htm>
That's the extend of my problem. I have an existing C library
depending on lapack/blas, which I need to extend to computing
in higher precision, and quadruple might not be enough.
Then you need something like MPFR.
<http://en.wikipedia.org/wiki/MPFR>
<http://www.mpfr.org/>
Otherwise, thanks to all and to Jacob for lcc-win, which I did
not knew about. But this work is supposed to be on linux x86
computers.
jacob was part way through implementing his lcc-win32 for Linux (x86)
when licensing restrictions forced him to freeze the effort. But he may
be able to still help you out if you can establish a commercial license
with him.
jacob navia wrote:
Dik T. Winter wrote:
>In article <fi**********@aioe.orgja***@nospam.org writes:
> If you are interested in portability of your code
you do
#ifdef __LCC__
typedef qfloat FLOAT_TYPE;
#else
typedef long double FLOAT_TYPE;
#endif
And what do you do with the octuple precision and so on?
You typedef your FLOAT_TYPE to the type you are using in the external
library you are linking with, what else?
Doesn't help with libraries which don't overload operators. So, in fact,
all libraries. ma************@gmail.com wrote:
>This only provides portability to implementations where 'long double'
has the required precision. These are remarkably few.
Yes that is somewhat more what I had in mind.
Actually, the intel fortran compiler version 10 has support for
quadruple precision of IEEE754r.
Does there exist some C compiler supporting quadruple precision?
The wikipedia page says that "long double" can be the 80-bits of
the x86 or sometimes the 128 bits of quadruple precision. What are
those "remarkably few" compilers? Also, how could we interface
fortran and C for quadruple precision?
I was specifically referring to jacob's qfloat precision which he claims
is 352-bits. I presume this is mantissa bits, including the hidden bit,
but I'm not sure. I doubt there are many compilers which provide long
double of this size.
Phil
Philip Potter wrote:
ma************@gmail.com wrote:
>>This only provides portability to implementations where 'long double'
has the required precision. These are remarkably few.
Yes that is somewhat more what I had in mind.
Actually, the intel fortran compiler version 10 has support for
quadruple precision of IEEE754r.
Does there exist some C compiler supporting quadruple precision?
The wikipedia page says that "long double" can be the 80-bits of
the x86 or sometimes the 128 bits of quadruple precision. What are
those "remarkably few" compilers? Also, how could we interface
fortran and C for quadruple precision?
I was specifically referring to jacob's qfloat precision which he claims
is 352-bits. I presume this is mantissa bits, including the hidden bit,
but I'm not sure. I doubt there are many compilers which provide long
double of this size.
Phil
This is mantissa bits. Gives around 107 decimal digits...
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique http://www.cs.virginia.edu/~lcc-win32
Philip Potter wrote:
ma************@gmail.com wrote:
.... snip ...
>
>Does there exist some C compiler supporting quadruple precision?
The wikipedia page says that "long double" can be the 80-bits of
the x86 or sometimes the 128 bits of quadruple precision. What are
those "remarkably few" compilers? Also, how could we interface
fortran and C for quadruple precision?
I was specifically referring to jacob's qfloat precision which he
claims is 352-bits. I presume this is mantissa bits, including the
hidden bit, but I'm not sure. I doubt there are many compilers
which provide long double of this size.
Those are off topic here, where we deal only with standard C. Try
comp.programming and/or comp.compilers.lcc.
--
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>
Try the download section.
--
Posted via a free Usenet account from http://www.teranews.com
CBFalconer wrote:
Philip Potter wrote:
>ma************@gmail.com wrote:
... snip ...
>>Does there exist some C compiler supporting quadruple precision?
The wikipedia page says that "long double" can be the 80-bits of
the x86 or sometimes the 128 bits of quadruple precision. What are
those "remarkably few" compilers? Also, how could we interface
fortran and C for quadruple precision?
I was specifically referring to jacob's qfloat precision which he
claims is 352-bits. I presume this is mantissa bits, including the
hidden bit, but I'm not sure. I doubt there are many compilers
which provide long double of this size.
Those are off topic here, where we deal only with standard C. Try
comp.programming and/or comp.compilers.lcc.
Topicality drifts, and deep-thread topicality violations are not as
damaging as offtopic new threads.
Besides, if you read the entire thread you will learn that I was
advocating the OP use Standard C.
On Nov 29, 10:54 am, mathieu.dut...@gmail.com wrote:
Does there exist some C compiler supporting quadruple precision?
The wikipedia page says that "long double" can be the 80-bits of
the x86 or sometimes the 128 bits of quadruple precision. What are
those "remarkably few" compilers? Also, how could we interface
fortran and C for quadruple precision?
Buy a used Macintosh with a G4 or G5 processor. The gcc compiler that
ships with it supports 128 bit long double. Each long double operation
is implemented using about ten ordinary floating point operations on
the average.
santosh wrote, On 29/11/07 11:05:
ma************@gmail.com wrote:
<snip>
>Otherwise, thanks to all and to Jacob for lcc-win, which I did
not knew about. But this work is supposed to be on linux x86
computers.
jacob was part way through implementing his lcc-win32 for Linux (x86)
when licensing restrictions forced him to freeze the effort. But he may
be able to still help you out if you can establish a commercial license
with him.
He can't do that until he has sorted out the licensing problems. Note
that this is NOT a complaint about Jacob since he did not suggest this.
--
Flash Gordon
Flash Gordon wrote:
santosh wrote, On 29/11/07 11:05:
ma************@gmail.com wrote:
<snip>
Otherwise, thanks to all and to Jacob for lcc-win, which I did
not knew about. But this work is supposed to be on linux x86
computers.
jacob was part way through implementing his lcc-win32 for Linux (x86)
when licensing restrictions forced him to freeze the effort. But he may
be able to still help you out if you can establish a commercial license
with him.
He can't do that until he has sorted out the licensing problems. Note
that this is NOT a complaint about Jacob since he did not suggest this.
The root cause of Navia's licensing problems is his own selfishness.
If he released his compiler under a free license like the GPL, then
his Linux version would be releasable.
Of course, there's still the question of why anyone would want to use
a compiler maintained by someone with no interest in C, but only his C+
+-like extensions, and who exposes his abysmal lack of knowledge about
the language every day in this group.
Flash Gordon wrote:
santosh wrote, On 29/11/07 11:05:
>ma************@gmail.com wrote:
<snip>
>>Otherwise, thanks to all and to Jacob for lcc-win, which I did
not knew about. But this work is supposed to be on linux x86
computers.
jacob was part way through implementing his lcc-win32 for Linux (x86)
when licensing restrictions forced him to freeze the effort. But he may
be able to still help you out if you can establish a commercial license
with him.
He can't do that until he has sorted out the licensing problems. Note
that this is NOT a complaint about Jacob since he did not suggest this.
Yeah I have been working again trying to use the system assembler with
1) writing the assembler output into /tmp/something66677.s
2) calling system("as /tmp/something66677.s");
But now there are some problems with the output as it seems,
and the compiler doesn't compile itself any more.
Is it because the assembler is different? It looks like.
Or is it because since I was assuming the lcc assembler behavior
in the compiler and that doesn't work any more?
What a waste of time...
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique http://www.cs.virginia.edu/~lcc-win32
In article <af**********************************@d61g2000hsa. googlegroups.com>,
one of Heathfield's sock puppets wrote:
....
>The root cause of Navia's licensing problems is his own selfishness.
If he released his compiler under a free license like the GPL, then
his Linux version would be releasable.
Of course, there's still the question of why anyone would want to use
a compiler maintained by someone with no interest in C, but only his C+
+-like extensions, and who exposes his abysmal lack of knowledge about
the language every day in this group.
I'd like to introduce a new metric - called the Heathfield-Navia delta -
that is defined as the number of responses between when Navia's name is
mentioned, in a CLC article or response, and when Navia gets slammed by
Heathfield (either directly or via a sock puppet).
On Nov 29, 2:54 am, mathieu.dut...@gmail.com wrote:
This only provides portability to implementations where 'long double'
has the required precision. These are remarkably few.
Yes that is somewhat more what I had in mind.
Actually, the intel fortran compiler version 10 has support for
quadruple precision of IEEE754r.
Does there exist some C compiler supporting quadruple precision?
The QD package found here: http://crd.lbl.gov/~dhbailey/mpdist/
has 32 and 64 digit floating point. It's C++ and not C, though.
The wikipedia page says that "long double" can be the 80-bits of
the x86 or sometimes the 128 bits of quadruple precision. What are
those "remarkably few" compilers? Also, how could we interface
fortran and C for quadruple precision?
The QD package contains an interface for Fortran. Generally one would
expect a DLL under windows and a shared library under UNIX variants to
provide an interface to a special purpose library.
That's the extend of my problem. I have an existing C library
depending on lapack/blas, which I need to extend to computing
in higher precision, and quadruple might not be enough.
If quadruple precision is not enough, then your matrices must be
awfully close to singular. I smell trouble.
Otherwise, thanks to all and to Jacob for lcc-win, which I did
not knew about. But this work is supposed to be on linux x86
computers.
The lcc-win numeric package is just the Cephes library from Moshier.
You can use it with any other compiler as well. See the qlib link
from this site: http://www.moshier.net/#Cephes
On Nov 29, 1:23 pm, rosewa...@mailinator.com wrote:
Flash Gordon wrote:
santosh wrote, On 29/11/07 11:05:
mathieu.dut...@gmail.com wrote:
<snip>
>Otherwise, thanks to all and to Jacob for lcc-win, which I did
>not knew about. But this work is supposed to be on linux x86
>computers.
jacob was part way through implementing his lcc-win32 for Linux (x86)
when licensing restrictions forced him to freeze the effort. But he may
be able to still help you out if you can establish a commercial license
with him.
He can't do that until he has sorted out the licensing problems. Note
that this is NOT a complaint about Jacob since he did not suggest this.
The root cause of Navia's licensing problems is his own selfishness.
If he released his compiler under a free license like the GPL, then
his Linux version would be releasable.
I guess that this is not possible, since his compiler was derived from
LCC, which does not have a license compatible with GPL. At any rate,
whatever licence he chooses should be his own choice -- within
whatever limits are possible.
Of course, there's still the question of why anyone would want to use
a compiler maintained by someone with no interest in C, but only his C+
+-like extensions, and who exposes his abysmal lack of knowledge about
the language every day in this group.
I think is qfloat extension is quite interesing. I would like it if
every C compiler had a Cephes compatible interface for all functions
and for all of the float sizes in the Cephes lib, including qfloat.
As far as Jacob's C knowledge goes, he is clearly above average. He's
a bit combative at times (which may be reactionary) and I think that
sometimes he deliberately pretends not to understand something, but
everyone who posts here has their own little quirks (myself definitely
included).
IMO-YMMV.
user923005 <dc*****@connx.comwrites:
On Nov 29, 1:23 pm, ro*******@mailinator.com wrote:
[...]
>The root cause of Navia's licensing problems [...]
I guess that this is not possible, since [...]
Please don't feed the troll. ro*******@mailinator.com has done
nothing but flame jacob navia; whatever you might think of jacob, this
rosewater person's trolling is not worth a response.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
user923005 wrote:
The lcc-win numeric package is just the Cephes library from Moshier.
You can use it with any other compiler as well. See the qlib link
from this site:
http://www.moshier.net/#Cephes
This is not exactly true.
1) I rewrote all the basic operations in assembler. Speed is 50%
increased compared to the original versions.
2) I rewrote all the C99 library, adapting all functions from the
original library, increasing precision when possible
3) Using operator overloading, I integrated this library
like a basic type into the language.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique http://www.cs.virginia.edu/~lcc-win32
jacob navia <ja***@nospam.comwrites:
user923005 wrote:
>The lcc-win numeric package is just the Cephes library from Moshier.
You can use it with any other compiler as well. See the qlib link
from this site:
http://www.moshier.net/#Cephes
This is not exactly true.
1) I rewrote all the basic operations in assembler. Speed is 50%
increased compared to the original versions.
2) I rewrote all the C99 library, adapting all functions from the
original library, increasing precision when possible
3) Using operator overloading, I integrated this library
like a basic type into the language.
Where the phrase "the language" refers to something other than C.
--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Keith Thompson wrote:
jacob navia <ja***@nospam.comwrites:
>user923005 wrote:
>>The lcc-win numeric package is just the Cephes library from Moshier.
You can use it with any other compiler as well. See the qlib link
from this site:
http://www.moshier.net/#Cephes
This is not exactly true.
1) I rewrote all the basic operations in assembler. Speed is 50%
increased compared to the original versions.
2) I rewrote all the C99 library, adapting all functions from the
original library, increasing precision when possible
3) Using operator overloading, I integrated this library
like a basic type into the language.
Where the phrase "the language" refers to something other than C.
No. All this extensions are compatible with the C standard as
I have explained thousand times in this newsgroup.
Note that the C standard does NOT forbid extensions
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique http://www.cs.virginia.edu/~lcc-win32
jacob navia wrote, On 30/11/07 21:32:
Keith Thompson wrote:
>jacob navia <ja***@nospam.comwrites:
<snip>
>>3) Using operator overloading, I integrated this library
like a basic type into the language.
Where the phrase "the language" refers to something other than C.
No. All this extensions are compatible with the C standard as
I have explained thousand times in this newsgroup.
Note that the C standard does NOT forbid extensions
Well, your compiler does not conform to the C standard *without* the
-ansic flag (for example declaring atof in math.h), so does it support
operator overloading *with* the -ansic flag? If not then it compiles C
when the -ansic flag is specified and something other than C that
supports operator overloading with it.
--
Flash Gordon
On Nov 30, 1:32 pm, jacob navia <ja...@nospam.comwrote:
Keith Thompson wrote:
jacob navia <ja...@nospam.comwrites:
user923005 wrote:
The lcc-win numeric package is just the Cephes library from Moshier.
You can use it with any other compiler as well. See the qlib link
from this site:
http://www.moshier.net/#Cephes
This is not exactly true.
1) I rewrote all the basic operations in assembler. Speed is 50%
increased compared to the original versions.
2) I rewrote all the C99 library, adapting all functions from the
original library, increasing precision when possible
3) Using operator overloading, I integrated this library
like a basic type into the language.
Where the phrase "the language" refers to something other than C.
No. All this extensions are compatible with the C standard as
I have explained thousand times in this newsgroup.
Note that the C standard does NOT forbid extensions
By the same logic, this is C code, since GCC compiles it:
PROGRAM STEFACC
C NUMERICAL METHODS: FORTRAN Programs, (c) John H. Mathews 1994
C To accompany the text:
C NUMERICAL METHODS for Mathematics, Science and Engineering, 2nd
Ed, 1992
C Prentice Hall, Englewood Cliffs, New Jersey, 07632, U.S.A.
C This free software is complements of the author.
C
C Algorithm 2.7 (Steffensen's Acceleration).
C Section 2.5, Aitken's Process & Steffensen's & Muller's Methods,
Page 96
C
PARAMETER(Delta=5E-6,Epsilon=5E-6,Max=99)
INTEGER Cond,K
REAL Dp,P0,P3
CHARACTER ANS*1
EXTERNAL F,F1
10 CALL INPUT(P0)
CALL STEFFEN(F,F1,P0,Delta,Epsilon,Max,P3,Dp,Cond,K)
CALL RESULTS(P0,P3,Dp,Cond,K)
WRITE(9,*)' '
WRITE(9,*)'WANT TO TRY ANOTHER STARTING VALUE ? <Y/N'
READ(9,'(A)') ANS
IF (ANS.EQ.'Y' .OR. ANS.EQ.'y') GOTO 10
STOP
END
REAL FUNCTION F(X)
REAL X
F=X*X*X-3*X+2
RETURN
END
REAL FUNCTION F1(X)
REAL X
F1=3*X*X-3
RETURN
END
SUBROUTINE PRINTFUN
WRITE(9,*)'F(X) = X*X*X-3*X+2'
RETURN
END
SUBROUTINE STEFFEN(F,F1,P0,Delta,Epsilon,Max,P3,Dp,Cond,K)
PARAMETER(Small=1E-20)
INTEGER Cond,K,Max
REAL D1,D2,Delta,DF0,DF1,Dp,Epsilon,P0,P1,P2,P3,Pold,Re lErr,Y3
EXTERNAL F,F1
Pold=P0
K=0
Cond=0
P3=P0
P2=P0+1
P1=P0+2
100 continue
IF ((K.LT.Max).AND.(Cond.EQ.0)) then
P0=P3
DF0=F1(P0)
IF (DF0.NE.0) THEN
P1=P0 - F(P0)/DF0
ELSE
Cond=1
Dp=P3-P2
P3=P0
ENDIF
DF1=F1(P1)
IF (DF1.EQ.0) THEN
Cond=1
Dp=P1-P0
P3=P1
ELSE
P2=P1 - F(P1)/DF1
D1=(P1-P0)*(P1-P0)
D2=P2-2*P1+P0
IF (D2.EQ.0) THEN
Cond=1
Dp=P2-P1
P3=P2
ELSE
P3=P0-D1/D2
Dp=P3-P2
ENDIF
Y3=F(P3)
RelErr=ABS(Dp)/(ABS(P3)+Small)
IF (RelErr.LT.Delta) then
Cond=2
endif
IF (ABS(Y3).LT.Epsilon) then
Cond=3
endif
IF ((Cond.EQ.2).AND.(ABS(Y3).LT.Epsilon)) then
Cond=4
endif
ENDIF
K=K+1
WRITE(9,1000) K,P3,P3
goto 100
ENDIF
P0=Pold
PAUSE
RETURN
1000 FORMAT(I2,4X,F15.7,4X,F15.7)
END
SUBROUTINE XSTEFFEN(F,F1,P0,Delta,Epsilon,Max,P3,Dp,Cond,K)
C This subroutine uses simulated WHILE loop(s).
PARAMETER(Small=1E-20)
INTEGER Cond,K,Max
REAL D1,D2,Delta,DF0,DF1,Dp,Epsilon,P0,P1,P2,P3,Pold,Re lErr,Y3
EXTERNAL F,F1
Pold=P0
K=0
Cond=0
P3=P0
P2=P0+1
P1=P0+2
10 IF ((K.LT.Max).AND.(Cond.EQ.0)) THEN
P0=P3
DF0=F1(P0)
IF (DF0.NE.0) THEN
P1=P0 - F(P0)/DF0
ELSE
Cond=1
Dp=P3-P2
P3=P0
ENDIF
DF1=F1(P1)
IF (DF1.EQ.0) THEN
Cond=1
Dp=P1-P0
P3=P1
ELSE
P2=P1 - F(P1)/DF1
D1=(P1-P0)*(P1-P0)
D2=P2-2*P1+P0
IF (D2.EQ.0) THEN
Cond=1
Dp=P2-P1
P3=P2
ELSE
P3=P0-D1/D2
Dp=P3-P2
ENDIF
Y3=F(P3)
RelErr=ABS(Dp)/(ABS(P3)+Small)
IF (RelErr.LT.Delta) then
Cond=2
endif
IF (ABS(Y3).LT.Epsilon) then
Cond=3
endif
IF ((RelErr.LT.Delta).AND.(ABS(Y3).LT.Epsilon)) then
Cond=4
endif
ENDIF
K=K+1
WRITE(9,1000) K,P3,P3
GOTO 10
ENDIF
P0=Pold
PAUSE
RETURN
1000 FORMAT(I2,4X,F15.7,4X,F15.7)
END
SUBROUTINE INPUT(P0)
INTEGER I
REAL P0
DO 10 I=1,18
WRITE(9,*)' '
10 CONTINUE
WRITE(9,*)' '
WRITE(9,*)'STEFFENSEN`S ACCELERATION OF THE NEWTON-RAPHSON'
WRITE(9,*)' '
WRITE(9,*)'METHOD IS USED TO FIND A ZERO OF THE FUNCTION'
WRITE(9,*)' '
CALL PRINTFUN
WRITE(9,*)' '
WRITE(9,*)'ONE INITIAL APPROXIMATION P0 IS NEEDED.'
WRITE(9,*)' '
WRITE(9,*)'ENTER P0 = '
READ(9,*) P0
WRITE(9,*)' '
RETURN
END
SUBROUTINE RESULTS(P0,P3,Dp,Cond,K)
INTEGER Cond,I,K
REAL P0,P3,Dp
DO 10 I=1,15
WRITE(9,*)' '
10 CONTINUE
WRITE(9,*)'STEFFENSEN`S ACCELERATION OF THE NEWTON-RAPHSON'
WRITE(9,*)' '
WRITE(9,*)'METHOD WAS USED TO FIND A ZERO OF THE FUNCTION'
WRITE(9,*)' '
CALL PRINTFUN
WRITE(9,*)' '
WRITE(9,*)'STARTING WITH THE APPROXIMATION P0 =',P0
WRITE(9,*)' '
WRITE(9,*)'AFTER ',K,' ITERATIONS AN APPROXIMATE VALUE OF THE
ZERO
+ IS'
WRITE(9,*)' '
WRITE(9,*)' P =',P3
WRITE(9,*)' '
WRITE(9,*)' DP =',ABS(Dp),' IS AN ESTIMATE OF THE ACCURACY.'
WRITE(9,*)' '
WRITE(9,*)' F(',P3,' ) =',F(P3)
WRITE(9,*)' '
IF (F(P3).EQ.0) THEN
WRITE(9,*)'THE COMPUTED FUNCTION VALUE IS EXACTLY ZERO!'
WRITE(9,*)' '
ENDIF
IF (Cond.EQ.0) THEN
WRITE(9,*)'CONVERGENCE IS DOUBTFUL BECAUSE'
WRITE(9,*)' '
WRITE(9,*)'THE MAXIMUM NUMBER OF ITERATIONS WAS EXCEEDED.'
ELSEIF (Cond.EQ.1) THEN
WRITE(9,*)'CONVERGENCE IS DOUBTFUL. DIVISION BY ZERO WAS
ENCOUNT
+ERED.'
ELSEIF (Cond.EQ.2) THEN
WRITE(9,*)'THE APPROXIMATION P IS WITHIN THE DESIRED
TOLERANCE.'
ELSEIF (Cond.EQ.3) THEN
WRITE(9,*)'THE FUNCTION VALUE F(P) IS WITHIN THE DESIRED
TOLERAN
+CE.'
ELSEIF (Cond.EQ.4) THEN
WRITE(9,*)'THE APPROXIMATION P AND THE FUNCTION VALUE '
WRITE(9,*)'F(P) ARE BOTH WITHIN THE DESIRED TOLERANCES.'
ENDIF
RETURN
END
Flash Gordon wrote:
jacob navia wrote, On 30/11/07 21:32:
>Keith Thompson wrote:
>>jacob navia <ja***@nospam.comwrites:
<snip>
>>>3) Using operator overloading, I integrated this library
like a basic type into the language.
Where the phrase "the language" refers to something other than C.
No. All this extensions are compatible with the C standard as
I have explained thousand times in this newsgroup.
Note that the C standard does NOT forbid extensions
Well, your compiler does not conform to the C standard *without* the
-ansic flag (for example declaring atof in math.h), so does it support
operator overloading *with* the -ansic flag? If not then it compiles C
when the -ansic flag is specified and something other than C that
supports operator overloading with it.
Just like gcc?
--
Ian Collins.
On Fri, 30 Nov 2007 14:36:58 -0800, user923005 wrote:
On Nov 30, 1:32 pm, jacob navia <ja...@nospam.comwrote:
>No. All this extensions are compatible with the C standard as I have
explained thousand times in this newsgroup.
Note that the C standard does NOT forbid extensions
By the same logic, this is C code, since GCC compiles it:
PROGRAM STEFACC
C NUMERICAL METHODS: FORTRAN Programs, (c) John H. Mathews 1994 C
[...]
This is not accepted by any version of GCC in any mode where it aims to
conform to any version of the C standard, and I would be very surprised
if it is accepted by any other compiler in any such mode.
Harald van Dijk wrote:
On Fri, 30 Nov 2007 14:36:58 -0800, user923005 wrote:
>On Nov 30, 1:32 pm, jacob navia <ja...@nospam.comwrote:
>>No. All this extensions are compatible with the C standard as I have
explained thousand times in this newsgroup.
Note that the C standard does NOT forbid extensions
By the same logic, this is C code, since GCC compiles it:
PROGRAM STEFACC
C NUMERICAL METHODS: FORTRAN Programs, (c) John H. Mathews 1994 C
[...]
This is not accepted by any version of GCC in any mode where it aims to
conform to any version of the C standard, and I would be very surprised
if it is accepted by any other compiler in any such mode.
gcc is not the C-compiler.
Keith Thompson wrote:
jacob navia <ja***@nospam.comwrites:
>user923005 wrote:
>>The lcc-win numeric package is just the Cephes library from
Moshier. You can use it with any other compiler as well. See
the qlib link from this site:
http://www.moshier.net/#Cephes
This is not exactly true.
1) I rewrote all the basic operations in assembler. Speed is 50%
increased compared to the original versions.
2) I rewrote all the C99 library, adapting all functions from the
original library, increasing precision when possible
3) Using operator overloading, I integrated this library
like a basic type into the language.
Where the phrase "the language" refers to something other than C.
Since the result is a library to go with the non-C capabilities of
lcc-win32, that doesn't matter, and is of negligible interest on
c.l.c. In fact, probably off-topic.
--
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>
Try the download section.
--
Posted via a free Usenet account from http://www.teranews.com
jacob navia wrote:
Keith Thompson wrote:
.... snip ...
>
>Where the phrase "the language" refers to something other than C.
No. All this extensions are compatible with the C standard as
I have explained thousand times in this newsgroup.
Note that the C standard does NOT forbid extensions
True. However c.l.c does.
--
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>
Try the download section.
--
Posted via a free Usenet account from http://www.teranews.com
Ian Collins wrote, On 30/11/07 22:51:
Flash Gordon wrote:
>jacob navia wrote, On 30/11/07 21:32:
>>Keith Thompson wrote:
jacob navia <ja***@nospam.comwrites:
<snip>
>>>>3) Using operator overloading, I integrated this library
like a basic type into the language.
Where the phrase "the language" refers to something other than C.
No. All this extensions are compatible with the C standard as
I have explained thousand times in this newsgroup.
Note that the C standard does NOT forbid extensions
Well, your compiler does not conform to the C standard *without* the
-ansic flag (for example declaring atof in math.h), so does it support
operator overloading *with* the -ansic flag? If not then it compiles C
when the -ansic flag is specified and something other than C that
supports operator overloading with it.
Just like gcc?
No.
Jacob is claiming that his compiler with its extensions conforms to the
standard, to do that it would have to have the extensions enabled whilst
*in* standards compatible mode.
gcc does not claim its extensions are compatible with the C standard,
and where they are not disables them when you tell it to conform to the
standard. Also no one is claiming that gcc+gnu extensions conforms to
the C standard.
Note that I am *not* complaining about the default mode not conforming
to the standard (that applies to most C compilers) nor about the
presence of extensions in a compiler, just querying whether as Jacob
says this extension is compatible with the standard it is enabled when
his compiler is instructed to conform to the standard.
--
Flash Gordon
user923005 wrote:
On Nov 30, 1:32 pm, jacob navia <ja...@nospam.comwrote:
>Keith Thompson wrote:
>>jacob navia <ja...@nospam.comwrites:
user923005 wrote:
The lcc-win numeric package is just the Cephes library from Moshier.
You can use it with any other compiler as well. See the qlib link
from this site:
http://www.moshier.net/#Cephes
This is not exactly true.
1) I rewrote all the basic operations in assembler. Speed is 50%
increased compared to the original versions.
2) I rewrote all the C99 library, adapting all functions from the
original library, increasing precision when possible
3) Using operator overloading, I integrated this library
like a basic type into the language.
Where the phrase "the language" refers to something other than C.
No. All this extensions are compatible with the C standard as
I have explained thousand times in this newsgroup.
Note that the C standard does NOT forbid extensions
By the same logic, this is C code, since GCC compiles it:
[snip fortran code]
All extensions and proposals that I have argued over and
over produce always this brainless answers...
BRAVO user923005!
Your arguments show the sophistication your mind is capable of!
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique http://www.cs.virginia.edu/~lcc-win32
Ian Collins wrote:
Flash Gordon wrote:
>jacob navia wrote, On 30/11/07 21:32:
>>Keith Thompson wrote:
jacob navia <ja***@nospam.comwrites:
<snip>
>>>>3) Using operator overloading, I integrated this library
like a basic type into the language.
Where the phrase "the language" refers to something other than C.
No. All this extensions are compatible with the C standard as
I have explained thousand times in this newsgroup.
Note that the C standard does NOT forbid extensions
Well, your compiler does not conform to the C standard *without* the
-ansic flag (for example declaring atof in math.h), so does it support
operator overloading *with* the -ansic flag? If not then it compiles C
when the -ansic flag is specified and something other than C that
supports operator overloading with it.
Just like gcc?
And MSVC:
__declspec(dllimport)
_stdcall
etc etc.
And IBM with their vector extensions...
And ANY compiler that existed since ALL of them had
extensions, and without those extensions many of the standard
things today would never had existed!
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique http://www.cs.virginia.edu/~lcc-win32
CBFalconer wrote:
Keith Thompson wrote:
>jacob navia <ja***@nospam.comwrites:
>>user923005 wrote:
The lcc-win numeric package is just the Cephes library from
Moshier. You can use it with any other compiler as well. See
the qlib link from this site:
http://www.moshier.net/#Cephes
This is not exactly true.
1) I rewrote all the basic operations in assembler. Speed is 50%
increased compared to the original versions.
2) I rewrote all the C99 library, adapting all functions from the
original library, increasing precision when possible
3) Using operator overloading, I integrated this library
like a basic type into the language.
Where the phrase "the language" refers to something other than C.
Since the result is a library to go with the non-C capabilities of
lcc-win32, that doesn't matter, and is of negligible interest on
c.l.c. In fact, probably off-topic.
I would say that your answer is of negligible interest anyway...
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique http://www.cs.virginia.edu/~lcc-win32
CBFalconer wrote:
jacob navia wrote:
>Keith Thompson wrote:
... snip ...
>>Where the phrase "the language" refers to something other than C.
No. All this extensions are compatible with the C standard as
I have explained thousand times in this newsgroup.
Note that the C standard does NOT forbid extensions
True. However c.l.c does.
You are speaking for yourself... There is no approved c.l.c
consensus about this.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique http://www.cs.virginia.edu/~lcc-win32
Harald van Dijk wrote:
On Fri, 30 Nov 2007 14:36:58 -0800, user923005 wrote:
>On Nov 30, 1:32 pm, jacob navia <ja...@nospam.comwrote:
>>No. All this extensions are compatible with the C standard as I have
explained thousand times in this newsgroup.
Note that the C standard does NOT forbid extensions
By the same logic, this is C code, since GCC compiles it:
PROGRAM STEFACC
C NUMERICAL METHODS: FORTRAN Programs, (c) John H. Mathews 1994 C
[...]
This is not accepted by any version of GCC in any mode where it aims to
conform to any version of the C standard, and I would be very surprised
if it is accepted by any other compiler in any such mode.
That doesn't matter Mr 923005... Important is just to
say something, even if it is nonsense.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique http://www.cs.virginia.edu/~lcc-win32
On Nov 30, 3:49 pm, jacob navia <ja...@nospam.comwrote:
user923005 wrote:
On Nov 30, 1:32 pm, jacob navia <ja...@nospam.comwrote:
Keith Thompson wrote:
jacob navia <ja...@nospam.comwrites:
user923005 wrote:
The lcc-win numeric package is just the Cephes library from Moshier.
You can use it with any other compiler as well. See the qlib link
from this site:
http://www.moshier.net/#Cephes
This is not exactly true.
1) I rewrote all the basic operations in assembler. Speed is 50%
increased compared to the original versions.
2) I rewrote all the C99 library, adapting all functions from the
original library, increasing precision when possible
3) Using operator overloading, I integrated this library
like a basic type into the language.
Where the phrase "the language" refers to something other than C.
No. All this extensions are compatible with the C standard as
I have explained thousand times in this newsgroup.
Note that the C standard does NOT forbid extensions
By the same logic, this is C code, since GCC compiles it:
[snip fortran code]
All extensions and proposals that I have argued over and
over produce always this brainless answers...
I would not say that your answers are brainless.
BRAVO user923005!
I am glad that you are capable of understanding that extensions to a
compiler do not extend the language, but simply create an incompatible
superset that is useful for additional purposes.
Your arguments show the sophistication your mind is capable of!
Thank you, but it was nothing.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatiquehttp://www.cs.virginia.edu/~lcc-win32- Hide quoted text -
- Show quoted text -
jacob navia <ja***@nospam.comwrites:
Keith Thompson wrote:
>jacob navia <ja***@nospam.comwrites:
[...]
>>3) Using operator overloading, I integrated this library
like a basic type into the language.
Where the phrase "the language" refers to something other than C.
No. All this extensions are compatible with the C standard as
I have explained thousand times in this newsgroup.
Note that the C standard does NOT forbid extensions
You're right. As long as your extension doesn't affect the behavior
of any strictly conforming program (and as far as I know it doesn't),
it's specifically allowed by the standard (C99 4p6).
I have a question (one that you may have answered before, but I've
forgotten the answer). Is this extension supported in conforming mode
(with "-ansic")? Though the standard permits this, IMHO it would be a
good idea to have *some* mode in which extensions are disabled, to
make it easier for programmers to write portable code and detect
non-portable code.
--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
user923005 <dc*****@connx.comwrites:
On Nov 30, 1:32 pm, jacob navia <ja...@nospam.comwrote:
>Keith Thompson wrote:
[...]
>No. All this extensions are compatible with the C standard as
I have explained thousand times in this newsgroup.
Note that the C standard does NOT forbid extensions
By the same logic, this is C code, since GCC compiles it:
PROGRAM STEFACC
C NUMERICAL METHODS: FORTRAN Programs, (c) John H. Mathews 1994
[232 lines deleted]
RETURN
END
Surely you could have made that point without posting 236 lines of
Fortran.
--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister" This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Philipp |
last post by:
Hello (not sure this is the right forum for that question so please redirect
me if necessary)
How can I know how many double values are available between 0 and 1?
On my machine (pentium 3) I get...
|
by: Roger Leigh |
last post by:
Hello,
I'm writing a fixed-precision floating point class, based on the ideas
in the example fixed_pt class in the "Practical C++ Programming" book
by Steve Oualline (O' Reilly). This uses a...
|
by: Brian van den Broek |
last post by:
Hi all,
I guess it is more of a maths question than a programming one, but it
involves use of the decimal module, so here goes:
As a self-directed learning exercise I've been working on a...
|
by: BigMan |
last post by:
How can I check if assignment of a float to a double (or vice versa)
will result in loss of precision?
|
by: michael.mcgarry |
last post by:
Hi,
I have a question about floating point precision in C.
What is the minimum distinguishable difference between 2 floating point
numbers? Does this differ for various computers?
Is this...
|
by: Madan |
last post by:
Hi all,
I had problem regarding float/double arithmetic only with + and -
operations, which gives inaccurate precisions. I would like to know how the
arithmetic operations are internally handled...
|
by: Bo Yang |
last post by:
Hi, I am confused by the double type in C++. I don't know whether
below is legal or possible:
double PI = 3.141592675932;
Now, can I get another double variable from PI with lower precision,...
|
by: Matthew |
last post by:
Hi,
I want to change the precision level of floating point variables and
calculations which is done in php.ini.
However the server I rent for my domain does not give me access to
php.ini,...
|
by: Charles Coldwell |
last post by:
James Kanze <james.kanze@gmail.comwrites:
True, with some additional considerations. The commonly used IEEE 754
floating point formats are
single precision: 32 bits including 1 sign bit, 23...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and...
| |
