On reflection my real question is; should mod suddenly and without warning give
the wrong answer when a number gets suffiently large? I have been caught by
this many times. The incorrect answer zero is problematic as it suggests
divisibility.
Apologies if this has all been discussed before.
R
The answer, oddly enough, is: yes.
The philosophical arguments are buried here:
https://en.wikipedia.org/wiki/Accuracy_and_precision
The technical issues are buried here:
https://en.wikipedia.org/wiki/IEEE_754
That said, if you have reason to be using numbers which are precise
beyond anyon
Thanks Raul, I am familiar with these ideas, and using x: is almost a reflex
now.
I feel that to protect the new J user, mod should convert to extended precision
automatically or issue an warning message. Giving tha answer zero is very
misleading.
PS I am not so concerned with small numbers an
Those proposals would cause operations on large arrays to
intermittently stall or spam.
FYI,
--
Raul
On Thu, Sep 7, 2017 at 7:54 AM, Rob B wrote:
> Thanks Raul, I am familiar with these ideas, and using x: is almost a reflex
> now.
>
> I feel that to protect the new J user, mod should conver
I would sooner get the right answer slowly than the wrong answer quickly.
Regards, Rob.
> On 7 Sep 2017, at 13:48, Raul Miller wrote:
>
> Those proposals would cause operations on large arrays to
> intermittently stall or spam.
>
> FYI,
>
> --
> Raul
>
>
>> On Thu, Sep 7, 2017 at 7:54 AM,
Rob,
To get your right answer, you have to ask the right question. It seems in
your case the right question has x: and for others the right question does
not.
On Thu, Sep 7, 2017 at 9:17 AM, Rob B wrote:
> I would sooner get the right answer slowly than the wrong answer quickly.
>
> Regards, Ro
How would a new user know that using mod with large numbers was 'asking the
wrong question'?
Surely user-friendly code protects the user as its first priority?
Regards, Rob.
> On 7 Sep 2017, at 14:24, Eric Iverson wrote:
>
> Rob,
>
> To get your right answer, you have to ask the right questi
Very nice demo. I suspect Ian is particularly interested in safari so he
will have to dig into that. My guess is that the BroadcastChannel is a
fairly simple thing built on top of the underlying localstorage mechanism
and I know that works in safari.
On Thu, Sep 7, 2017 at 1:45 AM, gmj wrote:
>
> (n^2) | 5729082486784839
>
> is promoted to float, and loses precision. Same when the big number is
> extended - it's converted to float.
>
Hello,
I still do not understand the logic here. Why do these three differ?
n =. 14
(*: n) | 5729082486784839
147
(n^2) | 5729082486784839
0
(n*n) | 5
Primality testing is a much less common use case than you think, and in
fact I'm not aware of any use for extended-precision integers outside of
recreational mathematics (I guess you can count cryptography, but anyone
using extended-precision integers instead of large fixed-width integers
for that
Elementary linear algebra breaks down for so-called ill-conditioned problems
needing more precision than is provided by standard floating point numbers.
Condition number
|
| |
Condition number
The condition number is an application of the derivative, and is formally
defined as the valu
Never assume that floating point numbers are exact.
On Sep 7, 2017 10:50 AM, "'Bo Jacoby' via Programming" <
programm...@jsoftware.com> wrote:
> Elementary linear algebra breaks down for so-called ill-conditioned
> problems needing more precision than is provided by standard floating point
> numb
Marshall, thanks for replying.
You're right my main use of J is recreational mathematics although I'm only
vaguely aware of Project Euler.
I do not entirely understand how this thread came to be about performance.
I presume this is to do with my mention of automatic conversion to extended
preci
Don,
It's not just that giving an answer of zero instead of 147 is 'imprecise'. It
is horribly wrong, as it implies divisibility where none exists.
Regards, Rob.
> On 7 Sep 2017, at 18:40, Don Guinn wrote:
>
> Never assume that floating point numbers are exact.
>
> On Sep 7, 2017 10:50 AM, "
Where would a new user get those large numbers?
That said, new users should be expected to either (a) read the
documentation, or (b) be puzzled at times and perhaps have to talk
with people.
In this case, http://www.jsoftware.com/help/dictionary/dcons.htm might
be relevant.
Thanks,
--
Raul
On
It's an issue of performance and choices, and it is not a problem of |. You
might really want to read those wikipedia entries. Here is roughly what j is
thinking:
n=.14^2
5729082486784839 = 5729082486784839 + n
1
If you can't reason within your problem domain and can't foresee precision
datatype *: 14
integer
datatype 14^2
floating
integer has 63 significant bits, floating has 53.
2^.+:^:(~: >:)^:_] 1
63
2^.+:^:(~: >:)^:_] 1^2
44
44 is actually an artifact of something else, which is comparison
tolerance. To see the full precision, we'll need to override that:
2
Since the consensus seems to be that this is acceptable, I will say no more.
Thanks for taking the time to reply.
Regards, Rob.
> On 7 Sep 2017, at 19:05, Raul Miller wrote:
>
> Where would a new user get those large numbers?
>
> That said, new users should be expected to either (a) read the
I'm not sure "acceptable" is nuanced enough - it's definitely an issue
worth understanding.
That said, mathematics routinely deals with infinities and computers
are always finite. This creates inevitable tensions and design
tradeoffs, regardless of the context.
However, in some contexts those tra
Never shy away from public channels. Can you at least tell me which part is
insulting?
I usually do the following substitutions:
.
It's an issue of performance and choices, and it is not a problem of |. I
might really want to read those wikipedia entries. Here is roughly what j is
thin
Hi all !
Case 1:
3!:0 [ (n^2)
8
(n^2) | 5729082486784839
0
It is non-intuitive that an integer raised to an integer is a float, but
I think it is normal. It would be possible with a performance penalty to
get an integer result. One problem with that is that it would easily
overflo
> On Sep 7, 2017, at 1:40 PM, Erling Hellenäs wrote:
>
> It is non-intuitive that (*: n) does not give the same result as (n^2). Maybe
> once this was decided because of performance reasons.
Just like, in C, I always do x*x, instead of pow(x,2).
---
The modulus operation is very widely used, and that's precisely why your
proposal would not be good for J. What I mean is that while there are a
few people using modulus on large integers for various experiments in
number theory, there are also a huge number of people using modulus on
small floatin
The definition in J dictionary is for classroom teaching. In real world ^
is implemented using hardware.
You may work around using <.14^2
On Sep 7, 2017 11:43 PM, "Rudolf Sykora" wrote:
> (n^2) | 5729082486784839
>
> is promoted to float, and loses precision. Same when the big number is
> ext
Yet this works
n=:14
(n^2x) |5729082486784839
147
Don Kelly
On 2017-09-07 11:40 AM, Erling Hellenäs wrote:
Hi all !
Case 1:
3!:0 [ (n^2)
8
(n^2) | 5729082486784839
0
It is non-intuitive that an integer raised to an integer is a float,
but I think it is normal. It would be pos
That's interesting, Don,
,.((_4+i.7)+n^2x)|5729082486784839
135
146
23
39
147
104
171
,.((_4+i.7)+n^2)|5729082486784839
0
0
0
0
0
0
0
Linda
Sent from AOL Mobile Mail
On Thursday, September 7, 2017 Don Kelly wrote:
Yet this works n=:14 (n^2x) |5729082486784839 147 Don Kelly
On 201
Yes, it might just have happened, since every programmer would choose
the most efficient operation. However, if you want to use the language
as an algebra, in which you can convert expressions into other
equivalent expressions, it is a complication which might not be
considered necessary. /Erli
27 matches
Mail list logo
