6:38 p.m.
Hi,
I have been struggling with this unexpected behavior:
<hansl>
matrix m = {0.5}
eval typename(m) # matrix
b = _(hu=m)
eval typename(b.hu) # scalar
</hansl>
So the mere copy of the object changes its type here. (Also happens
outside of a bundle, but there you can force the type more easily.) I
don't think that should happen.
thanks
sven
7:02 p.m.
Am 05.11.2024 um 00:38 schrieb Sven Schreiber:
<hansl>
matrix m = {0.5}
eval typename(m) # matrix
b = _(hu=m)
eval typename(b.hu) # scalar
</hansl>
So the mere copy of the object changes its type here. (Also happens
outside of a bundle, but there you can force the type more easily.)
OK, so the only way I'm seeing to force and preserve the matrix type is
via a pre-created bundle and then a separate copy, and then even without
explict type declarations:
<hansl>
clear
bundle B
m = {0.5}
B.m2 = m
eval typename(B.m2) # matrix
</hansl>
thanks
sven
7:12 p.m.
On Mon, Nov 4, 2024 at 6:39 PM Sven Schreiber
<sven.schreiber(a)fu-berlin.de> wrote:
I have been struggling with this unexpected behavior:
<hansl>
matrix m = {0.5}
eval typename(m) # matrix
b = _(hu=m)
eval typename(b.hu) # scalar
</hansl>
So the mere copy of the object changes its type here. (Also happens
outside of a bundle, but there you can force the type more easily.) I
don't think that should happen.
What exactly caused you to struggle? It's expected behavior in gretl
that a 1 x 1 matrix "decays" to a scalar outside of "genr" unless you
prevent that, but the idea is that a scalar ought to be usable as a 1
x 1 matrix if required. If you wanted to do something with b.hu that
was not allowed on account of it not being a matrix I think that would
be a bug. (Hmm, maybe trying for m[1,1]?)
However, you can ensure that m (1 x 1) maintains its matrix type
inside a bundle:
matrix m = {0.5}
bundle b = _()
matrix b.hu = m
eval typename(b.hu) # matrix
Allin
7:15 p.m.
Am 05.11.2024 um 01:12 schrieb Cottrell, Allin:
On Mon, Nov 4, 2024 at 6:39 PM Sven Schreiber
<sven.schreiber(a)fu-berlin.de> wrote:
What exactly caused you to struggle? It's expected behavior in gretl
that a 1 x 1 matrix "decays" to a scalar outside of "genr" unless
you
prevent that, but the idea is that a scalar ought to be usable as a 1
x 1 matrix if required. If you wanted to do something with b.hu that
was not allowed on account of it not being a matrix I think that would
be a bug. (Hmm, maybe trying for m[1,1]?)
I had added rowname(s) when the object
was still a matrix, and that was
lost. I noticed especially when I tried rnameget() on the bundle member
and got an error because it became a scalar in the meantime.
However, you can ensure that m (1 x 1) maintains its matrix type
inside a bundle:
matrix m = {0.5}
bundle b = _()
matrix b.hu = m
eval typename(b.hu) # matrix
Right, see my other message, that's the workaround I used in the end.
thanks
sven
11:06 a.m.
On Mon, Nov 4, 2024 at 7:07 PM Sven Schreiber
<sven.schreiber(a)fu-berlin.de> wrote:
Am 05.11.2024 um 00:38 schrieb Sven Schreiber:
> <hansl>
> matrix m = {0.5}
> eval typename(m) # matrix
> b = _(hu=m)
> eval typename(b.hu) # scalar
> </hansl>
>
> So the mere copy of the object changes its type here. (Also happens
> outside of a bundle, but there you can force the type more easily.)
OK, so the only way I'm seeing to force and preserve the matrix type is
via a pre-created bundle and then a separate copy, and then even without
explicit type declarations:
<hansl>
clear
bundle B
m = {0.5}
B.m2 = m
eval typename(B.m2) # matrix
</hansl>
Hmm, the fact that we don't auto-convert a 1x1 matrix to scalar in
your second case, but we do when the matrix figures as an argument to
defbundle() / _() seems like a nasty inconsistency. In git I've
cancelled that conversion. I think this should be "safer", in that
there are probably more contexts where a scalar can't do the job of a
matrix than vice versa (even though we've tried to minimize such
discrepancies). But we need to watch out for any unwanted side
effects.
Allin
12:32 p.m.
Am 05.11.2024 um 17:06 schrieb Cottrell, Allin:
Hmm, the fact that we don't auto-convert a 1x1 matrix to scalar
in
your second case, but we do when the matrix figures as an argument to
defbundle() / _() seems like a nasty inconsistency. In git I've
cancelled that conversion. I think this should be "safer", in that
there are probably more contexts where a scalar can't do the job of a
matrix than vice versa (even though we've tried to minimize such
discrepancies). But we need to watch out for any unwanted side
effects.
Thanks, Allin. Actually I encountered another scenario where this change
is welcome: In the context of the bcheck() function, when you give as
one member of "target" a 1x1-matrix as a default value, which then
apparently is auto-converted to a scalar, and then bcheck() complains
that the user input is a vector and thus allegedly of the wrong type.
cheers
sven
11
days inactive
13
days old
5 comments
2 participants
participants (2)
-
Cottrell, Allin -
Sven Schreiber