Changes
http://page.axiom-developer.org/zope/mathaction/167InfiniteFloatsDomain/diff
--
??changed:
-However, in my view, this still is not infinite precision in the sense of that
$2^(-35) + 2^34$ will not compute exactly because the system does not
*automatically* increase precision in 'FLOAT'
Changes
http://page.axiom-developer.org/zope/mathaction/167InfiniteFloatsDomain/diff
--
William, thank you very much for your comments on this issue.
Your presentation above is very instructive and useful to me.
I agree completely with your statements about the relevance of
> infinite sequences o
Changes
http://page.axiom-developer.org/zope/mathaction/167InfiniteFloatsDomain/diff
--
??changed:
-In fact I think this subject, on the boarder between symbolic
In fact I think this subject, on the border between symbolic
--
forwarded from http://page.axiom-developer.org/zope/mathaction/[EMAIL
Changes
http://page.axiom-developer.org/zope/mathaction/167InfiniteFloatsDomain/diff
--
++added:
>From William Sit, Tuesday June 14 20:06:00 -4:00
Subject: Float, Real, RealClosure
Tim wrote:
>This raises the same kind of implementation issue that indefinite computation
>raises except that i
Changes
http://page.axiom-developer.org/zope/mathaction/167InfiniteFloatsDomain/diff
--
How is this different than what Axiom already does?
I can write:
\begin{axiom}
a:=2*asin(1)
a::Expression Float
digits(100)
a::Expression Float
\end{axiom}
So %pi already has this kind of "closure" built-in.
I
Changes
http://page.axiom-developer.org/zope/mathaction/167InfiniteFloatsDomain/diff
--
>From Kai Kaminski:
> I just read your posts about infinite precision floats on the Axiom
> list and I recalled that I have seen something like this a while ago. I
> am not sure if this is what you are looki
Changes
http://page.axiom-developer.org/zope/mathaction/167InfiniteFloatsDomain/diff
--
++added:
Now that I'm awake the idea is coming back to me. What originally
triggered the thought was that we need a way to compute an answer
to a variable number of decimal places which could be expanded la
Changes
http://page.axiom-developer.org/zope/mathaction/167InfiniteFloatsDomain/diff
--
??changed:
-Most people would expect the answer of 'z-x' to be '0.16887242 E-20' but this
ignores the fact that the display is converted from an internal binary
representation to a decimal one. During the co
Changes
http://page.axiom-developer.org/zope/mathaction/167InfiniteFloatsDomain/diff
--
??changed:
-$m$ has 53 bits stored in a 52 bit field (not including sign, note that in
base 2, the most significant digit normalized must be 1, so no need to store
it!) and $e$ has 11 bits (including sign, r
Changes
http://page.axiom-developer.org/zope/mathaction/167InfiniteFloatsDomain/diff
--
??changed:
-In 'FLOAT', conceptually the infinite precision floating point system, is
basically also finite precision floating point system, with the ability to
increase precision as requested. However, this
Changes
http://page.axiom-developer.org/zope/mathaction/167InfiniteFloatsDomain/diff
--
??changed:
-What is the domain FLOAT if not already "infinite but bounded
What is the domain 'FLOAT' if not already "infinite but bounded
++added:
++added:
>From Tim Daly Sun, 12 Jun 2005 17:17:54 -0500
Changes
http://page.axiom-developer.org/zope/mathaction/167InfiniteFloatsDomain/diff
--
Tim,
What is the domain FLOAT if not already "infinite but bounded
length"? I thought that FLOAT has internal representation based
on a pair of "infinite but bounder length" INT's.
>From 'float.spad.pamphlet'
Changes
http://page.axiom-developer.org/zope/mathaction/167InfiniteFloatsDomain/diff
--
We need a way to handle infinite but bounded length floating
point computation. At present we have FLOAT and DFLOAT but
we really need general purpose floating point algorithms
similar in spirit to infinite len
13 matches
Mail list logo
