A minichallange for those who have *never before* taken part!
Write the SHORTEST routine that eliminates the same TYPE of element
     2: list
     1: element of which type is desired to be eliminated
 RELEMTYPE
     1: list
 Note:
Recall 'RELMTYPE' program contenst to stack and do BYTES
 to get the bytes of the program itself + checksum

Restrictions:
1) It must work correctly on an empty list too
2) The remaining elements have to be in their original order
3) No downloaded external libraries
4) UserRPL only, no SYSEVAL, LIBEVAL, FLASHEVAL
5) Be honest: don't ask for help from anyone!

Categories:
A) 48-series: 48S, 48SX, 48G, 48G+, 48GX
B) 49-series: 48gII, 49G, 49g+
C) 49-series using also manually attachable "secret" libraries
    Contestants are urged to dig information using internet.

The challange ends at 12.12.2004 midnight greenw. time
(regardless of D.MY/M.DY setting)

James M. Prange is invited to be the Great Judge!
:-D
[VPN]

Here's mine 164.5 bytes
\<< 0. \-> a b c
  \<< a OBJ\-> DUP 'c' STO { } 'a' STO
    WHILE 0. \=/
    REPEAT DUP TYPE b SAME { DROP }
      \<< 1. \->LIST a + 'a' STO
      \>> IFTE 'c' DECR
    END a
  \>>
\>>
 RDElm

"Veli-Pekka Nousiainen" <DROP_vpn@THIS.welho.com> wrote in message
news:coi21a$ugm$1@nyytiset.pp.htv.fi...
> A minichallange for those who have *never before* taken part!
> Write the SHORTEST routine that eliminates the same TYPE of element
>      2: list
>      1: element of which type is desired to be eliminated
>  RELEMTYPE
>      1: list
>  Note:
> Recall 'RELMTYPE' program contenst to stack and do BYTES
>  to get the bytes of the program itself + checksum
>
> Restrictions:
> 1) It must work correctly on an empty list too
> 2) The remaining elements have to be in their original order
> 3) No downloaded external libraries
> 4) UserRPL only, no SYSEVAL, LIBEVAL, FLASHEVAL
> 5) Be honest: don't ask for help from anyone!
>
> Categories:
> A) 48-series: 48S, 48SX, 48G, 48G+, 48GX
> B) 49-series: 48gII, 49G, 49g+
> C) 49-series using also manually attachable "secret" libraries
>     Contestants are urged to dig information using internet.
>
> The challange ends at 12.12.2004 midnight greenw. time
> (regardless of D.MY/M.DY setting)
>
> James M. Prange is invited to be the Great Judge!
> :-D
> [VPN]
>
>

Try this...

Checksum:  # BDABh
Bytes:  120

%%HP: T(3)A(D)F(.);
\<< { } \-> a b
  \<< OBJ\->
    IF DUP 0 ==
    THEN DROP
    ELSE 1 SWAP
      START DUP
TYPE a
        IF ==
        THEN DROP
        ELSE 1
\->LIST 'b' STO+
        END
      NEXT
    END b
  \>>
\>>



Kevin J

remove_the_Zs_kjessupZ@charZterZ.net


"Veli-Pekka Nousiainen" <DROP_vpn@THIS.welho.com> wrote in message
news:coi21a$ugm$1@nyytiset.pp.htv.fi...
> A minichallange for those who have *never before* taken part!
> Write the SHORTEST routine that eliminates the same TYPE of element
>      2: list
>      1: element of which type is desired to be eliminated
>  RELEMTYPE
>      1: list
>  Note:
> Recall 'RELMTYPE' program contenst to stack and do BYTES
>  to get the bytes of the program itself + checksum
>
> Restrictions:
> 1) It must work correctly on an empty list too
> 2) The remaining elements have to be in their original order
> 3) No downloaded external libraries
> 4) UserRPL only, no SYSEVAL, LIBEVAL, FLASHEVAL
> 5) Be honest: don't ask for help from anyone!
>
> Categories:
> A) 48-series: 48S, 48SX, 48G, 48G+, 48GX
> B) 49-series: 48gII, 49G, 49g+
> C) 49-series using also manually attachable "secret" libraries
>     Contestants are urged to dig information using internet.
>
> The challange ends at 12.12.2004 midnight greenw. time
> (regardless of D.MY/M.DY setting)
>
> James M. Prange is invited to be the Great Judge!
> :-D
> [VPN]
>
>

Veli-Pekka Nousiainen wrote:
> A minichallange for those who have *never before* taken part!
> Write the SHORTEST routine that eliminates the same TYPE of element

"SHORTEST" meaning the smallest size (in bytes) returned by the
BYTES command on the program itself; not the size when you run
BYTES on the program's quoted name. Execution time doesn't matter
in this particular minichallenge.

>      2: list
>      1: element of which type is desired to be eliminated

Meaning that the level 1 argument should be a "real number"
representing the type to be eliminated, such as 0 for reals
numbers, 1 for complex numbers, 2 for characters strings, and so
on, not an example of the type to be eliminated. Right,
Veli-Pekka?

Argument checking isn't required. In other words, it doesn't
matter what the program does for arguments other than the above.

>  RELEMTYPE
>      1: list
>  Note:
> Recall 'RELMTYPE' program contenst to stack and do BYTES
>  to get the bytes of the program itself + checksum

Please post the checksum and which model you used too, as an aid
to verifying that the program was downloaded or entered correctly.

To make it easier to read and download the program, I recommend
that you upload it to your PC using a Kermit ASCII transfer with
translation mode 3 (Xlat: ->255 in an input form), or use a Conn4x
"text" transfer with all translations enabled. For the 49 series,
have the calculator in exact mode while uploading. Copy and paste
the contents (including the transfer header) of the file to your
post. Of course, you can type in the program instead; if I don't
get the same checksum and size, then I'll ask for clarification.

For the 49 series, please be particularly careful of the
difference between real numbers (type 0) and exact integers (type
28); if you intend a real number, then include a decimal point.

> Restrictions:
> 1) It must work correctly on an empty list too

That is, if the level 2 argument is an empty list, then it must
return an empty list without causing an error.

> 2) The remaining elements have to be in their original order
> 3) No downloaded external libraries
> 4) UserRPL only, no SYSEVAL, LIBEVAL, FLASHEVAL
> 5) Be honest: don't ask for help from anyone!

But I'd encourage everyone to make use of whatever other resources
they can find, for example, the Google archive of this newsgroup.

6) Anything besides the arguments that was on the stack should
   still be there when the program ends. For example, clearing the
   stack is not acceptable, unless the program also restores it.
   Similarly, it shouldn't KILL any suspended programs, or purge
   or change any pre-existing variables.

7) Must not be mode or flag dependent. For example, it should work
   in both exact and approximate modes, and with or without last
   arguments saves (flag -55) enabled. It may change a flag while
   running, but if it does, then it must restore the original
   state.

> Categories:
> A) 48-series: 48S, 48SX, 48G, 48G+, 48GX

Considering the changes to list processing, let's split that into
two categories; one for the 48S and 48SX, and another for the 48G,
48GX, and 48G+.

> B) 49-series: 48gII, 49G, 49g+

I don't have a 48gII, but I expect that if it works on one of
these, then it ought to work on all of them. If it turns out
otherwise, let's just say that it must work on at least one of
them.

> C) 49-series using also manually attachable "secret" libraries
>     Contestants are urged to dig information using internet.

Of course, it could happen that one entry wins in more than one
category.

> The challange ends at 12.12.2004 midnight greenw. time
> (regardless of D.MY/M.DY setting)

"Midnight" meaning when 2004-12-12 ends, in Universal Coordinated
Time. I'll go by the date and time in the post's
"NNTP-Posting-Date:" header; usually (but not necessarily) this is
within a few seconds after you send the post. If the date isn't
2004-12-12 or earlier after converting to UTC, then it's too late.

In case of a tie, whoever posts first wins.

Entries or questions should be in replies to this thread. Of
course, if you come up with something smaller, then feel free to
post another entry.

Let's try to keep this an enjoyable learning exercise. Give it
your best shot. I'd encourage you to post your smallest program
before the deadline, even if someone else has already posted a
smaller one; it could turn out that there's a flaw in an
apparently better entry. It's interesting to see how many
different ways to get the same result are possible.

In case of a dispute, the judge's final decision is final. But if
you notice a flaw that the judge hasn't noticed, point it out. The
judge reserves his right to change his decision.

Prize: Fame (at least in this thread).

> James M. Prange is invited to be the Great Judge!

Accepted. Thank you!

-- 
Regards,
James

Lee wrote:
> Here's mine 164.5 bytes

Checksum on 48 series: # FC51h
Checksum on 49 series: # 87E5h

> \<< 0. \-> a b c
>   \<< a OBJ\-> DUP 'c' STO { } 'a' STO
>     WHILE 0. \=/
>     REPEAT DUP TYPE b SAME { DROP }
>       \<< 1. \->LIST a + 'a' STO
>       \>> IFTE 'c' DECR
>     END a
>   \>>
> \>>

There are certainly some interesting techniques in there. I
haven't analysed how it works, but it does seem to work on the
48SX, 48GX, and 49g+.

Note that on the 49 series, the level 1 argument has to be a real
number; an exact integer won't work. I hadn't expected that to
come up, but it's okay.

-- 
Regards,
James

KJ wrote:

> Try this...
>
> Checksum:  # BDABh

On the 48 series, that is.

On the 49 series, the checksum is # 7F72h.


> Bytes:  120
>
> %%HP: T(3)A(D)F(.);
> \<< { } \-> a b
>   \<< OBJ\->
>     IF DUP 0 ==
>     THEN DROP
>     ELSE 1 SWAP
>       START DUP
> TYPE a
>         IF ==
>         THEN DROP
>         ELSE 1
> \->LIST 'b' STO+
>         END
>       NEXT
>     END b
>   \>>
> \>>

We have a new leading entry. It works on 48SX, 48GX, and 49g+.

-- 
Regards,
James

I wrote:

> KJ wrote:
>
>
>>Try this...
>>
>>Checksum:  # BDABh
>
>
> On the 48 series, that is.
>
> On the 49 series, the checksum is # 7F72h.

Oops! Since this was from a 48 series, I should consider the
numbers to be reals instead of exact integers, which makes the 49
series checksum # 12E8h. This doesn't change the size.

>>Bytes:  120
>>
>>%%HP: T(3)A(D)F(.);
>>\<< { } \-> a b
>>  \<< OBJ\->
>>    IF DUP 0 ==
>>    THEN DROP
>>    ELSE 1 SWAP
>>      START DUP
>>TYPE a
>>        IF ==
>>        THEN DROP
>>        ELSE 1
>>\->LIST 'b' STO+
>>        END
>>      NEXT
>>    END b
>>  \>>
>>\>>
>
>
> We have a new leading entry. It works on 48SX, 48GX, and 49g+.

--
Regards,
James

Here's mine, 111 bytes, crc #35ACh on my hp48gx, I think it should work on
any hp48/49

\<< \-> T L
    \<< {}
        IF L SIZE DUP
        THEN 1 SWAP
            FOR I L I GET DUP TYPE T ==
                ::DROP
                ::+
                IFTE
            NEXT
        ELSE DROP
        END
    \>>
\>>


"Veli-Pekka Nousiainen" <DROP_vpn@THIS.welho.com> wrote in message
news:coi21a$ugm$1@nyytiset.pp.htv.fi...
> A minichallange for those who have *never before* taken part!
> Write the SHORTEST routine that eliminates the same TYPE of element
>      2: list
>      1: element of which type is desired to be eliminated
>  RELEMTYPE
>      1: list
>  Note:
> Recall 'RELMTYPE' program contenst to stack and do BYTES
>  to get the bytes of the program itself + checksum
>
> Restrictions:
> 1) It must work correctly on an empty list too
> 2) The remaining elements have to be in their original order
> 3) No downloaded external libraries
> 4) UserRPL only, no SYSEVAL, LIBEVAL, FLASHEVAL
> 5) Be honest: don't ask for help from anyone!
>
> Categories:
> A) 48-series: 48S, 48SX, 48G, 48G+, 48GX
> B) 49-series: 48gII, 49G, 49g+
> C) 49-series using also manually attachable "secret" libraries
>     Contestants are urged to dig information using internet.
>
> The challange ends at 12.12.2004 midnight greenw. time
> (regardless of D.MY/M.DY setting)
>
> James M. Prange is invited to be the Great Judge!
> :-D
> [VPN]
>
>

Note, I realized I mixed the order in which args are given, so it takes
2: type
1: list

To make it take
2: list
1: type

You just need to replace \-> T L with \-> L T, size stays the same, crc
becomes #9347h on the hp48

"Endless" <newsfree@daydreamnation.org> wrote in message
news:41adaa87$0$30405$636a15ce@news.free.fr...
> Here's mine, 111 bytes, crc #35ACh on my hp48gx, I think it should work on
> any hp48/49
>
> \<< \-> T L
>     \<< {}
>         IF L SIZE DUP
>         THEN 1 SWAP
>             FOR I L I GET DUP TYPE T ==
>                 ::DROP
>                 ::+
>                 IFTE
>             NEXT
>         ELSE DROP
>         END
>     \>>
> \>>
>
>
> "Veli-Pekka Nousiainen" <DROP_vpn@THIS.welho.com> wrote in message
> news:coi21a$ugm$1@nyytiset.pp.htv.fi...
> > A minichallange for those who have *never before* taken part!
> > Write the SHORTEST routine that eliminates the same TYPE of element
> >      2: list
> >      1: element of which type is desired to be eliminated
> >  RELEMTYPE
> >      1: list
> >  Note:
> > Recall 'RELMTYPE' program contenst to stack and do BYTES
> >  to get the bytes of the program itself + checksum
> >
> > Restrictions:
> > 1) It must work correctly on an empty list too
> > 2) The remaining elements have to be in their original order
> > 3) No downloaded external libraries
> > 4) UserRPL only, no SYSEVAL, LIBEVAL, FLASHEVAL
> > 5) Be honest: don't ask for help from anyone!
> >
> > Categories:
> > A) 48-series: 48S, 48SX, 48G, 48G+, 48GX
> > B) 49-series: 48gII, 49G, 49g+
> > C) 49-series using also manually attachable "secret" libraries
> >     Contestants are urged to dig information using internet.
> >
> > The challange ends at 12.12.2004 midnight greenw. time
> > (regardless of D.MY/M.DY setting)
> >
> > James M. Prange is invited to be the Great Judge!
> > :-D
> > [VPN]
> >
> >
>
>

Endless wrote:
> Here's mine, 111 bytes, crc #35ACh on my hp48gx, I think it should work on
> any hp48/49
>
> \<< \-> T L
>     \<< {}
>         IF L SIZE DUP
>         THEN 1 SWAP
>             FOR I L I GET DUP TYPE T ==
>                 ::DROP
>                 ::+
>                 IFTE
>             NEXT
>         ELSE DROP
>         END
>     \>>
> \>>

Sorry, as posted, this doesn't quite work as required. Review what
the arguments are supposed to be. It should be a trivial fix.

> "Veli-Pekka Nousiainen" <DROP_vpn@THIS.welho.com> wrote in message
> news:coi21a$ugm$1@nyytiset.pp.htv.fi...
>
>>A minichallange for those who have *never before* taken part!
>>Write the SHORTEST routine that eliminates the same TYPE of element
>>     2: list
>>     1: element of which type is desired to be eliminated
>> RELEMTYPE
>>     1: list

<snip>

-- 
Regards,
James

Endless wrote:
> Note, I realized I mixed the order in which args are given, so it takes
> 2: type
> 1: list
>
> To make it take
> 2: list
> 1: type
>
> You just need to replace \-> T L with \-> L T, size stays the same, crc
> becomes #9347h on the hp48

Exactly! So it becomes:


%%HP: T(3)A(D)F(.);
@ 48 series checksum: # 9347h
@ 49 series checksum: # A1E1h
@ Size: 111.
\<< \-> L T
    \<< {}
        IF L SIZE DUP
        THEN 1 SWAP
            FOR I L I GET DUP TYPE T ==
                ::DROP
                ::+
                IFTE
            NEXT
        ELSE DROP
        END
    \>>
\>>


It works on the 48S, 48G, and 49 series.

-- 
Regards,
James

Veli-Pekka Nousiainen a �crit :
> Write the SHORTEST routine that eliminates the same TYPE of element
>      2: list
>      1: element of which type is desired to be eliminated
>  RELEMTYPE
>      1: list

Here is my routine. It may work on hp48 and hp49. On my hp49g, BYTES 
gives #4064h and 98.5 bytes :

'RELMTYPE' :
\<<
  OVER SIZE

  {
    OVER HEAD

    OVER TYPE OVER TYPE ==
      SWAP 1. \->LIST 1. \->LIST
      { {} }
    IFTE

    ROT TAIL
    ROT
    RELMTYPE
    +
  }

  :: DROP

  IFTE
\>>

You may have noticed it is a recursive program, so that in order to 
work, it has to be stored in the variable 'RELMTYPE'. Of course, the 
program can be 7 bytes shorter if you call it 'R', or any other 1-char 
name. So, in reality my program is 91.5 bytes-long.

"James M. Prange" <jmprange@i-is.com> wrote in message 
news:lDfrd.5837$qk.522@fe39.usenetserver.com...
> Veli-Pekka Nousiainen wrote:
>> A minichallange for those who have *never before* taken part!
>> Write the SHORTEST routine that eliminates the same TYPE of element
>
> "SHORTEST" meaning the smallest size (in bytes) returned by the
> BYTES command on the program itself; not the size when you run
> BYTES on the program's quoted name. Execution time doesn't matter
> in this particular minichallenge.
>
>>      2: list
>>      1: element of which type is desired to be eliminated
>
> Meaning that the level 1 argument should be a "real number"
> representing the type to be eliminated, such as 0 for reals
> numbers, 1 for complex numbers, 2 for characters strings, and so
> on, not an example of the type to be eliminated. Right,
> Veli-Pekka?

Well actually I though that this could be an of object
instead of a type number, but since you are the
Great Judge
now, it's your call, 007
(one TYPE command [more/less] doesn't change the logic)
X
>> Categories:
>> A) 48-series: 48S, 48SX, 48G, 48G+, 48GX
>
> Considering the changes to list processing, let's split that into
> two categories; one for the 48S and 48SX, and another for the 48G,
> 48GX, and 48G+.

You are the Great Judge, James

> In case of a tie, whoever posts first wins.

You are the Great Judge, Monsieur Prange

> Let's try to keep this an enjoyable learning exercise. Give it
> your best shot. I'd encourage you to post your smallest program
> before the deadline, even if someone else has already posted a
> smaller one; it could turn out that there's a flaw in an
> apparently better entry. It's interesting to see how many
> different ways to get the same result are possible.

A *very* good point!!!

> In case of a dispute, the judge's final decision is final. But if
> you notice a flaw that the judge hasn't noticed, point it out. The
> judge reserves his right to change his decision.
>
> Prize: Fame (at least in this thread).
>
>> James M. Prange is invited to be the Great Judge!
>
> Accepted. Thank you!

You're welcome!
{ V P N }
6.
RELEMTYPE
{ }
6.
RELEMTYPE
{ }

"Khanh-Dang" <kd@fr.invalid> wrote in message 
news:41add6db$0$30421$8fcfb975@news.wanadoo.fr...
> Veli-Pekka Nousiainen a �crit :
>> Write the SHORTEST routine that eliminates the same TYPE of element
>>      2: list
>>      1: element of which type is desired to be eliminated
>>  RELEMTYPE
>>      1: list
>
> Here is my routine. It may work on hp48 and hp49. On my hp49g, BYTES gives 
> #4064h and 98.5 bytes :
>
> 'RELMTYPE' :
> \<<
>  OVER SIZE
>
>  {
>    OVER HEAD
>
>    OVER TYPE OVER TYPE ==
>      SWAP 1. \->LIST 1. \->LIST
>      { {} }
>    IFTE
>
>    ROT TAIL
>    ROT
>    RELMTYPE
>    +
>  }
>
>  :: DROP
>
>  IFTE
> \>>
>
> You may have noticed it is a recursive program, so that in order to work, 
> it has to be stored in the variable 'RELMTYPE'. Of course, the program can 
> be 7 bytes shorter if you call it 'R', or any other 1-char name. So, in 
> reality my program is 91.5 bytes-long.
Ahhh!
I was waiting for this one.
The name is deliberately long in my original MiniChallange
to not to give this solution too much advantage
BUT
James is the Great Judge
and he may deside in this matter whatever he will.
[VPN]

I came up with a much better method by going back to my orginal idea
(dosubs).
Down to 88.5 bytes, crc #D571h on the hp48.

\<<
    \-> T
    \<<
        T 0 NOVAL IFTE SWAP + 1
        \<<
            DUP TYPE T == ::DROP IFT
        \>>
    DOSUBS TAIL
    \>>
\>>

Congrats.. Looks like it works well
"Endless" <newsfree@daydreamnation.org> wrote in message
news:41ae02f9$0$30476$636a15ce@news.free.fr...
> I came up with a much better method by going back to my orginal idea
> (dosubs).
> Down to 88.5 bytes, crc #D571h on the hp48.
>
> \<<
>     \-> T
>     \<<
>         T 0 NOVAL IFTE SWAP + 1
>         \<<
>             DUP TYPE T == ::DROP IFT
>         \>>
>     DOSUBS TAIL
>     \>>
> \>>
>
>

Khanh-Dang wrote:
> Veli-Pekka Nousiainen a �crit :
>
>> Write the SHORTEST routine that eliminates the same TYPE of element
>>      2: list
>>      1: element of which type is desired to be eliminated
>>  RELEMTYPE
>>      1: list
>
>
> Here is my routine. It may work on hp48 and hp49. On my hp49g, BYTES
> gives #4064h and 98.5 bytes :

Or # CADBh on a 48GX. It works on the 49 and 48G series, but
because of the HEAD and TAIL commands, not on the 48S series.

> 'RELMTYPE' :
> \<<
>  OVER SIZE
>
>  {
>    OVER HEAD
>
>    OVER TYPE OVER TYPE ==
>      SWAP 1. \->LIST 1. \->LIST
>      { {} }
>    IFTE
>
>    ROT TAIL
>    ROT
>    RELMTYPE
>    +
>  }
>
>  :: DROP
>
>  IFTE
> \>>
>
> You may have noticed it is a recursive program, so that in order to
> work, it has to be stored in the variable 'RELMTYPE'. Of course, the
> program can be 7 bytes shorter if you call it 'R', or any other 1-char
> name. So, in reality my program is 91.5 bytes-long.

I have to admit that a recursive program didn't occur to me, or
that the HEAD or TAIL commands would be used, for that matter.
It's very interesting.

Sorry, my decision is that the name must match the name in the
announcement. But I might be persuaded to change my mind based on
comments from others. Are there any trial lawyers out there who
care to argue the case one way or the other? Of course, arguments
from those who aren't eligible for this minichallenge will carry a
lot more weight; I think I know which way other participants would
argue.

Actually, my initial reaction was that the name should be
'RELEMTYPE', but I see that Veli-Pekka also used 'RELMTYPE' in the
announcement, so I'll allow at least that much.

-- 
Regards,
James

And even shorter: 85.5 bytes, #8FB3h:

\<<
     \-> T
     \<<
         T 0 TRUE IFTE SWAP + 1
         \<<
             DUP TYPE T == ::DROP IFT
         \>>
     DOSUBS TAIL
     \>>
\>>

James M. Prange a �crit :
> I have to admit that a recursive program didn't occur to me, or
> that the HEAD or TAIL commands would be used, for that matter.
> It's very interesting.

In fact, it is usual to program this way if you write a Caml 
(http://caml.inria.fr/) program.

Using recursive programming with list a the normal way to program with 
Caml. In fact, if you want to traverse the list, you /have to/ make a 
recursive program, because you can only access the head of a list.
For example, the following Caml routine take a list of integers and add 
1 to each of these integer. It is equivalent to the UserRPL program << 1 
ADD >>.

let rec my_function list = match list with
  | [] -> []
  | head::tail -> (head + 1) :: my_function tail
;;

In fact, the program can be written shorter, but I write it this way in 
order to let everybody easily understand it. Notice that "[" and "]" are 
  caml-list delimiters.

\<< \-> t
  \<< 1.
    \<< DUP TYPE t == :: DROP IFT
    \>> DOLIST
  \>>
\>>
Same style 63 bytes #F1Eh
"Endless" <newsfree@daydreamnation.org> wrote in message
news:41ae098c$0$30427$636a15ce@news.free.fr...
> And even shorter: 85.5 bytes, #8FB3h:
>
> \<<
>      \-> T
>      \<<
>          T 0 TRUE IFTE SWAP + 1
>          \<<
>              DUP TYPE T == ::DROP IFT
>          \>>
>      DOSUBS TAIL
>      \>>
> \>>
>
>
>
>

Veli-Pekka Nousiainen wrote:
> "James M. Prange" <jmprange@i-is.com> wrote in message
> news:lDfrd.5837$qk.522@fe39.usenetserver.com...
>
>>Veli-Pekka Nousiainen wrote:
>>
>>>A minichallange for those who have *never before* taken part!
>>>Write the SHORTEST routine that eliminates the same TYPE of element
>>
>>"SHORTEST" meaning the smallest size (in bytes) returned by the
>>BYTES command on the program itself; not the size when you run
>>BYTES on the program's quoted name. Execution time doesn't matter
>>in this particular minichallenge.
>>
>>
>>>     2: list
>>>     1: element of which type is desired to be eliminated
>>
>>Meaning that the level 1 argument should be a "real number"
>>representing the type to be eliminated, such as 0 for reals
>>numbers, 1 for complex numbers, 2 for characters strings, and so
>>on, not an example of the type to be eliminated. Right,
>>Veli-Pekka?
>
>
> Well actually I though that this could be an of object
> instead of a type number, but since you are the
> Great Judge
> now, it's your call, 007
> (one TYPE command [more/less] doesn't change the logic

Okay, I'll allow the level 1 argument to be an example of the type
to be eliminated. For example, 0. for real numbers, (0.,0.) for
complex numbers, "A" for character strings, 0 for exact integers
on the 49 series, and so on. But the submission should state that
it's intended for the level 1 argument to be an example of the
type instead of a type number; don't make me guess about it.

Does anyone argue for making this a separate set of categories?

>>>Categories:
>>>A) 48-series: 48S, 48SX, 48G, 48G+, 48GX
>>
>>Considering the changes to list processing, let's split that into
>>two categories; one for the 48S and 48SX, and another for the 48G,
>>48GX, and 48G+.
>
>
> You are the Great Judge, James

Separate categories for the 48S series and 48G series. We've
already had one submission that works on the 48G but not the 48S.
I expect that there are at least a few 48S series still in use. So
far, I haven't noticed anything that I could accomplish on the
48GX that I couldn't also accomplish on the 48SX, although it may
well take more steps on the 48SX.

>>In case of a tie, whoever posts first wins.
>
>
> You are the Great Judge, Monsieur Prange

Hey, I thought that "Prange" was German, not French. On the other
hand, my niece's family tree shows a lot more French ancestors
than German ancestors, because they've been here a lot longer; so
long that a lot of the branches have grafted to each other. Maybe
it should be called a "network" instead of a "tree"? I guess they
were making sure that the best genes stayed in the family.

Anyway, I figure that the "first posted wins in case of a tie"
policy discourages participants from holding back until the last
minute, hoping to benefit from others' ideas while keeping their
own secret. The only reasonable alternative that occurs to me
would be for the submissions to be only size and checksum until
after the deadline, in which case not many ideas would be shared.

>>Let's try to keep this an enjoyable learning exercise. Give it
>>your best shot. I'd encourage you to post your smallest program
>>before the deadline, even if someone else has already posted a
>>smaller one; it could turn out that there's a flaw in an
>>apparently better entry. It's interesting to see how many
>>different ways to get the same result are possible.
>
>
> A *very* good point!!!

I'll add that it can be interesting how many things can go wrong
with what you'd thought was a logically flawless program.

>>In case of a dispute, the judge's final decision is final. But if
>>you notice a flaw that the judge hasn't noticed, point it out. The
>>judge reserves his right to change his decision.
>>
>>Prize: Fame (at least in this thread).
>>
>>
>>>James EM. Prange is invited to be the Great Judge!
>>
>>Accepted. Thank you!
>
>
> You're welcome!

Hmm, I had a hunch that this might involve some difficult
decisions.

-- 
Regards,
James

Hold on this won"t handle empty lists properly. My mistake, I should test
more and post less.
"Lee" <RDELM@PACBELL.NET> wrote in message
news:3Word.37081$6q2.24801@newssvr14.news.prodigy.com...
> \<< \-> t
>   \<< 1.
>     \<< DUP TYPE t == :: DROP IFT
>     \>> DOLIST
>   \>>
> \>>
> Same style 63 bytes #F1Eh
> "Endless" <newsfree@daydreamnation.org> wrote in message
> news:41ae098c$0$30427$636a15ce@news.free.fr...
> > And even shorter: 85.5 bytes, #8FB3h:
> >
> > \<<
> >      \-> T
> >      \<<
> >          T 0 TRUE IFTE SWAP + 1
> >          \<<
> >              DUP TYPE T == ::DROP IFT
> >          \>>
> >      DOSUBS TAIL
> >      \>>
> > \>>
> >
> >
> >
> >
>
>

It also doesn't return an empty list if all the elemnts got deleted. I know,
that was the first program I came up with. In my 85.5 bytes entry, the first
line is here only to ensure that dosubs operates on a non empty list and
returns a non empty list (that tails will make empty if it is supposed to
be).


"Lee" <RDELM@PACBELL.NET> wrote in message
news:60prd.37086$6q2.26805@newssvr14.news.prodigy.com...
> Hold on this won"t handle empty lists properly. My mistake, I should test
> more and post less.
> "Lee" <RDELM@PACBELL.NET> wrote in message
> news:3Word.37081$6q2.24801@newssvr14.news.prodigy.com...
> > \<< \-> t
> >   \<< 1.
> >     \<< DUP TYPE t == :: DROP IFT
> >     \>> DOLIST
> >   \>>
> > \>>
> > Same style 63 bytes #F1Eh
> > "Endless" <newsfree@daydreamnation.org> wrote in message
> > news:41ae098c$0$30427$636a15ce@news.free.fr...
> > > And even shorter: 85.5 bytes, #8FB3h:
> > >
> > > \<<
> > >      \-> T
> > >      \<<
> > >          T 0 TRUE IFTE SWAP + 1
> > >          \<<
> > >              DUP TYPE T == ::DROP IFT
> > >          \>>
> > >      DOSUBS TAIL
> > >      \>>
> > > \>>
> > >
> > >
> > >
> > >
> >
> >
>
>

Yep I noticed that after i posted. I could go smaller but it would be in
sysrpl
I conceede smallest to you Endless. (for now ;-) )
RDElm
"Endless" <newsfree@daydreamnation.org> wrote in message
news:41ae21f3$0$30403$636a15ce@news.free.fr...
> It also doesn't return an empty list if all the elemnts got deleted. I
know,
> that was the first program I came up with. In my 85.5 bytes entry, the
first
> line is here only to ensure that dosubs operates on a non empty list and
> returns a non empty list (that tails will make empty if it is supposed to
> be).
>
>
> "Lee" <RDELM@PACBELL.NET> wrote in message
> news:60prd.37086$6q2.26805@newssvr14.news.prodigy.com...
> > Hold on this won"t handle empty lists properly. My mistake, I should
test
> > more and post less.
> > "Lee" <RDELM@PACBELL.NET> wrote in message
> > news:3Word.37081$6q2.24801@newssvr14.news.prodigy.com...
> > > \<< \-> t
> > >   \<< 1.
> > >     \<< DUP TYPE t == :: DROP IFT
> > >     \>> DOLIST
> > >   \>>
> > > \>>
> > > Same style 63 bytes #F1Eh
> > > "Endless" <newsfree@daydreamnation.org> wrote in message
> > > news:41ae098c$0$30427$636a15ce@news.free.fr...
> > > > And even shorter: 85.5 bytes, #8FB3h:
> > > >
> > > > \<<
> > > >      \-> T
> > > >      \<<
> > > >          T 0 TRUE IFTE SWAP + 1
> > > >          \<<
> > > >              DUP TYPE T == ::DROP IFT
> > > >          \>>
> > > >      DOSUBS TAIL
> > > >      \>>
> > > > \>>
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>

If the 48s has SUB working like I think it does, replace TAIL with:
DUP SIZE 2 SWAP SUB. I have no idea what the size and crc on the 48s become,
as I don't own one to test.

"Endless" <newsfree@daydreamnation.org> wrote in message
news:41ae098c$0$30427$636a15ce@news.free.fr...
> And even shorter: 85.5 bytes, #8FB3h:
>
> \<<
>      \-> T
>      \<<
>          T 0 TRUE IFTE SWAP + 1
>          \<<
>              DUP TYPE T == ::DROP IFT
>          \>>
>      DOSUBS TAIL
>      \>>
> \>>
>
>
>
>

Khanh-Dang <kd@fr.invalid> wrote in message news:<41add6db$0$30421$8fcfb975@news.wanadoo.fr>...
> 
> Here is my routine. It may work on hp48 and hp49. On my hp49g, BYTES 
> gives #4064h and 98.5 bytes :
> 
> 'RELMTYPE' :
>  (snip)
> You may have noticed it is a recursive program, so that in order to 
> work, it has to be stored in the variable 'RELMTYPE'. Of course, the 
> program can be 7 bytes shorter if you call it 'R', or any other 1-char 
> name. So, in reality my program is 91.5 bytes-long.

BYTES does not include the program name.
Too bad I can't compete!

Werner

Endless wrote:
> I came up with a much better method by going back to my orginal idea
> (dosubs).
> Down to 88.5 bytes, crc #D571h on the hp48.

On the 48G series, that is. It doesn't work on the 48S because of
the TAIL command.

On the 49 series, the checksum is # 8EE2h, and the size is 85.5.

>
> \<<
>     \-> T
>     \<<
>         T 0 NOVAL IFTE SWAP + 1
>         \<<
>             DUP TYPE T == ::DROP IFT
>         \>>
>     DOSUBS TAIL
>     \>>
> \>>

-- 
Regards,
James

Endless wrote:
> And even shorter: 85.5 bytes, #8FB3h:

On my 48GX, I come up with 90.5 bytes, # 860Dh.
On my 49G, I come up with 90.5 bytes, # 71CFh.

Note that TRUE compiles to a global name on my calculators, at
least in UserRPL. Maybe it's an external library command on your
calculator? Or is TRUE a typo?

Even so, it does work on the 48G and 49 series, but not on the 48S
because of the DOSUBS and TAIL commands.

> \<<
>      \-> T
>      \<<
>          T 0 TRUE IFTE SWAP + 1
>          \<<
>              DUP TYPE T == ::DROP IFT
>          \>>
>      DOSUBS TAIL
>      \>>
> \>>

-- 
Regards,
James

Werner wrote:
> Khanh-Dang <kd@fr.invalid> wrote in message news:<41add6db$0$30421$8fcfb975@news.wanadoo.fr>...
>
>>Here is my routine. It may work on hp48 and hp49. On my hp49g, BYTES
>>gives #4064h and 98.5 bytes :
>>
>>'RELMTYPE' :
>> (snip)
>>You may have noticed it is a recursive program, so that in order to
>>work, it has to be stored in the variable 'RELMTYPE'. Of course, the
>>program can be 7 bytes shorter if you call it 'R', or any other 1-char
>>name. So, in reality my program is 91.5 bytes-long.
>
>
> BYTES does not include the program name.

True, but the point is that this is a recursive program with its
own name included in the body of the program, so the size of its
name does make a difference.

> Too bad I can't compete!

I know what you mean. But any time I enter a mini-challenge, I
figure that it's a safe bet that you're going to come up with
something better. I think that the idea is to give those new to
mini-challenges a chance, without discouraging right away with
techniques that would never have occurred to them at first.
They're doing a lot better than I expected.

-- 
Regards,
James

Now that you mention it, I didn't think that TRUE and FALSE worked on my
48gx only because I'm using MK and are not built-in.
In that case, try this:

%%HP: T(3)A(D)F(.);
\<< \-> T
  \<< T 0 <1d> IFTE SWAP + 1
    \<< DUP TYPE T == ::DROP IFT
    \>> DOSUBS TAIL
  \>>
\>>

I posted a TAIL replacement for the 48s in this thread, but I can't test to
see if it works.


"James M. Prange" <jmprange@i-is.com> wrote in message
news:EZqrd.266$nU.164@fe61.usenetserver.com...
> Endless wrote:
> > And even shorter: 85.5 bytes, #8FB3h:
>
> On my 48GX, I come up with 90.5 bytes, # 860Dh.
> On my 49G, I come up with 90.5 bytes, # 71CFh.
>
> Note that TRUE compiles to a global name on my calculators, at
> least in UserRPL. Maybe it's an external library command on your
> calculator? Or is TRUE a typo?
>
> Even so, it does work on the 48G and 49 series, but not on the 48S
> because of the DOSUBS and TAIL commands.
>
> > \<<
> >      \-> T
> >      \<<
> >          T 0 TRUE IFTE SWAP + 1
> >          \<<
> >              DUP TYPE T == ::DROP IFT
> >          \>>
> >      DOSUBS TAIL
> >      \>>
> > \>>
>
> -- 
> Regards,
> James
>

"Endless" <newsfree@daydreamnation.org> wrote in message 
news:41ae423c$0$30431$636a15ce@news.free.fr...
> Now that you mention it, I didn't think that TRUE and FALSE worked on my
> 48gx only because I'm using MK and are not built-in.
> In that case, try this:
>
> %%HP: T(3)A(D)F(.);
> \<< \-> T
>  \<< T 0 <1d> IFTE SWAP + 1
>    \<< DUP TYPE T == ::DROP IFT
>    \>> DOSUBS TAIL
>  \>>
> \>>
Advice (based on "<1d>") :
You might consider removing all external libraries for the moment
[VPN] 

"James M. Prange" <jmprange@i-is.com> wrote in message 
news:k%ord.5872$qk.5759@fe39.usenetserver.com...
X
>> Well actually I though that this could be an of object
>> instead of a type number, but since you are the
>> Great Judge
>> now, it's your call, 007
>> (one TYPE command [more/less] doesn't change the logic
>
> Okay, I'll allow the level 1 argument to be an example of the type
> to be eliminated. For example, 0. for real numbers, (0.,0.) for
> complex numbers, "A" for character strings, 0 for exact integers
> on the 49 series, and so on. But the submission should state that
> it's intended for the level 1 argument to be an example of the
> type instead of a type number; don't make me guess about it.
>
> Does anyone argue for making this a separate set of categories?

I do: it should be either type number or object itself
I vote for type number since everyone is using it already
I just answered for your question
and suggested that a single command TYPE
does not change the logic: I object dividing the categories.
BUT
James = Great Judge

X
> Separate categories for the 48S series and 48G series.
sounds good

> Anyway, I figure that the "first posted wins in case of a tie"
> policy discourages participants from holding back until the last
> minute, hoping to benefit from others' ideas while keeping their

Absolutely. You're much better judge than I would be
I never though of this onr to occur :-D

> own secret. The only reasonable alternative that occurs to me
> would be for the submissions to be only size and checksum until
> after the deadline, in which case not many ideas would be shared.

People have already posted whole programs
AND have withdrawn casese where {} is not handled OK

>>>Let's try to keep this an enjoyable learning exercise. Give it
>>>your best shot. I'd encourage you to post your smallest program
>>>before the deadline, even if someone else has already posted a
>>>smaller one; it could turn out that there's a flaw in an
>>>apparently better entry. It's interesting to see how many
>>>different ways to get the same result are possible.
>>
>> A *very* good point!!!
>
> I'll add that it can be interesting how many things can go wrong
> with what you'd thought was a logically flawless program.
X
I'm just a fan of recursion
[VPN]

"Veli-Pekka Nousiainen" <DROP_vpn@THIS.welho.com> wrote in message 
news:colgkv$ak9$1@nyytiset.pp.htv.fi...
> "James M. Prange" <jmprange@i-is.com> wrote in message 
> news:k%ord.5872$qk.5759@fe39.usenetserver.com...
> X
>>> Well actually I though that this could be an of object
>>> instead of a type number, but since you are the
>>> Great Judge
>>> now, it's your call, 007
>>> (one TYPE command [more/less] doesn't change the logic
>>
>> Okay, I'll allow the level 1 argument to be an example of the type
>> to be eliminated. For example, 0. for real numbers, (0.,0.) for
>> complex numbers, "A" for character strings, 0 for exact integers
>> on the 49 series, and so on. But the submission should state that
>> it's intended for the level 1 argument to be an example of the
>> type instead of a type number; don't make me guess about it.
>>
>> Does anyone argue for making this a separate set of categories?
>
> I do: it should be either type number or object itself
> I vote for type number since everyone is using it already
> I just answered for your question
> and suggested that a single command TYPE
> does not change the logic: I object dividing the categories.
> BUT
> James = Great Judge
X
Actually I should withdraw my suggestion
to stick into type number input,
since I just noticed that my original program (first try)
used the element property to make it very short
Darn!
Well, I'm not participating anyway
)-:
[VPN]

Endless wrote:
> Now that you mention it, I didn't think that TRUE and FALSE worked on my
> 48gx only because I'm using MK and are not built-in.
> In that case, try this:
>
> %%HP: T(3)A(D)F(.);
> \<< \-> T
>   \<< T 0 <1d> IFTE SWAP + 1
>     \<< DUP TYPE T == ::DROP IFT
>     \>> DOSUBS TAIL
>   \>>
> \>>

No, <1d> causes an "Invalid Syntax" error. But don't give up; I can think of
lots of things that would accomplish the same purpose.

> I posted a TAIL replacement for the 48s in this thread, but I can't test to
> see if it works.

DUP SIZE 2 SWAP SUB

It works, returning an empty list for a 1-element or empty list, taking 12.5
bytes. TAIL takes 5.5 bytes.

-- 
Regards,
James

Khanh-Dang wrote:
> James M. Prange a �crit :
>
>> I have to admit that a recursive program didn't occur to me, or
>> that the HEAD or TAIL commands would be used, for that matter.
>> It's very interesting.
>
>
> In fact, it is usual to program this way if you write a Caml
> (http://caml.inria.fr/) program.
>
> Using recursive programming with list a the normal way to program with
> Caml. In fact, if you want to traverse the list, you /have to/ make a
> recursive program, because you can only access the head of a list.
> For example, the following Caml routine take a list of integers and add
> 1 to each of these integer. It is equivalent to the UserRPL program << 1
> ADD >>.
>
> let rec my_function list = match list with
>  | [] -> []
>  | head::tail -> (head + 1) :: my_function tail
> ;;
>
> In fact, the program can be written shorter, but I write it this way in
> order to let everybody easily understand it. Notice that "[" and "]" are
>  caml-list delimiters.

Okay, but I guess that you don't use many 1-character names, except
locally.

I'm well aware of recursive programming, but I rarely use it,
accomplishing what I need with other methods. I don't have
anything particular against it. I just wish that I'd thought of
it, and especially of its effect on program size, before someone
actually used it in this mini-challenge.

As for HEAD and TAIL, those are still "new" commands to me; I
can't use them on my 48SX. They are indeed useful, but typically
they wouldn't be the first method that occurs to me.

With these calculators, there are usually several different ways
to accomplish any particular task. Which is best? Well, it depends
on your priorities. Smallest size, shortest execution time, least
memory use at runtime, not slowing garbage collection to a crawl,
and ease and speed of development and modification are all
reasonable goals, but often conflict, and typically it will be a
compromise.

Wolfgang is an exception; for him, shaving off a nibble seems to
be cause for celebration (as it is in this mini-challenge).

I suppose that execution speed would be a high priority for many
assembly languge programmers.

But note that in the ROM code, smallest size or more likely
fastest development seems to have had the higher priority. Often
it seems that the idea was to reuse code known to work correctly,
even if it was far from optimal (the "if it ain't broke, don't
'fix' it" philosophy, which isn't such a bad policy).

In the little project that I've been working on (occasionally),
there's a (rather large) speed critical section, but for the rest
of it, trying to keep the size down to something reasonable has a
higher priority.

Playing around at home, I can be fussy about size and speed and
"optimise" a program, but at work, other than returning the
correct results, development time has the highest priorty. If it
works, then it's good enough, even if I already see ways to make
it faster or smaller. Usually, for an ad hoc program, optimising
for speed would take more time than I could hope to regain in
reduced execution time, and the program will probably be purged
soon anyway, so size isn't an issue either.

-- 
Regards,
James

I wrote:
> Endless wrote:

<snip>

>>I posted a TAIL replacement for the 48s in this thread, but I can't test to
>>see if it works.
>
>
> DUP SIZE 2 SWAP SUB
>
> It works, returning an empty list for a 1-element or empty list, taking 12.5
> bytes. TAIL takes 5.5 bytes.

Ah, now I see (I think). Sorry, sometimes I'm a bit slow on the
uptake. You want me to substitute the above sequence into your
best program using TAIL to make a submission for the 48S, right?
The trouble with that is that the 48S doesn't have a built-in
DOSUBS command either.

The enhanced list processing, including the ADD, DOLIST, DOSUBS,
ENDSUB, HEAD, \GSLIST, \PILIST, \GDLIST, NSUB, REVLIST, SEQ, SORT,
STREAM, and TAIL commands, is new with the 48G series.

--
Regards,
James

Ah, ok. Then no entry from me for the 48s for now.


"James M. Prange" <jmprange@i-is.com> wrote in message
news:S0urd.5907$qk.2416@fe39.usenetserver.com...
> I wrote:
> > Endless wrote:
>
> <snip>
>
> >>I posted a TAIL replacement for the 48s in this thread, but I can't test
to
> >>see if it works.
> >
> >
> > DUP SIZE 2 SWAP SUB
> >
> > It works, returning an empty list for a 1-element or empty list, taking
12.5
> > bytes. TAIL takes 5.5 bytes.
>
> Ah, now I see (I think). Sorry, sometimes I'm a bit slow on the
> uptake. You want me to substitute the above sequence into your
> best program using TAIL to make a submission for the 48S, right?
> The trouble with that is that the 48S doesn't have a built-in
> DOSUBS command either.
>
> The enhanced list processing, including the ADD, DOLIST, DOSUBS,
> ENDSUB, HEAD, \GSLIST, \PILIST, \GDLIST, NSUB, REVLIST, SEQ, SORT,
> STREAM, and TAIL commands, is new with the 48G series.
>
> --
> Regards,
> James
>

Endless wrote:
> Now that you mention it, I didn't think that TRUE and FALSE worked on
my
> 48gx only because I'm using MK and are not built-in.
> In that case, try this:
>
> %%HP: T(3)A(D)F(.);
> \<< \-> T
>   \<< T 0 <1d> IFTE SWAP + 1
>     \<< DUP TYPE T == ::DROP IFT
>     \>> DOSUBS TAIL
>   \>>
> \>>
>
> I posted a TAIL replacement for the 48s in this thread, but I can't
test to
> see if it works.
>

You are getting close..
I have essentially the same routine, but it is only 77.5 bytes.

Werner

The purpose is to gain 3 bytes on the 48g, since it seems NOVAL takes only
2.5 bytes on the 49 series, as opposed to 5.5 bytes on the 48g.

I tried replacing <1d> with PI (the symbol), and it seems to work.


"James M. Prange" <jmprange@i-is.com> wrote in message
news:31trd.273$nU.135@fe61.usenetserver.com...
> Endless wrote:
> > Now that you mention it, I didn't think that TRUE and FALSE worked on my
> > 48gx only because I'm using MK and are not built-in.
> > In that case, try this:
> >
> > %%HP: T(3)A(D)F(.);
> > \<< \-> T
> >   \<< T 0 <1d> IFTE SWAP + 1
> >     \<< DUP TYPE T == ::DROP IFT
> >     \>> DOSUBS TAIL
> >   \>>
> > \>>
>
> No, <1d> causes an "Invalid Syntax" error. But don't give up; I can think
of
> lots of things that would accomplish the same purpose.
>
> > I posted a TAIL replacement for the 48s in this thread, but I can't test
to
> > see if it works.
>
> DUP SIZE 2 SWAP SUB
>
> It works, returning an empty list for a 1-element or empty list, taking
12.5
> bytes. TAIL takes 5.5 bytes.
>
> -- 
> Regards,
> James
>

I don't want to post my solution. I was thinking along the same line as
Endless. I just couldn't come up with a good object to put at the
beginning of the list -- for me NOVAL is excellent!!!

Why do I prefer the DOSUBS solution to the ones which use a loop (or a
recursion)? Just try your programs on the following problem:

2: { { 1 } 2 'a' }
1: 0
REMELTYPE

should return
1: { { 1 } 'a' }

Fabian

P.S. Observe what + does if you want to append an element to a list which
is a list itself.

On Tue, 30 Nov 2004, Veli-Pekka Nousiainen wrote:

> A minichallange for those who have *never before* taken part!
> Write the SHORTEST routine that eliminates the same TYPE of element
>      2: list
>      1: element of which type is desired to be eliminated
>  RELEMTYPE
>      1: list
>  Note:
> Recall 'RELMTYPE' program contenst to stack and do BYTES
>  to get the bytes of the program itself + checksum
>
> Restrictions:
> 1) It must work correctly on an empty list too
> 2) The remaining elements have to be in their original order
> 3) No downloaded external libraries
> 4) UserRPL only, no SYSEVAL, LIBEVAL, FLASHEVAL
> 5) Be honest: don't ask for help from anyone!
>
> Categories:
> A) 48-series: 48S, 48SX, 48G, 48G+, 48GX
> B) 49-series: 48gII, 49G, 49g+
> C) 49-series using also manually attachable "secret" libraries
>     Contestants are urged to dig information using internet.
>
> The challange ends at 12.12.2004 midnight greenw. time
> (regardless of D.MY/M.DY setting)
>
> James M. Prange is invited to be the Great Judge!
> :-D
> [VPN]
>
>
>
------------ And now a word from our sponsor ------------------
Want to have instant messaging, and chat rooms, and discussion
groups for your local users or business, you need dbabble!
--  See http://netwinsite.com/sponsor/sponsor_dbabble.htm  ----

"James M. Prange" <jmprange@i-is.com> wrote in message 
news:hOnrd.5866$qk.2372@fe39.usenetserver.com...
> Khanh-Dang wrote:
X
>> 'RELMTYPE' :
>> \<<
>>  OVER SIZE
>>
>>  {
>>    OVER HEAD
>>
>>    OVER TYPE OVER TYPE ==
>>      SWAP 1. \->LIST 1. \->LIST
>>      { {} }
>>    IFTE
>>
>>    ROT TAIL
>>    ROT
>>    RELMTYPE
>>    +
>>  }
>>
>>  :: DROP
>>
>>  IFTE
>> \>>
>>
>> You may have noticed it is a recursive program, so that in order to
>> work, it has to be stored in the variable 'RELMTYPE'. Of course, the
>> program can be 7 bytes shorter if you call it 'R', or any other 1-char
>> name. So, in reality my program is 91.5 bytes-long.
X
When I use recursion (and speed and/or size is not optimized)
I tend to use a local name for the subprogram that is recursive
this way I know that I can always change the Global name
if I need/want to (Except in my TEST subdirectories).

Using your program (and making it longer) as an example
'RELMTYPE' :
\<< -> l t \<< l t @ check for two arguments
\<< @ put the subrogram on the stack
 OVER SIZE
 {
   OVER HEAD
   OVER TYPE OVER TYPE ==
     SWAP 1. \->LIST 1. \->LIST
     { {} }
   IFTE
   ROT TAIL
   ROT
   t EVAL @ RELMTYPE replaced by local name
   +
 }
 :: DROP
 IFTE
\>> -> t \<< t EVAL @ re-using the variable name
\>> \>> \>>
NO BYTES:
this is *not* an entry (boy, it's long), I'm not qualified
One may learn something new here
[VPN]

"James M. Prange" <jmprange@i-is.com> wrote in message 
news:31trd.273$nU.135@fe61.usenetserver.com...
X
> DUP SIZE 2 SWAP SUB
>
> It works, returning an empty list for a 1-element or empty list, taking 
> 12.5
> bytes. TAIL takes 5.5 bytes.
X
2 OVER SIZE SUB
[VPN]

"James M. Prange" <jmprange@i-is.com> wrote in message 
news:S0urd.5907$qk.2416@fe39.usenetserver.com...
> The enhanced list processing, including the ADD, DOLIST, DOSUBS,
> ENDSUB, HEAD, \GSLIST, \PILIST, \GDLIST, NSUB, REVLIST, SEQ, SORT,
> STREAM, and TAIL commands, is new with the 48G series.
X
Just to remaind you all: NOVAL, too
[VPN] 

"Endless" <newsfree@daydreamnation.org> wrote in message 
news:41aeb9a0$0$19372$636a15ce@news.free.fr...
> The purpose is to gain 3 bytes on the 48g, since it seems NOVAL takes only
> 2.5 bytes on the 49 series, as opposed to 5.5 bytes on the 48g.
>
> I tried replacing <1d> with PI (the symbol), and it seems to work.
X
what is your flag -2 is Constant -> num
[VPN] 

I decided to post my solution. It is not specially short:

\<<
    SWAP OVER
    0 NOVAL IFTE
    SWAP +
    DUP 1 ::TYPE DOSUBS
    ROT - NOT
    2
    \<< ::DROP IFT \>>
   DOLIST
   TAIL
\>>

HP48GX: 89 bytes, checksum: # E1FFh



On Thu, 2 Dec 2004, Fabian wrote:

> I don't want to post my solution. I was thinking along the same line as
> Endless. I just couldn't come up with a good object to put at the
> beginning of the list -- for me NOVAL is excellent!!!
>
> Why do I prefer the DOSUBS solution to the ones which use a loop (or a
> recursion)? Just try your programs on the following problem:
>
> 2: { { 1 } 2 'a' }
> 1: 0
> REMELTYPE
>
> should return
> 1: { { 1 } 'a' }
>
> Fabian
>
> P.S. Observe what + does if you want to append an element to a list which
> is a list itself.
>
> On Tue, 30 Nov 2004, Veli-Pekka Nousiainen wrote:
>
> > A minichallange for those who have *never before* taken part!
> > Write the SHORTEST routine that eliminates the same TYPE of element
> >      2: list
> >      1: element of which type is desired to be eliminated
> >  RELEMTYPE
> >      1: list
> >  Note:
> > Recall 'RELMTYPE' program contenst to stack and do BYTES
> >  to get the bytes of the program itself + checksum
> >
> > Restrictions:
> > 1) It must work correctly on an empty list too
> > 2) The remaining elements have to be in their original order
> > 3) No downloaded external libraries
> > 4) UserRPL only, no SYSEVAL, LIBEVAL, FLASHEVAL
> > 5) Be honest: don't ask for help from anyone!
> >
> > Categories:
> > A) 48-series: 48S, 48SX, 48G, 48G+, 48GX
> > B) 49-series: 48gII, 49G, 49g+
> > C) 49-series using also manually attachable "secret" libraries
> >     Contestants are urged to dig information using internet.
> >
> > The challange ends at 12.12.2004 midnight greenw. time
> > (regardless of D.MY/M.DY setting)
> >
> > James M. Prange is invited to be the Great Judge!
> > :-D
> > [VPN]
> >
> >
> >
> ------------ And now a word from our sponsor ------------------
> Want to have instant messaging, and chat rooms, and discussion
> groups for your local users or business, you need dbabble!
> --  See http://netwinsite.com/sponsor/sponsor_dbabble.htm  ----
>

Fabian a �crit :
> 2: { { 1 } 2 'a' }
> 1: 0
> REMELTYPE
> 
> should return
> 1: { { 1 } 'a' }
> 

I am such an idiot : the recursive program I gave in a thread above 
should be called KEPPELTYPE (I've misread the rules :-)

Here is the corrected version of my program (same lenght, as \=/ is 2.5 
bytes, as well as ==)

Note that my version expect an object from level 1, and not a real 
giving the type you want to remove.

\<<
  OVER SIZE

  {
    OVER HEAD

    OVER TYPE OVER TYPE \=/
      SWAP 1. \->LIST 1. \->LIST
      { {} }
    IFTE

    ROT TAIL
    ROT
    RELMTYPE
    +
  }

  :: DROP

  IFTE
\>>


> 
> P.S. Observe what + does if you want to append an element to a list which
> is a list itself.

You are right, and that's why I have to add a 1. \->LIST in my program, 
wasting 5 bytes :)

It's also a shame in this particular case that << {} EVAL >> is 
equivalent to a DROP. Indeed, the command IFTE always EVALs one of the 
two first objects. This is the reason why I have to put { {} } instead 
of {}, wasting another 5 bytes !

There we go, I solved my saving 3 bytes problem, which was to generate a non
real (/integer on the 48g) in 2.5 bytes. On the 49, NOVAL was good enough,
but wasted 3 bytes on the 48g. I tried using boolean flags, but as JMP
noticed, it was specific of my calc, then system ints, but you can't enter
them easily, then PI, but it was dependant of the system flag. Then just a
minute ago, I thought about TICKS which returns a #num.

crc 96B7h on the 48gx, 85.5 bytes. Should work on the 49, if not, use NOVAL
instead of TICKS.

\<<
    \-> T
    \<<
        T 0 TICKS IFTE SWAP + 1
        \<<
            DUP TYPE T == ::DROP IFT
        \>>
    DOSUBS TAIL
    \>>
\>>

<werner.huysegoms@gmail.com> wrote in message
news:1101969060.190529.228630@z14g2000cwz.googlegroups.com...
>
>
> You are getting close..
> I have essentially the same routine, but it is only 77.5 bytes.
>

I'm really curious to see that since I have to make sure that:
- the list for dosubs is not empty
- it returns a list, even empty
- it doesn't modify the rest of the stack

I thought about always adding 0 (for example) then catching the error TAIL
would throw, but that works only if the 3rd object in the stack cannot be
TAILed. Catching the dosubs error on an empty input list doesn't help with
the case where dosubs returns nothing.

> Werner
>

"Endless" <newsfree@daydreamnation.org> wrote in message 
news:41af0d17$0$22451$626a14ce@news.free.fr...
> There we go, I solved my saving 3 bytes problem, which was to generate a 
> non
> real (/integer on the 48g) in 2.5 bytes. On the 49, NOVAL was good enough,
> but wasted 3 bytes on the 48g. I tried using boolean flags, but as JMP
> noticed, it was specific of my calc, then system ints, but you can't enter
> them easily, then PI, but it was dependant of the system flag. Then just a
> minute ago, I thought about TICKS which returns a #num.
>
> crc 96B7h on the 48gx, 85.5 bytes. Should work on the 49, if not, use 
> NOVAL
> instead of TICKS.

TICKS is ok, what other solutions you _can_ find?
[VPN]

> \<<
>    \-> T
>    \<<
>        T 0 TICKS IFTE SWAP + 1
>        \<<
>            DUP TYPE T == ::DROP IFT
>        \>>
>    DOSUBS TAIL
>    \>>
> \>>
>
> 

I have to agree. Since I'm supposed to actually be working and the fact that
normally if I need a program to do a given task its (the programming) not a
priority, I'll tend to minimize programming time. My first submission only
took about 3 minutes to come up with. After about another 5 minutes I
nibbled it down to 121 bytes. And there it would stay, unless I needed a
speed increase. Then i would write it in sysrpl. So enough typing for me.
My second submission 121 bytes # D1AFh on a 49G+
\<< 0. \-> b c
  \<< OBJ\-> DUP 'c' STO { } SWAP
    WHILE 0. \=/
    REPEAT SWAP DUP TYPE b SAME :: DROP { 1. \->LIST SWAP + } IFTE 'c' DECR
    END
  \>>
\>>

Endless wrote:
> There we go, I solved my saving 3 bytes problem, which was to generate a non
> real (/integer on the 48g) in 2.5 bytes. On the 49, NOVAL was good enough,
> but wasted 3 bytes on the 48g. I tried using boolean flags, but as JMP
> noticed, it was specific of my calc, then system ints, but you can't enter
> them easily, then PI, but it was dependant of the system flag. Then just a
> minute ago, I thought about TICKS which returns a #num.

TICKS does work, although it seems rather a kludge, but "elegance"
isn't a requirement.

> crc 96B7h on the 48gx, 85.5 bytes. Should work on the 49, if not, use NOVAL
> instead of TICKS.

It works on the 49g+ as it is. BYTES returns # BC8Fh, 85.5. For
anyone trying to compile the program on a 49 series, note that the
0 and 1 in the program are real numbers, not exact integers,
because the source code was written for the 48G series.

Of course it doesn't work on the 48S/SX.

> \<<
>     \-> T
>     \<<
>         T 0 TICKS IFTE SWAP + 1
>         \<<
>             DUP TYPE T == ::DROP IFT
>         \>>
>     DOSUBS TAIL
>     \>>
> \>>

-- 
Regards,
James

Lee wrote:
> I have to agree. Since I'm supposed to actually be working and the fact that
> normally if I need a program to do a given task its (the programming) not a
> priority, I'll tend to minimize programming time. My first submission only
> took about 3 minutes to come up with. After about another 5 minutes I
> nibbled it down to 121 bytes. And there it would stay, unless I needed a
> speed increase. Then i would write it in sysrpl. So enough typing for me.
> My second submission 121 bytes # D1AFh on a 49G+

It also works on the 48S and 48G series, 121 bytes # 628h.

> \<< 0. \-> b c
>   \<< OBJ\-> DUP 'c' STO { } SWAP
>     WHILE 0. \=/
>     REPEAT SWAP DUP TYPE b SAME :: DROP { 1. \->LIST SWAP + } IFTE 'c' DECR
>     END
>   \>>
> \>>

-- 
Regards,
James

Fabian wrote:
> I decided to post my solution. It is not specially short:
>
> \<<
>     SWAP OVER
>     0 NOVAL IFTE
>     SWAP +
>     DUP 1 ::TYPE DOSUBS
>     ROT - NOT
>     2
>     \<< ::DROP IFT \>>
>    DOLIST
>    TAIL
> \>>
>
> HP48GX: 89 bytes, checksum: # E1FFh

Or on a 49 series, 86 bytes, checksum: # 2679h. Again note that
the numbers in the program are reals, not exact integers.

Of course, it doesn't work on the 48S/SX.

<snip>

-- 
Regards,
James

Khanh-Dang wrote:
> Fabian a �crit :
>
>> 2: { { 1 } 2 'a' }
>> 1: 0
>> REMELTYPE
>>
>> should return
>> 1: { { 1 } 'a' }
>>
>
> I am such an idiot : the recursive program I gave in a thread above
> should be called KEPPELTYPE (I've misread the rules :-)

KEPPELTYPE?

> Here is the corrected version of my program (same lenght, as \=/ is 2.5
> bytes, as well as ==)

48S Checksum: N/A
48S Size:     N/A
48G Checksum: # 7ABEh
48G Size:     98.5
49  Checksum: # EF2h
49  Size:     98.5

A reminder to anyone trying to run this program, it must be stored
with the name 'RELMTYPE' because it's recursive.

> Note that my version expect an object from level 1, and not a real
> giving the type you want to remove.

The first of this sort to be posted. I didn't really expect anyone
to do that, but it does work, and an example of the type to be
removed instead of the type number may be easier for some.


>
> \<<
>  OVER SIZE
>
>  {
>    OVER HEAD
>
>    OVER TYPE OVER TYPE \=/
>      SWAP 1. \->LIST 1. \->LIST
>      { {} }
>    IFTE
>
>    ROT TAIL
>    ROT
>    RELMTYPE
>    +
>  }
>
>  :: DROP
>
>  IFTE
> \>>

<snip>

-- 
Regards,
James

"James M. Prange" <jmprange@i-is.com> wrote in message
news:dYNrd.5996$qk.2222@fe39.usenetserver.com...
> Endless wrote:
> > There we go, I solved my saving 3 bytes problem, which was to generate a
non
> > real (/integer on the 48g) in 2.5 bytes. On the 49, NOVAL was good
enough,
> > but wasted 3 bytes on the 48g. I tried using boolean flags, but as JMP
> > noticed, it was specific of my calc, then system ints, but you can't
enter
> > them easily, then PI, but it was dependant of the system flag. Then just
a
> > minute ago, I thought about TICKS which returns a #num.
>
> TICKS does work, although it seems rather a kludge, but "elegance"
> isn't a requirement.
>
> > crc 96B7h on the 48gx, 85.5 bytes. Should work on the 49, if not, use
NOVAL
> > instead of TICKS.
>
> It works on the 49g+ as it is. BYTES returns # BC8Fh, 85.5. For
> anyone trying to compile the program on a 49 series, note that the
> 0 and 1 in the program are real numbers, not exact integers,
> because the source code was written for the 48G series
>
> Of course it doesn't work on the 48S/SX.
>
> > \<<
> >     \-> T

*** here T is the element, not the type ***

> >     \<<
> >         T 0 TICKS IFTE SWAP + 1
> >         \<<
> >             DUP TYPE T == ::DROP IFT
> >         \>>
> >     DOSUBS TAIL
> >     \>>
> > \>>
>
> -- 
> Regards,
> James
>

so I can't see it working at all

Regards

reth wrote:
> "James M. Prange" <jmprange@i-is.com> wrote in message
> news:dYNrd.5996$qk.2222@fe39.usenetserver.com...
>
>>Endless wrote:
>>
>>>There we go, I solved my saving 3 bytes problem, which was to generate a
>
> non
>
>>>real (/integer on the 48g) in 2.5 bytes. On the 49, NOVAL was good
>
> enough,
>
>>>but wasted 3 bytes on the 48g. I tried using boolean flags, but as JMP
>>>noticed, it was specific of my calc, then system ints, but you can't
>
> enter
>
>>>them easily, then PI, but it was dependant of the system flag. Then just
>
> a
>
>>>minute ago, I thought about TICKS which returns a #num.
>>
>>TICKS does work, although it seems rather a kludge, but "elegance"
>>isn't a requirement.
>>
>>
>>>crc 96B7h on the 48gx, 85.5 bytes. Should work on the 49, if not, use
>
> NOVAL
>
>>>instead of TICKS.
>>
>>It works on the 49g+ as it is. BYTES returns # BC8Fh, 85.5. For
>>anyone trying to compile the program on a 49 series, note that the
>>0 and 1 in the program are real numbers, not exact integers,
>>because the source code was written for the 48G series
>>
>>Of course it doesn't work on the 48S/SX.
>>
>>
>>>\<<
>>>    \-> T
>
>
> *** here T is the element, not the type ***
>
>
>>>    \<<
>>>        T 0 TICKS IFTE SWAP + 1
>>>        \<<
>>>            DUP TYPE T == ::DROP IFT
>>>        \>>
>>>    DOSUBS TAIL
>>>    \>>
>>>\>>
>>
>>--
>>Regards,
>>James
>>
>
>
> so I can't see it working at all

???

I'm not sure what you're saying. The level 1 argument should be a
real number for the type of element to be eliminated. Optionally,
an alternative style can use an example of the type of element to
be eliminated, but that should be noted in the entry.

Note that for this mini-challenge, what the program does for
arguments other than a list in level 2 and a real (or example of a
type) in level 1 doesn't matter. In particular, it doesn't matter
what it does for a type 28 exact integer in level 1, except when
it's the style that's supposed to take an example of the type
there. To be sure, it's nice if it also works correctly with an
exact integer instead of a real in level 1, and gracefully errors
out with other wrong arguments, but those aren't requirements.

Any program that takes a type number could very easily be modified
to take a type example instead, just by inserting a TYPE command
at the very beginning of the program. Of course, that adds 2.5
bytes to the program size. If someone can manage it without adding
an extra 2.5 bytes, I'd like to see how.

It sure looks to me as if this entry ought to work, and trying it
out, I haven't noticed any cases where it doesn't. I'm not going
to publish an analysis of how it works; other participants can
figure it out for themselves, if they care to.

Since this was written for a 48 series, on the 49 series I compile
it in approximate mode. It would fail if the 0 in the program were
a type 28 exact integer instead of a type 0 real number.

If anyone has a problem getting one of these programs to work,
first check the results from the BYTES command to make sure that
it's compiled as intended. I encourage all entrants to include the
results from the BYTES command (on the program itself on level 1,
not the quoted program name) and which model that was from to help
verify that I (and anyone else who wants to try the program) can
verify that it's compiled as intended. If it works on more than
one series of calcultors, I'll publish the other checksum, and at
least where it's diifferent, the other size.

On a 49 series, if the program was written for a 49 series, then
use exact mode to compile it, but if it was written for a 48
series, then use approximate mode to compile it. Compiling reals
to zints or vice versa would probably be the most frequent error,
but certainly typos could occur if you type it in.

So far, all of the entries have been using Kermit translation mode
3, and I appreciate that, although I've had to insert the transfer
headers myself. I've been using "%%HP: T(3)A(D)F(.);" for the
header. If someone uses anything other than translation mode 3 and
"." for the fraction mark, I'll try to adjust for that, but I may
have to ask for clarification if it doesn't compile as expected on
my calculators.

If you're the first to notice that an entry doesn't work
correctly, tell us what circumstances it fails in; for example,
flag settings or particular arguments.

-- 
Regards,
James

"James M. Prange" <jmprange@i-is.com> wrote in message
news:acSrd.6039$qk.1061@fe39.usenetserver.com...

> >>>\<<
> >>>    \-> T
> >
> >
> > *** here T is the element, not the type ***
> >
> >
> >>>    \<<
> >>>        T 0 TICKS IFTE SWAP + 1
> >>>        \<<
> >>>            DUP TYPE T == ::DROP IFT
> >>>        \>>
> >>>    DOSUBS TAIL
> >>>    \>>
> >>>\>>
> >>

>
> I'm not sure what you're saying. The level 1 argument should be a
> real number for the type of element to be eliminated.> Regards,
> James
>

Quoting VPN:

"A minichallange for those who have *never before* taken part!
Write the SHORTEST routine that eliminates the same TYPE of element
     2: list
     1: element of which type is desired to be eliminated
 RELEMTYPE
     1: list
"
If I read properly the above in level 1 we should have the element itself
and not what's left after TYPE command performed on it. I can see the point
of that, used as a subroutine it should take any argument

What I'm saying for the above program is that it does not work on my HP48GX
if in level 1 of the stack there is anything but a real number.

***

I don't really get it if a program not working on the 48S counts for the 48
category and VPN is kindly prompted to clarify that.

here is my 106 byte version (48 series)

<< TYPE -> L T
  << { }
    IFERR 1 L SIZE
      FOR I L I GET DUP TYPE T ==
       :: DROP
       :: +
       IFTE
      NEXT
     THEN DROP2
     END
   >>
>>

Regards,
Reth

Based on Endless' ;) - hp48g

<< TYPE DUP -> T
    << 0 TICKS IFTE SWAP + 1
        <<
            DUP TYPE T == DROPN
        >>
    DOSUBS TAIL
    >>
>>

I guess that's the 77.5 bytes Werner was talking about (if you remove the
TYPE command at the beginning).
I didn't think using a temp var would use more space than dup, and really
didn't think about DROPN. Well done.

"reth" <reth@nospam.com.at> wrote in message
news:41b0036a$1@dnews.tpgi.com.au...
> Based on Endless' ;) - hp48g
>
> << TYPE DUP -> T
>     << 0 TICKS IFTE SWAP + 1
>         <<
>             DUP TYPE T == DROPN
>         >>
>     DOSUBS TAIL
>     >>
> >>
>
>

"reth" <reth@nospam.com.at> wrote in message 
news:41aff85a@dnews.tpgi.com.au...
X
> Quoting VPN:
>
> "A minichallange for those who have *never before* taken part!
> Write the SHORTEST routine that eliminates the same TYPE of element
>     2: list
>     1: element of which type is desired to be eliminated
> RELEMTYPE
>     1: list
> "
> If I read properly the above in level 1 we should have the element itself
> and not what's left after TYPE command performed on it. I can see the 
> point
> of that, used as a subroutine it should take any argument
X
That was my original intention
X
> I don't really get it if a program not working on the 48S counts for the 
> 48
> category and VPN is kindly prompted to clarify that.
X
If you follow the thread back
you will notice that James M. Prange is the Great Judge
So now there are separate 48S/48G categories

Great Judge is kindly prompted to TakeOver
of these questions, too...
I only answered, giving my opinions, because I was addressed.
[VPN]

"Endless" <newsfree@daydreamnation.org> wrote in message 
news:41b01164$0$1798$626a14ce@news.free.fr...
>I guess that's the 77.5 bytes Werner was talking about (if you remove the
> TYPE command at the beginning).
> I didn't think using a temp var would use more space than dup, and really
> didn't think about DROPN. Well done.
>
> "reth" <reth@nospam.com.at> wrote in message
> news:41b0036a$1@dnews.tpgi.com.au...
>> Based on Endless' ;) - hp48g
>>
>> << TYPE DUP -> T
>>     << 0 TICKS IFTE SWAP + 1
>>         <<
>>             DUP TYPE T == DROPN
>>         >>
>>     DOSUBS TAIL
>>     >>
This "Endless" minichallange looks like it's going to end soon...
(-;
I would still like to see more entries.
Maybe someone can make it faster?
    Veli-Pekka
PS: This MiniChallange reveales also the "features" of the
    DOSUBS
which is a command that differs from other commands.
I don't know the decisions behind it.
This has been discussed before in this news group,
but I still hate the behaviour )-:<
:-(
[VPN]

reth wrote:
> "James M. Prange" <jmprange@i-is.com> wrote in message
> news:acSrd.6039$qk.1061@fe39.usenetserver.com...
>
>
>>>>>\<<
>>>>>   \-> T
>>>
>>>
>>>*** here T is the element, not the type ***
>>>
>>>
>>>
>>>>>   \<<
>>>>>       T 0 TICKS IFTE SWAP + 1
>>>>>       \<<
>>>>>           DUP TYPE T == ::DROP IFT
>>>>>       \>>
>>>>>   DOSUBS TAIL
>>>>>   \>>
>>>>>\>>
>>>>
>
>>I'm not sure what you're saying. The level 1 argument should be a
>>real number for the type of element to be eliminated.> Regards,
>>James
>>
>
>
> Quoting VPN:
>
> "A minichallange for those who have *never before* taken part!
> Write the SHORTEST routine that eliminates the same TYPE of element
>      2: list
>      1: element of which type is desired to be eliminated
>  RELEMTYPE
>      1: list
> "
> If I read properly the above in level 1 we should have the element itself
> and not what's left after TYPE command performed on it. I can see the point
> of that, used as a subroutine it should take any argument

Well, yes, it could be used that way, but then I'd have to have an
object of the type to be eliminated on the stack. Offhand, I'd
guess that I'd know which type I wanted to eliminate, and simply
supply the type as a real number on the stack. Either way has its
advantages.

> What I'm saying for the above program is that it does not work on my HP48GX
> if in level 1 of the stack there is anything but a real number.

I'm sorry for the misunderstanding.

Quoting myself, from when I accepted the "Great Judgeship":

>>      2: list
>>      1: element of which type is desired to be eliminated
>
> Meaning that the level 1 argument should be a "real number"
> representing the type to be eliminated, such as 0 for reals
> numbers, 1 for complex numbers, 2 for characters strings, and so
> on, not an example of the type to be eliminated. Right,
> Veli-Pekka?

I simply didn't quite understand Veli-Pekka's wording, using
"element" instead of "object", and in "clarifying" the rules, I
apparently ended up changing them from what he intended. I later
added in the option of using an object as an example of the type
to be eliminated instead of a real number.

As noted elsewhere, I expect that programs that use an object as
an example of the type to be eliminated will simply be 2.5 bytes
larger than programs that use a real number representing the
object type. But who knows? Maybe someone will surprise me.

> ***
>
> I don't really get it if a program not working on the 48S counts for the 48
> category and VPN is kindly prompted to clarify that.

That's easy. I split the 48 series category into two separate
categories; one for the 48SX and 48S, and another for the 48GX,
48G, and 48G+. As we've seen, there are very significant
differences in how these handle lists, and it's quite possible
that a program written for the 48G series won't work in the 48S
series. Requiring all 48 series entries to also work on the 48S
series would seem rather a burden to those (perhaps the majority
of 48 series users) who've never used a 48S series. On the other
hand, I expect that enough 48S series are still in use that they
should be included, and the users may not be familiar with how
lists are treated on the 48G series. Anyway, I thought it best to
have the two separate categories for the 48 series. There's also a
category for the 49G, 49g+, and 49gII. Currently, it looks to me
as if the differences between the 48S series and the 48G series
will turn out to be more important than the differences between
the 48 series and the 49 series, so I'm glad I did it that way.

In cases where an entry works in more than one category, I'm
treating it as an entry into all of the categories that it
actually works correctly in.

> here is my 106 byte version (48 series)
>
> << TYPE -> L T
>   << { }
>     IFERR 1 L SIZE
>       FOR I L I GET DUP TYPE T ==
>        :: DROP
>        :: +
>        IFTE
>       NEXT
>      THEN DROP2
>      END
>    >>

Which I think has the dubious distinction of being the first entry
to give me a "Syntax Error" even after I'd inserted the transfer
header. I took the liberty of modifying the source code as
follows:


%%HP: T(3)A(D)F(.);
@ 48S Checksum: # AC9Eh
@ 48S Size:         106
@ 48G Checksum: # AC9Eh
@ 48G Size:         106
@ 49  Checksum: # 3221h
@ 49  Size:        106.
\<< TYPE \-> L T
  \<< { }
    IFERR 1. L SIZE
      FOR I L I GET
DUP TYPE T == :: DROP
:: + IFTE
      NEXT
    THEN DROP2
    END
  \>>
\>>


Sorry, if the list contain any "sublist" as an element, then
that's always eliminated, so this doesn't work as required.

For example:

2:     { 1 "1" { 1 } }
1:                   0
RELEMTYPE

returns:

1:             { "1" }

instead of:

1:     { "1" { 1 } }

Don't feel too bad; my program had the same flaw.

-- 
Regards,
James

"Endless" <newsfree@daydreamnation.org> wrote in message news:<41af10ee$0$22457$626a14ce@news.free.fr>...
> <werner.huysegoms@gmail.com> wrote in message
> news:1101969060.190529.228630@z14g2000cwz.googlegroups.com...
> >
> >
> > You are getting close..
> > I have essentially the same routine, but it is only 77.5 bytes.
> >
> 
> I'm really curious to see that since I have to make sure that:
> - the list for dosubs is not empty
> - it returns a list, even empty
> - it doesn't modify the rest of the stack
> 
> I thought about always adding 0 (for example) then catching the error TAIL
> would throw, but that works only if the 3rd object in the stack cannot be
> TAILed. Catching the dosubs error on an empty input list doesn't help with
> the case where dosubs returns nothing.
> 
> > Werner
> >

The logic of your program is the same as mine: add a sentinel up front
that will
always make it into the result list, and take its TAIL.  
The devil is in the details..
For instance: a  local variable reference is 4.5 bytes, and one of the
differences between your version and mine is that I avoid one, and
have a DUP (2.5 bytes) instead: 2 bytes less. Look carefully...
Another difference (that does not .. make a difference):
You have found TICKS as a 2.5 byte 'constant', congrats!  I use C$ 0,
which will show up as a 2.5 byte empty string - but if you enter it as
"", it is 5 bytes.  C$ <length> <chars> is used to enter strings that
contain the string delimiters themselves, and works on all 48/49
machines afaik.
There's only one other difference between your version and mine..

I can't post mine - I'm not allowed to compete!
Werner

reth wrote:
> Based on Endless' ;) - hp48g
>
> << TYPE DUP -> T
>     << 0 TICKS IFTE SWAP + 1
>         <<
>             DUP TYPE T == DROPN
>         >>
>     DOSUBS TAIL
>     >>

Modified for downloading to any of these calculators:

%%HP: T(3)A(D)F(.);
@ 48S Checksum: N/A
@ 48S Size:     N/A
@ 48G Checksum: # 593Fh
@ 48G Size:          80
@ 49  Checksum: # 990Dh
@ 49  Size:         80.
\<< TYPE DUP \-> T
  \<< 0. TICKS IFTE
SWAP + 1.
    \<< DUP TYPE T ==
DROPN
    \>> DOSUBS TAIL
  \>>
\>>

Note that the level 1 argument for this program is an object
that's an example of the type to be eliminated, instead of the
real number for the type.

-- 
Regards,
James

"James M. Prange" <jmprange@i-is.com> wrote in message
news:3NVrd.3321$nU.2174@fe61.usenetserver.com...

> Sorry, if the list contain any "sublist" as an element, then
> that's always eliminated, so this doesn't work as required.
>
> For example:
>
> 2:     { 1 "1" { 1 } }
> 1:                   0
> RELEMTYPE
>
> returns:
>
> 1:             { "1" }
>
> instead of:
>
> 1:     { "1" { 1 } }
>
> Don't feel too bad; my program had the same flaw.
>
> -- 
> Regards,
> James
>
Sorry, James, you're right, what about:

%%HP: T(3)A(D)F(.);
\<< TYPE \-> L T
  \<< { }
    IFERR 1 L SIZE
      FOR I L I GET
        IF DUP TYPE
T ==
        THEN DROP
        ELSE
          IF DUP
TYPE 5 ==
          THEN 1
\->LIST
          END +
        END
      NEXT
    THEN DROP2
    END
  \>>
\>>

You're doing a great job, exactly what I like! My girlfriend recons it's all
bullshit, "how do you find this interesting..." :) Well I do

Best regards
Reth

"Endless" <newsfree@daydreamnation.org> wrote in message news:<41b01164$0$1798$626a14ce@news.free.fr>...
> I guess that's the 77.5 bytes Werner was talking about (if you remove the
> TYPE command at the beginning).
> I didn't think using a temp var would use more space than dup, and really
> didn't think about DROPN. Well done.
> 

That is it, indeed.  Even if I use SAME instead of == and DOLIST instead of DOSUBS.

Werner

"Werner" <werner.huysegoms@gmail.com> wrote in message 
news:e4f1e026.0412030117.6a3d24e1@posting.google.com...
X
> For instance: a  local variable reference is 4.5 bytes, and one of the
> differences between your version and mine is that I avoid one, and
> have a DUP (2.5 bytes) instead: 2 bytes less. Look carefully...
> Another difference (that does not .. make a difference):
> You have found TICKS as a 2.5 byte 'constant', congrats!  I use C$ 0,
> which will show up as a 2.5 byte empty string - but if you enter it as
> "", it is 5 bytes.  C$ <length> <chars> is used to enter strings that
> contain the string delimiters themselves, and works on all 48/49
> machines afaik.
> There's only one other difference between your version and mine..
>
> I can't post mine - I'm not allowed to compete!

You can post to me, Werner
[VPN]

reth wrote:
> "James M. Prange" <jmprange@i-is.com> wrote in message
> news:3NVrd.3321$nU.2174@fe61.usenetserver.com...
>
>
>>Sorry, if the list contain any "sublist" as an element, then
>>that's always eliminated, so this doesn't work as required.
>>
>>For example:
>>
>>2:     { 1 "1" { 1 } }
>>1:                   0
>>RELEMTYPE
>>
>>returns:
>>
>>1:             { "1" }
>>
>>instead of:
>>
>>1:     { "1" { 1 } }
>>
>>Don't feel too bad; my program had the same flaw.
>>
>>--
>>Regards,
>>James
>>
>
> Sorry, James, you're right, what about:
>
> %%HP: T(3)A(D)F(.);
> \<< TYPE \-> L T
>   \<< { }
>     IFERR 1 L SIZE
>       FOR I L I GET
>         IF DUP TYPE
> T ==
>         THEN DROP
>         ELSE
>           IF DUP
> TYPE 5 ==
>           THEN 1
> \->LIST
>           END +
>         END
>       NEXT
>     THEN DROP2
>     END
>   \>>
> \>>

Yes, it works, at least as far as I've noticed. But notice what
happened to the size.

@ 48S Checksum: # 152Bh
@ 48S Size:         139
@ 48G Checksum: # 152Bh
@ 48G Size:         139
@ 49  Checksum: # 8EF1h
@ 49  Size:        139.

This program takes an object as an example of the type to be
eliminated.

> You're doing a great job, exactly what I like!

Thank you!

>  My girlfriend recons it's all
> bullshit, "how do you find this interesting..."

Some people just don't get it, do they? Usually, but not always,
females; at least it seems that way to me. But I expect that your
girlfriend can think of something that you'd find more
interesting, at least for a while.

>  :) Well I do

Same here, and no doubt everyone who reads this newsgroup
regularly.

-- 
Regards,
James

"James M. Prange" <jmprange@i-is.com> wrote in message
news:7vZrd.102$AI.31@fe39.usenetserver.com...
> reth wrote:
> > "James M. Prange" <jmprange@i-is.com> wrote in message
> > news:3NVrd.3321$nU.2174@fe61.usenetserver.com...
> >
> >
> >>Sorry, if the list contain any "sublist" as an element, then
> >>that's always eliminated, so this doesn't work as required.
> >>
> >>For example:
> >>
> >>2:     { 1 "1" { 1 } }
> >>1:                   0
> >>RELEMTYPE
> >>
> >>returns:
> >>
> >>1:             { "1" }
> >>
> >>instead of:
> >>
> >>1:     { "1" { 1 } }
> >>
> >>Don't feel too bad; my program had the same flaw.
> >>
> >>--
> >>Regards,
> >>James
> >>
> >
> > Sorry, James, you're right, what about:
> >
> > %%HP: T(3)A(D)F(.);
> > \<< TYPE \-> L T
> >   \<< { }
> >     IFERR 1 L SIZE
> >       FOR I L I GET
> >         IF DUP TYPE
> > T ==
> >         THEN DROP
> >         ELSE
> >           IF DUP
> > TYPE 5 ==
> >           THEN 1
> > \->LIST
> >           END +
> >         END
> >       NEXT
> >     THEN DROP2
> >     END
> >   \>>
> > \>>
>
> Yes, it works, at least as far as I've noticed. But notice what
> happened to the size.
>
> @ 48S Checksum: # 152Bh
> @ 48S Size:         139
> @ 48G Checksum: # 152Bh
> @ 48G Size:         139
> @ 49  Checksum: # 8EF1h
> @ 49  Size:        139.
>
> This program takes an object as an example of the type to be
> eliminated.
>
> > You're doing a great job, exactly what I like!
>
> Thank you!
>
> >  My girlfriend recons it's all
> > bullshit, "how do you find this interesting..."
>
> Some people just don't get it, do they? Usually, but not always,
> females; at least it seems that way to me. But I expect that your
> girlfriend can think of something that you'd find more
> interesting, at least for a while.
>
> >  :) Well I do
>
> Same here, and no doubt everyone who reads this newsgroup
> regularly.
>
> -- 
> Regards,
> James
>
Whatever you do whatever (prog for HPcalc) you write there will be better
solution, that's what makes it the greatest calculator. Practically I don't
use it for work (except for + - etc) it's all onboard these days (surveying
instruments). But it's fun all over. Not to mention the memories. Strange, I
find computers boring despite of all their power. And the opposite for this
little gadget :)
Cheers

Note:
 This new program takes an example of an object of the type you want to
 delete as an input!!! (as originally postet by VPN)

Input:
2: list
1: element of which type is desired to be eliminated

Program:
\<<
  DUP TYPE SWAP ROT
  + DUP
  1 ::TYPE
  DOSUBS
  ROT - NOT
  2 \<< DROPN \>>
  DOLIST
\>>
HP48GX: 69.5 bytes, checksum: # 3D35h


On Thu, 2 Dec 2004, James M. Prange wrote:

> Fabian wrote:
> > I decided to post my solution. It is not specially short:
> >
> > \<<
> >     SWAP OVER
> >     0 NOVAL IFTE
> >     SWAP +
> >     DUP 1 ::TYPE DOSUBS
> >     ROT - NOT
> >     2
> >     \<< ::DROP IFT \>>
> >    DOLIST
> >    TAIL
> > \>>
> >
> > HP48GX: 89 bytes, checksum: # E1FFh
>
> Or on a 49 series, 86 bytes, checksum: # 2679h. Again note that
> the numbers in the program are reals, not exact integers.
>
> Of course, it doesn't work on the 48S/SX.
>
> <snip>
>
> --
> Regards,
> James
>
>
------------ And now a word from our sponsor ------------------
Want to have instant messaging, and chat rooms, and discussion
groups for your local users or business, you need dbabble!
--  See http://netwinsite.com/sponsor/sponsor_dbabble.htm  ----

"Fabian" <NOSPAM_fahasch@yahoo.de> wrote in message 
news:Pine.LNX.4.58L.0412031414490.2404@ptah.ethz.ch...
> Note:
> This new program takes an example of an object of the type you want to
> delete as an input!!! (as originally postet by VPN)
>
> Input:
> 2: list
> 1: element of which type is desired to be eliminated
>
> Program:
> \<<
>  DUP TYPE SWAP ROT
>  + DUP
>  1 ::TYPE
>  DOSUBS
>  ROT - NOT
>  2 \<< DROPN \>>
>  DOLIST
> \>>
> HP48GX: 69.5 bytes, checksum: # 3D35h
X
This is what I originally wanted to see...
:-D
[VPN]

"Veli-Pekka Nousiainen" <DROP_vpn@THIS.welho.com> wrote in message
news:coprlq$ot4$1@nyytiset.pp.htv.fi...
> "Fabian" <NOSPAM_fahasch@yahoo.de> wrote in message
> news:Pine.LNX.4.58L.0412031414490.2404@ptah.ethz.ch...
> > Note:
> > This new program takes an example of an object of the type you want to
> > delete as an input!!! (as originally postet by VPN)
> >
> > Input:
> > 2: list
> > 1: element of which type is desired to be eliminated
> >
> > Program:
> > \<<
> >  DUP TYPE SWAP ROT
> >  + DUP
> >  1 ::TYPE
> >  DOSUBS
> >  ROT - NOT
> >  2 \<< DROPN \>>
> >  DOLIST
> > \>>
> > HP48GX: 69.5 bytes, checksum: # 3D35h
> X
> This is what I originally wanted to see...
> :-D
> [VPN]
>
really?
try :
{ 1 "1" { 1 } }
DUP
<THE ABOVE PROGRAM>
:)

otherwise very elegant and original solution

cheers
reth

"reth" <reth@nospam.com.at> wrote in message 
news:41b07ab6@dnews.tpgi.com.au...
X
> really?
> try :
> { 1 "1" { 1 } }
> DUP
> <THE ABOVE PROGRAM>
> :)
>
> otherwise very elegant and original solution
X
Well It's not exactly what I had
but close enough
Naturally I have not tested entries I read here
(I let James to worry about them)
just my own
we will see late what Werner has in his sleeves
[VPN]

On Sat, 4 Dec 2004, reth wrote:

> really?
> try :
> { 1 "1" { 1 } }
> DUP
> <THE ABOVE PROGRAM>
> :)
>

You are right. One cannot eliminate lists from a list. Furthermore (and
this even more serious), it does not work on a empty list properly.

It seems that I didn't enough testing.
Fabian

Endless wrote:
> I guess that's the 77.5 bytes Werner was talking about (if you remove the
> TYPE command at the beginning).
> I didn't think using a temp var would use more space than dup,

Indeed it does, and I expect that in most cases, it's slower than
keeping everything that you still need right on the stack. But
local variables often make program development easier, and in some
cases, I haven't found a way to avoid using them to accomplish
what I want.

Actually, I was rather surprised that so many entries were using
local variables. I've sometimes been sorely tempted to give hints,
but that may well give some participants more help than others, so
I've been trying to avoid it. A judge is supposed to be impartial,
right?

> and really
> didn't think about DROPN. Well done.

I've noticed that participants seem to be borrowing ideas from
each other, which is fine with me. That way, you make faster
progress toward the best possible program, and we're learning new
things. I'm glad that nobody seems to be expressing hard feelings
when an idea is borrowed from him.

> "reth" <reth@nospam.com.at> wrote in message
> news:41b0036a$1@dnews.tpgi.com.au...
>
>>Based on Endless' ;) - hp48g
>>
>><< TYPE DUP -> T
>>    << 0 TICKS IFTE SWAP + 1
>>        <<
>>            DUP TYPE T == DROPN
>>        >>
>>    DOSUBS TAIL
>>    >>

-- 
Regards,
James

"James M. Prange" <jmprange@i-is.com> wrote in message
news:2%3sd.8$yY1.3@fe39.usenetserver.com...
> Endless wrote:
> > I guess that's the 77.5 bytes Werner was talking about (if you remove
the
> > TYPE command at the beginning).
> > I didn't think using a temp var would use more space than dup,
>
> Indeed it does, and I expect that in most cases, it's slower than
> keeping everything that you still need right on the stack. But
> local variables often make program development easier, and in some
> cases, I haven't found a way to avoid using them to accomplish
> what I want.
>
> Actually, I was rather surprised that so many entries were using
> local variables. I've sometimes been sorely tempted to give hints,
> but that may well give some participants more help than others, so
> I've been trying to avoid it. A judge is supposed to be impartial,
> right?
>
> > and really
> > didn't think about DROPN. Well done.
>
> I've noticed that participants seem to be borrowing ideas from
> each other, which is fine with me. That way, you make faster
> progress toward the best possible program, and we're learning new
> things. I'm glad that nobody seems to be expressing hard feelings
> when an idea is borrowed from him.
>
> > "reth" <reth@nospam.com.at> wrote in message
> > news:41b0036a$1@dnews.tpgi.com.au...
> >
> >>Based on Endless' ;) - hp48g
> >>
> >><< TYPE DUP -> T
> >>    << 0 TICKS IFTE SWAP + 1
> >>        <<
> >>            DUP TYPE T == DROPN
> >>        >>
> >>    DOSUBS TAIL
> >>    >>
>
> -- 
> Regards,
> James
>

I certainly take no credit - it's all Endless' idea and the DROPN trick I
learnt from Werner!

Cheers
Reth

          -=[ Sun, 5.12.04 12:02 p.m. +1300 (NZDT) ]=-

Hi James M. Prange ! <jmprange@i-is.com>

1 day 02h35m ago, on Fri, 3.12.04 at 3:27 p.m. -0500, you wrote
in message ID <2%3sd.8$yY1.3@fe39.usenetserver.com> :

> Actually, I was rather surprised that so many entries were
> using local variables.

Hint taken :-) 
I had to have a go at this, having never been involved in an
official challenge where size matters. Here is a 100 byter for
my old HP48SX. CRC #3137h.

%%HP: T(3)A(R)F(.);
\<< \-> T
  \<< OBJ\-> { } SWAP
    IF DUP
    THEN 1 SWAP
      START SWAP T OVER TYPE SAME :: DROP { 1 \->LIST SWAP + } IFTE
      NEXT
    ELSE DROP
    END
  \>>
\>>

It turns out to be merely a variant of Lee's program.
Disqualification happily accepted for any reason :-)

--
Tony Hutchins
New Zealand

          -=[ Sun, 5.12.04 12:40 p.m. +1300 (NZDT) ]=-

25m ago, on Sun, 5.12.04 at 12:15 p.m. +1300 (NZDT), I wrote
in message ID <10803799ROBOTLX@news.individual.net> :
 
> > Actually, I was rather surprised that so many entries were
> > using local variables.
> 
> Hint taken :-) 
Oops I forgot to say I tried it on the 48SX without local
variables and got the BYTES down to 103.5 - but using just one
local variable made stack manipulation much easier and the
BYTES reduced to 100, and the size of the source text file
reduced even more :-)

--
Tony Hutchins
New Zealand

          -=[ Sun, 5.12.04 1:34 p.m. +1300 (NZDT) ]=-

01h18m ago, on Sun, 5.12.04 at 12:15 p.m. +1300 (NZDT), I wrote
in message ID <10803799ROBOTLX@news.individual.net> :
[...]
> It turns out to be merely a variant of Lee's program.
> Disqualification happily accepted for any reason :-)

Actually, and I'm really plagiarizing now<G>, using Lee's
WHILE... REPEAT instead of my START.. shaves off another 5
bytes. This 48S version is 95 bytes.

%%HP: T(3)A(R)F(.);
\<< \-> T
  \<< OBJ\-> { } SWAP
    WHILE DUP
    REPEAT 1 - ROT T OVER TYPE SAME 
    :: DROP { 1 \->LIST ROT + SWAP } IFTE
    END DROP
  \>>
\>>

--
Tony Hutchins
New Zealand

I wrote:
> reth wrote:
>>Sorry, James, you're right, what about:
>>
>>%%HP: T(3)A(D)F(.);
>>\<< TYPE \-> L T
>>  \<< { }
>>    IFERR 1 L SIZE
>>      FOR I L I GET
>>        IF DUP TYPE
>>T ==
>>        THEN DROP
>>        ELSE
>>          IF DUP
>>TYPE 5 ==
>>          THEN 1
>>\->LIST
>>          END +
>>        END
>>      NEXT
>>    THEN DROP2
>>    END
>>  \>>
>>\>>
>
>
> Yes, it works, at least as far as I've noticed. But notice what
> happened to the size.
>
> @ 48S Checksum: # 152Bh
> @ 48S Size:         139
> @ 48G Checksum: # 152Bh
> @ 48G Size:         139
> @ 49  Checksum: # 8EF1h
> @ 49  Size:        139.
>
> This program takes an object as an example of the type to be
> eliminated.

On second thought, notice what happens if you have flag -55 set
(No last args), and you try eliminating elements from an empty
list. So this one doesn't qualify after all.

My apologies for not noticing sooner. I had such cases
specifically in mind when I wrote the rules, and was thinking that
I'd have to watch for IFERR structures as a "red flag", but this
one slipped by for a while.

Someone mentioned IFERR, and I thought, "I hope he doesn't try
going there!"

Big hint to all: If you use an IFERR structure, you may well have
to add code, either to save the flag state, force flag -55, and
restore it, or else to detect the flag -55 state and act
appropriately for it.

Of course, such techniques aren't prohibited, and if you can get
the program smaller using an IFERR structure and still meet the
requirements, then so be it. Personally, I don't think I'd start
down that path when the goal is the smallest size and I can avoid
doing things differently depending on the flag states.

--
Regards,
James

I wrote:
> Veli-Pekka Nousiainen wrote:

<snip>

>>The challange ends at 12.12.2004 midnight greenw. time
>>(regardless of D.MY/M.DY setting)
>
>
> "Midnight" meaning when 2004-12-12 ends, in Universal Coordinated
> Time. I'll go by the date and time in the post's
> "NNTP-Posting-Date:" header; usually (but not necessarily) this is
> within a few seconds after you send the post. If the date isn't
> 2004-12-12 or earlier after converting to UTC, then it's too late.
>
> In case of a tie, whoever posts first wins.

But I was surprised to find that some posts don't have an
"NNTP-Posting-Date:" header. Oh well, it probably won't be an
issue, but there are other headers that have the date and time. I
specifically don't want to use the "Date:" header, because with
most newsreaders, I can change that simply by changing the date or
time on my PC. Not that anyone on this newsgroup would cheat, but
just trying to make sure.

<snip>

-- 
Regards,
James

Has anyone bettered 77.5 bytes for the 49+?

Checksum # 37D4h or # 14295d

If given an empty  or a list all of which are to be eliminated it 
correctly returns an empty, and has passed all the other tests I can 
think of right now.

          -=[ Sun, 5.12.04 8:51 p.m. +1300 (NZDT) ]=-

Hi James M. Prange ! <jmprange@i-is.com>

1 day 11h24m ago, on Fri, 3.12.04 at 3:27 p.m. -0500, you wrote
in message ID <2%3sd.8$yY1.3@fe39.usenetserver.com> :

[...]
> I'm glad that nobody seems to be expressing hard feelings
> when an idea is borrowed from him.
> 
> > "reth" <reth@nospam.com.at> wrote in message
> > news:41b0036a$1@dnews.tpgi.com.au...
> >
> >>Based on Endless' ;) - hp48g
> >>
> >><< TYPE DUP -> T
> >>    << 0 TICKS IFTE SWAP + 1
> >>        <<
> >>            DUP TYPE T == DROPN
> >>        >>
> >>    DOSUBS TAIL
> >>    >>

Following Endless and Reth I had to try transposing this 80
byter to no local variable usage. This appears to be
equivalent, but 73 bytes, for the 49g+:

\<< TYPE SWAP 1
    \<< DUP TYPE PICK3 == DROPN \>>
   DOLIST
   DUP IF TYPE 5 \=/ THEN {} END
   NIP
\>>

For the 48G it would be 78 bytes (using 3 PICK and SWAP DROP
instead of PICK3 and NIP).

Strange how {} doesn't register in IFT.
<< 1. {} IFT >> EVAL just wipes itself out, but
<< IF 1. THEN {} END>> EVAL leaves {} on level 1.

--
Tony Hutchins
New Zealand

#232 Nothing in the world can take the place of
persistence. Calvin Coolidge

Tony Hutchins wrote:

>           -=[ Sun, 5.12.04 12:02 p.m. +1300 (NZDT) ]=-
>
> Hi James M. Prange ! <jmprange@i-is.com>
>
> 1 day 02h35m ago, on Fri, 3.12.04 at 3:27 p.m. -0500, you wrote
> in message ID <2%3sd.8$yY1.3@fe39.usenetserver.com> :
>
>
>>Actually, I was rather surprised that so many entries were
>>using local variables.
>
>
> Hint taken :-)
> I had to have a go at this, having never been involved in an
> official challenge where size matters.

But you have entered a mini-challenge before right? Based on that
I'm disqualifying you. Sorry, it was a tough decision to make.

But I will check your programs.

-- 
Regards,
James

          -=[ Sun, 5.12.04 9:40 p.m. +1300 (NZDT) ]=-

Hi Virgil ! <ITSnetNOTcom#virgil@COMCAST.com>

54m ago, on Sun, 5.12.04 at 00:45 a.m. -0700, you wrote
in message ID <ITSnetNOTcom#virgil-099439.00451405122004@comcast.dca.giganews.com> :

> Has anyone bettered 77.5 bytes for the 49+?

Without the initial TYPE this is 70.5 bytes

\<< TYPE SWAP 1
    \<< DUP TYPE PICK3 == DROPN \>>
   DOLIST
   DUP IF TYPE 5 \=/ THEN {} END
   NIP
\>>
Without the initial TYPE one must also allow the input (which
then remains unchanged & needs to be NIPped at the end ) to be
an integer (eg 8) or a real (eg 8.) so I test against 5
(string) at the end.

I also wrote:

> Strange how {} doesn't register in IFT.
> << 1. {} IFT >> EVAL just wipes itself out, but
> << IF 1. THEN {} END>> EVAL leaves {} on level 1.

Ahha I see the IFT needs {{}}, so loses the byte advantage in
this case. 

I'm sure the above can be shrunk. Let's target 50 bytes :-)

Following Endless & Reth and Werner more closely, this is down
to 66 bytes without the initial TYPE:

\<< TYPE DUP 0 TICKS IFTE ROT + 1
    \<< DUP TYPE PICK3 == DROPN \>>
   DOSUBS TAIL NIP
\>>

16 bytes to go :-)

*If* DOLIST/DOSUBS did the expected and actually produced an
explicit *something* for the null result - a {} would be quite
nice for example<G>, then we would hit 50.5 or 48 bytes
without the initial TYPE - i.e.
<< TYPE SWAP 1 << DUP TYPE PICK3 == DROPN >> DOLIST NIP >>
If we leave off the final NIP this does work without run-time
error but we need to carefully interpret the output<G> - so 50
is a tantalising target.
--
Tony Hutchins
New Zealand

Tony Hutchins wrote:
>           -=[ Sun, 5.12.04 12:02 p.m. +1300 (NZDT) ]=-
>
> Hi James M. Prange ! <jmprange@i-is.com>
>
> 1 day 02h35m ago, on Fri, 3.12.04 at 3:27 p.m. -0500, you wrote
> in message ID <2%3sd.8$yY1.3@fe39.usenetserver.com> :
>
>
>>Actually, I was rather surprised that so many entries were
>>using local variables.
>
>
> Hint taken :-)
> I had to have a go at this, having never been involved in an
> official challenge where size matters. Here is a 100 byter for
> my old HP48SX. CRC #3137h.

@ 48S Checksum: # 3137h
@ 48S Size:         100
@ 48G Checksum: # 3137h
@ 48G Size:         100
@ 49  Checksum: # B316h
@ 49  Size:        100.

Note: Download to 49 series in approximate mode.

It works in all categories, but as noted elsewhere, I disqualified
Tony.

> %%HP: T(3)A(R)F(.);
> \<< \-> T
>   \<< OBJ\-> { } SWAP
>     IF DUP
>     THEN 1 SWAP
>       START SWAP T OVER TYPE SAME :: DROP { 1 \->LIST SWAP + } IFTE
>       NEXT
>     ELSE DROP
>     END
>   \>>
> \>>
>
> It turns out to be merely a variant of Lee's program.
> Disqualification happily accepted for any reason :-)

-- 
Regards,
James

          -=[ Sun, 5.12.04 10:32 p.m. +1300 (NZDT) ]=-

Hi James

38m ago, on Sun, 5.12.04 at 03:54 a.m. -0500, you wrote
in message ID <s1Asd.191$jb3.162@fe61.usenetserver.com> :
[...]
> > I had to have a go at this, having never been involved in an
> > official challenge where size matters.
> 
> But you have entered a mini-challenge before right? Based on
> that I'm disqualifying you. Sorry, it was a tough decision
> to make.

Fair enough. Sorry to put you on the spot!

Cheers,
Tony

Virgil wrote:
> Has anyone bettered 77.5 bytes for the 49+?

Well, read the thread.

I think I'll end up making a table to see which programs were
which size in each category.

> Checksum # 37D4h or # 14295d
>
> If given an empty  or a list all of which are to be eliminated it
> correctly returns an empty, and has passed all the other tests I can
> think of right now.

Before you post an entry, have you ever entered a mini-challenge
before?

-- 
Regards,
James

Tony Hutchins wrote:
>           -=[ Sun, 5.12.04 1:34 p.m. +1300 (NZDT) ]=-
>
> 01h18m ago, on Sun, 5.12.04 at 12:15 p.m. +1300 (NZDT), I wrote
> in message ID <10803799ROBOTLX@news.individual.net> :
> [...]
>
>>It turns out to be merely a variant of Lee's program.
>>Disqualification happily accepted for any reason :-)
>
>
> Actually, and I'm really plagiarizing now<G>, using Lee's
> WHILE... REPEAT instead of my START.. shaves off another 5
> bytes. This 48S version is 95 bytes.

@ 48S Checksum:  # 7B9h
@ 48S Size:          95
@ 48G Checksum:  # 7B9h
@ 48G Size:          95
@ 49  Checksum: # 6D37h
@ 49  Size:         95.

Download to 49 series in approximate mode.

Works in all categories, but as noted before, I disqualified Tony.

> %%HP: T(3)A(R)F(.);
> \<< \-> T
>   \<< OBJ\-> { } SWAP
>     WHILE DUP
>     REPEAT 1 - ROT T OVER TYPE SAME
>     :: DROP { 1 \->LIST ROT + SWAP } IFTE
>     END DROP
>   \>>
> \>>

-- 
Regards,
James

"Tony Hutchins" <justth@csi.com> wrote in message
news:11464906ROBOTLX@news.individual.net...
>           -=[ Sun, 5.12.04 9:40 p.m. +1300 (NZDT) ]=-
>
> Hi Virgil ! <ITSnetNOTcom#virgil@COMCAST.com>
>
> 54m ago, on Sun, 5.12.04 at 00:45 a.m. -0700, you wrote
> in message ID
<ITSnetNOTcom#virgil-099439.00451405122004@comcast.dca.giganews.com> :
>
> > Has anyone bettered 77.5 bytes for the 49+?
>
> Without the initial TYPE this is 70.5 bytes
>
> \<< TYPE SWAP 1
>     \<< DUP TYPE PICK3 == DROPN \>>
>    DOLIST
>    DUP IF TYPE 5 \=/ THEN {} END
>    NIP
> \>>

Try {{1} 2 3. "4"}
0 (or 0.)
Nothing happens.

In fact, as soon as te list contains mixed types, it just stops working.

> Without the initial TYPE one must also allow the input (which
> then remains unchanged & needs to be NIPped at the end ) to be
> an integer (eg 8) or a real (eg 8.) so I test against 5
> (string) at the end.
>
> I also wrote:
>
> > Strange how {} doesn't register in IFT.
> > << 1. {} IFT >> EVAL just wipes itself out, but
> > << IF 1. THEN {} END>> EVAL leaves {} on level 1.
>
> Ahha I see the IFT needs {{}}, so loses the byte advantage in
> this case.
>
> I'm sure the above can be shrunk. Let's target 50 bytes :-)
>
> Following Endless & Reth and Werner more closely, this is down
> to 66 bytes without the initial TYPE:
>
> \<< TYPE DUP 0 TICKS IFTE ROT + 1
>     \<< DUP TYPE PICK3 == DROPN \>>
>    DOSUBS TAIL NIP
> \>>
>

Try
{ 1 2 3 }
0

I get a TAIL error

Or even
{ 1. 2. 3.}
0

-> returns { 2. 3. }

And last, { 1. 2. 3. }
0.
Returns the original list.

> 16 bytes to go :-)
>
> *If* DOLIST/DOSUBS did the expected and actually produced an
> explicit *something* for the null result - a {} would be quite
> nice for example<G>, then we would hit 50.5 or 48 bytes
> without the initial TYPE - i.e.
> << TYPE SWAP 1 << DUP TYPE PICK3 == DROPN >> DOLIST NIP >>
> If we leave off the final NIP this does work without run-time
> error but we need to carefully interpret the output<G> - so 50
> is a tantalising target.
> --
> Tony Hutchins
> New Zealand
>

"Tony Hutchins" <justth@csi.com> wrote in message
news:11394149ROBOTLX@news.individual.net...
>           -=[ Sun, 5.12.04 8:51 p.m. +1300 (NZDT) ]=-
>
> Hi James M. Prange ! <jmprange@i-is.com>
>
> 1 day 11h24m ago, on Fri, 3.12.04 at 3:27 p.m. -0500, you wrote
> in message ID <2%3sd.8$yY1.3@fe39.usenetserver.com> :
>
> [...]
> > I'm glad that nobody seems to be expressing hard feelings
> > when an idea is borrowed from him.
> >
> > > "reth" <reth@nospam.com.at> wrote in message
> > > news:41b0036a$1@dnews.tpgi.com.au...
> > >
> > >>Based on Endless' ;) - hp48g
> > >>
> > >><< TYPE DUP -> T
> > >>    << 0 TICKS IFTE SWAP + 1
> > >>        <<
> > >>            DUP TYPE T == DROPN
> > >>        >>
> > >>    DOSUBS TAIL
> > >>    >>
>
> Following Endless and Reth I had to try transposing this 80
> byter to no local variable usage. This appears to be
> equivalent, but 73 bytes, for the 49g+:
>
> \<< TYPE SWAP 1
>     \<< DUP TYPE PICK3 == DROPN \>>
>    DOLIST
>    DUP IF TYPE 5 \=/ THEN {} END
>    NIP
> \>>
>

I commented on that above in the thread (in short, it doesn't work)

> For the 48G it would be 78 bytes (using 3 PICK and SWAP DROP
> instead of PICK3 and NIP).
>
And I just tested it on the 48gx:
{1 2 "3"}
#2

Returns { 1 2 }

And I just figured what is wrong with your program, I think.

At one point we have
10 (result of TYPE on #2)
{1 2 "3"}
1
<<DUP TYPE 3 PICK == DROPN >>

Then DOLIST arrives and it breaks it into

10
1
the little code is run: DUP
10
1
1

TYPE
10
1
0

PICK3
10
1
0
10

==
10
1
0

DROPN
10
1

Then... the next element is pushed on the stack
10
1
2

Same thing, we end up with:
10
1
2

Then "3" is pushed
10
1
2
"3"

Then
DUP
TYPE
10
1
2
"3"
2

PICK3
10
1
2
"3"
2
2

== DROPN
10
1
2

We finished the dolist, the internal counter is at two, it becomes
10
{1 2}

then we clean, and finish with
{1 2}



> Strange how {} doesn't register in IFT.
> << 1. {} IFT >> EVAL just wipes itself out, but
> << IF 1. THEN {} END>> EVAL leaves {} on level 1.
>
> --
> Tony Hutchins
> New Zealand
>
> #232 Nothing in the world can take the place of
> persistence. Calvin Coolidge
>

Tony Hutchins wrote:
>           -=[ Sun, 5.12.04 8:51 p.m. +1300 (NZDT) ]=-
>
> Hi James M. Prange ! <jmprange@i-is.com>
>
> 1 day 11h24m ago, on Fri, 3.12.04 at 3:27 p.m. -0500, you wrote
> in message ID <2%3sd.8$yY1.3@fe39.usenetserver.com> :
>
> [...]
>
>>I'm glad that nobody seems to be expressing hard feelings
>>when an idea is borrowed from him.
>>
>>
>>>"reth" <reth@nospam.com.at> wrote in message
>>>news:41b0036a$1@dnews.tpgi.com.au...
>>>
>>>
>>>>Based on Endless' ;) - hp48g
>>>>
>>>><< TYPE DUP -> T
>>>>   << 0 TICKS IFTE SWAP + 1
>>>>       <<
>>>>           DUP TYPE T == DROPN
>>>>       >>
>>>>   DOSUBS TAIL
>>>>   >>
>
>
> Following Endless and Reth I had to try transposing this 80
> byter to no local variable usage. This appears to be
> equivalent, but 73 bytes, for the 49g+:

@ 48S Checksum: N/A
@ 48S Size:     N/A
@ 48G Checksum: N/A
@ 48G Size:     N/A
@ 49  Checksum: # 2E97h
@ 49  Size:         73.

Download to 49 series in exact mode.

Apparently, this is intended to take an example of a type in
level 1.

What's really interesting about this one is that it looks like it
has to error out with an empty list, and indeed it does on my 49G
with ROM revision 1.19-6, failing with "DOLIST Error: Invalid
Dimension". But it *seemed* to work on my 49g+ (ROM revision
1.23). How could that be?

As far as I've investigated, DOLIST fails with an empty list in
the 48G and 49G, but with the 49g+, it returns what *looks* like
an empty list. But actually, the list isn't really empty; SIZE on
it returns 1, but SIZE on a really empty list returns 0, and the
results from the BYTES command is different too. Looking at it
with flag -85 set (SysRPL stk disp), the list contains PTR 05607,
which is the pointer to an empty secondary, which of course isn't
displayed with flag -85 clear (Normal stk disp).

Is this supposed to be a feature? To me it seems to be a bug; if I
ask the calculator to do something unreasonable, then I expect it
to error out, not return a phony result that isn't what it looks
like. Is there a flag that controls this behaviour?

A more immediate concern for me is whether this phony
empty-looking list should be an acceptable result for this
mini-challenge. Comments, anyone?

Of course, I've already disqualified Tony.

> \<< TYPE SWAP 1
>     \<< DUP TYPE PICK3 == DROPN \>>
>    DOLIST
>    DUP IF TYPE 5 \=/ THEN {} END
>    NIP
> \>>
>
> For the 48G it would be 78 bytes (using 3 PICK and SWAP DROP
> instead of PICK3 and NIP).

But of course it wouldn't work on a 48G.

> Strange how {} doesn't register in IFT.
> << 1. {} IFT >> EVAL just wipes itself out, but
> << IF 1. THEN {} END>> EVAL leaves {} on level 1.

-- 
Regards,
James

Tony Hutchins wrote:
>           -=[ Sun, 5.12.04 9:40 p.m. +1300 (NZDT) ]=-
>
> Hi Virgil ! <ITSnetNOTcom#virgil@COMCAST.com>
>
> 54m ago, on Sun, 5.12.04 at 00:45 a.m. -0700, you wrote
> in message ID <ITSnetNOTcom#virgil-099439.00451405122004@comcast.dca.giganews.com> :
>
>
>>Has anyone bettered 77.5 bytes for the 49+?
>
>
> Without the initial TYPE this is 70.5 bytes

@ 48S Checksum: N/A
@ 48S Size:     N/A
@ 48G Checksum: N/A
@ 48G Size:     N/A
@ 49  Checksum: 2E97h
@ 49  Size:       73.

> \<< TYPE SWAP 1
>     \<< DUP TYPE PICK3 == DROPN \>>
>    DOLIST
>    DUP IF TYPE 5 \=/ THEN {} END
>    NIP
> \>>

With an empty list, this fails on a 49G. On a 49g+, it returns an
empty-looking list with PTR 05607 as an element.

> Without the initial TYPE one must also allow the input (which
> then remains unchanged & needs to be NIPped at the end ) to be
> an integer (eg 8) or a real (eg 8.) so I test against 5
> (string) at the end.
>
> I also wrote:
>
>
>>Strange how {} doesn't register in IFT.
>><< 1. {} IFT >> EVAL just wipes itself out, but
>><< IF 1. THEN {} END>> EVAL leaves {} on level 1.
>
>
> Ahha I see the IFT needs {{}}, so loses the byte advantage in
> this case.
>
> I'm sure the above can be shrunk. Let's target 50 bytes :-)
>
> Following Endless & Reth and Werner more closely, this is down
> to 66 bytes without the initial TYPE:

@ 48S Checksum: N/A
@ 48S Size:     N/A
@ 48G Checksum: N/A
@ 48G Size:     N/A
@ 49  Checksum: # F3F8h
@ 49  Size:        68.5

Download in exact mode.

> \<< TYPE DUP 0 TICKS IFTE ROT + 1
>     \<< DUP TYPE PICK3 == DROPN \>>
>    DOSUBS TAIL NIP
> \>>

Fails pretty badly on both the 49G and 49g+

> 16 bytes to go :-)
>
> *If* DOLIST/DOSUBS did the expected and actually produced an
> explicit *something* for the null result - a {} would be quite
> nice for example<G>, then we would hit 50.5 or 48 bytes
> without the initial TYPE - i.e.

> << TYPE SWAP 1 << DUP TYPE PICK3 == DROPN >> DOLIST NIP >>

Or:

%%HP: T(3)A(R)F(.);
@ 48S Checksum: N/A
@ 48S Size:     N/A
@ 48G Checksum: N/A
@ 48G Size:     N/A
@ 49  Checksum: EC22h
@ 49  Size:     50.5
@ Download in exact mode.
\<< TYPE SWAP 1
  \<< DUP TYPE PICK3 ==
DROPN
  \>> DOLIST NIP
\>>

With a 1- or 2-elemnt list, fails on the 49G. With a 1-element
list, fails on the 49g+. With an empty list, returns a list with
the element PTR 05607 on the 49g+.

> If we leave off the final NIP this does work without run-time
> error but we need to carefully interpret the output<G> - so 50
> is a tantalising target.

-- 
Regards,
James

I wrote:
> Veli-Pekka Nousiainen wrote:
>
>>A minichallange for those who have *never before* taken part!

In any mini-challenge, whether it involved size or not.

>>Write the SHORTEST routine that eliminates the same TYPE of element
>
>
> "SHORTEST" meaning the smallest size (in bytes) returned by the
> BYTES command on the program itself; not the size when you run
> BYTES on the program's quoted name. Execution time doesn't matter
> in this particular minichallenge.
>
>
>>     2: list
>>     1: element of which type is desired to be eliminated
>
>
> Meaning that the level 1 argument should be a "real number"
> representing the type to be eliminated, such as 0 for reals
> numbers, 1 for complex numbers, 2 for characters strings, and so
> on, not an example of the type to be eliminated. Right,
> Veli-Pekka?

As an alternative, programs which take an object as an example of
the type to be eliminated are also acceptable, but if you do this,
please note it in the entry.

> Argument checking isn't required. In other words, it doesn't
> matter what the program does for arguments other than the above.
>
>
>> RELEMTYPE
>>     1: list
>> Note:
>>Recall 'RELMTYPE' program contenst to stack and do BYTES
>> to get the bytes of the program itself + checksum

It must work correctly when stored in a global variable with
either the name 'RELEMTYPE' or 'RELMTYPE'

> Please post the checksum and which model you used too, as an aid
> to verifying that the program was downloaded or entered correctly.

If I can tell which series (48 or 49) it was written for, an entry
written for the 48 series will be compiled in approximate mode on
the 49 series, and an entry written for the 49 series will be
compiled in exact mode on the 49 series.

Note that exact integers from the 49 series will always be
compiled as real numbers in the 48 series.

> To make it easier to read and download the program, I recommend
> that you upload it to your PC using a Kermit ASCII transfer with
> translation mode 3 (Xlat: ->255 in an input form), or use a Conn4x
> "text" transfer with all translations enabled. For the 49 series,
> have the calculator in exact mode while uploading. Copy and paste
> the contents (including the transfer header) of the file to your
> post. Of course, you can type in the program instead; if I don't
> get the same checksum and size, then I'll ask for clarification.
>
> For the 49 series, please be particularly careful of the
> difference between real numbers (type 0) and exact integers (type
> 28); if you intend a real number, then include a decimal point.
>
>
>>Restrictions:
>>1) It must work correctly on an empty list too
>
>
> That is, if the level 2 argument is an empty list, then it must
> return an empty list without causing an error.

To clarify, looking like an empty list isn't enough; it must
actually be empty. If SIZE on it returns something other than 0,
then it isn't empty. My reasoning is that it's very basic to RPN
(including RPL) calculators that the result(s) returned by an
operation be suitable for the argument(s) in a subsequent
operation. If the list looks empty but actually contains a element
that isn't displayed, then it certainly isn't suitable.

>>2) The remaining elements have to be in their original order
>>3) No downloaded external libraries
>>4) UserRPL only, no SYSEVAL, LIBEVAL, FLASHEVAL
>>5) Be honest: don't ask for help from anyone!
>
>
> But I'd encourage everyone to make use of whatever other resources
> they can find, for example, the Google archive of this newsgroup.
>
> 6) Anything besides the arguments that was on the stack should
>    still be there when the program ends. For example, clearing the
>    stack is not acceptable, unless the program also restores it.
>    Similarly, it shouldn't KILL any suspended programs, or purge
>    or change any pre-existing variables.
>
> 7) Must not be mode or flag dependent. For example, it should work
>    in both exact and approximate modes, and with or without last
>    arguments saves (flag -55) enabled. It may change a flag while
>    running, but if it does, then it must restore the original
>    state.
>
>
>>Categories:
>>A) 48-series: 48S, 48SX, 48G, 48G+, 48GX
>
>
> Considering the changes to list processing, let's split that into
> two categories; one for the 48S and 48SX, and another for the 48G,
> 48GX, and 48G+.
>
>
>>B) 49-series: 48gII, 49G, 49g+
>
>
> I don't have a 48gII, but I expect that if it works on one of
> these, then it ought to work on all of them. If it turns out
> otherwise, let's just say that it must work on at least one of
> them.
>
>
>>C) 49-series using also manually attachable "secret" libraries
>>    Contestants are urged to dig information using internet.
>
>
> Of course, it could happen that one entry wins in more than one
> category.

An entry that works correctly in more than one category will be
treated as an entry into every category that it works in.

>>The challange ends at 12.12.2004 midnight greenw. time
>>(regardless of D.MY/M.DY setting)
>
>
> "Midnight" meaning when 2004-12-12 ends, in Universal Coordinated
> Time. I'll go by the date and time in the post's
> "NNTP-Posting-Date:" header; usually (but not necessarily) this is
> within a few seconds after you send the post. If the date isn't
> 2004-12-12 or earlier after converting to UTC, then it's too late.

It turns out the some posts don't have an "NNTP-Posting-Date:"
header, so I'll use whichever header, *except the "Date:" header*
has the earliest date and time.

> In case of a tie, whoever posts first wins.

To be considered as an entry, the source code must be posted.

> Entries or questions should be in replies to this thread. Of
> course, if you come up with something smaller, then feel free to
> post another entry.
>
> Let's try to keep this an enjoyable learning exercise. Give it
> your best shot. I'd encourage you to post your smallest program
> before the deadline, even if someone else has already posted a
> smaller one; it could turn out that there's a flaw in an
> apparently better entry. It's interesting to see how many
> different ways to get the same result are possible.

Plagiarism is encouraged. Of course, it's nice to credit whomever
you just got a brilliant idea from.

> In case of a dispute, the judge's final decision is final. But if
> you notice a flaw that the judge hasn't noticed, point it out. The
> judge reserves his right to change his decision.
>
> Prize: Fame (at least in this thread).
>
>
>>James M. Prange is invited to be the Great Judge!
>
>
> Accepted. Thank you!

-- 
Regards,
James

"Tony Hutchins" <justth@csi.com> wrote in message
news:10803799ROBOTLX@news.individual.net...
>          -=[ Sun, 5.12.04 12:02 p.m. +1300 (NZDT) ]=-
>
> Hi James M. Prange ! <jmprange@i-is.com>
>
> 1 day 02h35m ago, on Fri, 3.12.04 at 3:27 p.m. -0500, you wrote
> in message ID <2%3sd.8$yY1.3@fe39.usenetserver.com> :
>
>> Actually, I was rather surprised that so many entries were
>> using local variables.
>
> Hint taken :-)
> I had to have a go at this, having never been involved in an
> official challenge where size matters.

Any minichallange ever, not just size
IF you do not qualify
THEN please stop posting
END

[VPN]

"Virgil" <ITSnetNOTcom#virgil@COMCAST.com> wrote in message 
news:ITSnetNOTcom%23virgil-099439.00451405122004@comcast.dca.giganews.com...
> Has anyone bettered 77.5 bytes for the 49+?
>
> Checksum # 37D4h or # 14295d
>
> If given an empty  or a list all of which are to be eliminated it
> correctly returns an empty, and has passed all the other tests I can
> think of right now.

We will see in the 13th day
when also the old-timers can put out their entries
We will see some different variations of the same method
I guess, but [VPN] just might have a trick in his sleeve
I just hope that the Great Judge doesn't sentense me to jail...
(-;
[VPN]

          -=[ Mon, 6.12.04 08:13 a.m. +1300 (NZDT) ]=-

Hi James

01h43m ago, on Sun, 5.12.04 at 12:30 p.m. -0500, you wrote
in message ID <SAHsd.11473$QJ2.1331@fe39.usenetserver.com> :

> I wrote:
> > Veli-Pekka Nousiainen wrote:
> >
> >>A minichallange for those who have *never before* taken part!
> 
> In any mini-challenge, whether it involved size or not.

And, even if the mini-challenge was disguised :-) 

===============================
From: joehorn@holyjoe.net (Joseph K. Horn)
Newsgroups: comp.sys.hp48	
Subject: 48/49: Best Fraction Challenge	
Date: 11 Oct 2003 13:02:42 -0700

The "Best Fraction Challenge"
(An Extremely Difficult Challenge Disguised as a Mini-Challenge)
[...]
=================================

That's the one that disqualified me. Still it doesn't stop me
learning from the postings of others. Especially about DOLIST
which I had never used - and as Endless (Thanks BTW) pointed
out my program was totally non-functional and therefore
self-disqualifying<G> - easily the worst I've seen. It's so
hard to see "inside" DOLIST - I tried 4 PICK though which gave
an error showing a stack that makes it look like 3 PICK should
work, but .... :-(

Hey, you guys who can take part are the lucky ones!

--
Tony Hutchins
New Zealand

#27 Just got a new car for my wife... Great trade...

          -=[ Mon, 6.12.04 08:51 a.m. +1300 (NZDT) ]=-

Hi Veli-Pekka Nousiainen ! <DROP_vpn@THIS.welho.com>

57m ago, on Sun, 5.12.04 at 8:53 p.m. +0200, you wrote
in message ID <covlcu$tb0$1@nyytiset.pp.htv.fi> :

> "Tony Hutchins" <justth@csi.com> wrote in message
> news:10803799ROBOTLX@news.individual.net...
> >          -=[ Sun, 5.12.04 12:02 p.m. +1300 (NZDT) ]=-
> >
> > Hi James M. Prange ! <jmprange@i-is.com>
> >
> > 1 day 02h35m ago, on Fri, 3.12.04 at 3:27 p.m. -0500, you wrote
> > in message ID <2%3sd.8$yY1.3@fe39.usenetserver.com> :
> >
> >> Actually, I was rather surprised that so many entries were
> >> using local variables.
> >
> > Hint taken :-)
> > I had to have a go at this, having never been involved in an
> > official challenge where size matters.
> 
> Any minichallange ever, not just size
> IF you do not qualify
> THEN please stop posting
> END

{Hutchins}
mini-challenge_disqualified_TYPE
REMELEM
{}

That's all I will post. Better than those non-solutions anyway
<G>. 

--
Tony Hutchins
New Zealand

#38 I have seen the evidence.  I want DIFFERENT evidence!

          -=[ Mon, 6.12.04 09:13 a.m. +1300 (NZDT) ]=-

Hi Endless ! <newsfree@daydreamnation.org>

07h10m ago, on Sun, 5.12.04 at 2:02 p.m. +0100, you wrote
in message ID <41b306db$0$15818$636a15ce@news.free.fr> :

> > \<< TYPE SWAP 1
> >     \<< DUP TYPE PICK3 == DROPN \>>
> >    DOLIST
> >    DUP IF TYPE 5 \=/ THEN {} END
> >    NIP
> > \>>
> >
> 
> I commented on that above in the thread (in short, it
> doesn't work)

I agree :-( Thanks for your post!

The PICK3 works a little bit only<G>. DOLIST actually *uses*
the upper stack to store any output elements (via a fixed
ROLLD) so our comparison TYPE actually rises up the stack,
sitting on top of the output element sub-stack. Hehe. We need
a variable PICK, or make it a local variable, like you have
already done. What fun :-). *If* DOLIST stored a zero by
default as the starting output LIST SIZE then the final ->LIST
it seems to do would actually produce a clean {}.

--
Tony Hutchins
New Zealand

"Tony Hutchins" <justth@csi.com> wrote in message 
news:10563451ROBOTLX@news.individual.net...
>          -=[ Mon, 6.12.04 08:13 a.m. +1300 (NZDT) ]=-
>
> Hi James
>
> 01h43m ago, on Sun, 5.12.04 at 12:30 p.m. -0500, you wrote
> in message ID <SAHsd.11473$QJ2.1331@fe39.usenetserver.com> :
>
>> I wrote:
>> > Veli-Pekka Nousiainen wrote:
>> >
>> >>A minichallange for those who have *never before* taken part!
>>
>> In any mini-challenge, whether it involved size or not.
>
> And, even if the mini-challenge was disguised :-)
>
> ===============================
> From: joehorn@holyjoe.net (Joseph K. Horn)
> Newsgroups: comp.sys.hp48
> Subject: 48/49: Best Fraction Challenge
> Date: 11 Oct 2003 13:02:42 -0700
>
> The "Best Fraction Challenge"
> (An Extremely Difficult Challenge Disguised as a Mini-Challenge)
> [...]
> =================================
>
> That's the one that disqualified me. Still it doesn't stop me
> learning from the postings of others. Especially about DOLIST
> which I had never used - and as Endless (Thanks BTW) pointed
> out my program was totally non-functional and therefore
> self-disqualifying<G> - easily the worst I've seen. It's so
> hard to see "inside" DOLIST

Not hard at all: You could do something like this:
{} 'L' STO
Fill the stack with dummies like
65 DUP 25 + FOR c c CHR NEXT
then a sample list and the type value
DBUG the program and just before DOLIST/DOSUBS
(you can see it coming using |NEXT|)
edit the program to hold say (in case of DOSUBS) :
    20 DUPN NSUB "
" + 21 ->LIST 'L' STO+
just before the test
    ==
I you are using DOLIST you may want to have
{} 'L' STO 0 'J' STO
in the beginning and then use
    20 DUPN 'J' INCR "
" + 21 ->LIST 'L' STO+
just before the test
    ==
Just help you all in debugging your code!
[VPN]

          -=[ Mon, 6.12.04 2:12 p.m. +1300 (NZDT) ]=-

Hi Veli-Pekka Nousiainen ! <DROP_vpn@THIS.welho.com>

01h41m ago, on Mon, 6.12.04 at 01:31 a.m. +0200, you wrote
in message ID <cp05mn$9c6$1@nyytiset.pp.htv.fi> :

> > self-disqualifying<G> - easily the worst I've seen. It's so
> > hard to see "inside" DOLIST
> 
> Not hard at all: You could do something like this:
> {} 'L' STO
> Fill the stack with dummies like
> 65 DUP 25 + FOR c c CHR NEXT
> then a sample list and the type value
> DBUG the program and just before DOLIST/DOSUBS
> (you can see it coming using |NEXT|)

I never pressed |NEXT| before!! I only really started RPL when I
got the 49g+, but have since resurrected and really like the
old 48SX as well :-)

> edit the program to hold say (in case of DOSUBS) :
>     20 DUPN NSUB "
> " + 21 ->LIST 'L' STO+
> just before the test
>     ==
> I you are using DOLIST you may want to have
> {} 'L' STO 0 'J' STO
> in the beginning and then use
>     20 DUPN 'J' INCR "
> " + 21 ->LIST 'L' STO+
> just before the test
>     ==
> Just help you all in debugging your code!

Thanks VPN! I think I see the idea - capture the stack in a
global variable for perusal later? DOLIST is a funny creature
- I think it only finally knows the length of its output list
from variation in stack size - it is not done recursively as I
first thought. But, this leaves it exposed to tricks, in fact
almost recursive in themselves and .... results in more BYTES
smallness :-) And, it works too - honest<G>.

--
Tony Hutchins
New Zealand

          -=[ Mon, 6.12.04 3:12 p.m. +1300 (NZDT) ]=-

Hi James ! <jmprange@i-is.com>

12h02m ago, on Sun, 5.12.04 at 09:10 a.m. -0500, you wrote
in message ID <uFEsd.206$jb3.193@fe61.usenetserver.com> :

> Of course, I've already disqualified Tony.
> 
> > \<< TYPE SWAP 1
> >     \<< DUP TYPE PICK3 == DROPN \>>
> >    DOLIST
> >    DUP IF TYPE 5 \=/ THEN {} END
> >    NIP
> > \>>
> >
> > For the 48G it would be 78 bytes (using 3 PICK and SWAP DROP
> > instead of PICK3 and NIP).
> 
> But of course it wouldn't work on a 48G.

Off the record I have now fixed this (it's really quite
different but still has that PICK3 and  NIP!) at a cost of 3.5
bytes (76.5 on the 49g+, 74 w/o an initial TYPE). I suppose we
can all share results after the 12th?

--
Tony Hutchins
New Zealand

#59 AAAAA - American Assoc. Against Acronym Abuse

"Tony Hutchins" <justth@csi.com> wrote in message 
news:11021263ROBOTLX@news.individual.net...
X
> Off the record I have now fixed this (it's really quite
> different but still has that PICK3 and  NIP!) at a cost of 3.5
> bytes (76.5 on the 49g+, 74 w/o an initial TYPE). I suppose we
> can all share results after the 12th?
Sure!
You may also sent them to me, I'd love to take an early peek!
[VPN]

> > > self-disqualifying<G> - easily the worst I've seen. It's so
> > > hard to see "inside" DOLIST
> >
> > Not hard at all: You could do something like this:
> > {} 'L' STO
> > Fill the stack with dummies like
> > 65 DUP 25 + FOR c c CHR NEXT
> > then a sample list and the type value
> > DBUG the program and just before DOLIST/DOSUBS
> > (you can see it coming using |NEXT|)

Or just put a HALT right at the beginning of the secondary which is
executed by DOLIST.
------------ And now a word from our sponsor ------------------
Want to have instant messaging, and chat rooms, and discussion
groups for your local users or business, you need dbabble!
--  See http://netwinsite.com/sponsor/sponsor_dbabble.htm  ----

Inspired by what you tried, I have a semi working entry (assumes the stack
is exactly 2: list 1: type; nothing above).

\<< SWAP OVER 0 TICKS IFTE SWAP + 1
    \<< DUP TYPE DEPTH PICK == DROPN \>>
    DOSUBS TAIL SWAP DROP
\>>

crc #2852h, 73.5 bytes.

"Tony Hutchins" <justth@csi.com> wrote in message
news:11021263ROBOTLX@news.individual.net...
>           -=[ Mon, 6.12.04 3:12 p.m. +1300 (NZDT) ]=-
>
> Hi James ! <jmprange@i-is.com>
>
> 12h02m ago, on Sun, 5.12.04 at 09:10 a.m. -0500, you wrote
> in message ID <uFEsd.206$jb3.193@fe61.usenetserver.com> :
>
> > Of course, I've already disqualified Tony.
> >
> > > \<< TYPE SWAP 1
> > >     \<< DUP TYPE PICK3 == DROPN \>>
> > >    DOLIST
> > >    DUP IF TYPE 5 \=/ THEN {} END
> > >    NIP
> > > \>>
> > >
> > > For the 48G it would be 78 bytes (using 3 PICK and SWAP DROP
> > > instead of PICK3 and NIP).
> >
> > But of course it wouldn't work on a 48G.
>
> Off the record I have now fixed this (it's really quite
> different but still has that PICK3 and  NIP!) at a cost of 3.5
> bytes (76.5 on the 49g+, 74 w/o an initial TYPE). I suppose we
> can all share results after the 12th?
>
> --
> Tony Hutchins
> New Zealand
>
> #59 AAAAA - American Assoc. Against Acronym Abuse
>

And now the same with the whole stack (I just read the whole "bug in REPL
thread ;) ):

\<< DUP DEPTH ROLLD 0 TICKS IFTE SWAP + 1
    \<< DUP TYPE DEPTH PICK == DROPN \>>
    DOSUBS TAIL DEPTH ROLL DROP
\>>

crc #240Eh, 78.5 bytes (thus not as good as the 77.5 achieved before).


"Endless" <newsfree@daydreamnation.org> wrote in message
news:41b42345$0$14580$626a14ce@news.free.fr...
> Inspired by what you tried, I have a semi working entry (assumes the stack
> is exactly 2: list 1: type; nothing above).
>
> \<< SWAP OVER 0 TICKS IFTE SWAP + 1
>     \<< DUP TYPE DEPTH PICK == DROPN \>>
>     DOSUBS TAIL SWAP DROP
> \>>
>
> crc #2852h, 73.5 bytes.
>

          -=[ Mon, 6.12.04 10:19 p.m. +1300 (NZDT) ]=-

Hi Veli-Pekka Nousiainen ! <DROP_vpn@THIS.welho.com>

05h13m ago, on Mon, 6.12.04 at 06:06 a.m. +0200, you wrote
in message ID <cp0lq8$deb$1@nyytiset.pp.htv.fi> :

> > I suppose we can all share results after the 12th?
> Sure!
Great!
> You may also sent them to me, I'd love to take an early peek!

Thanks VPN.

Have sent 'em. Possibly examples of bad programming because
they exploit the unexpected DOLIST null result, which makes
avoiding local variables much easier. I make DOLIST think it
has done nothing, and if it delivered {} as expected my method
would be history. Then again maybe there is a reason for that
behaviour. Also I shamelessly optimised the 49g+ version (for
smallness) by taking as many NIPs as possible<G>. They look
fully shrunk now :-)

-- 
Tony

          -=[ Mon, 6.12.04 11:13 p.m. +1300 (NZDT) ]=-

Hi Endless ! <newsfree@daydreamnation.org>

42m ago, on Mon, 6.12.04 at 10:31 a.m. +0100, you wrote
in message ID <41b426e2$0$15048$626a14ce@news.free.fr> :

> And now the same with the whole stack (I just read the whole "bug in REPL
> thread ;) ):
> 
> \<< DUP DEPTH ROLLD 0 TICKS IFTE SWAP + 1
>     \<< DUP TYPE DEPTH PICK == DROPN \>>
>     DOSUBS TAIL DEPTH ROLL DROP
> \>>
> 
> crc #240Eh, 78.5 bytes (thus not as good as the 77.5 achieved before).

Yup 1 byte bigger. But, it sure looks more than only 1 byte
bigger. The 77.5 is proving hard to pass, especially on the
48G. But, it's only the 6th so there's time yet :-)

-- 
Tony

In article <XPAsd.209$QJ2.91@fe39.usenetserver.com>,
 "James M. Prange" <jmprange@i-is.com> wrote:

> Virgil wrote:
> > Has anyone bettered 77.5 bytes for the 49+?
> 
> Well, read the thread.
> 
> I think I'll end up making a table to see which programs were
> which size in each category.
> 
> > Checksum # 37D4h or # 14295d
> >
> > If given an empty  or a list all of which are to be eliminated it
> > correctly returns an empty, and has passed all the other tests I can
> > think of right now.
> 
> Before you post an entry, have you ever entered a mini-challenge
> before?

I entered a couple of them back in 1997/1998, or at least posted 
comments and hints related to them.

Endless wrote:
> And now the same with the whole stack (I just read the whole "bug in REPL
> thread ;) ):

%%HP: T(3)A(D)F(.);
@ 48S Checksum: N/A
@ 48S Size:     N/A
@ 48G Checksum: # 240Eh
@ 48G Size:     78.5
@ 49  Checksum: # C4ACh
@ 49  Size:     78.5
@ Download to 49 series in approximate mode.

> \<< DUP DEPTH ROLLD 0 TICKS IFTE SWAP + 1
>     \<< DUP TYPE DEPTH PICK == DROPN \>>
>     DOSUBS TAIL DEPTH ROLL DROP
> \>>
>
> crc #240Eh, 78.5 bytes (thus not as good as the 77.5 achieved before).

I'm impressed. That works around any problems with altering the
stack above the arguments in a lot fewer bytes than the solution
that occurred to me.

I think that I can use that method in my own programs. They're
nowhere near as small as some of the entries so far, but since
they don't depend on the 48G series' enhanced list processing,
they can be modified to work on the 48SX/S with minor
modifications.

> "Endless" <newsfree@daydreamnation.org> wrote in message
> news:41b42345$0$14580$626a14ce@news.free.fr...
>
>>Inspired by what you tried, I have a semi working entry (assumes the stack
>>is exactly 2: list 1: type; nothing above).
>>
>>\<< SWAP OVER 0 TICKS IFTE SWAP + 1
>>    \<< DUP TYPE DEPTH PICK == DROPN \>>
>>    DOSUBS TAIL SWAP DROP
>>\>>
>>
>>crc #2852h, 73.5 bytes.

-- 
Regards,
James

Fabian wrote:

>>>>self-disqualifying<G> - easily the worst I've seen. It's so
>>>>hard to see "inside" DOLIST
>>>
>>>Not hard at all: You could do something like this:
>>>{} 'L' STO
>>>Fill the stack with dummies like
>>>65 DUP 25 + FOR c c CHR NEXT
>>>then a sample list and the type value
>>>DBUG the program and just before DOLIST/DOSUBS
>>>(you can see it coming using |NEXT|)
>
>
> Or just put a HALT right at the beginning of the secondary which is
> executed by DOLIST.

Yes, DBUG treats some program structures or subprograms as a
single step. In such cases, inserting a HALT at the beginning of
them allows single-stepping through them. The SSTDownArrow key
allows you to single-step into programs called by name. Pressing
CONT allows you to skip to the next HALT command, often an
advantage when you want to avoid repetitively single-stepping
through a loop or want to quickly get to a problem area. The KILL
command aborts the program and removes any suspended environments,
one of which is caused by the DBUG operation; usually, KILL will
be used when you've found a problem. I usually use NEXT to see
what the next object will be, with the possible exception of
quickly single-stepping through code known to be good.

-- 
Regards,
James

Tony Hutchins wrote:
>           -=[ Mon, 6.12.04 3:12 p.m. +1300 (NZDT) ]=-
>
> Hi James ! <jmprange@i-is.com>
>
> 12h02m ago, on Sun, 5.12.04 at 09:10 a.m. -0500, you wrote
> in message ID <uFEsd.206$jb3.193@fe61.usenetserver.com> :
>
>
>>Of course, I've already disqualified Tony.
>>
>>
>>>\<< TYPE SWAP 1
>>>    \<< DUP TYPE PICK3 == DROPN \>>
>>>   DOLIST
>>>   DUP IF TYPE 5 \=/ THEN {} END
>>>   NIP
>>>\>>
>>>
>>>For the 48G it would be 78 bytes (using 3 PICK and SWAP DROP
>>>instead of PICK3 and NIP).
>>
>>But of course it wouldn't work on a 48G.
>
>
> Off the record I have now fixed this (it's really quite
> different but still has that PICK3 and  NIP!) at a cost of 3.5
> bytes (76.5 on the 49g+, 74 w/o an initial TYPE).

Interesting; assuming that you've tested it thoroughly, that means
that there's still room for improvement. Please make sure that the
"empty list" returned when the argument is an empty list is really
empty; SIZE on it should return 0.

>  I suppose we
> can all share results after the 12th?

Sure; I don't see any reason why not. Of course, from your time
zone, that means waiting until 13:00 (1:00 P.M.) on the 13th. I
get to post mine after 19:00 on the 12th.  On the other hand,
these guys have me beaten so badly that I'm not so sure that I
want to post mine.

-- 
Regards,
James

Virgil wrote:
> In article <XPAsd.209$QJ2.91@fe39.usenetserver.com>,
>  "James M. Prange" <jmprange@i-is.com> wrote:
>
>
>>Virgil wrote:
>>
>>>Has anyone bettered 77.5 bytes for the 49+?
>>
>>Well, read the thread.
>>
>>I think I'll end up making a table to see which programs were
>>which size in each category.
>>
>>
>>>Checksum # 37D4h or # 14295d
>>>
>>>If given an empty  or a list all of which are to be eliminated it
>>>correctly returns an empty, and has passed all the other tests I can
>>>think of right now.
>>
>>Before you post an entry, have you ever entered a mini-challenge
>>before?
>
>
> I entered a couple of them back in 1997/1998, or at least posted
> comments and hints related to them.

Well, that makes you sort of an "old-timer" doesn't it? Of course,
comments and hints don't disqualify anyone, only actual entries.
I'm not inclined to do a thorough search of the Google newsgroup
archive, and of course some may have posted using a different
name, so to a large extent it's "word of honour". If you can
confirm that you've never actually entered a mini-challenge, and
no one presents evidence to the contrary, then you're eligible.

The whole idea is to give "newbies" a chance to compete, without
discouraging them right away with smaller programs using
techniques that they wouldn't initially think of. Of course, some
of these "newbies" may in fact have a lot of experience with RPL,
but that they've never before entered a mini-challenge implies
that they've never really tried very hard to squeeze a program
down to the smallest possible size.

Offhand, I don't recall whether the mini-challenges that I've
entered involved size at all, or only speed or correct results,
but certainly I've put a lot of effort into reducing program size
in some cases.

Of course, even "old-timers" can post their code after the
deadline. It will be interesting to see whether anyone can best
the winners.

-- 
Regards,
James

          -=[ Tue, 7.12.04 9:17 p.m. +1300 (NZDT) ]=-

Hi James

20m ago, on Tue, 7.12.04 at 02:56 a.m. -0500, you wrote
in message ID <0ndtd.10521$jb3.2656@fe61.usenetserver.com> :

> > Off the record I have now fixed this (it's really quite
> > different but still has that PICK3 and  NIP!) at a cost of 3.5
> > bytes (76.5 on the 49g+, 74 w/o an initial TYPE).
> 
> Interesting; assuming that you've tested it thoroughly,

LOL! Yup that's my weakness. It's the first time I've gone for
smallness in RPL, and I write too many versions with only very
sparse testing and I just remember them by the byte count<G>.
There are so many ways to do things, and hard to predict how
certain mixes will pan out. I discovered the 49g+ is really
useful for these challenges - the Filer view even shows the
byte counts and one can quickly view the programs too.

> that means that there's still room for improvement. Please
> make sure that the "empty list" returned when the argument
> is an empty list is really empty; SIZE on it should return 0.

That was my method's weakness. I started using flag -85 this
morning. The code was down to 71.5 but is back up to 76.5
again as I need to finally ->STR OBJ-> to remove any strange
hidden objects :-) Also, this will only work on a 49g+ - not a
49G, or 48G. So, it's a very quirky solution, dependent on the
current 49g+ ROM I guess. If a future ROM fixes the DOLIST bug
it won't work at all <G>. It's got 2 NIPs! I never found a use
for NIP before. I had fun but it's not really a very
interesting solution, and I can't imagine anyone wanting to
actually use it. Hehe if I were a judge I'd find a way to
disallow it<G>. I even had one that *only* worked if an example
of the "type" were input - well I think it worked - sort of
like an inverse of Endless's where I needed something that
would be dropped, rather than kept.

> >  I suppose we
> > can all share results after the 12th?
> 
> Sure; I don't see any reason why not. Of course, from your time
> zone, that means waiting until 13:00 (1:00 P.M.) on the 13th. I
> get to post mine after 19:00 on the 12th.  On the other hand,
> these guys have me beaten so badly that I'm not so sure that I
> want to post mine.

I'm very happy to wait - maybe then I will at least post
something that works for a change. LOL! I'm really looking
forward to seeing all the results! 

BTW thanks for your description of debugging. I tried the HALT
today - very useful. Now, I must stop writing here so much -
it's just too easy on the 10 year old HP200LX - it's always
with me.  My news client is pretty simple - it doesn't add the
NNT-Posting-Date for example... nor does my news server
apparently, so it may be an optional thingy that can be added
by clients?

-- 
Tony

reth wrote:

<snip>

> Whatever you do whatever (prog for HPcalc) you write there will be better
> solution,

Certainly better than anything that *I* write, if anyone cares to
write for the problems my programs are intended to solve, but if,
by "best" we mean "smallest", then I suspect that it would be hard
to better Werner in UserRPL or Wolfgang in SysRPL. I don't have
enough experience in assembly language to comment on that.

My inclinations are for "fastest", or more often I end up with a
compromise between speed and size, probably giving more weight to
speed.

>  that's what makes it the greatest calculator. Practically I don't
> use it for work (except for + - etc) it's all onboard these days (surveying
> instruments).

Yes, I certainly use the trig functions, units conversions, and
statistics a lot too, but mostly I rely on software built-in to
CMM systems for the geometry and trig, and PC-based specialized
statistics applications, often built-in to CMM systems.

>  But it's fun all over. Not to mention the memories. Strange, I
> find computers boring despite of all their power.

At one time I quite enjoyed writing useful little batch programs
and aliases, for the 4DOS command processor running on DRDOS, and
macros for Qedit (later renamed to TSE Junior), but with MS
Windows 9x and TSE Pro's SAL macro language, I seem to have lost
my interest, though I'm sure that I could write some very useful
things if I gave it half a try. I really should get back into them
a bit.

>  And the opposite for this
> little gadget :)

Quite so. After the "Goodies Disks" ended, I "coasted" with my
UserRPL programming techniques for a few years; after all, I could
accomplish what I wanted with little effort, but this newsgroup
certainly revived my interest.

But now, having dabbled in SysRPL and assembly language a bit, I'm
beginning to feel UserRPL a bit restrictive. SysRPL offers so many
more commands, and without the speed penalty of unneeded argument
checking, and I'm rather amazed on how much I can accomplish in
less than a single tick in assembly language.

Still, for "ad hoc" fast development, I rather prefer UseRPL's
"safe sandbox" restrictions and argument checking. At work, the
calculator is merely another tool, and writing the fastest or
smallest possible program for it has never been part of my job
descriptions.

-- 
Regards,
James

"James M. Prange" <jmprange@i-is.com> wrote in message 
news:E4dtd.10519$jb3.521@fe61.usenetserver.com...
> Fabian wrote:
>
>>>>>self-disqualifying<G> - easily the worst I've seen. It's so
>>>>>hard to see "inside" DOLIST
>>>>
>>>>Not hard at all: You could do something like this:
>>>>{} 'L' STO
>>>>Fill the stack with dummies like
>>>>65 DUP 25 + FOR c c CHR NEXT
>>>>then a sample list and the type value
>>>>DBUG the program and just before DOLIST/DOSUBS
>>>>(you can see it coming using |NEXT|)
>>
>>
>> Or just put a HALT right at the beginning of the secondary which is
>> executed by DOLIST.
You can also do that while single stepping your program
just before DOLIST edit the program in stack to have
HALT as the first step of the subprogram and
your saved version is left unaltered
[VPN] 

Ok, here's one more. 99.5 bytes #6062h on a 49G+ Should work on all models.

\<< \-> b
  \<< DUP SIZE { OBJ\-> { } 1. ROT
    FOR C SWAP DUP TYPE b SAME :: DROP { 1. \->LIST SWAP + } IFTE
    NEXT } IFT
  \>>
\>>
 Last one I promise.
"Lee" <RDELM@PACBELL.NET> wrote in message
news:WdHrd.37287$6q2.30897@newssvr14.news.prodigy.com...
> I have to agree. Since I'm supposed to actually be working and the fact
that
> normally if I need a program to do a given task its (the programming) not
a
> priority, I'll tend to minimize programming time. My first submission only
> took about 3 minutes to come up with. After about another 5 minutes I
> nibbled it down to 121 bytes. And there it would stay, unless I needed a
> speed increase. Then i would write it in sysrpl. So enough typing for me.
> My second submission 121 bytes # D1AFh on a 49G+
> \<< 0. \-> b c
>   \<< OBJ\-> DUP 'c' STO { } SWAP
>     WHILE 0. \=/
>     REPEAT SWAP DUP TYPE b SAME :: DROP { 1. \->LIST SWAP + } IFTE 'c'
DECR
>     END
>   \>>
> \>>
>
>

          -=[ Wed, 8.12.04 3:08 p.m. +1300 (NZDT) ]=-

Hi Lee ! <RDELM@PACBELL.NET>

02h34m ago, on Tue, 7.12.04 at 11:34 p.m. +0000 (GMT), you wrote
in message ID <96rtd.55821$QJ3.745@newssvr21.news.prodigy.com> :

> Ok, here's one more. 99.5 bytes #6062h on a 49G+ Should work on all models.
> 
> \<< \-> b
>   \<< DUP SIZE { OBJ\-> { } 1. ROT
>     FOR C SWAP DUP TYPE b SAME :: DROP { 1. \->LIST SWAP + } IFTE
>     NEXT } IFT
>   \>>
> \>>
>  Last one I promise.

No, no, keep 'em coming.

I just worked how NDUPN works here - it's not on the 48G but
on the 49G and 49g+
You could replace:

SAME :: DROP { 1. \->LIST SWAP + } IFTE

with:

\=/ NDUPN \->LIST SWAP +

Just after I worked this out I got a low battery warning
but kept working, till I lost everything - too much
enthusiam<G>.

NDPUN just made my version here shrink by 11 bytes!!!

I think NDUPN is just like DUPN except it also returns the
"n". And 0 DUPN does a DROP.
So, calling the element e we have
e 1 NDUPN -> e 1. ready for the ->LIST
e 0 NDUPN -> 0.   also ready as it produces {} which can be
safely added to no effect <G>

I hope this causes much shrinkage in entries :-)
 
-- 
Tony Hutchins
New Zealand

"Tony Hutchins" <justth@csi.com> wrote in message 
news:11014150ROBOTLX@news.individual.net...
X
> I hope this causes much shrinkage in entries :-)

Maybe you are helping them too much, Tony
They are supposed to find the NDUPN and
other tricks all by themselves
AND
you can still shave off some nibbles from your program, Tony
(which is the best [par none] I can think of myself)
[VPN]

          -=[ Wed, 8.12.04 5:44 p.m. +1300 (NZDT) ]=-

Hi Veli-Pekka Nousiainen ! <DROP_vpn@THIS.welho.com>

01h29m ago, on Wed, 8.12.04 at 05:14 a.m. +0200, you wrote
in message ID <cp5rgp$rf6$1@nyytiset.pp.htv.fi> :

> "Tony Hutchins" <justth@csi.com> wrote in message 
> news:11014150ROBOTLX@news.individual.net...
> X
> > I hope this causes much shrinkage in entries :-)
> 
> Maybe you are helping them too much, Tony
LOL! Rare for me<G>. Couldn't resist as I only got started by
copying from other entries here.

> They are supposed to find the NDUPN and
> other tricks all by themselves

But NDUPN is not documented in any paper manuals I peruse.
It was such a surprise it did just what I wanted. Sort of
equivalent to DUP DEPTH ROLL DUPN DEPTH ROLL - no wonder it
gave me 11 bytes. It's such a big trick it's more like a
truck!

If there are other trucks I'm looking forward to seeing them
after the 12th :-)

> AND
> you can still shave off some nibbles from your program, Tony
LOL! I can but will it work?<G>. I can't see nibbles, just 2.5
byte chunks <G>.
> (which is the best [par none] I can think of myself)
Thanks VPN - you're welcome to polish it off. Still 5 days to
go as well, so there is hope for something better - shake your
sleeve ;-) 
 
-- 
Tony

Tony Hutchins wrote:
>           -=[ Tue, 7.12.04 9:17 p.m. +1300 (NZDT) ]=-
>
> Hi James
>
> 20m ago, on Tue, 7.12.04 at 02:56 a.m. -0500, you wrote
> in message ID <0ndtd.10521$jb3.2656@fe61.usenetserver.com> :
>
>
>>>Off the record I have now fixed this (it's really quite
>>>different but still has that PICK3 and  NIP!) at a cost of 3.5
>>>bytes (76.5 on the 49g+, 74 w/o an initial TYPE).
>>
>>Interesting; assuming that you've tested it thoroughly,
>
>
> LOL! Yup that's my weakness. It's the first time I've gone for
> smallness in RPL, and I write too many versions with only very
> sparse testing and I just remember them by the byte count<G>.
> There are so many ways to do things, and hard to predict how
> certain mixes will pan out. I discovered the 49g+ is really
> useful for these challenges - the Filer view even shows the
> byte counts

Although often rounded up to an integer.

>  and one can quickly view the programs too.

Of course, the same is true of the 49G. I rather prefer Wolfgang's
Filer programs, but even the built-in filer is useful indeed.

>>that means that there's still room for improvement. Please
>>make sure that the "empty list" returned when the argument
>>is an empty list is really empty; SIZE on it should return 0.
>
>
> That was my method's weakness. I started using flag -85 this
> morning.

Setting flag -85 can show some things that aren't always so
obvious.

>  The code was down to 71.5 but is back up to 76.5
> again as I need to finally ->STR OBJ-> to remove any strange
> hidden objects

Good point; \->STR decompiles this particular "hidden object" to
an empty string, so STR\-> or OBJ\-> on the resulting source
string reurns the original UserRPL object with the "hidden object"
removed. Even though it relies on a bug in the 49g+, I'll allow
it.

..  :-) Also, this will only work on a 49g+ - not a
> 49G, or 48G.

Well, if someone posts something that works on at least one of the
49g+, 49G, or 48gII, but not all of them, then I'll split that
category. The program is required to work on at least one model,
not necessarily on every model in the originally intended
category, although I'd expected that any program that worked on
the 49G with ROM 1.19-6, the 49g+, or the 48gII would work on all
of them.

>  So, it's a very quirky solution, dependent on the
> current 49g+ ROM I guess. If a future ROM fixes the DOLIST bug
> it won't work at all <G>.

I don't know about the earlier 49g+ ROM revisions, but this bug
isn't present in the 49G revision 1.19-6 ROM, or in the 48GX
version R ROM.

Perhaps it's an attempt to return an empty list when DOLIST gets
an empty list for an argument; I could understand the reasoning
behind that. But as it is, it seems a rather serious bug. Suppose
that I have the empty-looking list on the stack and then do "A" +;
it returns what looks like the 1-element list { "A" }, but "A" is
really the second element, not the only element as it appears to
be. Programs (and users) that use the misleading list could get
very "confused". I'd much prefer to just get an error when I tell
the calculator to do something that doesn't make sense.

>  It's got 2 NIPs! I never found a use
> for NIP before.

It's useful wherever you'd otherwise use SWAP DROP. It's nothing
that we can't live without, but I like it. What I'd really like
would be to have some more of the stack manipulation commands that
are available in SysRPL also available as built-in UserRPL
commands. It would be easy enough to write a SysRPL library making
them argument-checking external library commands, but then the
library would be required for any program that used them.

>  I had fun but it's not really a very
> interesting solution, and I can't imagine anyone wanting to
> actually use it. Hehe if I were a judge I'd find a way to
> disallow it<G>. I even had one that *only* worked if an example
> of the "type" were input

Huh? I think that ordinarily the ones that take an object as an
example of a type always require that, and the ones that take a
real number always require a real number, although of course this
means that the real number 0 works with both kinds of program when
real numbers are the type to be eliminated.

So far, I'm inclined to consider a program that requires an
example to be equivalent to the same program with a TYPE command
removed (2.5 bytes smaller) and taking a real number argument
instead, but I may change my mind if someone comes up with an
example that can't be changed from one kind of program to the
other by such a trivial change.

>  - well I think it worked - sort of
> like an inverse of Endless's where I needed something that
> would be dropped, rather than kept.
>
>>> I suppose we
>>>can all share results after the 12th?
>>
>>Sure; I don't see any reason why not. Of course, from your time
>>zone, that means waiting until 13:00 (1:00 P.M.) on the 13th. I
>>get to post mine after 19:00 on the 12th.  On the other hand,
>>these guys have me beaten so badly that I'm not so sure that I
>>want to post mine.
>
>
> I'm very happy to wait - maybe then I will at least post
> something that works for a change. LOL! I'm really looking
> forward to seeing all the results!
>
> BTW thanks for your description of debugging. I tried the HALT
> today - very useful.

Yes, it can make debugging a lot easier. Also note Veli-Pekka's
helpful tip that you can insert it while debugging, to only the
copy of the program that you're currently running.

>  Now, I must stop writing here so much -
> it's just too easy on the 10 year old HP200LX - it's always
> with me.  My news client is pretty simple - it doesn't add the
> NNT-Posting-Date for example... nor does my news server
> apparently, so it may be an optional thingy that can be added
> by clients?

As far as I know, the only header that a client adds when sending
that includes the date and time is the "Date:" header, and some
don't even include a "Date:" header unless they're configured to
do so. Of course, since they use the operating system's time, the
"Date:" header isn't always very accurate. I'm assuming that any
time stamp added by a server is likely to be more accurate. I had
thought that the "NNTP-Posting-Date:" header was added by every
news server on initial postings, but I've found that that's just
not so. On your post that I'm replying to, I get an
"X-Received-Date: Tue, 07 Dec 2004:04:18:07 EST (text02)" header,
which I believe is added by the NNTP server that my ISP uses. It
also has a "Date: Tue, 7 Dec 2004 22:21:12 +1300 (NZDT)" header,
so I surmise that your PC's time is a little fast (or the server's
time is a little slow). Strangely enough, the body of the message
includes "-=[ Tue, 7.12.04 9:17 p.m. +1300 (NZDT) ]=-", an hour
and 4 minutes before the "Date:" header; maybe the time in the
message body is added by your editor, but the "Date:" header isn't
added until you actually send the message? I'd treat it as
"2004-12-07 09:18:07 UTC", based on my "X-Received-Date:" header.
My client always displays the "Date:" header time, converted to my
time zone, or if the "Date:" header is missing, then
"1969-12-31 19:00" or, during daylight saving time,
"1969-12-31 20:00", which are "1970-01-01 00:00 UTC" converted to
my operating system's time zone. Of course, I have the option of
viewing posts with all headers displayed, and in some cases, there
are additional headers that include the date and time.

By the way, your sigdash (two dashes followed by a space and
nothing else on a single line) works correctly. Now my newsreader
(as currently configured) displays that line and anything
following "greyed out", and when I reply, it isn't included in the
quoted text, which saves me the minor task of editing out the
signature.

-- 
Regards,
James

Lee wrote:

> Ok, here's one more. 99.5 bytes #6062h on a 49G+ Should work on all models.

And indeed it does.

%%HP: T(3)A(D)F(.);
@ 48S Checksum: # 57B8h
@ 48S Size:        99.5
@ 48G Checksum: # 57B8h
@ 48G Size:        99.5
@ 49  Checksum: # 6062h
@ 49  Size:        99.5

> \<< \-> b
>   \<< DUP SIZE { OBJ\-> { } 1. ROT
>     FOR C SWAP DUP TYPE b SAME :: DROP { 1. \->LIST SWAP + } IFTE
>     NEXT } IFT
>   \>>
> \>>
>  Last one I promise.

Last one? But the deadline is still a few days away! And I've been
hoping to see a few more of these that work on the 48SX/S.

-- 
Regards,
James

          -=[ Wed, 8.12.04 7:43 p.m. +1300 (NZDT) ]=-

Hi James

01h23m ago, on Wed, 8.12.04 at 00:20 a.m. -0500, you wrote
in message ID <yawtd.12635$QJ2.8316@fe39.usenetserver.com> :
[...]
> >  It's got 2 NIPs! I never found a use
> > for NIP before.
> 
> It's useful wherever you'd otherwise use SWAP DROP. It's
> nothing that we can't live without, but I like it. What
> I'd really like would be to have some more of the stack
> manipulation commands that are available in SysRPL
> also available as built-in UserRPL commands.

One day I'll *have* to look at SysRPL.
[...]
> >  I had fun but it's not really a very
> > interesting solution, and I can't imagine anyone wanting to
> > actually use it. Hehe if I were a judge I'd find a way to
> > disallow it<G>. I even had one that *only* worked if an example
> > of the "type" were input
> 
> Huh? I think that ordinarily the ones that take an object as
> an example of a type always require that, and the ones that
> take a real number always require a real number, although
> of course this means that the real number 0 works with
> both kinds of program when real numbers are the type to
> be eliminated.
> 
> So far, I'm inclined to consider a program that requires
> an example to be equivalent to the same program with a TYPE
> command removed (2.5 bytes smaller) and taking a real number
> argument instead, but I may change my mind if someone comes
> up with an example that can't be changed from one kind of
> program to the other by such a trivial change.

As an example - STREAM requires an input list of at least SIZE
2. So if I feed STREAM a list with {{} type_example}
pre-pended it will happily use the {} as a basis and the
type_example will be dropped, as the TYPE is actually the TYPE
of the example<G>. Such a program might go:

<< DUP TYPE {} ROT 2 \->LIST ROT + <<....>> STREAM>>

input of List, Tex -> TYPE(Tex) {{} Tex }+List

In this one the "TYPE" cannot be removed, and the type_example
must be the input. If it has size X then it would be unfair to
catalogue it with size X-2.5 as it wouldn't work<G>. Maybe you
have covered this in your comments above. Anyway this is a
hypothetical example from a disqualified person<G>.
 
[....]
> On your post that I'm replying to, I get an "X-Received-Date:
> Tue, 07 Dec 2004:04:18:07 EST (text02)" header, which I
> believe is added by the NNTP server that my ISP uses.

Looks like a server date.

> It also has a "Date: Tue, 7 Dec 2004 22:21:12 +1300 (NZDT)"
> header, so I surmise that your PC's time is a little fast
> (or the server's time is a little slow).

It'll be my palmtop - yup it's a couple of minutes fast.

> Strangely enough, the body of the message includes "-=[ Tue,
> 7.12.04 9:17 p.m. +1300 (NZDT) ]=-", an hour and 4 minutes
> before the "Date:" header; maybe the time in the message
> body is added by your editor, but the "Date:" header isn't
> added until you actually send the message?

Yes I should really stop that particular header. It's added as
soon as I start replying - and the other info about the time
delay since the date of the received message. Sometimes it
helps me with the context.

> I'd treat it as "2004-12-07 09:18:07 UTC", based on my
> "X-Received-Date:" header.

It will be interesting if this becomes an issue :-)

> My client always displays the "Date:" header time, converted
> to my time zone, or if the "Date:" header is missing, then
> "1969-12-31 19:00" or, during daylight saving time,
> "1969-12-31 20:00", which are "1970-01-01 00:00 UTC"
> converted to my operating system's time zone.

Interesting! I'm not sure what happens here - I just get no
date header in that case, so it is not displayed<G>.

> By the way, your sigdash (two dashes followed by a space
> and nothing else on a single line) works correctly. Now my
> newsreader (as currently configured) displays that line and
> anything following "greyed out", and when I reply, it isn't
> included in the quoted text, which saves me the minor task
> of editing out the signature.

I must have a look at Mozilla. My palmtop must be on its last
legs by now. As it is I do no e-mail on a desktop.

-- 
Tony

Tony Hutchins wrote:
>           -=[ Wed, 8.12.04 5:44 p.m. +1300 (NZDT) ]=-
>
> Hi Veli-Pekka Nousiainen ! <DROP_vpn@THIS.welho.com>
>
> 01h29m ago, on Wed, 8.12.04 at 05:14 a.m. +0200, you wrote
> in message ID <cp5rgp$rf6$1@nyytiset.pp.htv.fi> :
>
>
>>"Tony Hutchins" <justth@csi.com> wrote in message
>>news:11014150ROBOTLX@news.individual.net...
>>X
>>
>>>I hope this causes much shrinkage in entries :-)
>>
>>Maybe you are helping them too much, Tony

I tend to agree.

> LOL! Rare for me<G>. Couldn't resist as I only got started by
> copying from other entries here.

So keep working on it, and post your programs after the deadliine.

>>They are supposed to find the NDUPN and
>>other tricks all by themselves
>
>
> But NDUPN is not documented in any paper manuals I peruse.

That's strange; it's documented in the paper manual that I have
open to the page for NDUPN. But this paper manual I printed out
myself from a PDF file, easily found on the Internet. Note that
the 49g+ is much like the 49G, so most information for the 49G
still applies to the 49g+.

But the documentation that I have for NDUPN is disgraceful. It
doesn't work the way that the description says, and the stack
diagram doesn't even make sense. Experiment with this one a bit
rather than relying on the documentation.

> It was such a surprise it did just what I wanted. Sort of
> equivalent to DUP DEPTH ROLL DUPN DEPTH ROLL

No. Maybe you should look a little closer at DUPN, for a start.

>  - no wonder it
> gave me 11 bytes. It's such a big trick it's more like a
> truck!
>
> If there are other trucks I'm looking forward to seeing them
> after the 12th :-)
>
>
>>AND
>>you can still shave off some nibbles from your program, Tony
>
> LOL! I can but will it work?<G>. I can't see nibbles, just 2.5
> byte chunks <G>.
>
>>(which is the best [par none] I can think of myself)
>
> Thanks VPN - you're welcome to polish it off. Still 5 days to
> go as well, so there is hope for something better - shake your
> sleeve ;-)

-- 
Regards,
James

          -=[ Wed, 8.12.04 11:37 p.m. +1300 (NZDT) ]=-

Hi James M. Prange ! <jmprange@i-is.com>

20m ago, on Wed, 8.12.04 at 05:16 a.m. -0500, you wrote
in message ID <hxAtd.12645$QJ2.11338@fe39.usenetserver.com> :

> >>>I hope this causes much shrinkage in entries :-)
> >>
> >>Maybe you are helping them too much, Tony
> 
> I tend to agree.

Eleven bytes is probably too much :-)
Aplogies, I'm not really familiar with the etiquette of
mini-challenges, and the magnitude of helping.

> > LOL! Rare for me<G>. Couldn't resist as I only got started by
> > copying from other entries here.
> 
> So keep working on it, and post your programs after the deadliine.

Mine are finished. I have nothing competitive for the 48G,
only the 49g+, 49G and 48SX.

Those 11 bytes take the cake really. I'm pretty much down to
minimum size now - i.e. what it would take if DOLIST etc
worked as expected. 

> >>They are supposed to find the NDUPN and
> >>other tricks all by themselves
> >
> >
> > But NDUPN is not documented in any paper manuals I peruse.
> 
> That's strange; it's documented in the paper manual that I have
> open to the page for NDUPN. But this paper manual I printed out
> myself from a PDF file, easily found on the Internet. Note that
> the 49g+ is much like the 49G, so most information for the 49G
> still applies to the 49g+.

I have the paper 49G Advanced User's Guide. That lists 3
"Other Commands" (A-F, G-P, Q-Z) apparently "available from the
web site". I never found them. Ahha, www.hpcalc.org I guess -
must have a look.
 
> But the documentation that I have for NDUPN is disgraceful. It
> doesn't work the way that the description says, and the stack
> diagram doesn't even make sense. Experiment with this one a bit
> rather than relying on the documentation.

Just what I did ;-) Hehe I just tested that it did what I
wanted for 2 arguments only. This was after trying to coerce a
variable UNPICK to work. Just trial and error. 

> > It was such a surprise it did just what I wanted. Sort of
> > equivalent to DUP DEPTH ROLL DUPN DEPTH ROLL
> 
> No. Maybe you should look a little closer at DUPN, for a start.

Oh, not one but TWO lacunae - a missing D and a missing DROP:
After all I wrote "sort of equivalent ..." :-)
One way to replicate NDUPN is:
DUP DEPTH ROLLD DUPN DROP DEPTH ROLL.
              ^      ^^^^
or
<<->d << DUPN DROP d >> >>

LOL! There is probably a bug in NDUPN as well, but I hope they
don't fix it. That implied DROP is pretty unexpected as we
only get (n-1) copies, as it it were...

DUP DEPTH ROLLD 1 - DUPN DROP DEPTH ROLL
Except that this is not how it works because -1 DUPN doesn't
do a DROP.

Still, I like NDUPN as it is, especially the way it returns
the argument.
-- 
Tony

"Tony Hutchins" <justth@csi.com> wrote in message 
news:10018271ROBOTLX@news.individual.net...
X
>> >>>I hope this causes much shrinkage in entries :-)
>> >>
>> >>Maybe you are helping them too much, Tony
>>
>> I tend to agree.
>
> Eleven bytes is probably too much :-)
> Aplogies, I'm not really familiar with the etiquette of
> mini-challenges, and the magnitude of helping.
>
>> > LOL! Rare for me<G>. Couldn't resist as I only got started by
>> > copying from other entries here.
>>
>> So keep working on it, and post your programs after the deadliine.
>
> Mine are finished. I have nothing competitive for the 48G,
> only the 49g+, 49G and 48SX.
>
> Those 11 bytes take the cake really. I'm pretty much down to
> minimum size now - i.e. what it would take if DOLIST etc
> worked as expected.
X
Tony, you may present your byte count here
AND
my optimized code if very very similar to yours
(have not seen your new code, no need to :)
BUT
you can still shave off some nibbles
look carefully at _all_ of your code
[VPN]
PS: Werner - can you go below 61 bytes?

          -=[ Thu, 9.12.04 00:40 a.m. +1300 (NZDT) ]=-

Hi Tony Hutchins ! <justth@csi.com>

23m ago, on Thu, 9.12.04 at 00:16 a.m. +1300 (NZDT), you wrote
in message ID <10018271ROBOTLX@news.individual.net> :

> Oh, not one but TWO lacunae - a missing D and a missing DROP:
> After all I wrote "sort of equivalent ..." :-)
> One way to replicate NDUPN is:
> DUP DEPTH ROLLD DUPN DROP DEPTH ROLL.
>               ^      ^^^^
> or
> <<->d << DUPN DROP d >> >>

oops
  <<->d << d DUPN DROP d >> >>

James I found the pdfs - already had them from hpcalc,
secreted away on a CD produced in panic once when I ran out of
room on the laptop! I see what you mean about the NDUPN
documentation. Quite nice pdfs though. Good overall index! Not
often I see pdfs that are almost designed for screen reading.

This has been a lot of fun. Thanks for your patience.
I've really got used to the 49g+ and also the old 49G.
But I admit I still use a 41C for the monthly tax ritual :-)
-- 
Tony

well I took a  few minutes and rewrote it in sysrpl and it drops to 57.5
bytes for all models. But i can't submit that one.
"James M. Prange" <jmprange@i-is.com> wrote in message
news:ySwtd.12636$QJ2.9237@fe39.usenetserver.com...
> Lee wrote:
>
> > Ok, here's one more. 99.5 bytes #6062h on a 49G+ Should work on all
models.
>
> And indeed it does.
>
> %%HP: T(3)A(D)F(.);
> @ 48S Checksum: # 57B8h
> @ 48S Size:        99.5
> @ 48G Checksum: # 57B8h
> @ 48G Size:        99.5
> @ 49  Checksum: # 6062h
> @ 49  Size:        99.5
>
> > \<< \-> b
> >   \<< DUP SIZE { OBJ\-> { } 1. ROT
> >     FOR C SWAP DUP TYPE b SAME :: DROP { 1. \->LIST SWAP + } IFTE
> >     NEXT } IFT
> >   \>>
> > \>>
> >  Last one I promise.
>
> Last one? But the deadline is still a few days away! And I've been
> hoping to see a few more of these that work on the 48SX/S.
>
> -- 
> Regards,
> James
>

It won"t work on the 48S series
"Tony Hutchins" <justth@csi.com> wrote in message
news:11014150ROBOTLX@news.individual.net...
>           -=[ Wed, 8.12.04 3:08 p.m. +1300 (NZDT) ]=-
>
> Hi Lee ! <RDELM@PACBELL.NET>
>
> 02h34m ago, on Tue, 7.12.04 at 11:34 p.m. +0000 (GMT), you wrote
> in message ID <96rtd.55821$QJ3.745@newssvr21.news.prodigy.com> :
>
> > Ok, here's one more. 99.5 bytes #6062h on a 49G+ Should work on all
models.
> >
> > \<< \-> b
> >   \<< DUP SIZE { OBJ\-> { } 1. ROT
> >     FOR C SWAP DUP TYPE b SAME :: DROP { 1. \->LIST SWAP + } IFTE
> >     NEXT } IFT
> >   \>>
> > \>>
> >  Last one I promise.
>
> No, no, keep 'em coming.
>
> I just worked how NDUPN works here - it's not on the 48G but
> on the 49G and 49g+
> You could replace:
>
> SAME :: DROP { 1. \->LIST SWAP + } IFTE
>
> with:
>
> \=/ NDUPN \->LIST SWAP +
>
> Just after I worked this out I got a low battery warning
> but kept working, till I lost everything - too much
> enthusiam<G>.
>
> NDPUN just made my version here shrink by 11 bytes!!!
>
> I think NDUPN is just like DUPN except it also returns the
> "n". And 0 DUPN does a DROP.
> So, calling the element e we have
> e 1 NDUPN -> e 1. ready for the ->LIST
> e 0 NDUPN -> 0.   also ready as it produces {} which can be
> safely added to no effect <G>
>
> I hope this causes much shrinkage in entries :-)
>
> -- 
> Tony Hutchins
> New Zealand
>

          -=[ Thu, 9.12.04 07:01 a.m. +1300 (NZDT) ]=-

Hi Lee ! <RDELM@PACBELL.NET>

02h05m ago, on Wed, 8.12.04 at 3:55 p.m. +0000 (GMT), you wrote
in message ID <XtFtd.30525$zx1.24905@newssvr13.news.prodigy.com> :

> It won"t work on the 48S series

Correct. Or the 48G.

> "Tony Hutchins" <justth@csi.com> wrote in message
> news:11014150ROBOTLX@news.individual.net...
> >           -=[ Wed, 8.12.04 3:08 p.m. +1300 (NZDT) ]=-
[...]
> > I just worked how NDUPN works here - it's not on the 48G but
> > on the 49G and 49g+
> > You could replace:
> >
> > SAME :: DROP { 1. \->LIST SWAP + } IFTE
> >
> > with:
> >
> > \=/ NDUPN \->LIST SWAP +
> >
[...]
> > NDPUN just made my version here shrink by 11 bytes!!!
> >
> > I think NDUPN is just like DUPN except it also returns the
> > "n". And 0 DUPN does a DROP.

Ahha NDUPN itself does that drop, not 0 DUPN.

> > So, calling the element e we have
> > e 1 NDUPN -> e 1. ready for the ->LIST
> > e 0 NDUPN -> 0.   also ready as it produces {} which can be
> > safely added to no effect <G>

At least I got that right<G>

-- 
Tony Hutchins
Wellington
New Zealand

#100 The important thing is not to stop
questioning. Albert Einstein

          -=[ Thu, 9.12.04 07:06 a.m. +1300 (NZDT) ]=-

Hi Veli-Pekka Nousiainen ! <DROP_vpn@THIS.welho.com>

06h39m ago, on Wed, 8.12.04 at 1:26 p.m. +0200, you wrote
in message ID <cp6ob8$6fm$1@nyytiset.pp.htv.fi> :
[...]
> X
> Tony, you may present your byte count here
> AND
> my optimized code if very very similar to yours
> (have not seen your new code, no need to :)

It is as in my last e-mail where I mentioned NDUPN.

I haven't seen any code from you so cannot really present
it :-). I hope you present it though! 

> BUT
> you can still shave off some nibbles
> look carefully at _all_ of your code

I did yesterday. Than I blinked and lost it<G>.
Can't see a thing to change. NDUPN was like an Eiffel Tower,
just took my breath away. 

> [VPN]
> PS: Werner - can you go below 61 bytes?

My guess is that would only be possible if DOLIST actually
worked<G>. Then this 59.5 byter would do.
<< TYPE ->T << 1 <<DUP TYPE T == DROPN>> DOLIST >> >>
Except I suspect you could shave some nibbles still :-)

Can you give another clue VPN? Except I probably break all
protocol again merely by asking. If so, there is simply no
need to answer. No problem. 

- could you shave the above one as well as
  mine or is it something really peculiar to my code?

I'm very interested to find it if this is the case - i.e. if
some actual commands can be changed.

- is it something I would be expected to know from reading a
  manual? 

If so I'll scour the 48G manuals again looking a programs for
a sign :-)

- does it involve using special characters? It took me a while
  to just figure out that IFTE structure for example, with
  those tag/list delimiters. So, I always look for ways to
  avoid branching overhead :-)

-- 
Tony Hutchins
Wellington
New Zealand

#62 After two weeks of dieting, all I lost was two weeks.

          -=[ Thu, 9.12.04 08:06 a.m. +1300 (NZDT) ]=-

Hi Tony Hutchins ! <justth@csi.com>

19m ago, on Thu, 9.12.04 at 07:46 a.m. +1300 (NZDT), you wrote
in message ID <10509863ROBOTLX@news.individual.net> :

[...] 
> > [VPN]
> > PS: Werner - can you go below 61 bytes?
> 
> My guess is that would only be possible if DOLIST actually
> worked<G>. Then this 59.5 byter would do.
> << TYPE ->T << 1 <<DUP TYPE T == DROPN>> DOLIST >> >>
> Except I suspect you could shave some nibbles still :-)

Actually on the 49G and g+ that could be shrunk to 58 bytes, if
only DOLIST worked :-) But, on the 48G I think the Endless'
classic solution using the local variable reigns supreme -
there trying to use the stack instead adds 1 byte as Endless
showed. On the 49G it is NDUPN that makes all the difference,
aNDVPN can shave anything, of course :-)

-- 
Tony Hutchins
Wellington
New Zealand

#259 To forget one's purpose is the commonest form
of stupidity. Friedrich Nietzsche

          -=[ Thu, 9.12.04 08:21 a.m. +1300 (NZDT) ]=-

Hi Veli-Pekka Nousiainen ! <DROP_vpn@THIS.welho.com>

07h54m ago, on Wed, 8.12.04 at 1:26 p.m. +0200, you wrote
in message ID <cp6ob8$6fm$1@nyytiset.pp.htv.fi> :

> > Mine are finished. I have nothing competitive for the 48G,
> > only the 49g+, 49G and 48SX.
> >
> > Those 11 bytes take the cake really. I'm pretty much down to
> > minimum size now - i.e. what it would take if DOLIST etc
> > worked as expected.
> X
> Tony, you may present your byte count here
Me again.
Sorry, forgot. 
49g+ : 74 - 11 = 63 (using DOLIST)
+7 bytes ->
49G  : 70.5 (using STREAM, and needs example of TYPE as input)
+7 bytes ->
48G  : nothing beats Endless's 77.5
+13.5 bytes ->
48SX : 91 (basically copied from others here but using STACK
          only)
I am at least under the illusion that they all work. The only
really interesting feature is how NDUPN helps in the 49g+ and
49G!! The 49G is different because it doesn't have the new
DOLIST bug on the 49g+.

-- 
Tony Hutchins

"Tony Hutchins" <justth@csi.com> wrote in message 
news:10509863ROBOTLX@news.individual.net...
X
> I haven't seen any code from you so cannot really present
> it :-). I hope you present it though!
>
>> BUT
>> you can still shave off some nibbles
>> look carefully at _all_ of your code
X
Look outside of NDUPN and DOLIST
Maybe we should talk through e-mail
OR
only after 12.12.
[VPN]

Tony Hutchins wrote:
>           -=[ Wed, 8.12.04 11:37 p.m. +1300 (NZDT) ]=-
>
> Hi James M. Prange ! <jmprange@i-is.com>
>
> 20m ago, on Wed, 8.12.04 at 05:16 a.m. -0500, you wrote
> in message ID <hxAtd.12645$QJ2.11338@fe39.usenetserver.com> :
>
>
>>>>>I hope this causes much shrinkage in entries :-)
>>>>
>>>>Maybe you are helping them too much, Tony
>>
>>I tend to agree.
>
>
> Eleven bytes is probably too much :-)
> Aplogies, I'm not really familiar with the etiquette of
> mini-challenges, and the magnitude of helping.

I think that in most mini-challenges, helping would be
unrestricted; after all, most are open to anyone, so whoever cares
to help could post his own entry if he chose to. But this
particular mini-challenge is restricted to those who have never
participated before, and they're expected to find useful methods
wherever they can, short of asking for help. I'm uncomfortable
with offering help, first because I hope that everyone looks for
useful methods and commands himself, and also because it might
help some participants more than others. Of course, I can't stop
anyone from posting whatever he chooses to, but let's be careful
about posting helpful hints.

Sometimes, where hints have been posted, I've attempted to clarify
or expand on them a bit, so that they'll be helpful to everyone
who can make use of them.

>>>LOL! Rare for me<G>. Couldn't resist as I only got started by
>>>copying from other entries here.
>>
>>So keep working on it, and post your programs after the deadliine.
>
>
> Mine are finished. I have nothing competitive for the 48G,
> only the 49g+, 49G and 48SX.
>
> Those 11 bytes take the cake really. I'm pretty much down to
> minimum size now - i.e. what it would take if DOLIST etc
> worked as expected.
>
>
>>>>They are supposed to find the NDUPN and
>>>>other tricks all by themselves
>>>
>>>
>>>But NDUPN is not documented in any paper manuals I peruse.
>>
>>That's strange; it's documented in the paper manual that I have
>>open to the page for NDUPN. But this paper manual I printed out
>>myself from a PDF file, easily found on the Internet. Note that
>>the 49g+ is much like the 49G, so most information for the 49G
>>still applies to the 49g+.
>
>
> I have the paper 49G Advanced User's Guide. That lists 3
> "Other Commands" (A-F, G-P, Q-Z) apparently "available from the
> web site". I never found them. Ahha, www.hpcalc.org I guess -
> must have a look.

They used to be on HP's Web site, but as far as I can tell, the
Advanced User's Guide and Ver C Rev 1.18 ROM were removed
somewhere along the way, which doesn't make sense, as the User's
Guide and HPComm are still available there, even though the 49G
has been discontinued. I'm very thankful that the Advanced User's
Guide is still available at hpcalc.org.

Personally, I think that HP ought to make all documentation,
including for discontinued products, available on its Web site.
For older models, scanned-in PDF files would be acceptable.
Failing that, I'd like to see them give a general permission to
publish unaltered copies of all documentation.

Third-party "corrected" or annotated copies of documentation would
be a bit more complicated. We can't expect anyone to take
responsibility for anything that he didn't publish himself, and of
course the same applies to anything published by a company.

But I don't see anything wrong with anyone publishing extra notes
or an errata of documentation as separate files.

I'd also like them to make all documentation for current products
available in printed form. For things that not everyone would care
to spend extra money on, they could use a "publish on demand"
company; that would relieve them of the trouble of stocking the
printed copies of "Advanced" documentation, and the risk of being
stuck with unsold copies.

The last time that I looked, the usual publish on demand copyright
policy was that the author retained all rights to the material, so
HP could still keep the PDF files on a CD and its Web site.

Of course we can print out copies of the "e-published"
documentation for ourselves, but the result isn't so nice as a
professionally printed and bound copy. Printing or publishing
companies may well refuse to make copies of the documentation to
avoid running afoul of HP's intellectual property rights.

I don't find it very expensive to print out documentation because
I do it with my good old 24-pin impact dot-matrix printers using
re-inked ribbons, but it is time-consuming and a bit noisy. Of
course, the result is black-on-white; no colour, but I find that
to be acceptable for documentation. I could use my Bubble-Jet
printer to print in colour, but I'm not very impressed with the
print quality from any of the liquid-ink "jet" type printers that
I've seen; even 180 X 180 DPI from the impact printers seems
better to me. I could use 360 X 360 DPI, but the improvement seems
slight and it takes four times as long. I usually use tractor-fed
fanfold paper, so the edges are a bit fuzzy, but I could use the
cut-sheet feeders if I chose to.

>>But the documentation that I have for NDUPN is disgraceful. It
>>doesn't work the way that the description says, and the stack
>>diagram doesn't even make sense. Experiment with this one a bit
>>rather than relying on the documentation.
>
>
> Just what I did ;-) Hehe I just tested that it did what I
> wanted for 2 arguments only. This was after trying to coerce a
> variable UNPICK to work. Just trial and error.

I think that UNPICK works exactly as documented. It's very useful,
and *fast*, without using a lot of memory. Whether it's useful for
the goal of this mini-challenge, I don't know.

Just about all documentation, even HP's "official" documentation
for the 48 series, Jim Donnelly's books, and Bill Wickes's books,
has errors. I suppose that expecting documentation for anything as
complicated as these calculators to be entirely error-free would
be much like expecting the product itself to be entirely bug-free.

Use the documentation as a starting point, but experiment to be
certain of how the calculators *really* work.

Of course, the same goes for anything you read on the Internet,
including this newsgroup.

>>>It was such a surprise it did just what I wanted. Sort of
>>>equivalent to DUP DEPTH ROLL DUPN DEPTH ROLL
>>
>>No. Maybe you should look a little closer at DUPN, for a start.
>
>
> Oh, not one but TWO lacunae - a missing D and a missing DROP:
> After all I wrote "sort of equivalent ..." :-)
> One way to replicate NDUPN is:
> DUP DEPTH ROLLD DUPN DROP DEPTH ROLL.
>               ^      ^^^^
> or
> <<->d << DUPN DROP d >> >>

Well, the thing is, I guess that your thinking is that DUPN
removes n and then does DUP n times. It doesn't; rather, it
removes n and then duplicates n levels only one time. DUPN is more
like a generalized version of DUP2 than a generalized version of
DUPDUP.

For what it's worth, my description of NDUPN would be:

With any object on level 2 and n on level 1, returns the level 2
object n times and then n as a real number. Note that if n<1, then
NDUPN returns 0. only.

Here, n would be understood to be an integer value, or be rounded
to an integer value.

My attempt at a stack diagram:

Level 2  Level 1  ->  Level 2...Level n+1   Level 1
  obj     n|n>0   ->    obj  ...   obj      real  n
  obj     n|n<1   ->                          0.

A UserRPL program that returns the same results as NDUPN on all 48
and 49 series (I hope):

%%HP: T(3)A(D)F(.);
@ 48 series checksum: # 3341h
@ 49 series checksum: # E39Eh
@ Size:                    80
@ Arguments:
@   Lvevl 2: Any object, obj
@   Level 1: Any real or zint, n
@ Returns:
@   For n>0: Level 2...Level n+1: obj
@   Level 1: real number n
\<<
  DUP 0.
  IF
    <
  THEN
    DROP 0.
  END
  0. RND
  DUP DEPTH ROLLD
  WHILE
    DUP
  REPEAT
    OVER
    SWAP 1. -
  END
  DR0P2
  DEPTH ROLL
\>>

> LOL! There is probably a bug in NDUPN as well, but I hope they
> don't fix it. That implied DROP is pretty unexpected as we
> only get (n-1) copies, as it it were...

I don't know. Maybe it's a bug in NDUPN, or maybe NDUPN works as
intended, but the guide is buggy instead. The description in the
guide uses "Duplicates"; if that were true, then the program above
with DROP2 changed to DROP would be the expected behaviour. The
stack diagram in the documentation doesn't make any sense when n
is 0 or less. I rather prefer the way that it actually works to
the description in the documentation.

> DUP DEPTH ROLLD 1 - DUPN DROP DEPTH ROLL
> Except that this is not how it works because -1 DUPN doesn't
> do a DROP.
>
> Still, I like NDUPN as it is, especially the way it returns
> the argument.

It rather goes against the general rule that if you want to have a
copy of an argument, then you have to arrange for that yourself,
but it's okay; if you don't want the count, then just DROP it.

--
Regards,
James

"James M. Prange" <jmprange@i-is.com> wrote in message 
news:9lXtd.185$bu1.45@fe61.usenetserver.com...
X
> particular mini-challenge is restricted to those who have never
> participated before, and they're expected to find useful methods
> wherever they can, short of asking for help.
X
That's right: don't ask help from another human,
but use web and any possible resource (HP or not).
X
> NDUPN works as
> intended, but the guide is buggy instead.

That's what I think: the guide has not been debugged carefully enough
by the Manual Betatesters Group. Shame on them!  :-(
[VPN]

          -=[ Fri, 10.12.04 07:56 a.m. +1300 (NZDT) ]=-

Hi James M. Prange ! <jmprange@i-is.com>

06h42m ago, on Thu, 9.12.04 at 07:14 a.m. -0500, you wrote
in message ID <9lXtd.185$bu1.45@fe61.usenetserver.com> :
[...]
> Just about all documentation, even HP's "official"
> documentation for the 48 series, Jim Donnelly's books,
> and Bill Wickes's books, has errors. I suppose that
> expecting documentation for anything as complicated as
> these calculators to be entirely error-free would be much
> like expecting the product itself to be entirely bug-free.

:-)

> >>>It was such a surprise it did just what I wanted. Sort of
> >>>equivalent to DUP DEPTH ROLL DUPN DEPTH ROLL
> >>
> >>No. Maybe you should look a little closer at DUPN, for a start.
> >
> >
> > Oh, not one but TWO lacunae - a missing D and a missing DROP:
> > After all I wrote "sort of equivalent ..." :-)
> > One way to replicate NDUPN is:
> > DUP DEPTH ROLLD DUPN DROP DEPTH ROLL.
> >               ^      ^^^^
> > or
> > <<->d << DUPN DROP d >> >>
> 
> Well, the thing is, I guess that your thinking is that DUPN
> removes n and then does DUP n times. It doesn't; rather, it
> removes n and then duplicates n levels only one time. DUPN
> is more like a generalized version of DUP2 than a generalized
> version of DUPDUP.

What I needed was the *nonexistent* command NDUP which would
be a generalization of DUP, DUPDUP, DUP DUPDUP, DUPDUP
DUPDUP,... Then I could amend what my dog wrote above<G>:

DUP DEPTH ROLLD NDUP DROP DEPTH ROLL.
or
<<->d << d NDUP DROP d >> >>

where 1 NDUP = DUP, etc. 0 NDUP does nothing.

NDUP might be
<<->d << IF d 0 > THEN 1 d START DUP NEXT END >> >>

> For what it's worth, my description of NDUPN would be:
> 
> With any object on level 2 and n on level 1, returns the level 2
> object n times and then n as a real number. Note that if n<1, then
> NDUPN returns 0. only.
> 
> Here, n would be understood to be an integer value, or be rounded
> to an integer value.
> 
> My attempt at a stack diagram:
> 
> Level 2  Level 1  ->  Level 2...Level n+1   Level 1
>   obj     n|n>0   ->    obj  ...   obj      real  n
>   obj     n|n<1   ->                          0.

Looks PERFECT to me. Yup 2 levels -->  n+1 levels, even for
n=0 <g>.
 
> A UserRPL program that returns the same results as NDUPN on all 48
> and 49 series (I hope):
> 
> %%HP: T(3)A(D)F(.);
> @ 48 series checksum: # 3341h
> @ 49 series checksum: # E39Eh
> @ Size:                    80

I typed it in a 49g+ and got the same SIZE but #8D26h for the
checksum. It works though :-)

> @ Arguments:
> @   Lvevl 2: Any object, obj
> @   Level 1: Any real or zint, n
> @ Returns:
> @   For n>0: Level 2...Level n+1: obj
> @   Level 1: real number n
> \<<
>   DUP 0.
>   IF
>     <
>   THEN
>     DROP 0.
>   END

Excellent purifying of negative input :-)

>   0. RND

>   DUP DEPTH ROLLD

-------
Ahha already I see here a better coding of the non-existent
NDUP!! You use the OVER to do the DUP - I'd never thought of
that one!


>   WHILE
>     DUP
>   REPEAT
>     OVER
>     SWAP 1. -
>   END
>   DR0P2
---------------

>   DEPTH ROLL
> \>>
> 
> > LOL! There is probably a bug in NDUPN as well, but I hope they
> > don't fix it. That implied DROP is pretty unexpected as we
> > only get (n-1) copies, as it it were...

Maybe if I think of the stack depth. One DUP makes it 1 level
deeper. My NDUP would make it N levels deeper. So does NDUPN.
It's just a question of what is in the new levels :-)
 
> I don't know. Maybe it's a bug in NDUPN, or maybe NDUPN
> works as intended, but the guide is buggy instead. The
> description in the guide uses "Duplicates"; if that were
> true, then the program above with DROP2 changed to DROP
> would be the expected behaviour.

Exactly!

> The stack diagram in the documentation doesn't make any
> sense when n is 0 or less. I rather prefer the way that it
> actually works to the description in the documentation.

Me too. Thanks James.
-- 
Tony

 bytes I have one thats 95 bytes and should work on the 48 SX. Only thing is
it errors out on an empty list to begin with. But I'll post it anyway.

\<< \-> a b
  \<< { } 1. a SIZE
    FOR C a C GET DUP TYPE b SAME :: DROP { 1. \->LIST + } IFTE
    NEXT
  \>>
\>>

Should work just fine on the SX.
"James M. Prange" <jmprange@i-is.com> wrote in message
news:ySwtd.12636$QJ2.9237@fe39.usenetserver.com...
> Lee wrote:
>
> > Ok, here's one more. 99.5 bytes #6062h on a 49G+ Should work on all
models.
>
> And indeed it does.
>
> %%HP: T(3)A(D)F(.);
> @ 48S Checksum: # 57B8h
> @ 48S Size:        99.5
> @ 48G Checksum: # 57B8h
> @ 48G Size:        99.5
> @ 49  Checksum: # 6062h
> @ 49  Size:        99.5
>
> > \<< \-> b
> >   \<< DUP SIZE { OBJ\-> { } 1. ROT
> >     FOR C SWAP DUP TYPE b SAME :: DROP { 1. \->LIST SWAP + } IFTE
> >     NEXT } IFT
> >   \>>
> > \>>
> >  Last one I promise.
>
> Last one? But the deadline is still a few days away! And I've been
> hoping to see a few more of these that work on the 48SX/S.
>
> -- 
> Regards,
> James
>

This was posted as an assumption that you would not want to take anything
out of an empty list.
"Lee" <RDELM@PACBELL.NET> wrote in message
news:Ul2ud.31231$zx1.21064@newssvr13.news.prodigy.com...
> bytes I have one thats 95 bytes and should work on the 48 SX. Only thing
is
> it errors out on an empty list to begin with. But I'll post it anyway.
>
> \<< \-> a b
>   \<< { } 1. a SIZE
>     FOR C a C GET DUP TYPE b SAME :: DROP { 1. \->LIST + } IFTE
>     NEXT
>   \>>
> \>>
>
> Should work just fine on the SX.
> "James M. Prange" <jmprange@i-is.com> wrote in message
> news:ySwtd.12636$QJ2.9237@fe39.usenetserver.com...
> > Lee wrote:
> >
> > > Ok, here's one more. 99.5 bytes #6062h on a 49G+ Should work on all
> models.
> >
> > And indeed it does.
> >
> > %%HP: T(3)A(D)F(.);
> > @ 48S Checksum: # 57B8h
> > @ 48S Size:        99.5
> > @ 48G Checksum: # 57B8h
> > @ 48G Size:        99.5
> > @ 49  Checksum: # 6062h
> > @ 49  Size:        99.5
> >
> > > \<< \-> b
> > >   \<< DUP SIZE { OBJ\-> { } 1. ROT
> > >     FOR C SWAP DUP TYPE b SAME :: DROP { 1. \->LIST SWAP + } IFTE
> > >     NEXT } IFT
> > >   \>>
> > > \>>
> > >  Last one I promise.
> >
> > Last one? But the deadline is still a few days away! And I've been
> > hoping to see a few more of these that work on the 48SX/S.
> >
> > -- 
> > Regards,
> > James
> >
>
>

          -=[ Fri, 10.12.04 09:11 a.m. +1300 (NZDT) ]=-

Hi James M. Prange ! <jmprange@i-is.com>

07h57m ago, on Thu, 9.12.04 at 07:14 a.m. -0500, you wrote
in message ID <9lXtd.185$bu1.45@fe61.usenetserver.com> :
[...]
> For what it's worth, my description of NDUPN would be:
> 
> With any object on level 2 and n on level 1, returns the level 2
> object n times and then n as a real number. Note that if n<1, then
> NDUPN returns 0. only.

The documentation says:

"Duplicates an object n times, and returns n."

Maybe this would do?:

"Duplicates an object n-1 times, and returns n."

or

"Duplicates an object n times, and overwites it with n."

Yes, that at least covers the n=0 case better, in words.

> My attempt at a stack diagram:
> 
> Level 2  Level 1  ->  Level 2...Level n+1   Level 1
>   obj     n|n>0   ->    obj  ...   obj      real  n

Comparing that with the documentation it is basically the same
apart from the level 1 descriptions?

One could also say it is correct for n=0?

> > Still, I like NDUPN as it is, especially the way it returns
> > the argument.
> 
> It rather goes against the general rule that if you want
> to have a copy of an argument, then you have to arrange for
> that yourself, but it's okay; if you don't want the count,
> then just DROP it.

Exactly, so we do have a new command "NDUP" which generalises
DUPDUP = 2 NDUP: 

NDUP
<<NDUPN DROP DUP>> :-)

HP gave us NDUPN instead of NDUP.

Ah, yes we can subsitiute this in here

simulated NDUPN with hypothetical NDUP
<<->d << d NDUP DROP d >> >>

->
<<->d << d NDUPN DROP DUP DROP d >> >>

but DUP DROP does nothing so
->
<<->d << d NDUPN DROP d >> >>
Yes, we have proved NDUPN=NDUPN :-)

-- 
Tony

          -=[ Fri, 10.12.04 09:48 a.m. +1300 (NZDT) ]=-

Hi Tony Hutchins ! <teehaitch@csi.com>

07m ago, on Fri, 10.12.04 at 09:40 a.m. +1300 (NZDT), you wrote
in message ID <10634558ROBOTLX@news.clear.net.nz> :

> HP gave us NDUPN instead of NDUP.
> 
> Ah, yes we can subsitiute this in here

oops that should be tit instead of iti. This extended
transposition (DROP SWAP OVER instead of the usual SWAP <G>)
must be a sure sign of an old-timer.

-- 
Tony

          -=[ Fri, 10.12.04 10:23 a.m. +1300 (NZDT) ]=-

Hi Veli-Pekka Nousiainen ! <DROP_vpn@THIS.welho.com>

04h14m ago, on Thu, 9.12.04 at 7:08 p.m. +0200, you wrote
in message ID <cpa0nl$frs$1@nyytiset.pp.htv.fi> :

> "James M. Prange" <jmprange@i-is.com> wrote in message 
> news:9lXtd.185$bu1.45@fe61.usenetserver.com...
> X
> > particular mini-challenge is restricted to those who have never
> > participated before, and they're expected to find useful methods
> > wherever they can, short of asking for help.
> X
> That's right: don't ask help from another human,
> but use web and any possible resource (HP or not).
> X

But isn't it much more fun for anyone to be allowed to share and
help as much as they wish? Even if the help turns out to be
wrong or misleading? After all no human really knows what the
best answer is going to be. The more help, even if it leads to
unrully noise, the better the final solution might be? 
It's just as competitive, or *more* so if good help is offered.
Folk could still keep something up their sleeves<G>.

Then again, I could be wrong :-)

> > NDUPN works as
> > intended, but the guide is buggy instead.
> 
> That's what I think: the guide has not been debugged
> carefully enough by the Manual Betatesters Group. Shame
> on them!  :-(
> [VPN]

It's a lot better than nothing though, and the layout is
excellent for computer screen reading. Best I have seen! 
Perfect for a competition like this as the index of commands
is very compact and usable - and it's cool how the index .PDF
connects with the other .PDF files. First time I have seen
that. I refer to the 49G AUG with files dated way back on 24
Jan 2000.  

-- 
Tony Hutchins
Wellington
New Zealand

#298 I like long walks, especially when they are
taken by people who annoy me. Fred Allen

In article <cpa0nl$frs$1@nyytiset.pp.htv.fi>,
 "Veli-Pekka Nousiainen" <DROP_vpn@THIS.welho.com> wrote:

> "James M. Prange" <jmprange@i-is.com> wrote in message 
> news:9lXtd.185$bu1.45@fe61.usenetserver.com...
> X
> > particular mini-challenge is restricted to those who have never
> > participated before, and they're expected to find useful methods
> > wherever they can, short of asking for help.
> X
> That's right: don't ask help from another human,
> but use web and any possible resource (HP or not).
> X
> > NDUPN works as
> > intended, but the guide is buggy instead.
> 
> That's what I think: the guide has not been debugged carefully enough
> by the Manual Betatesters Group. Shame on them!  :-(
> [VPN]

I found  what may be a bug in the 49+, which allows a program cocompiled 
in real mode to operate correctly but may crash the same program when 
compiled in exact mode:

\<<  0 'X' IFT \>>  
\<<  1 'X' IFT \>>
\<<  0 'X'  'Y'IFTE \>>
\<<  1 'X' 'Y' IFTE \>>

All crash if complied in exact mode, since apparently the IFT and IFTE 
commands will not accept integers as their Boolean arguemnts.

One can cure this, regardless of compilation mode, by inserting the 
I\->R command after the 0 or 1, but if one is trying for the shortest 
possible program, just compile it in approximate mode.

Tony Hutchins wrote:

<snip>

> What I needed was the *nonexistent* command NDUP which would
> be a generalization of DUP, DUPDUP, DUP DUPDUP, DUPDUP
> DUPDUP,... Then I could amend what my dog wrote above<G>:
>
> DUP DEPTH ROLLD NDUP DROP DEPTH ROLL.
> or
> <<->d << d NDUP DROP d >> >>
>
> where 1 NDUP = DUP, etc. 0 NDUP does nothing.
>
> NDUP might be
> <<->d << IF d 0 > THEN 1 d START DUP NEXT END >> >>

But wouldn't that do DUP at least once, even if n were 0? And what
if n were a non-integer value? Or n were a negative value? I
expect that it needs a little refinement.

Perhaps larger but faster for NDUP:

%%HP: T(3)A(D)F(.);
@ 48 series checksum: # DE3Bh
@ 49 series checksum: # 907Eh
@ Size:                  62.5
@ Arguments:
@   Level 2: Any object, obj
@   Level 1: Any real or zint, n
@ Returns:
@   Level 1...Level n+1: obj
\<<
  DUP 0
  IF
    <
  THEN
    DROP 0
  END
  WHILE
    DUP
  REPEAT
    OVER
    SWAP 1 -
  END
  DROP
\>>

Or a variation that *returns* rather than *duplicates* level 2 n
times; maybe call it NDUPDROP:

%%HP: T(3)A(D)F(.);
@ 48 series checksum: # CFEAh
@ 49 series checksum: # 3DD8h
@ Size:                  62.5
@ Arguments:
@   Level 2: Any object, obj
@   Level 1: Any real or zint, n
@ Returns:
@   Level 0...Level n: obj
\<<
  DUP 0
  IF
    <
  THEN
    DROP 0
  END
  WHILE
    DUP
  REPEAT
    OVER
    SWAP 1 -
  END
  DROP2
\>>

Level 0 or less should be considered the "bit bucket".

>>For what it's worth, my description of NDUPN would be:
>>
>>With any object on level 2 and n on level 1, returns the level 2
>>object n times and then n as a real number. Note that if n<1, then
>>NDUPN returns 0. only.
>>
>>Here, n would be understood to be an integer value, or be rounded
>>to an integer value.
>>
>>My attempt at a stack diagram:
>>
>>Level 2  Level 1  ->  Level 2...Level n+1   Level 1
>>  obj     n|n>0   ->    obj  ...   obj      real  n
>>  obj     n|n<1   ->                          0.
>
>
> Looks PERFECT to me. Yup 2 levels -->  n+1 levels, even for
> n=0 <g>.

Well, for n=0, Level n+1 = Level 1, but we already have the count
there, so I made n<1 a separate case.

>>A UserRPL program that returns the same results as NDUPN on all 48
>>and 49 series (I hope):
>>
>>%%HP: T(3)A(D)F(.);
>>@ 48 series checksum: # 3341h
>>@ 49 series checksum: # E39Eh
>>@ Size:                    80
>
>
> I typed it in a 49g+ and got the same SIZE but #8D26h for the
> checksum. It works though :-)
>
>
>>@ Arguments:
>>@   Lvevl 2: Any object, obj
>>@   Level 1: Any real or zint, n
>>@ Returns:
>>@   For n>0: Level 2...Level n+1: obj
>>@   Level 1: real number n
>>\<<
>>  DUP 0.
>>  IF
>>    <
>>  THEN
>>    DROP 0.
>>  END
>
>
> Excellent purifying of negative input :-)
>
>
>>  0. RND
>
>
>>  DUP DEPTH ROLLD
>
>
> -------
> Ahha already I see here a better coding of the non-existent
> NDUP!! You use the OVER to do the DUP - I'd never thought of
> that one!

Think of DUP and OVER as special cases of PICK.

Similarly, think of SWAP and ROT as special cases of ROLL.

SWAP and UNROT would be special cases of ROLLD.

Of course, with an argument that rounds to 1 or less, ROLL and
ROLLD return the same thing.

It occurs to me they could've made negative arguments for ROLL
behave the same as ABS ROLLD, but instead they behave as 0 ROLL. I
expect that the ROM code uses COERCE to change the real or zint to
a bint for commands like ROLL, ROLLD, DUPN, NDUPN, and so on.

>>  WHILE
>>    DUP
>>  REPEAT
>>    OVER
>>    SWAP 1. -
>>  END
>>  DR0P2

Somehow, what I posted doesn't quite match what I have in the
file. That should be DROP2 (alphabetic O), not DR0P2 (numeric 0).

But that still doesn't explain the different checksum, but same
size and still works.

> ---------------
>
>
>>  DEPTH ROLL
>>\>>

In case anyone wants to download a corrected version.:

%%HP: T(3)A(D)F(.);
@ 48 series checksum: # E39Eh
@ 49 series checksum: # 3341h
@ Size:                    80
@ Arguments:
@   Level 2: Any object, obj
@   Level 1: Any real or zint, n
@ Returns:
@   For n>0: Level 2...Level n+1: obj
@   Level 1: real number n
\<<
  DUP 0.
  IF
    <
  THEN
    DROP 0.
  END
  0. RND
  DUP DEPTH ROLLD
  WHILE
    DUP
  REPEAT
    OVER
    SWAP 1. -
  END
  DROP2
  DEPTH ROLL
\>>

>>>LOL! There is probably a bug in NDUPN as well, but I hope they
>>>don't fix it. That implied DROP is pretty unexpected as we
>>>only get (n-1) copies, as it it were...
>
>
> Maybe if I think of the stack depth. One DUP makes it 1 level
> deeper. My NDUP would make it N levels deeper. So does NDUPN.
> It's just a question of what is in the new levels :-)
>
>
>>I don't know. Maybe it's a bug in NDUPN, or maybe NDUPN
>>works as intended, but the guide is buggy instead. The
>>description in the guide uses "Duplicates"; if that were
>>true, then the program above with DROP2 changed to DROP
>>would be the expected behaviour.
>
>
> Exactly!
>
>
>>The stack diagram in the documentation doesn't make any
>>sense when n is 0 or less. I rather prefer the way that it
>>actually works to the description in the documentation.
>
>
> Me too. Thanks James.

You're welcome.

It occurs to me that NDUPN might better be named NDUPDROPN? But
there are certainly advantages to keeping names short.

-- 
Regards,
James

Here's smaller
94 bytes

\<< \->  b
   \<< { } 1 3 PICK SIZE
     FOR C OVER C GET DUP TYPE b SAME :: DROP { 1. \->LIST + } IFTE
     NEXT
   \>> SWAP DROP
 \>>


Or 89 bytes

\<< \->  b
   \<< { } 1 3 PICK SIZE
     FOR C OVER C GET DUP TYPE b SAME :: DROP { 1. \->LIST + } IFTE
     NEXT
   \>>
 \>>

This one leaves the original list on the stack as well, thus the SWAP DROP
in the first one.
Should work just fine on the 48S series. As before it errors out on an empty
list as an input.

Virgil wrote:
> I found  what may be a bug in the 49+, which allows a program cocompiled
> in real mode to operate correctly but may crash the same program when
> compiled in exact mode:
>
> \<<  0 'X' IFT \>>
> \<<  1 'X' IFT \>>
> \<<  0 'X'  'Y'IFTE \>>
> \<<  1 'X' 'Y' IFTE \>>
>
> All crash if complied in exact mode, since apparently the IFT and IFTE
> commands will not accept integers as their Boolean arguemnts.

I thought that I saw that behaviour recently (in both the 49G and
49g+), but today, IFT and IFTE are taking exact integers for flags
with no problem. And yes, that's compiling and running the above
programs in exact mode. When I noticed that this morning, I
figured that I must've been too sleepy to know what I was doing
when I thought that they weren't working. But now someone else is
seeing what I saw, so maybe I'm not going crazy after all. I
thought that it might be a library making the difference, but I
just tried with no libraries configured, and they still take exact
integers. Could it be a system flag state making the difference?

If it were consistent, I'd be inclined to call it a "limitation"
or "quirk" of the way the 49 series treats exact integers, but it
seems to be inconsistent.

> One can cure this, regardless of compilation mode, by inserting the
> I\->R command after the 0 or 1, but if one is trying for the shortest
> possible program, just compile it in approximate mode.

Or enter the 0 or 1 with a trailing decimal point.

-- 
Regards,
James

Lee wrote:
> Here's smaller
> 94 bytes
>
> \<< \->  b
>    \<< { } 1 3 PICK SIZE
>      FOR C OVER C GET DUP TYPE b SAME :: DROP { 1. \->LIST + } IFTE
>      NEXT
>    \>> SWAP DROP
>  \>>
>
>
> Or 89 bytes
>
> \<< \->  b
>    \<< { } 1 3 PICK SIZE
>      FOR C OVER C GET DUP TYPE b SAME :: DROP { 1. \->LIST + } IFTE
>      NEXT
>    \>>
>  \>>
>
> This one leaves the original list on the stack as well, thus the SWAP DROP
> in the first one.
> Should work just fine on the 48S series. As before it errors out on an empty
> list as an input.

I hope that you're not expecting me to check programs that you
already know don't work.

-- 
Regards,
James

In article <kL5ud.6$CH4.3@fe39.usenetserver.com>,
 "James M. Prange" <jmprange@i-is.com> wrote:

> Virgil wrote:
> > I found  what may be a bug in the 49+, which allows a program cocompiled
> > in real mode to operate correctly but may crash the same program when
> > compiled in exact mode:
> >
> > \<<  0 'X' IFT \>>
> > \<<  1 'X' IFT \>>
> > \<<  0 'X'  'Y'IFTE \>>
> > \<<  1 'X' 'Y' IFTE \>>
> >
> > All crash if complied in exact mode, since apparently the IFT and IFTE
> > commands will not accept integers as their Boolean arguemnts.
> 
> I thought that I saw that behaviour recently (in both the 49G and
> 49g+), but today, IFT and IFTE are taking exact integers for flags
> with no problem. And yes, that's compiling and running the above
> programs in exact mode. When I noticed that this morning, I
> figured that I must've been too sleepy to know what I was doing
> when I thought that they weren't working. But now someone else is
> seeing what I saw, so maybe I'm not going crazy after all. I
> thought that it might be a library making the difference, but I
> just tried with no libraries configured, and they still take exact
> integers. Could it be a system flag state making the difference?
> 
> If it were consistent, I'd be inclined to call it a "limitation"
> or "quirk" of the way the 49 series treats exact integers, but it
> seems to be inconsistent.
> 
> > One can cure this, regardless of compilation mode, by inserting the
> > I\->R command after the 0 or 1, but if one is trying for the shortest
> > possible program, just compile it in approximate mode.
> 
> Or enter the 0 or 1 with a trailing decimal point.

If a zero or nonzero integer occurs as a result of some preceding 
computation, one must  make sure it is converted to real somehow before 
using it in the test position of a IFT or IFTE command.

In a program compiled in exact mode on the 49+ the conversion is usually 
automatic, but not when complied in exact mode, so an extra I\->R may be 
needed.

Nope not at all. My last program that worked as required was the 99.5 byte
program.

These are just to see if i can go smaller. And to put them out ther if
anyone wants them.
This is from my own thought processes to see if i could get them working.
If I add the req'd commands to check for a null list they go to about 105
bytes.
And it looks like

 \<< \->  b
   \<< DUP SIZE NOT :: KILL IFT { } 1 3 PICK SIZE
     FOR C OVER C GET DUP TYPE b SAME :: DROP { 1. \->LIST + } IFTE
      NEXT
    \>> SWAP DROP
  \>>

That works as req'd.  But my other program beat it. No need to check this
one

On the subject of non checkable programs is 57.5 Bytes

::
  CK2 1LAMBIND DUPNULL{}? NOT IT
  :: xOBJ> NULL{} SWAP COERCE
    #1+_ONE_DO SWAPDUP xTYPE
    1GETLAM %= ITE DROP >HCOMP
    LOOP ;   ABND  ;

"James M. Prange" <jmprange@i-is.com> wrote in message
news:R98ud.170$z75.13@fe61.usenetserver.com...
> Lee wrote:
> > Here's smaller
> > 94 bytes
> >
> > \<< \->  b
> >    \<< { } 1 3 PICK SIZE
> >      FOR C OVER C GET DUP TYPE b SAME :: DROP { 1. \->LIST + } IFTE
> >      NEXT
> >    \>> SWAP DROP
> >  \>>
> >
> >
> > Or 89 bytes
> >
> > \<< \->  b
> >    \<< { } 1 3 PICK SIZE
> >      FOR C OVER C GET DUP TYPE b SAME :: DROP { 1. \->LIST + } IFTE
> >      NEXT
> >    \>>
> >  \>>
> >
> > This one leaves the original list on the stack as well, thus the SWAP
DROP
> > in the first one.
> > Should work just fine on the 48S series. As before it errors out on an
empty
> > list as an input.
>
> I hope that you're not expecting me to check programs that you
> already know don't work.
>
> -- 
> Regards,
> James
>

              -=[ Fri, 10.12.04 10:22 p.m. GMT ]=-

Hi Veli-Pekka Nousiainen ! <DROP_vpn@THIS.welho.com>

2 days 02h ago, on Wed, 8.12.04 at 10:22 p.m. +0200, you wrote
in message ID <cp7npi$edp$1@nyytiset.pp.htv.fi> :

> "Tony Hutchins" <justth@csi.com> wrote in message
> news:10509863ROBOTLX@news.individual.net...
> X
> > I haven't seen any code from you so cannot really present
> > it :-). I hope you present it though!
> >
> >> BUT
> >> you can still shave off some nibbles
> >> look carefully at _all_ of your code

I understood that hint :-)

> X
> Look outside of NDUPN and DOLIST

I don't understand that hint<G>

I could shave nibbles but only at the expense of
functionality.  Mine have been sitting quietly unchanged,
since NDUPN hit them, in an unsent usenet posting, ready to
escape when Big Ben strikes midnight to end this week-end.

> Maybe we should talk through e-mail
> OR
> only after 12.12.

12.12 approaches!

I even changed my usenet template [date] header above to show
Big Ben time, to remind me :-)

Looking forward to seeing your work VPN.

--
Tony Hutchins
Wellington
New Zealand

#16 Beginnings and endings are truly artificial constructs.

              -=[ Sat, 11.12.04 08:32 a.m. GMT ]=-

Hi James M. Prange ! <jmprange@i-is.com>

1 day 09h07m ago, on Thu, 9.12.04 at 6:24 p.m. -0500, you wrote
in message ID <m95ud.1$CH4.0@fe39.usenetserver.com> :

[... thanks for the programs James ...]

> It occurs to me that NDUPN might better be named
> NDUPDROPN? But there are certainly advantages to keeping
> names short.

Forgive me but when I read that I did giggle a little as it
looks like NDUP followed by DROPN which could be expected to
undo itself<G>. The weirdest thing is that when I look at the
NDUPN description again in the .PDF I almost understand it, as
is. There are two arguments (Level 2 and Level 1) and I guess
the assumption is these get "taken" from the stack. And what
gets returned are the n duplicates and the n. It is as if the
original from which the copies were made was worn out<G>.

-- 
Tony

"Tony Hutchins" <justth@csi.com> wrote in message 
news:11440784ROBOTLX@news.individual.net...
X
> There are two arguments (Level 2 and Level 1) and I guess
> the assumption is these get "taken" from the stack. And what
> gets returned are the n duplicates and the n.

Excatly -as all other commands with "N" should do, too.
-- 
VPN 

Here are the headers and comments that I'm using for the leaders
(so far) in this mini-challenge.

If you've submitted a better entry that I've missed somehow, then
let me know.

Of course, if you notice some way that these leading entries don't
meet all requirements, then let me know that too.

There's still over 8 hours left to enter.


For the 48SX and 48S category:


%%HP: T(3)A(R)F(.);
@ Message-ID: <41adb0ac$0$30417$636a15ce@news.free.fr>
@ Author: Endless
@ Official entry time: 2004-12-01 11:53:16 UTC
@ 48S Checksum: # 9347h
@ 48S Size:         111
@ 48G Checksum: # 9347h
@ 48G Size:         111
@ 49  Checksum: # A1E1h
@ 49  Size:        111.
@ Download to 49 in approximate mode.
@ Level 1 argument: Real type number.
@ Works


For both the 48GX, 48G, and 48G+ category and the 49G, 49g+, and
48gII category:


%%HP: T(3)A(D)F(.);
@ Message-ID: <41b0036a$1@dnews.tpgi.com.au>
@ Author: reth
@ Official entry time: 2004-12-03 06:10:50 UTC
@ 48S Checksum: N/A
@ 48S Size:     N/A
@ 48G Checksum: # 593Fh
@ 48G Size:          80
@ 49  Checksum: # 990Dh
@ 49  Size:         80.
@ Download to 49 in approximate mode.
@ Level 1 argument: Example
@ Works.


-- 
Regards,
James

For the 48g series, with all the ideas exchanged through submissions, reth
found the 77.5 bytes entry Werner had found. Otherwise I submitted a 78.5
bytes entry based on the stack manipulation during dosubs (on Dec 6):
%%HP: T(3)A(D)F(.);
@ 48S Checksum: N/A
@ 48S Size:     N/A
@ 48G Checksum: # 240Eh
@ 48G Size:     78.5
@ 49 Checksum: # C4ACh
@ 49  Size:     78.5
@ Download to 49 series in approximate mode.

And lee on Dec 7th posted a 99.5 entry (
http://groups-beta.google.com/group/comp.sys.hp48/msg/d6914be259ccd97d )
that should work on the S series, but I can't test it.

"James M. Prange" <jmprange@i-is.com> wrote in message
news:w_Xud.214$z66.67@fe61.usenetserver.com...
> Here are the headers and comments that I'm using for the leaders
> (so far) in this mini-challenge.
>
> If you've submitted a better entry that I've missed somehow, then
> let me know.
>
> Of course, if you notice some way that these leading entries don't
> meet all requirements, then let me know that too.
>
> There's still over 8 hours left to enter.
>
>
> For the 48SX and 48S category:
>
>
> %%HP: T(3)A(R)F(.);
> @ Message-ID: <41adb0ac$0$30417$636a15ce@news.free.fr>
> @ Author: Endless
> @ Official entry time: 2004-12-01 11:53:16 UTC
> @ 48S Checksum: # 9347h
> @ 48S Size:         111
> @ 48G Checksum: # 9347h
> @ 48G Size:         111
> @ 49  Checksum: # A1E1h
> @ 49  Size:        111.
> @ Download to 49 in approximate mode.
> @ Level 1 argument: Real type number.
> @ Works
>
>
> For both the 48GX, 48G, and 48G+ category and the 49G, 49g+, and
> 48gII category:
>
>
> %%HP: T(3)A(D)F(.);
> @ Message-ID: <41b0036a$1@dnews.tpgi.com.au>
> @ Author: reth
> @ Official entry time: 2004-12-03 06:10:50 UTC
> @ 48S Checksum: N/A
> @ 48S Size:     N/A
> @ 48G Checksum: # 593Fh
> @ 48G Size:          80
> @ 49  Checksum: # 990Dh
> @ 49  Size:         80.
> @ Download to 49 in approximate mode.
> @ Level 1 argument: Example
> @ Works.
>
>
> -- 
> Regards,
> James
>

          -=[ Wed, 08.12.04 03:37 p.m. +1300 (NZDT) ]=-

Hi James M. Prange ! <jmprange@i-is.com>

4h41m ago, on Tue, 7.12.04 at 02:56 a.m. -0500, you wrote
in message ID <0ndtd.10521$jb3.2656@fe61.usenetserver.com> :

> > I suppose we can all share results after the 12th?
> 
> Sure; I don't see any reason why not. Of course, from your
> time zone, that means waiting until 13:00 (1:00 P.M.) on
> the 13th.

OK, this will have been waiting unsent for nearly 5 days,
before escaping ;-)

Three programs submitted herewith.

1. 48S, 48G, 49G, 49g+
-----------------------
90 bytes. Takes type as input.
Handles example_of_type with initial TYPE.

%%HP: T(3)A(R)F(.);
  \<< + OBJ\-> { }
    WHILE SWAP 1 - DUP
    REPEAT 4 ROLL 4 PICK OVER TYPE
    SAME DUP {SWAP DROP} IFT NOT \->LIST ROT +
    END ROT DROP2
  \>>

Checksums: #C6E7h on 49g+, #BC9Bh on 48SX.

On the 49G & 49g+ we have NDUPN which can shrink the above 
by 15 bytes (to 75 bytes) if
    SAME DUP {SWAP DROP} IFT NOT \->LIST ROT +
is replaced with
    \=/ NDUPN \->LIST ROT +

So, this actually becomes a competitive candidate for the 49G
where type can be used as input. My smaller 70.5 byte entry
submitted below for the 49G requires example_of_type as input,
so it is shorter but a less flexible.

Note: I do not have a anything under 77.5 bytes for the 48G.
There I think Endless's solution, with type as a local
variable and unconstrained use of DOLIST with the final TAIL,
will reign supreme. Well, apart from other programs of the
*same* 77.5 byte size like:
<< TYPE DUP 0. TICKS IFTE ROT + DUP 1 ::TYPE DOSUBS
   ROT - NOT 2 << DROPN >> DOLIST TAIL >>
- a combination of Endless's and Fabian's programs. Another
interesting way to use the overhead associated with the type
being a local variable.

2. 49G, 49g+
------------
70.5 bytes. Takes example_of_type as input.
*Cannot* be modified to take type as input.

%%HP: T(3)A(R)F(.);
  \<< DUP TYPE { } ROT 2 \->LIST ROT +
    \<< PICK3 OVER TYPE \=/ NDUPN \->LIST +
    \>> STREAM NIP
  \>>

Checksum is #A9F7h on 49g+

Fairly straightforward application of STREAM. It avoids the
error for input lists of SIZE 0 and SIZE 1 by augmenting the
list with a {} and the example_of_type. The former is just the
basis for the list building and the later of course gets
discarded as it is the same type - pathetic I know but it's
much easier than formulating an example of different type, and
then taking the TAIL. This one takes its own TAIL<G>.

3. 49g+
-------
63 bytes. Takes type as input.
Handles example_of_type with initial TYPE.

%%HP: T(3)A(R)F(.);
  \<< { } ROT 1
    \<< PICK3 OVER TYPE \=/ NDUPN \->LIST +
    \>> DOLIST NIP \->STR OBJ\->
  \>>

Checksum is #F6BCh on 49g+

Note 1.

This takes advantage of the highly specific 49g+ DOLIST bug
whereby an empty list {} *is* accepted without error (not so
for DOSUBS on the 49g+ for example or either DOLIST or DOSUBS
on the 49G or 48G). On the 49g+ such an empty list is deemed
by DOLIST to contain an empty program and the final ->STR
OBJ-> removes this - these 5 bytes are much cheaper than the
"cost" of modifying or separately checking for an initial {}.

Just passing an empty string through DOLIST like so:
{} 1 <<>> DOLIST
produces what looks like {} but -85 SF shows {PTR 05607}.

Note 2.

The program actually makes DOLIST think it has created "no
list" as output because the stack DEPTH is unchanged. So,
DOLIST merely leaves the stack as is. Normally this is
considered a bad feature of DOLIST as when it really does
nothing one would expect a new empty list {} *created* as
output. So, the program here takes advantage of not only a bug
but also a "bad feature".

Note 3.

The only reason I initially experimented in taking control of
the list output of DOLIST was so I didn't need the type to be
stored as a local variable. By forcing the stack DEPTH to stay
the same after each iteration, the type is always accessible
from the same level. It was just lucky that the local variable
size overhead was, in this case, higher than using the stack -
and NDUPN just magnified that dramatically. When I found NDUPN
I just stopped all work.

It will be interesting if anybody can shorten this one. To me
it looks incompressible, but I am sure to be proved wrong,
possibly even by myself<G>. I was lucky that PICK3, NDUPN and
NIP are classic 2.5 byte commands. DOLIST, DOSUBS and even
HEAD and TAIL are 5.5 byters, which surprised me.

-- 
Tony Hutchins
Wellington
New Zealand

#244 It is a bad plan that admits of no
modification. Publilius Syrus

Endless wrote:
> For the 48g series, with all the ideas exchanged through submissions, reth
> found the 77.5 bytes entry Werner had found.

Yes, that's the one that I listed with 80 bytes. It's effectively
77.5 bytes with the beginning TYPE command removed.

>  Otherwise I submitted a 78.5
> bytes entry based on the stack manipulation during dosubs (on Dec 6):
> %%HP: T(3)A(D)F(.);
> @ 48S Checksum: N/A
> @ 48S Size:     N/A
> @ 48G Checksum: # 240Eh
> @ 48G Size:     78.5
> @ 49 Checksum: # C4ACh
> @ 49  Size:     78.5
> @ Download to 49 series in approximate mode.

Yes, I have that one too. 78.5 bytes as is, or 81 bytes if we add
a TYPE command to have it take an example instead.

> And lee on Dec 7th posted a 99.5 entry (
> http://groups-beta.google.com/group/comp.sys.hp48/msg/d6914be259ccd97d )

I'm glad you that mentioned that. I have it, and on paper, I even
have it circled as the best, but somehow, when I posted, I missed
it in my file.

> that should work on the S series, but I can't test it.

Yes, it works fine in the 48SX, and 48G and 49 too, for that
matter.

<snip>

-- 
Regards,
James

Unless someone can show me that I've misjudged, the winning
entries are as follows:



48SX and 48S category:

Message-ID: <96rtd.55821$QJ3.745@newssvr21.news.prodigy.com>
%%HP: T(3)A(D)F(.);
@
@ Author: Lee
@ Official entry time: 2004-12-07 23:34:29 UTC
@ 48S Checksum: # 57B8h
@ 48S Size:        99.5
@ 48G Checksum: # 57B8h
@ 48G Size:        99.5
@ 49  Checksum: # 6062h
@ 49  Size:        99.5
@ Download to 49 in exact mode.
@ Level 1 argument: Real type number
@ Works.
\<< \-> b
  \<< DUP SIZE { OBJ\-> { } 1. ROT
    FOR C SWAP DUP TYPE b SAME :: DROP { 1. \->LIST SWAP + } IFTE
    NEXT } IFT
  \>>
\>>

Would be 102 bytes with a TYPE command inserted at the beginning
to take an example of an object type.



48GX, 48G, and 48G+ category:

Message-ID: <41b0036a$1@dnews.tpgi.com.au>
%%HP: T(3)A(D)F(.);
@
@ Author: reth
@ Official entry time: 2004-12-03 06:10:50 UTC
@ 48S Checksum: N/A
@ 48S Size:     N/A
@ 48G Checksum: # 593Fh
@ 48G Size:          80
@ 49  Checksum: # 990Dh
@ 49  Size:         80.
@ Download to 49 in approximate mode.
@ Level 1 argument: Example
@ Works.
\<< TYPE DUP \-> T
  \<< 0 TICKS IFTE SWAP + 1
    \<< DUP TYPE T == DROPN
    \>> DOSUBS TAIL
  \>>
\>>

Would be 77.5 bytes with the initial TYPE command removed to take
a real type number.

Note that reth generously credits Endless for the idea; still, it
was reth who got it down to this size.

An almost winner, 3-4 seconds too late to meet the deadline:

Message-ID: <41bcdb82$0$11576$626a14ce@news.free.fr>
%%HP: T(3)A(R)F(.);
@
@ Author: Endless
@ Official entry time: 2004-12-13 00:00:03
@ 48S Checksum: N/A
@ 48S Size:     N/A
@ 48G checksum: # 7241h
@ 48S Size:        75.5
@ 49 checksum:  # 7A4Fh
@ 49 Size:         75.5
@ Download to 49 in approximate mode.
@ Level 1 argument: Real type number
@ Works
@ Entry time barely too late.
\<< DUP "\-> T\<<0C$ 0 IFTE SWAP + 1\<<DUP TYPE T == DROPN\>>DOSUBS" OBJ\->
TAIL
\>>

Would be 78 bytes with an initial TYPE command inserted to take an
example of an object type.



49G, 49g+, and 48gII category:

Message-ID: <49ed4c.0412121107.388d23b5@posting.google.com>
%%HP: T(3)A(R)F(.);
@
@ Author: JoGa
@ Official entry time: 2004-12-12 19:07:28
@ 48S Checksum: N/A
@ 48S Size:     N/A
@ 48G checksum: N/A
@ 48S Size:     N/A
@ 49 checksum: # 1A4Eh
@ 49 Size:         73.
@ Download to 49 in exact mode.
@ Level 1 argument: Real type number
@ Works
\<< "\-> T\<<0SWAP + 1\<<DUP TYPE T
== NSUB 1> *::;IFT\>>DOSUBS" OBJ\-> TAIL
\>>

Would be 75.5 bytes with an initial TYPE command inserted to take
an example of an object type.

Very interesting technique. For this, the size of the source code
for the objects in the string makes a difference, and of course
eliminating source code separators where they aren't strictly
necessary is important.



But in a sense, everyone who participated is a winner. Just coming
up with a program that works as intended, even if not the very
smallest or fastest possible, is a worthwhile accomplishment.

Of course, all participants in this mini-challenge are now
"old-timers", and everyone is invited to participate in the
"Old-timers' mini-challenge" in a separate thread.

Thanks for sharing your skills.

--
Regards,
James

thanks, James, you're the greatest judge I've ever seen; thanks also for the
great job you've been doing!
Best regards
reth
"James M. Prange" <jmprange@i-is.com> wrote in message
news:G7cvd.290$z66.84@fe61.usenetserver.com...
> Unless someone can show me that I've misjudged, the winning
> entries are as follows:
>
>
>
> 48SX and 48S category:
>
> Message-ID: <96rtd.55821$QJ3.745@newssvr21.news.prodigy.com>
> %%HP: T(3)A(D)F(.);
> @
> @ Author: Lee
> @ Official entry time: 2004-12-07 23:34:29 UTC
> @ 48S Checksum: # 57B8h
> @ 48S Size:        99.5
> @ 48G Checksum: # 57B8h
> @ 48G Size:        99.5
> @ 49  Checksum: # 6062h
> @ 49  Size:        99.5
> @ Download to 49 in exact mode.
> @ Level 1 argument: Real type number
> @ Works.
> \<< \-> b
>   \<< DUP SIZE { OBJ\-> { } 1. ROT
>     FOR C SWAP DUP TYPE b SAME :: DROP { 1. \->LIST SWAP + } IFTE
>     NEXT } IFT
>   \>>
> \>>
>
> Would be 102 bytes with a TYPE command inserted at the beginning
> to take an example of an object type.
>
>
>
> 48GX, 48G, and 48G+ category:
>
> Message-ID: <41b0036a$1@dnews.tpgi.com.au>
> %%HP: T(3)A(D)F(.);
> @
> @ Author: reth
> @ Official entry time: 2004-12-03 06:10:50 UTC
> @ 48S Checksum: N/A
> @ 48S Size:     N/A
> @ 48G Checksum: # 593Fh
> @ 48G Size:          80
> @ 49  Checksum: # 990Dh
> @ 49  Size:         80.
> @ Download to 49 in approximate mode.
> @ Level 1 argument: Example
> @ Works.
> \<< TYPE DUP \-> T
>   \<< 0 TICKS IFTE SWAP + 1
>     \<< DUP TYPE T == DROPN
>     \>> DOSUBS TAIL
>   \>>
> \>>
>
> Would be 77.5 bytes with the initial TYPE command removed to take
> a real type number.
>
> Note that reth generously credits Endless for the idea; still, it
> was reth who got it down to this size.
>
> An almost winner, 3-4 seconds too late to meet the deadline:
>
> Message-ID: <41bcdb82$0$11576$626a14ce@news.free.fr>
> %%HP: T(3)A(R)F(.);
> @
> @ Author: Endless
> @ Official entry time: 2004-12-13 00:00:03
> @ 48S Checksum: N/A
> @ 48S Size:     N/A
> @ 48G checksum: # 7241h
> @ 48S Size:        75.5
> @ 49 checksum:  # 7A4Fh
> @ 49 Size:         75.5
> @ Download to 49 in approximate mode.
> @ Level 1 argument: Real type number
> @ Works
> @ Entry time barely too late.
> \<< DUP "\-> T\<<0C$ 0 IFTE SWAP + 1\<<DUP TYPE T == DROPN\>>DOSUBS"
OBJ\->
> TAIL
> \>>
>
> Would be 78 bytes with an initial TYPE command inserted to take an
> example of an object type.
>
>
>
> 49G, 49g+, and 48gII category:
>
> Message-ID: <49ed4c.0412121107.388d23b5@posting.google.com>
> %%HP: T(3)A(R)F(.);
> @
> @ Author: JoGa
> @ Official entry time: 2004-12-12 19:07:28
> @ 48S Checksum: N/A
> @ 48S Size:     N/A
> @ 48G checksum: N/A
> @ 48S Size:     N/A
> @ 49 checksum: # 1A4Eh
> @ 49 Size:         73.
> @ Download to 49 in exact mode.
> @ Level 1 argument: Real type number
> @ Works
> \<< "\-> T\<<0SWAP + 1\<<DUP TYPE T
> == NSUB 1> *::;IFT\>>DOSUBS" OBJ\-> TAIL
> \>>
>
> Would be 75.5 bytes with an initial TYPE command inserted to take
> an example of an object type.
>
> Very interesting technique. For this, the size of the source code
> for the objects in the string makes a difference, and of course
> eliminating source code separators where they aren't strictly
> necessary is important.
>
>
>
> But in a sense, everyone who participated is a winner. Just coming
> up with a program that works as intended, even if not the very
> smallest or fastest possible, is a worthwhile accomplishment.
>
> Of course, all participants in this mini-challenge are now
> "old-timers", and everyone is invited to participate in the
> "Old-timers' mini-challenge" in a separate thread.
>
> Thanks for sharing your skills.
>
> --
> Regards,
> James
>

I can't take credit for the smallest for the 48S james. Khanh-Dang beat me
by 1 byte with his recursive program..
"James M. Prange" <jmprange@i-is.com> wrote in message
news:G7cvd.290$z66.84@fe61.usenetserver.com...
> Unless someone can show me that I've misjudged, the winning
> entries are as follows:
>
>
>
> 48SX and 48S category:
>
> Message-ID: <96rtd.55821$QJ3.745@newssvr21.news.prodigy.com>
> %%HP: T(3)A(D)F(.);
> @
> @ Author: Lee
> @ Official entry time: 2004-12-07 23:34:29 UTC
> @ 48S Checksum: # 57B8h
> @ 48S Size:        99.5
> @ 48G Checksum: # 57B8h
> @ 48G Size:        99.5
> @ 49  Checksum: # 6062h
> @ 49  Size:        99.5
> @ Download to 49 in exact mode.
> @ Level 1 argument: Real type number
> @ Works.
> \<< \-> b
>   \<< DUP SIZE { OBJ\-> { } 1. ROT
>     FOR C SWAP DUP TYPE b SAME :: DROP { 1. \->LIST SWAP + } IFTE
>     NEXT } IFT
>   \>>
> \>>
>
> Would be 102 bytes with a TYPE command inserted at the beginning
> to take an example of an object type.
>
>
>
> 48GX, 48G, and 48G+ category:
>
> Message-ID: <41b0036a$1@dnews.tpgi.com.au>
> %%HP: T(3)A(D)F(.);
> @
> @ Author: reth
> @ Official entry time: 2004-12-03 06:10:50 UTC
> @ 48S Checksum: N/A
> @ 48S Size:     N/A
> @ 48G Checksum: # 593Fh
> @ 48G Size:          80
> @ 49  Checksum: # 990Dh
> @ 49  Size:         80.
> @ Download to 49 in approximate mode.
> @ Level 1 argument: Example
> @ Works.
> \<< TYPE DUP \-> T
>   \<< 0 TICKS IFTE SWAP + 1
>     \<< DUP TYPE T == DROPN
>     \>> DOSUBS TAIL
>   \>>
> \>>
>
> Would be 77.5 bytes with the initial TYPE command removed to take
> a real type number.
>
> Note that reth generously credits Endless for the idea; still, it
> was reth who got it down to this size.
>
> An almost winner, 3-4 seconds too late to meet the deadline:
>
> Message-ID: <41bcdb82$0$11576$626a14ce@news.free.fr>
> %%HP: T(3)A(R)F(.);
> @
> @ Author: Endless
> @ Official entry time: 2004-12-13 00:00:03
> @ 48S Checksum: N/A
> @ 48S Size:     N/A
> @ 48G checksum: # 7241h
> @ 48S Size:        75.5
> @ 49 checksum:  # 7A4Fh
> @ 49 Size:         75.5
> @ Download to 49 in approximate mode.
> @ Level 1 argument: Real type number
> @ Works
> @ Entry time barely too late.
> \<< DUP "\-> T\<<0C$ 0 IFTE SWAP + 1\<<DUP TYPE T == DROPN\>>DOSUBS"
OBJ\->
> TAIL
> \>>
>
> Would be 78 bytes with an initial TYPE command inserted to take an
> example of an object type.
>
>
>
> 49G, 49g+, and 48gII category:
>
> Message-ID: <49ed4c.0412121107.388d23b5@posting.google.com>
> %%HP: T(3)A(R)F(.);
> @
> @ Author: JoGa
> @ Official entry time: 2004-12-12 19:07:28
> @ 48S Checksum: N/A
> @ 48S Size:     N/A
> @ 48G checksum: N/A
> @ 48S Size:     N/A
> @ 49 checksum: # 1A4Eh
> @ 49 Size:         73.
> @ Download to 49 in exact mode.
> @ Level 1 argument: Real type number
> @ Works
> \<< "\-> T\<<0SWAP + 1\<<DUP TYPE T
> == NSUB 1> *::;IFT\>>DOSUBS" OBJ\-> TAIL
> \>>
>
> Would be 75.5 bytes with an initial TYPE command inserted to take
> an example of an object type.
>
> Very interesting technique. For this, the size of the source code
> for the objects in the string makes a difference, and of course
> eliminating source code separators where they aren't strictly
> necessary is important.
>
>
>
> But in a sense, everyone who participated is a winner. Just coming
> up with a program that works as intended, even if not the very
> smallest or fastest possible, is a worthwhile accomplishment.
>
> Of course, all participants in this mini-challenge are now
> "old-timers", and everyone is invited to participate in the
> "Old-timers' mini-challenge" in a separate thread.
>
> Thanks for sharing your skills.
>
> --
> Regards,
> James
>

"Lee" <RDELM@PACBELL.NET> wrote in message 
news:D2jvd.59204$QJ3.40863@newssvr21.news.prodigy.com...
>I can't take credit for the smallest for the 48S james. Khanh-Dang beat me
> by 1 byte with his recursive program..
X
And if RMTYP would be allowed as the name...
--
VPN 

Then its a few more bytes.
"Veli-Pekka Nousiainen" <DROP_vpn@THIS.welho.com> wrote in message
news:cpkg5l$h6g$1@nyytiset.pp.htv.fi...
> "Lee" <RDELM@PACBELL.NET> wrote in message
> news:D2jvd.59204$QJ3.40863@newssvr21.news.prodigy.com...
> >I can't take credit for the smallest for the 48S james. Khanh-Dang beat
me
> > by 1 byte with his recursive program..
> X
> And if RMTYP would be allowed as the name...
> --
> VPN
>
>

Lee wrote:

> I can't take credit for the smallest for the 48S james. Khanh-Dang beat me
> by 1 byte with his recursive program..

No, those programs don't work on the 48S; they require the 48G
series' new list-processing commands.

-- 
Regards,
James

I stand corrected..
"James M. Prange" <jmprange@i-is.com> wrote in message
news:mrKvd.1020$lV.636@fe39.usenetserver.com...
> Lee wrote:
>
> > I can't take credit for the smallest for the 48S james. Khanh-Dang beat
me
> > by 1 byte with his recursive program..
>
> No, those programs don't work on the 48S; they require the 48G
> series' new list-processing commands.
>
> -- 
> Regards,
> James
>

          -=[ Tue, 4.1.05 09:37 a.m. +1300 (NZDT) ]=-

Hello Veli-Pekka Nousiainen,  <DROP_vpn@THIS.welho.com>

4 weeks 4 days 10h58m ago,
on Thu, 2.12.04 at 11:39 a.m. +0200, you wrote
in message ID <comnqp$udd$1@nyytiset.pp.htv.fi> :
> X
> When I use recursion (and speed and/or size is not optimized)
> I tend to use a local name for the subprogram that is recursive
> this way I know that I can always change the Global name
> if I need/want to (Except in my TEST subdirectories).
> 
> Using your program (and making it longer) as an example
> 'RELMTYPE' :
> \<< -> l t \<< l t @ check for two arguments
> \<< @ put the subrogram on the stack
>  OVER SIZE
>  {
>    OVER HEAD
>    OVER TYPE OVER TYPE ==
>      SWAP 1. \->LIST 1. \->LIST
>      { {} }
>    IFTE
>    ROT TAIL
>    ROT
>    t EVAL @ RELMTYPE replaced by local name
>    +
>  }
>  :: DROP
>  IFTE
> \>> -> t \<< t EVAL @ re-using the variable name
> \>> \>> \>>
> NO BYTES:
> this is *not* an entry (boy, it's long), I'm not qualified
> One may learn something new here
> [VPN]

Nice technique VPN.
Using Virgil's recursive program I get a 109.5 byter, but I
like it. Oh it's 107 w/o the initial TYPE. Now, it's like the
others with the removable TYPE up front, and name-length
independent, but very hard to shrink much below say 90 bytes.

<< TYPE 1 -> T P
<< {DUP SIZE {OBJ-> 1 - ->LIST SWAP T OVER TYPE
   != NDUPN ->LIST SWAP P EVAL + } IFT } ->P
   << P EVAL >>
>>
>>

Was interesting to see it work.
'P' STO P EVAL  
seems exactly equivalent (in size and function) to the 
->P << P EVAL>>
in this case where P is already designated local using the
dummy value 1.

-- 
Tony

#346 Pandora's Rule: Never open a box you didn't close.