Apparently this discussion should be in the beta forums: http://jsoftware.com/pipermail/beta/2018-February/009056.html<http://jsoftware.com/pipermail/beta/2018-February/009056.html>
________________________________ From: Source <[email protected]> on behalf of Vijay Lulla <[email protected]> Sent: Monday, February 26, 2018 8:28:57 PM To: [email protected] Subject: Re: [Jsource] Propositions Raul, Your points are very valid and I agree with them. I like J the way it is and will continue using it however it evolves. J does extended precision and Sparse arrays better, and more coherently, than any other language. And the way it deals with edge cases is just beyond compare! I am sorry that my post came across as criticizing J. Cordially, Vijay. On Mon, Feb 26, 2018 at 2:14 PM, Raul Miller <[email protected]> wrote: > *Why* is this good, though? > > If "language x implements it" is all that is needed for something to > be good, then no language can be good, because there are just too many > gimmicks in too many languages. > > Restated: if we introduce a new primitive type (this range thing) then > the interpreter would have to be built with support for this type in > all primitives that currently take numeric arguments. > > That's quite a lot of work (to get an idea of the magnitude of this > effort, note that support for sparse arrays has been stalled "in > progress" for over a decade). So what is the benefit? You wind up > implementing a behind-the-scenes algebra (similar to tacit verbs, in > the general case, though supporting only a scalar addition and an > index vector is an obvious subset of that) which gets executed "as > necessary", > > The biggest benefit I can see is better cpu cache management for a few > calculations involving large arrays. But it seems to me that: > > [a] The obvious cases where this is a significant benefit tend to be > trivial, and > > [b] The non-trivial cases where this is an actual help might benefit > more from the programmer structuring the computation to fit in L2 (or > L3) cache. [Note that this is similar to what you do when you don't > have enough memory for intermediate results.] > > But, also, identifying why it is good can help with the specification > process (the nature of that behind-the-scenes algebra which is a > necessary part of the implementation of this proposal). > > Thanks, > > -- > Raul > > > On Mon, Feb 26, 2018 at 2:01 PM, Vijay Lulla <[email protected]> wrote: > > The "range" idea that James is proposing is a good one! Julia implements > > range like this. And, if I recollect correctly this is also one of the > > fundamental changes between Python 2 and Python 3's range function > > behavior! And if I understand correctly what James is saying is that we > > can do some really clever things with '+ - * %' when i. is not executed. > > For e.g., below is an example of my Julia session explaining what James > is > > getting at: > > > > ---- Julia REPL ---- > > julia> x = 1:2:15 > > 1:2:15 > > > > julia> x > > 1:2:15 > > > > julia> collect(x) > > 8-element Array{Int64,1}: > > 1 > > 3 > > 5 > > 7 > > 9 > > 11 > > 13 > > 15 > > > > julia> x*2 > > 2:4:30 > > > > julia> collect(x*2) > > 8-element Array{Int64,1}: > > 2 > > 6 > > 10 > > 14 > > 18 > > 22 > > 26 > > 30 > > > > julia> dump(x) > > StepRange{Int64,Int64} > > start: Int64 1 > > step: Int64 2 > > stop: Int64 15 > > > > julia> dump(collect(x)) > > Array{Int64}((8,)) [1, 3, 5, 7, 9, 11, 13, 15] > > > > julia> > > ---- End Julia REPL ---- > > > > The main thing to notice is that only when you "collect" a "range" object > > is the actual space allocated (used?). > > > > > > On Mon, Feb 26, 2018 at 1:37 PM, Raul Miller <[email protected]> > wrote: > > > >> I guess I'm not sure what you think the word "execution" means, in the > >> context of this proposition. > >> > >> But it's also not clear to me why you think that all use of i. should > >> require extra complexity which is already available through the use of > >> bind. > >> > >> But there's an additional difficulty, here, which is two unrelated > >> proposals making talking about either of them likely to bring in the > >> other unrelated topic. > >> > >> Thanks, > >> > >> -- > >> Raul > >> > >> > >> On Mon, Feb 26, 2018 at 1:32 PM, james faure <[email protected]> > >> wrote: > >> > 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 <[email protected]> on behalf of Raul > >> Miller <[email protected]> > >> > 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 <[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. > >> > [https://avatars2.githubusercontent.com/u/1525981?s=400&v=4]<https:// > >> github.com/python/cpython/blob/65d4639677d60ec503bb2ccd2a196e > >> 5347065f27/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<http://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<http://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 > >> ---------------------------------------------------------------------- > >> For information about J forums see http://www.jsoftware.com/forums.htm > >> > > > > > > > > -- > > Vijay Lulla, Ph.D. > > > > Assistant Professor, > > Dept. of Geography, IUPUI > > 425 University Blvd, CA-207C. > > Indianapolis, IN-46202 > > [email protected] > > > > <http://vijaylulla.com> > > http://vijaylulla.com > > ---------------------------------------------------------------------- > > 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
