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
