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
