I worked on an APL implementation in 1972 that had exactly what you are proposing. We called them arithmetic progression vectors. The implementation was very successful. But at the end of the day, I decided that the code and complexity required was not justified. It made for many very impressive trivial benchmarks. But made no difference for a real application. As always, it matters where you put your effort.
On Mon, Feb 26, 2018 at 3:15 PM, james faure <[email protected]> wrote: > 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 > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
