I can reproduce this. The problem boils down to:
0j0.099999241037416198 | 0.099999241037430409j0
_0.0999992
Because of the definitions of complex residue and complex floor, some
residues like this one create results that are about the same magnitude
as the arguments. Then the Euclid's algorithm that the JE uses fails to
terminate.
For the next release I have made it return 0 if the algorithm takes too
long.
Henry Rich
On 10/17/2019 7:22 PM, ethiejiesa via Beta wrote:
From a fresh jconsole session:
9!:14''
j901/j64/linux/beta-k/commercial/www.jsoftware.com/2019-09-16T17:03:03
0j1 +. 0.1 + i.16
1.11022e_16 4.44089e_16 4.44089e_16 ...
0j1 +. 16.1 NB. hangs
Forgive the spam if this is a known issue and fixed in a later beta. Is the
above known and reproducible on your machines?
About the only useful thing I can provide is a gdb backtrace. Cutting out the
useless bit at the bottom:
#0 0x00007ffff7a6cbcc in jtzrem () from /j901/bin/libj.so
#1 0x00007ffff7a6cd21 in jtzgcd () from /j901/bin/libj.so
#2 0x00007ffff79cde6f in gcdZZ () from /j901/bin/libj.so
#3 0x00007ffff7996ca8 in jtva2 () from /j901/bin/libj.so
#4 0x00007ffff7995a6d in jtatomic2 () from /j901/bin/libj.so
#5 0x00007ffff796f7b9 in jtparsea () from /j901/bin/libj.so
#6 0x00007ffff796efe0 in jtparse () from /j901/bin/libj.so
#7 0x00007ffff7971aef in jtimmex () from /j901/bin/libj.so
#8 0x00007ffff79666a3 in jdo () from /j901/bin/libj.so
#9 0x00007ffff7966ac0 in JDo () from /j901/bin/libj.so
#10 0x0000000000401df0 in main ()
General pointers on J debugging certainly welcome. I would love to give more
useful bug sleuthing details.
Cheers,
----------------------------------------------------------------------
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
