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
> > 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
> ----------------------------------------------------------------------
> 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
