

Hi, Help of resize() function says:  Builtin Function: resize (X, M)  Builtin 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 MbyM. 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 MbyN.
See also: reshape. resize is a builtin 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! *****************************************
_______________________________________________
Helpoctave mailing list
[hidden email]
https://wwwold.cae.wisc.edu/mailman/listinfo/helpoctave


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
_______________________________________________
Helpoctave mailing list
[hidden email]
https://wwwold.cae.wisc.edu/mailman/listinfo/helpoctave


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! *****************************************
_______________________________________________
Helpoctave mailing list
[hidden email]
https://wwwold.cae.wisc.edu/mailman/listinfo/helpoctave


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.
_______________________________________________
Helpoctave mailing list
[hidden email]
https://wwwold.cae.wisc.edu/mailman/listinfo/helpoctave


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 nonexistent 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!
> *****************************************
>
> _______________________________________________
> Helpoctave mailing list
> [hidden email]
> https://wwwold.cae.wisc.edu/mailman/listinfo/helpoctave>
>

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


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 nonexistent 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 Octaveforge 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 GifSurYvette 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
_______________________________________________
Helpoctave mailing list
[hidden email]
https://wwwold.cae.wisc.edu/mailman/listinfo/helpoctave


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 nonexistent 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 Octaveforge 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
> GifSurYvette 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
_______________________________________________
Helpoctave mailing list
[hidden email]
https://wwwold.cae.wisc.edu/mailman/listinfo/helpoctave


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 GifSurYvette 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
_______________________________________________
Helpoctave mailing list
[hidden email]
https://wwwold.cae.wisc.edu/mailman/listinfo/helpoctave


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 outof 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
> GifSurYvette 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
_______________________________________________
Helpoctave mailing list
[hidden email]
https://wwwold.cae.wisc.edu/mailman/listinfo/helpoctave

