I thought one of the issues with GMP would be memory management, but it looks like it could hook into J's system:
https://gmplib.org/manual/Custom-Allocation.html Another issue, of course, is programmer time - there's a good amount that would need to change. -- Raul On Mon, Feb 26, 2018 at 3:37 PM, Jose Mario Quintana <[email protected]> wrote: >> Secondly: operations on extended precision numbers are unbelievably > slow... The most direct example: '! 100000x' takes 50 (!) times longer than > python3's math.factorial(100000). It should be well worth looking into > llvm's APInt and APfloats<http://llvm.org/doxygen/classllvm_1_1APInt.html>, > or perhaps Cpython's bigint's, I wouldn't think it's necessary to write > another custom library > > My $0.02... > > J might be a "general-purpose, high-performance programming language" but > it is low-performance for arbitrary-precision arithmetic, operating on > signed integers, rational numbers, and it lacks (arbitrary-precision) > floating point numbers. This is hardly breaking news (e.g., [0, 1]) and a > potential solution, using GMP [2], has also been apparent [0, 1]. > > Other languages are using GMP: "The basic interface is for C but wrappers > exist for other languages including Ada, C++, C#, Julia, .NET, OCaml, Perl, > PHP, Python, R, Ruby and the Wolfram Language." > > Why is J not using GMP? Reasons could be economical (distribution of > resources), technical (compatibility), legal, etc. I have no idea. > > [0] [Jforum] Mathematica v APL > http://www.jsoftware.com/pipermail/general/2005-July/023651.html > > [1] [Jprogramming] Comparing J speed > > http://www.jsoftware.com/pipermail/programming/2015-September/042728.html > > [2] GNU Multiple Precision Arithmetic Library Wikipedia > https://en.wikipedia.org/wiki/GNU_Multiple_Precision_Arithmetic_Library > > > > On Mon, Feb 26, 2018 at 12:48 PM, james faure <[email protected]> > wrote: > >> I have 2 major propositions: >> >> Recently, I (to my chagrin) demonstarted to a friend that '>: i.1e7' takes >> almost twice as long as 'i.1e7'. Of course I expected them both to execute >> instantly, not after a full second. So my suggestion: i. should return a >> 'range' (or 'i.') object containing three vars: 'start end step'. In this >> way, '+ - * %' and indeed any linear combination of linear operations can >> be executed on only 3 variables rather than #y . besides the immediate >> speed and memory improvements here, other operations (on i. objects), like >> '+/ */ e. i.' etc.. can now be found by direct calculation, without ever >> spawning a physical array! Another fascinating possibility becomes >> available: 'i._'. Thus something like '*/ x * y ^ - i. _' is now able to >> return the result of the infinite geometric series. In fact in general it >> may be very profitable to use virtual arrays only, unless forced otherwise. >> Another concrete example: when searching for the first number to satisfy a >> certain property, one could use 'i.@u seq i. _' rather than some likely >> inefficent variation of ^: or while. . Perhaps this 'array only when >> forced' approach may even void the need for special combinations, a concept >> which feels suspicious to me. >> >> Secondly: operations on extended precision numbers are unbelievably >> slow... The most direct example: '! 100000x' takes 50 (!) times longer than >> python3's math.factorial(100000). It should be well worth looking into >> llvm's APInt and APfloats http://llvm.org/doxygen/classllvm_1_1APInt.html, >> or perhaps Cpython's bigint's https://github.com/python/cpython/blob/ >> 65d4639677d60ec503bb2ccd2a196e5347065f27/Objects/longobject.c, I wouldn't >> think it's necessary to write another custom library. >> >> James Faure >> ---------------------------------------------------------------------- >> 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
