K
Keith Thompson
jacob navia said:
GNU MP is provided with Cygwin. I don't use it much, but as far as I
can tell it works just fine.
GNU MP is provided with Cygwin. I don't use it much, but as far as I
can tell it works just fine.
J
jacob navia
Keith said:
cygwin is not native windows. It is a unix emulation under windows that
combines the worst of each system in a wonderful mix
F
Flash Gordon
jacob said:Keith said:
cygwin is not native windows. It is a unix emulation under windows that
combines the worst of each system in a wonderful mix
Cygwin is an incredibly useful tool. However, if you don't want it (and
for licensing reasons I would not build software against it for
distribution) then you can follow the instructions to build it with
MinGW and the instructions for using the resulting dll (if that is how
you build it) with MS C if you want.
Or cheat and use one of the pre-build versions.
Seems easy to me.
B
BartC
Richard Bos said:
Keith advised using long double and Gordon vaguely mentioned the
availability of multi-precision libraries that could deal with thousands of
digits.
Jacob's qfloat feature uses a more reasonable 100 digits and in fact within
a few minutes I was able to read this input:
0.123456789012345678901234567890
into a qfloat and print it as:
0.12345678901234567890123456789000000000000000000000 ... (to 100 or so
places)
/That's/ what I call a solution.
So /if/ using lcc-win32 is an option, then this would be perfect. And if
it's not (eg. the OP is already relying on extensions in other compilers),
then maybe somebody might be minded to add this to one or two other systems.
(I think qfloat needs compiler support rather than just being a library.)
T
Tim Rentsch
Dik T. Winter said:
You mean /does not/ guarantee, right? As long as a qfloat holds
at least 90 or so bits of (what used to be called) mantissa, a
qfloat /could/ guarantee (a*a)/a == a for all 30 decimal digits
of a (assuming no exponent overflow or underflow, or division by
zero, etc).
B
Ben Bacarisse
BartC said:
But the question, in my option, requires clarification which is what
many of the answers have done.
The OP specified the compiler (pgcc) and asked if the precision could
be increased. In this context, the most directly helpful answer was
Keith's. Switching from a specialised parallelizing compiler to
lcc-win32 to gain precision is not obviously a good idea.
The question is vague enough that one /can/ reasonably suggest using
another compiler; but then one can also reasonably suggest using GMP,
or question the very need to have >= 30 digits of precision. All of
these answers may help the OP resolve the underlying problem which we
can only guess at.
K
Keith Thompson
jacob navia said:Keith said:
cygwin is not native windows. It is a unix emulation under windows that
combines the worst of each system in a wonderful mix
So what? Your claim was that "windows support is non existing".
And again, you might want to compare the portability of GNU MP to the
portability of qfloat.
J
jacob navia
Keith said:jacob navia said:cygwin is not native windows. It is a unix emulation under windows thatKeith said:
combines the worst of each system in a wonderful mix
So what? Your claim was that "windows support is non existing".
Apparently you can't read what you yourself cite above:
I am speaking about NATIVE windows, not some emulation!
K
Keith Thompson
jacob navia said:Keith said:jacob navia said:Keith Thompson wrote:
Beej Jorgensen wrote:
The GNU MP package is very difficult to install for native windows,
[snip]
GNU is Not Usable
Heh!
I've only ever used GNU MP for fun (little crypto learning programs),
but I have to say my experience with it was pretty painless (under
Linux, though, not Windows.)
Windows is proprietary, so it wouldn't surprise me in the least if it
gets some backhanded treatment from the FSF...
That is what I was saying: windows support is non existing
GNU MP is provided with Cygwin. I don't use it much, but as far as I
can tell it works just fine.
cygwin is not native windows. It is a unix emulation under windows that
combines the worst of each system in a wonderful mix
So what? Your claim was that "windows support is non existing".
Apparently you can't read what you yourself cite above:
I am speaking about NATIVE windows, not some emulation!
And if you had said so, there wouldn't be a problem. Your statement,
without qualification, was that "windows support is non existing".
A quick look at the documentation indicates that there *is* support
for native Windows as well. It can be built either as a static
library or as a DLL. (I haven't tried it myself.)
D
Dik T. Winter
If (a * a) fits exactly, the above is guaranteed. But an arbitrary 30 digit
decimal number does not fit exactly in a qfloat, let alone the square of it,
so it can not be guaranteed in general. If (a * a) does not fit, rounding
takes place, this can give just the wrong result when dividing. And we have
also a rounding in reading in the number. It is true that with an increasing
number of bits the possibility that it goes wrong diminishes, but it can not
be ruled out.
T
Tim Rentsch
Dik T. Winter said:
Let me see if we understand each other.
If a qfloat had a million bits of precision, then (a*a)/a == a
would hold for all 'a' of 30 decimal digits (assuming no problems
with exponent overflow, etc).
If a qfloat had, say, 105 bits of precision, then a qfloat could
hold a 30 decimal-digit number exactly. (The 105 number is
a sharpening of my earlier "90 or so" number, which was fudged
because I knew it was only a first approximation.)
If a qfloat could hold a 30 decimal-digit number exactly, then
(a*a)/a == a could be guaranteed (assuming as above) because the
intermediate values could be calculated in a higher precision
sufficient to make that happen (a million bits, say).
You say a qfloat is not sufficient to hold an arbitrary 30
digit decimal number. (Maybe that's true, maybe it isn't,
I have no information either way, but what's of interest
is the statement, not whether it's true or false.)
So to ask my question again: what you mean is that a qfloat
/does not/ guarantee (a*a)/a==a, and not that it /could not/
guarantee (a*a)/a==a, which could be done if a qfloat had a
higher precision. Do I have that right, or did I misunderstand
something somewhere?
K
Keith Thompson
Tim Rentsch said:
Maybe, depending on rounding modes.
No. qfloat is a binary format. Some 30 decimal-digit
numbers can be represented exactly in 105 bits (e.g.,
0.12500000000000000000000000000), but most cannot (e.g.,
0.10000000000000000000000000000). A 105-bit floating-point
type could store a very very close approximation of
0.10000000000000000000000000000, close enought to distinguish
it from any other 30-digit number, but it can't store it exactly.
I'm too lazy to work out how rounding modes might affect the
computation of (0.1*0.1)/0.1, but I was just able to demonstrate that
(0.1*0.1)/0.1 is unequal to 0.1 using long double.
[snip]
T
Tim Rentsch
Keith Thompson said:
Or other representation choices; see below.
Are you saying that qfloat /is/ a binary format, or that qfloat /must
be/ a binary format? Doesn't the standard allow floating-point
numbers to be represented using a different base, such as base 10?
If a qfloat represented numbers using base 10, wouldn't you agree
that it /could/ hold a 30 decimal-digit exactly? Is there anything
preventing qfloat from representing numbers using base 10?
I assume you mean it is unequal on your implementation.
Do you think it must be unequal on all implementations,
or even just those implementations limited to no more
than 80 bits of precision?
K
Keith Thompson
Tim Rentsch said:
Certainly qfloat could be decimal. My understanding is that the
qfloat implemented by lcc-win32 is binary. (It's not impossible that
I'm mistaken on this point.)
I meant merely that it's unequal on the implementation I used; it
could be equal on another implementation, regardless of the number of
bits of precision.
D
Dik T. Winter
Can you prove it?
Eh, no. It even can't hold 0.1 exactly. Remember, we are talking
floating-point here.
Regardless of the precision, it is pretty difficult to get a guarantee
that for some precision the equation (a*a)/a==a does hold. But I think
you were thinking about integers where the original question was about
floating point.
D
Dik T. Winter
It *is* a binary format. It is the "qfloat" from lcc-win32.
That is not necessary, but it is nearly impossible to guaranty equality
for al representable numbers.
R
Richard Bos
jacob navia said:
You do realise that Appendix J is _not normative_, and therefore has
sweet fanny adams to do with a _general_ solution?
Oh, right. That's exactly the kind of thing you choose not to realise.
If I were to read the entire Standard every time I answered your
nonsense, I'd have no time left to write anything. I'm sure you'd prefer
that, because criticism is painful, but I'm afraid I can't pander to
your hurt self-esteem.
Richard
T
Tim Rentsch
Dik T. Winter said:
ISTM that it's pretty easy to guarantee that a*a/a == a (assuming
a is an actual number and a != 0), simply by having intermediate
values have twice as much precision and have an exponent range
that's twice as large. In that case the result of the multiplication
would be exact, and so the division should yield an exact result.
T
Tim Rentsch
Dik T. Winter said:
Sorry, I should have been more clear about the expected conditions
(hinted at a bit too indirectly by "etc"). My bad. See below.
Actually, it could, for several different reasons.
(A) qfloat is a "floating point" type, but it is not one of the
three standard floating-point types. As such it's an extension
and isn't covered by the Standard. (Maybe someone else can find
a proviso for additional, implementation-defined floating-point
types, but I couldn't; even if the Standard allows such types,
qfloat doesn't have to be one of them). Since it's an extension
it isn't obligated to follow the model in 5.2.4.2.2.
(B) Even if qfloat does have to conform to the requirements of
other floating-point types, the model in 5.2.4.2.2 allows decimal
bases. Using a decimal base would allow exact representation of
decimal numbers.
(C) In fact, even the standard floating-point types don't have
to conform to the model given in 5.2.4.2.2. As noted in (16)
to 5.2.4.2.2 p 1:
(16) The floating-point model is intended to clarify
the description of each floating-point characteristic
and does not require the floating-point arithmetic of
the implementation to be identical.
As far as I can see (and I looked pretty thoroughly) there
is no requirement that floating-point types must conform
to the model given in 5.2.4.2.2. They do have to define
the macros, but other than that the choice of what numbers
can be represented and how they are represented is pretty
open.
The point of my original question was to discover whether
you were making a statement about the specific implementation
of qfloat or if you were meaning to make a more general
statement about how floating-point types might be implemented.
My question was indeed about floating-point and not about integers.
I think some confusion may have arisen because I was asking about
floating-point in the generality allowed by the Standard, whereas
you were commenting about floating-point as it is commonly (and in
fact, almost universally) implemented.
I responded to the a*a/a == a question in my last posting.
D
Dik T. Winter
Ah, so you are not discussion the actual qfloat that was being discussed.
Yes, I know that if you do not conform to the C model (which is losely
based on Brown's model), all bets are off. I know that on the Cray-1,
17.0/17.0 != 1.0
so what?
Of course you could calculate expressions in arbitrary precision, and
under such circumstances a*a/a==a would certainly be true. But in that
case you are no longer working within a single floating-point type.