You meant to write that (* y) uses absolute precision.
Henry Rich
On 2/22/2021 4:36 PM, Jan-Pieter Jacobs wrote:
If I got it correctly, the purpose is removing near-0 numbers, correct?
I recently used the following for an Advent of Code solution:
list=: 0.210224j2.92605e_98 _7.31512e_99j0.210224
(*|@*)&.+. list
0.210224 0j0.210224
The (*|@*) I picked up from one of the big shots here at the forum, if I
recall correctly. It relies on * using relative precision, making it return
0 for near-zero components.
I hope it's useful!
Best regards,
Jan-Pieter
On Sun, Feb 21, 2021, 19:14 Raul Miller <[email protected]> wrote:
33j15":1j1
1.000000000000000
":1j1
1j1
It looks like that's an issue with the dyadic form of ":
(Using anything larger than j15 for the left argument of ": is rarely
wise, unless you're working with exact or rational numeric types.)
Thanks,
--
Raul
On Sun, Feb 21, 2021 at 9:05 AM Don Guinn <[email protected]> wrote:
A different issue - ": ignores the imaginary part of a number.
33j30":1j1
1.000000000000000000000000000000
On Sun, Feb 21, 2021 at 3:55 AM Raul Miller <[email protected]>
wrote:
Ok, let's walk through this.
First, let's extract the J's binary representation of pi:
' '-.~":(64#2)#:256x#.|.a.i.2(3!:5) o.1
0100000000001001001000011111101101010100010001000010110100011000
To interpret this, let's refer to the wikipedia page on this numeric
format:
https://en.wikipedia.org/wiki/Double-precision_floating-point_format
(];.1~0 1 12 e.~i.@#)' '-.~":#:256x#.|.a.i.2(3!:5) o.1
(];.1~0 1 12 e.~i.@#)' '-.~":(64#2)#:256x#.|.a.i.2(3!:5) o.1
0
10000000000
1001001000011111101101010100010001000010110100011000
The sign flag is zero, which means it's a positive number. Negative
numbers have a sign flag of 1.
The binary exponent is
2b10000000000-1023
1
Or, we've got a binary fraction which we'll be multiplying by 2.
The binary fraction is
2b1.1001001000011111101101010100010001000010110100011000
1.5708
Or, the actual value is:
2*2b1.1001001000011111101101010100010001000010110100011000
3.14159
Our problem is that this is not the actual value of pi, it's just an
approximation.
If we want to work with a better approximation, we might do something
like
this:
pistring=:{{)n
3.14159265358979323846264338327950288419716939937510582097494459
2307816406286208998628034825342117067982148086513282306647093844
6095505822317253594081284811174502841027019385211055596446229489
5493038196442881097566593344612847564823378678316527120190914564
8566923460348610454326648213393607260249141273724587006606315588
1748815209209628292540917153643678925903600113305305488204665213
8414695194151160943305727036575959195309218611738193261179310511
8548074462379962749567351885752724891227938183011949129833673362
}}-.LF
pirat=: (".(pistring,'x')-.'.')%_10x^_2+#pistring
60{.' '-.~":#:(2^64x)*pirat
110010010000111111011010101000100010000101101000110000100011
There's a trailing 0100011 on that binary fraction which would make
our representation just a bit more accurate (but which would also make
J slower, because we would no longer be taking advantage of the
specialized hardware supporting the number format).
This would crop up if we're subtracting something from pi (or adding a
negative number), in a fashion which lops off leading digits from the
representation.
Short form: if we're going to be using + or - on values which are
non-zero multiples of pi, this might matter.
I hope this made sense.
--
Raul
On Sun, Feb 21, 2021 at 2:14 AM 'Bo Jacoby' via Programming
<[email protected]> wrote:
Thank you all for the comments!
Raul wrote: "A cost, though, of that kind of approach, is that it
would
lure us into a false sense of security, leaving us even more upset in
other
circumstances."
Which circumstances are you thinking of?
The rounding to zero is beneficial in all the cases mentioned in the
comments, and I fail to construct examples where it is not.
(^ j. 1p1) NB. confusing
_1j1.22465e_16
f0(^ j. 1p1) NB. clear
_1
f0 9e99j1e6
9e99
Thanks.
Bo.
Den søndag den 21. februar 2021 07.32.51 CET skrev Joey K Tuttle
<
[email protected]>:
Ahh for the good ole days ;-)
JVERSION
Binary: j601binc_linux32
Library: j601libc
Help: j601hlpc
Engine: j601/2006-11-17/17:05
^ o.0j1
_1
^j.1p1
_1
But time marches on and things change ...
JVERSION
Installer: j602a_linux32.sh
Engine: j602/2008-03-03/16:45
Library: 6.02.023
^ o. 0j1
_1j1.22461e_16
(^j.1p1)
_1j1.22461e_16
JVERSION
Engine: j903/j64avx2/darwin
Beta-e: commercial/2021-02-16T18:34:19
Library: 9.03.01
Platform: Darwin 64
Installer: J903 install
InstallPath: /applications/j903
Contact: www.jsoftware.com
^j.1p1
_1j1.224646799e_16
NB. but even today the formatted result is satisfying.
33j30 ": ^ o. 0j1
_1.000000000000000000000000000000
On 2021Feb 20, at 11:12, Henry Rich <[email protected]> wrote:
No, the code is still there, but it doesn't do much - gives a
little
bit better precision on large arguments IIRC.
Henry Rich
On 2/20/2021 2:10 PM, Roger Hui wrote:
https://www.jsoftware.com/papers/APLQA.htm#worldmathsday
* ○ 0j1 × 2e9 + a ÷ 2
1 0J1 ¯1 0J¯1
1 0J1 ¯1 0J¯1
1 0J1 ¯1 0J¯1
(Basically, ^ o. 0j1 * 2e9 + a % 2 where a=: 3 4$i.12)
I thought I did the same in J, predating what's done in Dyalog
APL.
According to
https://www.jsoftware.com/help/dictionary/special.htm,
there
is supposed to be special code for ^@o., but apparently it got
lost
somewhere, sometime.
On Sat, Feb 20, 2021 at 9:45 AM Raul Miller <
[email protected]>
wrote:
On Sat, Feb 20, 2021 at 12:46 AM María Magdalena Mixuhca
<[email protected]> wrote:
I find this lack of beauty surprisingly disturbing:
(^ j. 1p1)
_1j1.22465e_16
Ok... so...
I think what we want here is a handling of
exponentials/transcendentals so that necessarily minimal
deviations
from pi are smoothly handled so that we get zeros when we expect
them.
A cost, though, of that kind of approach, is that it would lure
us
into a false sense of security, leaving us even more upset in
other
circumstances.
Still... it's an interesting challenge.
Thanks,
--
Raul
----------------------------------------------------------------------
For information about J forums see
http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see
http://www.jsoftware.com/forums.htm
--
This email has been checked for viruses by AVG.
https://www.avg.com
----------------------------------------------------------------------
For information about J forums see
http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see
http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see
http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
--
This email has been checked for viruses by AVG.
https://www.avg.com
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
