(Tip: When you paste into some browsers, you should use the menu option "Paste and match style" to avoid some needless blank lines.)
The difference between J's treatment of 3r1 and 3j1 has to do with some issues documented here: http://www.jsoftware.com/help/dictionary/dictg.htm Basically, integer will automatically get promoted to floating point, and then complex, as needed. So there's no real loss of information there. However, 3r1 is in rational notation and the only type which will automatically get promoted to rational is extended. So J can't get any more efficient than that without losing information in subsequent results. I hope this makes sense? Thanks, -- Raul On Sat, Aug 20, 2016 at 2:06 PM, Skip Cave <[email protected]> wrote: > 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 > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
