Is it really important what the internal type is for unums? Since 2&x: and +. always create a pair of numbers. +.0 0 0 2 x:0 0 1
On Sat, Aug 20, 2016 at 12: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
