I think formating of complex numbers in jsource should be this line.
> fmtD(s,&v->re); if(v->im){I k=strlen(s); *(k+s)='j'; fmtD(1+k+s,&v->im);}
If you can take away the if(v->im) check, it then always displays
both real and imaginary parts. Not sure this should be done but
it looks harmless.
Пт, 19 авг 2016, Skip Cave написал(а):
> Bob,
>
> Thanks! Your hint was exactly what I needed, to help me make my output
> "imaginary-zero-restorer" function.
>
> zr =. (' ';'j')rplc~ ] NB. use the "string replace" verb to put the
> 'j' back in the complex number.
>
> zr '1 0'
> 1j0 NB. we can do it!
>
> Just need to get the real & imaginary parts of a complex number into a text
> string. Robert showed us how to do that:
> +. 1j0
> 1 0
> $ +. 1j0
>
> 2
> NB. Got the complex parts as two separate numbers,
> thanks to Robert. Now convert to a string.
>
> ": +. 1j0
> 1 0 NB. This is a string.
>
> $ ": +. 1j0
>
> 3 NB. See? A string 3 characters long.
>
>
> zr ": +. 1j0
>
> 1j0 NB. Eureka! We did it. The Zero Restorer verb!
>
> $ zr ": +. 1j0
>
> 3 NB. Of course, the zero-restored display is a
> string as well. It has to be, for J to display the zero.
>
> zr ": +. _3.1j0.5
>
> _3.1j0.5 NB. Our Zero Restorer doesn't affect the display of
> other complex numbers.
>
> ". zr ": +. 1j0
>
> 1 NB. Of course if you let J display the complex
> number natively, it steals the zero.
>
>
> Is there a more compact way to define the Zero Restorer verb? The
> string-replace function is probably overkill for what we want to do, and I
> haven't figured out how to include the Real/Imaginary (+. ) and the Format
> (":) inside the Zero Restorer Function.
>
>
> When you think about it, something like J's complex notation is the kind of
> notation that you would need for a native unum-based computational system.
> We don't want to use 'j' for the separator, it's already taken. What if we
> defined a new number format in J, the unum format, that used a 'u' instead
> of a 'j' for intervals. 4 bit unums would look something like this:
>
>
> UNUMS
>
> ┌──┬─────┬──┬─────┬──┬───────┬────┬──────┬─┬─────┬───┬─────┬─┬───┬─┬───┐
>
> │__ │ __u_2 │ _2│_2u_1 │_1 │ _1u_1r2 │ _1r2 │ _1r2u0 │0│ 0u1r2 │
> 1r2 │ 1r2u1 │ 1 │1u2 │2│ 2u_ │
>
> └──┴─────┴──┴─────┴──┴───────┴────┴──────┴─┴─────┴───┴─────┴─┴───┴─┴───┘
>
>
>
> If this was a native format, then we could just do all our unum
> calculations easily. No notation hassle.
>
>
> Skip
>
> Skip Cave
> Cave Consulting LLC
>
> On Thu, Aug 18, 2016 at 11:58 PM, robert therriault <[email protected]>
> wrote:
>
> > Hey Skip,
> >
> > You could capture that structure yourself using +. couldn't you? It may
> > not be as nice as having the display done
> > natively, but the information is not really thrown away.
> >
> > +. 3j0
> > 3 0
> > +. 3
> > 3 0
> >
> > Cheers, bob
> >
> > > On Aug 18, 2016, at 9:44 PM, Skip Cave <[email protected]> wrote:
> > >
> > > If we did have a display verb that could always show the
> > > zero-imaginary-part of complex numbers in storage, then we would have to
> > > use that verb every time we displayed output that might be complex, if we
> > > wanted to see any zero imaginary part.
> >
> > ----------------------------------------------------------------------
> > For information about J forums see http://www.jsoftware.com/forums.htm
> >
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
gpg --keyserver subkeys.pgp.net --armor --export 4434BAB3
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
