An integer is auto-converted to extended precision, but not to rational.
Yet Residue seems to be defined for rationals.
n=.14
(n^2x) |5729082486784839
147
3!:0 (n^2x)
64
3!:0 (n^2x) |5729082486784839
64
/Erling
Den 2017-09-08 kl. 03:19, skrev Don Kelly:
Yet this works
Just to make it clear that this really is an integer, a 64 bit integer,
and that the precision is not lost before it is input to Residue. /Erling
3!:0 [ 5729082486784839
4
[ 5729082486784839
5729082486784839
2x^32x
4294967296
2x^64x
18446744073709551616
Den 2017-09-08 kl. 09:02
The basic problem here is the limits of the IEEE-754 floating point
representation. When you are computing with numbers that are near the max
or min values of the range of numbers representable in the IEEE format,
strange things can happen. Over the years, programmers have learned to live
with this
No: integers do not automatically get converted to extended precision.
Integers simply have sufficient precision for this example.
Thanks,
--
Raul
On Fri, Sep 8, 2017 at 3:02 AM, Erling Hellenäs
wrote:
> An integer is auto-converted to extended precision, but not to rational. Yet
> Residue se
Note that unums are limited precision also, and have their own edge cases.
Thanks,
--
Raul
On Fri, Sep 8, 2017 at 3:25 AM, Skip Cave wrote:
> The basic problem here is the limits of the IEEE-754 floating point
> representation. When you are computing with numbers that are near the max
> or mi
Does the left extended precision argument get converted to an integer
before the Residue operation or is there a special case of the Residue
operation for an extended precision left argument and an integer right
argument? /Erling
Den 2017-09-08 kl. 10:36, skrev Raul Miller:
No: integers do n
You can answer this for yourself by checking datatype on intermediate
arguments and results.
For example:
datatype 14
integer
datatype *: 14
integer
datatype 5729082486784839
integer
datatype (*: 14)|5729082486784839
integer
...
datatype 14 ^ 2x
extended
...
I hope this helps,
--
In hardvare and languages I know of there are no multiplication,
division and subtraction operations acting on a left extended precision
argument and a right integer argument. Since the left extended precision
argument in the general case can not be converted to integer, the
integer would have
We are still diskussing this case, nothing else. Extended left argument
to Residue, integer right argument. /Erling
n=.14
(n^2x) |5729082486784839
147
3!:0 (n^2x)
64
3!:0 (n^2x) |5729082486784839
64
Den 2017-09-08 kl. 11:30, skrev Raul Miller:
You can answer this for you
Raul said: Note that unums are limited precision also, and have their own
edge cases.
Yes, but unums will let you know when an edge case occurs, and give you an
interval within which the correct answer will reside.
Skip
Skip Cave
Cave Consulting LLC
On Fri, Sep 8, 2017 at 3:37 AM, Raul Miller
Ok, yes - if one of the arguments is extended and the other is integer
and the operation supports it, the result will be extended. That said,
this depends on the operation.
Thanks,
--
Raul
On Fri, Sep 8, 2017 at 5:39 AM, Erling Hellenäs
wrote:
> We are still diskussing this case, nothing else
I expect this would tend to decay rather rapidly, for example if you
did something like -/x where x was long and not integer.
Thanks,
--
Raul
On Fri, Sep 8, 2017 at 5:47 AM, Skip Cave wrote:
> Raul said: Note that unums are limited precision also, and have their own
> edge cases.
>
> Yes, but
More specifically: to be mathematically accurate these intervals would
have to represent worst case possibilities. But to be relevant they
would have to represent typical case possibilities. There's an
inherent tension there which really needs some contextual thought by
the developer.
Thanks,
--
Case 3 seems to be working in the latest Beta(8.06.03). The problem
seems to be solved. /Erling
3!:0 (x: n^2)
128
(x: n^2) | 5729082486784839
147
3!:0 (x: n^2)
128
Den 2017-09-07 kl. 20:40, skrev Erling Hellenäs:
Hi all !
Case 1:
3!:0 [ (n^2)
8
(n^2) | 572908248
Hi all !
It seems an IEEE double can hold this value without lost precision. I
don't know what might happen in the calculations. Where the precision is
lost. Maybe something with comparison tolerance.
5729082486784839 - 5729082486784839 - 0.999
1
JWithATwist does not lose precision. H
Hi,
I was curious how J's cousin, APL, deals with this.
So I used Dyalog APL (Version: 15.0.27982.0 64 Unicode) and got a
surprising result:
⍪(¯4 ¯3 ¯2 ¯1 0 1 2 3 4+14*2) | 5729082486784839
0
0
0
0
0
104
0
113
0
Changing from IEE-754 64-bit to IEE-754-2008 128-bit floating po
It appears that Intel supports quad iee 128. How available is this in other
microprocessors as well? Any thoughts of this in J?
On Sep 8, 2017 11:50 AM, "Jimmy Gauvin" wrote:
> Hi,
>
> I was curious how J's cousin, APL, deals with this.
> So I used Dyalog APL (Version: 15.0.27982.0 64 Unicode) a
It appears that the verb ^ may be a large part of the problem (as in
14^2). Check NuVoc /vocabulary/Numeric Precision and go the table for
different verbs . This and the division may be floating point in this case
_
^ ^. -: % %. inexact (complex if needed),
pr
%2 NB. floating
0.5
x: %2 NB. extended
1r2
%1j1 NB. floating
0.5j_0.5
x: %1j1 NB. why not extended?
|domain error
| x:%1j1
Den 3:53 lørdag den 9. september 2017 skrev Don Kelly :
It appears that the verb ^ may be a large part of the problem (as in
14^2). Check NuVoc /v
19 matches
Mail list logo
