bug-apl
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-apl] box and unbox that work uniformly and without exceptions


From: Frederick H. Pitts
Subject: Re: [Bug-apl] box and unbox that work uniformly and without exceptions
Date: Fri, 16 May 2014 21:07:42 -0500

Hello Blake,

        Please present at least one use case where box/unbox behavior differs
from ⊂/⊃ behavior.  For all the use cases you present in your email, I
do not believe there is a difference.

Regards,

Fred Pitts
Retired Chemical Engineer

On Tue, 2014-05-13 at 09:00 -0500, Blake McBride wrote:
> I wrote two APL functions that operate like ⊃ and ⊂ packing an APL1
> array into a scalar and unpacking it back into its APL1 array.  It
> works as Iverson preferred, and is simple to understand and use.
>  There are no exceptions to what can be nested (i.e. scalars can be
> recursively nested).  And there are no data transformations, i.e.
> unboxing always gives you back what you boxed.
> 
> 
> These functions return an APL2 nested scalar that can be concatenated
> and used like other APL2 nested arrays - you just need to use
> box/unbox rather than ⊂ and ⊃ to box / unbox them.
> 
> 
> Here are the functions, examples to follow:
> 
> 
>       ∇box[⎕]∇
> [0] z←box x
> [1] z←⊂(⊂⍴x),⊂,x
>       
>       ∇unbox[⎕]∇
> [0] z←unbox x
> [1] z←(⊃x[⎕IO])⍴⊃(x←⊃x)[⎕IO+1]
>  
> 
> 
>       ]boxing 8
>       unbox box ,6
> ┌→┐
> │6│
> └─┘
>       unbox box 6
> ┌─┐
> │6│
> └─┘
>       unbox box ''
> ┌⊖┐
> │ │
> └─┘
>       unbox box ⍳3
> ┌→────┐
> │1 2 3│
> └─────┘
>       unbox box 0⍴0
> ┌⊖┐
> │0│
> └─┘
>       unbox box 'f'
> ┌─┐
> │f│
> └─┘
>       ⍴box ⍳3
> ┌⊖┐
> │0│
> └─┘
>       unbox unbox unbox box box box 6
> ┌─┐
> │6│
> └─┘
>       x←(box ''),(box 6), box ⍳3
>       ⍴x
> ┌→┐
> │3│
> └─┘
>       unbox x[1]
> ┌⊖┐
> │ │
> └─┘
>       unbox x[2]
> ┌─┐
> │6│
> └─┘
>       unbox x[3]
> ┌→────┐
> │1 2 3│
> └─────┘
>       
> These functions, while not a replacement for ⊂ and ⊃, they do provide
> functionality that is sometimes preferred.
> 
> 
> Thanks.
> 
> 
> Blake
> 
> 





reply via email to

[Prev in Thread] Current Thread [Next in Thread]