"
IMHO the only time it would actually be useful to distinguish between
numerical datatypes is when using extended precision. Perhaps append an "x"
to the last number of an extended precision array if all denominators are 1
(i.e. it is visually impossible to distinguish from an integer array).
"

I definitively agree.  One reason is to make ": really invertible for
extended precision numbers such as, 123456789012345678901234567890x,
instead of,

    ":inv@:": 123456789012345678901234567890x
1.23457e29
   datatype ":inv@:": 123456789012345678901234567890x
floating

I have wished that were the case sometimes.  It is good to know I am not
alone.



On Sat, Aug 20, 2016 at 7:25 AM, Louis de Forcrand <[email protected]> wrote:

> IMHO the only time it would actually be useful to distinguish between
> numerical datatypes is when using extended precision. Perhaps append an "x"
> to the last number of an extended precision array if all denominators are 1
> (i.e. it is visually impossible to distinguish from an integer array).
> I'm saying this because of the dangerous performance loss associated with
> extended precision numbers, and dangerous expressions like "%_1x" or "1 2
> 3x,4 5 6" which return extended precision arrays, and are very similar to
> ones like "%:_1x" or "1 2 3x,4 5 6.5", which "demote" the extended numbers
> to complex or floating point.
>
> Otherwise, among "classic" numerical datatypes, which are all
> mathematically subsets of complex numbers, J primitives are seamless. The
> display is mathematically rigorous (omitting precision loss); two numbers,
> wether they are internally an integer, float, or complex pair, are always
> displayed in the same way if they are mathematically equal.
> A complex number used to represent an interval can also be a natural
> number; this simply implies that its imaginary part is 0.
>
> If you really need to make sure your input is floating point or complex,
> you can use Roger's cmpx and
> float=: %&1
> which is analoguous to it, although I don't really see the need to do this.
> The risky datatype is extended precision; otherwise I wouldn't about types
> in J.
>
> Hope this helps,
> Louis
>
> Sorry for the poor formatting; on mobile.
>
> > On 19 Aug 2016, at 21:05, Skip Cave <[email protected]> wrote:
> >
> > Wow! Being able to distinguish the datatype of a displayed value by it's
> > appearance. And have the ability to control the datatype of a stored
> value
> > by entering the value in the required format. What a novel, (and very
> > useful) idea!
> >
> > Skip
> >
> > Skip Cave
> > Cave Consulting LLC
> >
> > On Fri, Aug 19, 2016 at 9:11 AM, robert therriault <
> [email protected]>
> > 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
>
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
>
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm

Reply via email to