About resize() function

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

About resize() function

José Luis García Pallero
Hi,
Help of resize() function says:

-- Built-in Function:  resize (X, M)
 -- Built-in Function:  resize (X, M, N)
     Destructively resize X.

     *Values in X are not preserved as they are with `reshape'.*

     If only M is supplied and it is a scalar, the dimension of the
     result is M-by-M.  If M is a vector, then the dimensions of the
     result are given by the elements of M.  If both M and N are
     scalars, then the dimensions of the result are M-by-N.

     See also: reshape.

resize is a built-in function

But in fact, not is a destructive resize, or I didn't understand what *Values in X are not preserved as they are with `reshape'.* means.
For example, if:

a=[1 2;3 4];
resize(a,3,3) returns:

1 2 0
3 4 0
0 0 0

Is the function wrong or the help

--
*****************************************
José Luis García Pallero
[hidden email]
(o<
/ / \
V_/_
Use Debian GNU/Linux and enjoy!
*****************************************

_______________________________________________
Help-octave mailing list
[hidden email]
https://www-old.cae.wisc.edu/mailman/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|

Re: About resize() function

Bill Denney-5
José Luis García Pallero wrote:

> But in fact, not is a destructive resize, or I didn't understand what
> *Values in X are not preserved as they are with `reshape'.* means.
> For example, if:
>
> a=[1 2;3 4];
> resize(a,3,3) returns:
>
> 1 2 0
> 3 4 0
> 0 0 0
>
> Is the function wrong or the help
Both are correct if you do things a little differently.  Values are not
preserved if you make the matrix smaller.  Try the following:

a = [1 2;3 4];
resize(a, 1, 3)

Have a good day,

Bill
_______________________________________________
Help-octave mailing list
[hidden email]
https://www-old.cae.wisc.edu/mailman/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|

Re: About resize() function

José Luis García Pallero
Ok, but the fact that some elements are not preserved if the new matrix is samaller is logical. I think that the help of the function is quite confused.

2008/10/24 Bill Denney <[hidden email]>
José Luis García Pallero wrote:
> But in fact, not is a destructive resize, or I didn't understand what
> *Values in X are not preserved as they are with `reshape'.* means.
> For example, if:
>
> a=[1 2;3 4];
> resize(a,3,3) returns:
>
> 1 2 0
> 3 4 0
> 0 0 0
>
> Is the function wrong or the help
Both are correct if you do things a little differently.  Values are not
preserved if you make the matrix smaller.  Try the following:

a = [1 2;3 4];
resize(a, 1, 3)

Have a good day,

Bill



--
*****************************************
José Luis García Pallero
[hidden email]
(o<
/ / \
V_/_
Use Debian GNU/Linux and enjoy!
*****************************************

_______________________________________________
Help-octave mailing list
[hidden email]
https://www-old.cae.wisc.edu/mailman/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|

Re: About resize() function

c.-2

On 24/ott/08, at 09:24, José Luis García Pallero wrote:

> Ok, but the fact that some elements are not preserved if the new  
> matrix is samaller is logical. I think that the help of the function  
> is quite confused.

no, the feature is not obvious, for example compare

a = rand(4)
resize(a, 2, 8)

to

reshape(a, 2, 8)

anyway, if you think the documentation can be improved, please send a  
patch
c.



_______________________________________________
Help-octave mailing list
[hidden email]
https://www-old.cae.wisc.edu/mailman/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|

Re: About resize() function

Jaroslav Hajek-2
In reply to this post by José Luis García Pallero
On Fri, Oct 24, 2008 at 10:24 AM, José Luis García Pallero
<[hidden email]> wrote:
> Ok, but the fact that some elements are not preserved if the new matrix is
> samaller is logical. I think that the help of the function is quite
> confused.

I agree. Also, the behaviour when given a single dimension argument is
not logical - IMHO, it should do a vector resize (similarly to what
assigning to a non-existent vector element does). I intend to patch
resize soon, after I finish the patch I'm now working on, improving
the speed of dense indexing and cleaning up the indexing code in
Array<T>.

regards,


>
> 2008/10/24 Bill Denney <[hidden email]>
>>
>> José Luis García Pallero wrote:
>> > But in fact, not is a destructive resize, or I didn't understand what
>> > *Values in X are not preserved as they are with `reshape'.* means.
>> > For example, if:
>> >
>> > a=[1 2;3 4];
>> > resize(a,3,3) returns:
>> >
>> > 1 2 0
>> > 3 4 0
>> > 0 0 0
>> >
>> > Is the function wrong or the help
>> Both are correct if you do things a little differently.  Values are not
>> preserved if you make the matrix smaller.  Try the following:
>>
>> a = [1 2;3 4];
>> resize(a, 1, 3)
>>
>> Have a good day,
>>
>> Bill
>
>
>
> --
> *****************************************
> José Luis García Pallero
> [hidden email]
> (o<
> / / \
> V_/_
> Use Debian GNU/Linux and enjoy!
> *****************************************
>
> _______________________________________________
> Help-octave mailing list
> [hidden email]
> https://www-old.cae.wisc.edu/mailman/listinfo/help-octave
>
>



--
RNDr. Jaroslav Hajek
computing expert
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz

_______________________________________________
Help-octave mailing list
[hidden email]
https://www-old.cae.wisc.edu/mailman/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|

Re: About resize() function

David Bateman-3
Jaroslav Hajek wrote:

> On Fri, Oct 24, 2008 at 10:24 AM, José Luis García Pallero
> <[hidden email]> wrote:
>  
>> Ok, but the fact that some elements are not preserved if the new matrix is
>> samaller is logical. I think that the help of the function is quite
>> confused.
>>    
>
> I agree. Also, the behaviour when given a single dimension argument is
> not logical - IMHO, it should do a vector resize (similarly to what
> assigning to a non-existent vector element does). I intend to patch
> resize soon, after I finish the patch I'm now working on, improving
> the speed of dense indexing and cleaning up the indexing code in
> Array<T>.
>
> regards,
>
>  

If you do check that if you have the Octave-forge comms toolbox
installed something like

m = 2;
n = 2.^m;
a = gf (floor(randn(10,10,n), m);
b = tril (a)

resize is used in tril and is used so that metadata in the input matrix
(for the galois field about the primitive polynomial of the field), is
preserved during the operation.

Regards
David



--
David Bateman                                [hidden email]
Motorola Labs - Paris                        +33 1 69 35 48 04 (Ph)
Parc Les Algorithmes, Commune de St Aubin    +33 6 72 01 06 33 (Mob)
91193 Gif-Sur-Yvette FRANCE                  +33 1 69 35 77 01 (Fax)

The information contained in this communication has been classified as:

[x] General Business Information
[ ] Motorola Internal Use Only
[ ] Motorola Confidential Proprietary

_______________________________________________
Help-octave mailing list
[hidden email]
https://www-old.cae.wisc.edu/mailman/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|

Re: About resize() function

Jaroslav Hajek-2
On Fri, Oct 24, 2008 at 11:03 AM, David Bateman
<[hidden email]> wrote:

> Jaroslav Hajek wrote:
>>
>> On Fri, Oct 24, 2008 at 10:24 AM, José Luis García Pallero
>> <[hidden email]> wrote:
>>
>>>
>>> Ok, but the fact that some elements are not preserved if the new matrix
>>> is
>>> samaller is logical. I think that the help of the function is quite
>>> confused.
>>>
>>
>> I agree. Also, the behaviour when given a single dimension argument is
>> not logical - IMHO, it should do a vector resize (similarly to what
>> assigning to a non-existent vector element does). I intend to patch
>> resize soon, after I finish the patch I'm now working on, improving
>> the speed of dense indexing and cleaning up the indexing code in
>> Array<T>.
>>
>> regards,
>>
>>
>
> If you do check that if you have the Octave-forge comms toolbox installed
> something like
>
> m = 2;
> n = 2.^m;
> a = gf (floor(randn(10,10,n), m);
> b = tril (a)
>
> resize is used in tril and is used so that metadata in the input matrix (for
> the galois field about the primitive polynomial of the field), is preserved
> during the operation.
>

OK, so what? I'm not saying that resize is not useful, I'm just saying that
resize (x, m) should not mean the same as resize (x, m, m). resize
(zeros (3, 1), 4) should, IMHO, give zeros (4, 1), not zeros (4, 4) as
it gives now. That makes no sense to me.

> Regards
> David
>
>
>
> --
> David Bateman                                [hidden email]
> Motorola Labs - Paris                        +33 1 69 35 48 04 (Ph) Parc Les
> Algorithmes, Commune de St Aubin    +33 6 72 01 06 33 (Mob) 91193
> Gif-Sur-Yvette FRANCE                  +33 1 69 35 77 01 (Fax)
> The information contained in this communication has been classified as:
> [x] General Business Information [ ] Motorola Internal Use Only [ ] Motorola
> Confidential Proprietary
>
>



--
RNDr. Jaroslav Hajek
computing expert
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz

_______________________________________________
Help-octave mailing list
[hidden email]
https://www-old.cae.wisc.edu/mailman/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|

Re: About resize() function

David Bateman-3
Jaroslav Hajek wrote:
> OK, so what? I'm not saying that resize is not useful, I'm just saying that
> resize (x, m) should not mean the same as resize (x, m, m). resize
> (zeros (3, 1), 4) should, IMHO, give zeros (4, 1), not zeros (4, 4) as
> it gives now. That makes no sense to me.
>
>  
>
The test I gave is a test that is needed that justifies the existence of
resize at all. Otherwise we could just use zeros() instead in
tril/triu.. Comparse to output of rand(4) and rand(4,1) .... Therefore
in a certain logic (probably the one I use when I wrote resize) resize
(arg, n) == resize(arg, n, n) makes sense compared to the output of
zeros(4), ones(4), rand(4), etc...

D.


--
David Bateman                                [hidden email]
Motorola Labs - Paris                        +33 1 69 35 48 04 (Ph)
Parc Les Algorithmes, Commune de St Aubin    +33 6 72 01 06 33 (Mob)
91193 Gif-Sur-Yvette FRANCE                  +33 1 69 35 77 01 (Fax)

The information contained in this communication has been classified as:

[x] General Business Information
[ ] Motorola Internal Use Only
[ ] Motorola Confidential Proprietary

_______________________________________________
Help-octave mailing list
[hidden email]
https://www-old.cae.wisc.edu/mailman/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|

Re: About resize() function

Jaroslav Hajek-2
On Fri, Oct 24, 2008 at 11:50 AM, David Bateman
<[hidden email]> wrote:

> Jaroslav Hajek wrote:
>>
>> OK, so what? I'm not saying that resize is not useful, I'm just saying
>> that
>> resize (x, m) should not mean the same as resize (x, m, m). resize
>> (zeros (3, 1), 4) should, IMHO, give zeros (4, 1), not zeros (4, 4) as
>> it gives now. That makes no sense to me.
>>
>>
>
> The test I gave is a test that is needed that justifies the existence of
> resize at all. Otherwise we could just use zeros() instead in tril/triu..
> Comparse to output of rand(4) and rand(4,1) .... Therefore in a certain
> logic (probably the one I use when I wrote resize) resize (arg, n) ==
> resize(arg, n, n) makes sense compared to the output of zeros(4), ones(4),
> rand(4), etc...
>

OK, that's a good point as well. I would, however, want resize to
match what Array<T>::resize does, and have the following invariant:
If, in indexed assignment A(ind) = X or A(ind(1), ind(2), ...) = X,
any of the indices contains an out-of range value, then A = resize (A,
dims) is executed first, where
dims is max (size (A), ext) and ext(i) = max (ind (i)) (this may
contain errors and is a little wordy, but I hope you get my meaning).

Thus, in accord with Array<T>::resize (and resizing on indexed
assignment), resize with a single dim spec will resize a vector. You
can get the current behaviour of resize (A, n) using resize (A, n, n)
which also seems more readable to me.
Resizing a vector, however, is not easily achievable using the current
resize (you have to check for orientation first).

Do you think that such a change to resize is worthwhile? I couldn't
find any code depending on this form of resize in current Octave's
sources.


> D.
>
>
> --
> David Bateman                                [hidden email]
> Motorola Labs - Paris                        +33 1 69 35 48 04 (Ph) Parc Les
> Algorithmes, Commune de St Aubin    +33 6 72 01 06 33 (Mob) 91193
> Gif-Sur-Yvette FRANCE                  +33 1 69 35 77 01 (Fax)
> The information contained in this communication has been classified as:
> [x] General Business Information [ ] Motorola Internal Use Only [ ] Motorola
> Confidential Proprietary
>
>



--
RNDr. Jaroslav Hajek
computing expert
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz
_______________________________________________
Help-octave mailing list
[hidden email]
https://www-old.cae.wisc.edu/mailman/listinfo/help-octave