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
