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
