Converting numeric results to smallest valid type would be very
time-consuming.
Henry Rich
On 10/11/2019 6:51 AM, ethiejiesa via Programming wrote:
I assume this is well known by the cognoscenti, but I just ran into a newbie
surprise:
<. _1e_14j0
_1
<. _1e_14 j. 0
0
This came about as I was learning about and playing with the complex floor.
Apparently, the differing behaviour traces back to how tolerance is handled
differently for different numeric types:
(3!:0) 0j0
1
(3!:0) 0 j. 0
16
Tricky. So in the former case, it seems that the number literal parser understands
equivalence classes of types and is lifting numbers to their most specific type. In
the latter case, from the dictionary, 0 j. 0 <--> 0 + 0j1 * 0:
(3!:0) 0 + 0j1 * 0
16
So, in a sense 0 j. 0 is a complex because the return values of + and * are the
_coarser_ of their arguments, which seems to lie in tension with the cleverness
of the number parser.
Perhaps this is all documented clearly somewhere and I just missed it, but I
had fun figuring this one out and wanted to share.
I assume that complex vs. real tolerance is a well-worn discussion topic; however, is
there much on the idea of making field operations "type lifting" in a way
similar to number literal parsing? Not even sure if this a reasonable thing to do.
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
---
This email has been checked for viruses by AVG.
https://www.avg.com
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
