Bind is not relevant here, since I'm talking about the execution of i., which must inevitably happen at some point to be of any use.
Also, I don't see how there could possibly be a tradeoff between the time taken to write the results of a multiplication and evaluate it. In any event my tests had both python and j print the result of '! y', which should favor j even, since it only writes the first 256 digits, whilst python prints the entire number. James Faure ________________________________ From: Source <source-boun...@forums.jsoftware.com> on behalf of Raul Miller <rauldmil...@gmail.com> Sent: Monday, February 26, 2018 7:08:31 PM To: Source forum Subject: Re: [Jsource] Propositions This is the "sweep it under the rug" design aesthetic - very useful when dealing with infinities and/or any other calculations which you really do not want to perform. That said, J already supports this kind of thing - albeit with slightly different syntax. For example, you can do: i. bind 1e7 and 1 + i. bind 1e7 and J will faithfully not perform the indicated calculations, quite yet (but still stashes them so that if you later change your mind it can instead perform them). And, yes, the current extended precision implementation is slow for multiplications (though fast for display). It's a design tradeoff, and perhaps one which should be reconsidered. (Though memory management and cross platform stability and support are critical issues which can take precedence over mere performance.) Or at least: that's how I understand this issue... Thanks, -- Raul On Mon, Feb 26, 2018 at 12:48 PM, james faure <james.fa...@epitech.eu> 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. [https://avatars2.githubusercontent.com/u/1525981?s=400&v=4]<https://github.com/python/cpython/blob/65d4639677d60ec503bb2ccd2a196e5347065f27/Objects/longobject.c> python/cpython<https://github.com/python/cpython/blob/65d4639677d60ec503bb2ccd2a196e5347065f27/Objects/longobject.c> github.com cpython - The Python programming language LLVM: llvm::APInt Class Reference<http://llvm.org/doxygen/classllvm_1_1APInt.html> llvm.org Class for arbitrary precision integers. APInt is a functional replacement for common case unsigned integer type like "unsigned", "unsigned long" or "uint64_t", but ... > > James Faure > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm J Forums<http://www.jsoftware.com/forums.htm> www.jsoftware.com Forums. The J forum mailing lists give life to the J community. They are the best way to get help, help others, report bugs, and share your interest in J. ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm J Forums<http://www.jsoftware.com/forums.htm> www.jsoftware.com Forums. The J forum mailing lists give life to the J community. They are the best way to get help, help others, report bugs, and share your interest in J. ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
