Getting a 1..100 vector

[oliverue]

Does someone see a better way to get a vector [1..100] than using one
of these snippets?

≪ ≪i≫ 'i' 1 100 1 SEQ AXL ≫

≪ { 100 } 0 CON 1 AXL ≪ DROP NSUB ≫ DOSUBS AXL ≫

Thanks.

[Vurgil]

In article
<06c1094f-25fc-4d79...@y10g2000vbn.googlegroups.com>,

oliverue <oliv...@hotmail.com> wrote:

> Does someone see a better way to get a vector [1..100] than using one
> of these snippets?
>

> ŷ ŷiŒ 'i' 1 100 1 SEQ AXL Œ
>
> ŷ { 100 } 0 CON 1 AXL ŷ DROP NSUB Œ DOSUBS AXL Œ
>
> Thanks.

\<< {} 1 100 FOR i i + NEXT AXL \>>
is about s simple as it gets.

[John H Meyers]

1 100 FOR x x NEXT DUP \->ARRY

[Vurgil]

In article <4F277B15...@nomail.invalid>,

John H Meyers <jhme...@nomail.invalid> wrote:

> 1 100 FOR x x NEXT DUP \->ARRY

Might have guessed you'd have a good one!

[oliverue]

On Jan 31, 6:24 am, John H Meyers <jhmey...@nomail.invalid> wrote:
> 1 100 FOR x x NEXT DUP \->ARRY

Thanks, John and Vurgil.

John's is nice because it avoids adding to a list which comes at non-
linear expense, as we know.

I'll compare timings against the SEQ version. I figured SEQ was faster
for larger vectors (say, 10,000 elements) because it doesn't need the
interpreter for the loop. (FOR-loops are really slow, for some
reason.)

[oliverue]

Whoa. Emu48 49G benchmark results:

1..1000
SEQ: 2.6s
DOSUBS: 4.2s
FOR & {} +: minutes
FOR & ->ARRY: 1.5s

1..10000
SEQ: probably forever (couldn't CANCEL after minutes!)
DOSUBS: after 2 minutes: Insufficient memory
FOR & {} +: probably forever
FOR & ->ARRY: 9.5s

Moral: John's solution is the *only* one to go for for larger values.
Likely implication about SEQ: also uses slow list adds internally
(which makes it impractical for use for anything past 100 or so...)

[John H Meyers]

On 1/31/2012 4:41 AM, oliverue wrote:

> I'll compare timings against the SEQ version. I figured SEQ was faster
> for larger vectors (say, 10,000 elements) because it doesn't need the
> interpreter for the loop. (FOR-loops are really slow, for some reason.)

FOR is fast when the limits are "real-valued,"
slower when "integer-valued," particularly for longer integers,
because "integer arithmetic" is performed in memory, digit by digit,
rather than in processor registers. SysRPL versions of FOR,
using "bint" limits (20-bit internal unsigned integers), are particularly fast.

As to SEQ, have anti-shock medication on hand before reading this:

"How SEQ works (or doesn't!), plus S/SX version"
<http://groups.google.com/group/comp.sys.hp48/msg/627c4479ff9da448>


As to why it pays to generate individual elements and defer \->ARRY
until the end, it has always been known, as well as being taught
by example throughout ROM and in SysRPL texts, that processing "meta objects"
(individual elements followed by a counter) on the stack
is the fastest way to handle large lists,
and numerous SysRPL functions exist to perform such actions
as SWAP, ROT, etc. among meta-objects themselves on the stack,
in an already optimized manner.

[r->] [OFF]

[Travis Evans]

On Tue, 31 Jan 2012 11:28:44 -0600, John H Meyers
<jhme...@nomail.invalid> wrote:
> On 1/31/2012 4:41 AM, oliverue wrote:
>
>> I'll compare timings against the SEQ version. I figured SEQ was faster
>> for larger vectors (say, 10,000 elements) because it doesn't need the
>> interpreter for the loop. (FOR-loops are really slow, for some reason.)
>
> FOR is fast when the limits are "real-valued,"
> slower when "integer-valued," particularly for longer integers,
> because "integer arithmetic" is performed in memory, digit by digit,
> rather than in processor registers. SysRPL versions of FOR,
> using "bint" limits (20-bit internal unsigned integers), are particularly fast.
>
> As to SEQ, have anti-shock medication on hand before reading this:
>
> "How SEQ works (or doesn't!), plus S/SX version"
> <http://groups.google.com/group/comp.sys.hp48/msg/627c4479ff9da448>

Wow, *that* is what I call a lazy approach to implementation. And now I
know that the AUR holds some dirty secrets if you read between the
lines. ;-)

> As to why it pays to generate individual elements and defer \->ARRY
> until the end, it has always been known, as well as being taught
> by example throughout ROM and in SysRPL texts, that processing "meta objects"
> (individual elements followed by a counter) on the stack
> is the fastest way to handle large lists,
> and numerous SysRPL functions exist to perform such actions
> as SWAP, ROT, etc. among meta-objects themselves on the stack,
> in an already optimized manner.

Indeed, and the funny thing is that it's perhaps not all that intuitive.
When I was starting out, it was a little while before I even considered
this option, since (to me, at least) it would seem like a particularly
expensive operation compared to other strategies, but in reality it's by
far the fastest.

--
Travis Evans

[John H Meyers]

On 2/1/2012 5:48 AM, Travis Evans wrote:

>> As to SEQ, have anti-shock medication on hand before reading this:
>>
>> "How SEQ works (or doesn't!), plus S/SX version"
>> <http://groups.google.com/group/comp.sys.hp48/msg/627c4479ff9da448>

> Wow, *that* is what I call a lazy approach to implementation.

I think that the creators of the HP48 series were anything but lazy.

There are times when it makes much more sense to accomplish something elegant
with minimal extra work, extra time, extra debugging, or bloated extra code.

"Life is short, and ROM is full"
- Bill Wickes, "father" of the HP48 series

<http://www.amazon.com/dp/0962525839>
<http://www.amazon.com/William-C-Wickes/e/B000APC37S/>

-[ ]-

[Travis Evans]

I understand. I think I may have misunderstood you, then--I thought you
were critiquing the internal code. That, and the fact that over on the
TI calculator side of things we're accustomed to TI's developers
routinely implementing truly inelegant, unnecessary hoops in their OS
code, probably led me to jump to that conclusion. I apologize if I
offended anybody.

Still, though, I have to ask: What is the reason for creating a text
string and then compiling and then executing it, rather than executing
looping code directly in the ROM and evaluating the given formula or
expression in the body?

--
Travis Evans

[John H Meyers]

On 2/7/2012 6:11 AM, Travis Evans wrote:

> Still, though, I have to ask: What is the reason for creating a text
> string and then compiling and then executing it, rather than executing
> looping code directly in the ROM and evaluating the given formula or
> expression in the body?

I wasn't involved in creating the ROM,
but I already supplied a speculation in my post:

> There are times when it makes much more sense to accomplish something elegant
> with minimal extra work, extra time, extra debugging, or bloated extra code.
>
> "Life is short, and ROM is full"
> - Bill Wickes, "father" of the HP48 series

[Bills original books on HP48 design are listed at Amazon.com]

There is plenty more UserRPL in the ROM, which you might encounter while exploring.

I have seen cases where someone has thought that machine coding (ML)
was the way to go, and made a large ML program to perform VARS fast;
however, a 40-byte SysRPL loop can nearly match it.

The "bottom line" is how economical the entire universe is
when all parts act together,
not how much engineering can be invested in one part at a time.

[r->] [OFF]