Interesting...
d =. 3j_1 ; 3j0 ; 3j1 3 ; 3.1 ; 3r1
d
┌────┬─┬─────┬───┬─┐
│ 3j_1 │3 │ 3j1 3 │3.1 │3│
└────┴─┴─────┴───┴─┘
datatype @>d
complex
integer
complex
floating
extended
So J "remembers" 3r1 as extended, even though it displays as a '3'.
However, J doesn't remember 3j0, also displayed as a '3'. which is stored
as an integer. Seems like if you "remember" the type of one, you should
"remember" the type of the other.
+. > 0 1 2 3 4 { d
3 _1
0 0
3 0
0 0
3 1
3 0
3.1 0
0 0
3 0
0 0
Not sure what is happening here.
Skip Cave
Cave Consulting LLC
On Sat, Aug 20, 2016 at 9:15 AM, Raul Miller <[email protected]> wrote:
> I believe that types are a necessary evil which should be neglected
> wherever possible.
>
> Sure, ok, it can be fun to make it painful to work with values of different
> types. But that mostly gets in the way when you do not want to focus on
> that particular issue.
>
> The underlying myth, I think, is the very human "make it someone else's
> problem" sort of thing we do when we want to focus on one particular thing.
> But there's no silver bullet and mostly we just wind up trying to sweep
> problems under the carpet when we do this, rather than actually solving
> useful problems.
>
> What we are really, doing, though, is working with engineering tradeoffs.
> It's a matter of what you want to sacrifice and what you want to develop.
>
> Anyways, I'd probably go with another language (one which has strong type
> theory roots) if I wanted to mess with types.
>
> (Though they do come up, also, if I get into implementing the language.
> Which, I suppose, serves to emphasize the point...)
>
> Thanks,
>
> --
> Raul
>
> On Sat, Aug 20, 2016 at 2:06 AM, dhkelly <[email protected]> wrote:
>
> > That makes sense as xry does involve the need for longer denominators and
> > numerators as with extended precision.
> >
> > 3!:0[15.5j10
> >
> > 16
> >
> >
> > 3!:0[15
> >
> > 4
> >
> > 3!:0[15.01234567
> >
> > 8
> >
> > 3!:0[1j15.36
> >
> > 16
> >
> > 3!:0[1j0
> >
> > 1
> >
> > 3!:0[20j0
> >
> > 4
> >
> > 3!:0[2j0
> >
> > 4
> >
> > 3!:0[2.45j0
> >
> > 8
> >
> > 3!:0[0j1
> >
> > 16
> >
> > 3!:0[1j1
> >
> > 16
> >
> > 3!:0[0j0
> >
> > 1
> >
> > It appears that the memory is dependent on being boolean, integer,
> > floating point or complex - in general it appears that J tries to
> minimize
> > storage by looking at the actual value- boolean, integer, float, with
> > exceptions "r" or "x" in most cases. (this may be a throwback to the
> stage
> > that memory was a serious issue for APL and other languages ). In the
> last
> > cases
> >
> > there is a change and the effect of this change may affect some
> operations
> > on complex numbers -as I recall, without checking, these are noted in the
> > vocabulary.
> >
> >
> > Do we really need, for most of the applications involving complex
> numbers,
> > that are not covered in J as it stands?
> >
> >
> > Don Kelly
> >
> >
> >
> >
> > On 8/19/2016 9:01 PM, Roger Hui wrote:
> >
> >> These are not bugs. 3r1 and 3x are not "demoted" to facilitate
> >> incorporating extended precision numbers into the language.
> >>
> >>
> >>
> >> On Fri, Aug 19, 2016 at 8:42 PM, bill lam <[email protected]> wrote:
> >>
> >> Actually rational 3r1 does not demoted to integer after parsing,
> >>> 3r1
> >>> 3
> >>> 3!:0[3r1
> >>> 64
> >>>
> >>> Similarly for extended integer
> >>> 3x
> >>> 3
> >>> 3!:0[ 3x
> >>> 64
> >>>
> >>>
> >>> Perhaps this is a bug but I cannot be sure.
> >>>
> >>> Пт, 19 авг 2016, dhkelly написал(а):
> >>>
> >>>> Handling 3r1 or 3j0 as being different than 3 does add complexity
> to
> >>>>
> >>> the
> >>>
> >>>> J interpreter
> >>>> without adding anything worth while in the essentially mathematical
> >>>> representation. as 3r1 and 3j0 ARE the integer 3 in any sense.
> >>>>
> >>> Representing
> >>>
> >>>> either differently requires wasting of memory space and associated
> >>>>
> >>> overhead.
> >>>
> >>>> Working with complex numbers is simply recognizing that real numbers
> are
> >>>> along the real (call it x ) axis and the j0 is not needed.
> >>>> Much of the advantage of J and APL are that if a number is
> >>>> sufficiently
> >>>> close to an integer -treat it as such and let the idiot box sort it
> out.
> >>>> Put it this way, would you like to carry this to the extreme and
> >>>>
> >>> represent
> >>>
> >>>> all numbers in the same format (3j0)r(1j0) and God help us where
> floats
> >>>>
> >>> are
> >>>
> >>>> concerned.
> >>>> As Bob has suggested - the use of +. does the job of getting from 1j0
> >>>>
> >>> to 1
> >>>
> >>>> 0 as it also does for getting from 1 to 1 0 (+.1 is 1 0 correctly).
> >>>>
> >>>> The set of real numbers and real fractions (either as rational or
> >>>>
> >>> float) is
> >>>
> >>>> simply a subset of the set of complex numbers - a "complex" number of
> >>>>
> >>> 1jo
> >>>
> >>>> is the real number 1
> >>>>
> >>>> In other words, the mathematical use of complex numbers or rational
> >>>> fractions in J is elegant. Expressing numbers such as 3r1 or 3j0 as
> >>>> formatted character pairs (3,1) .(3,0)
> >>>> appears to be of little use but I would like to see applications where
> >>>>
> >>> this
> >>>
> >>>> is needed.
> >>>>
> >>>> Don Kelly
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> On 8/19/2016 7:11 AM, robert therriault wrote:
> >>>>
> >>>>> Bill,
> >>>>>
> >>>>> If you extended this idea to rationals so that 3r1 displayed as 3r1
> >>>>>
> >>>> instead of 3 then you would have a way to distinguish rational and
> >>> extended
> >>> types from integers.
> >>>
> >>>> This could be done with floats as well, so that by including the
> >>>>>
> >>>> decimal point and the right 0, you could immediately see that 1.0 was
> a
> >>> float result and was different from the integer 1.
> >>>
> >>>> Unicode and literal would still be a challenge to differentiate using
> >>>>>
> >>>> text alone, but being able to clearly differentiate the numerical
> types
> >>> through text display may be something to think about.
> >>>
> >>>> Cheers, bob
> >>>>>
> >>>>> On Aug 19, 2016, at 12:58 AM, bill lam <[email protected]> wrote:
> >>>>>>
> >>>>>> 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.
> >>>>>>
> >>>>> ------------------------------------------------------------
> ----------
> >>>>> 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
> >>>
> >> ----------------------------------------------------------------------
> >> 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
