7:12 p.m.
Hi,
I can copy an array to a bundle, but cannot create it there right away.
This time I'm not sure whether it's a bug...
<hansl>
bundle bc = null
strings s = array(3)
strings bc.s = s
strings bc.s2 = array(2) # this fails
</hansl>
(Also fails with matrices array.)
thanks,
sven
9:56 p.m.
On Tue, 22 Nov 2016, Sven Schreiber wrote:
Hi,
I can copy an array to a bundle, but cannot create it there right away. This
time I'm not sure whether it's a bug...
<hansl>
bundle bc = null
strings s = array(3)
strings bc.s = s
strings bc.s2 = array(2) # this fails
</hansl>
(Also fails with matrices array.)
One might say it's a missing feature, but I would say it's a bug.
Now fixed in git.
Allin
10:10 p.m.
On Tue, 22 Nov 2016, Allin Cottrell wrote:
On Tue, 22 Nov 2016, Sven Schreiber wrote:
> Hi,
> I can copy an array to a bundle, but cannot create it there right away.
> This time I'm not sure whether it's a bug...
>
> <hansl>
> bundle bc = null
> strings s = array(3)
> strings bc.s = s
>
> strings bc.s2 = array(2) # this fails
> </hansl>
>
> (Also fails with matrices array.)
One might say it's a missing feature, but I would say it's a bug. Now fixed
in git.
Another comment on this. At this point we don't support arbitrary
nesting of types on the left-hand side of an assignment, as in
assign a certain value to an element of a matrix, in an array of
matrices, in a bundle, in an array of bundles, ...
This is no doubt something for aim for, though it will take some
thought and careful redesign. However, even now we should support
at least one level of nesting, which is why I'm ready to acknowledge
the failure above as a bug.
Allin
5:34 p.m.
Am 22.11.2016 um 23:10 schrieb Allin Cottrell:
This is no doubt something for aim for, though it will take some
thought
and careful redesign. However, even now we should support at least one
level of nesting, which is why I'm ready to acknowledge the failure
above as a bug.
Thanks, and here's something that might be related:
<hansl>
matrix m1 = ones(3,1)
m1[,1] = m1[,1] + 3
matrices mm = defarray(ones(3,1))
mm[1][,1] = mm[1][,1] + 5 # fails
</hansl>
However, I'm probably one snapshot behind, so this might have been fixed
by your latest changes. Or it might count as second-level-nesting.
cheers,
sven
6:48 p.m.
On Wed, 23 Nov 2016, Sven Schreiber wrote:
Am 22.11.2016 um 23:10 schrieb Allin Cottrell:
> This is no doubt something for aim for, though it will take some thought
> and careful redesign. However, even now we should support at least one
> level of nesting, which is why I'm ready to acknowledge the failure
> above as a bug.
Thanks, and here's something that might be related:
<hansl>
matrix m1 = ones(3,1)
m1[,1] = m1[,1] + 3
matrices mm = defarray(ones(3,1))
mm[1][,1] = mm[1][,1] + 5 # fails
</hansl>
However, I'm probably one snapshot behind, so this might have been fixed by
your latest changes. Or it might count as second-level-nesting.
I don't think you're behind in any relevant respect; and I'd be
inclined to call this second-level nesting. It would be nice to have
it working, but rather than coming up with a customized hack to
support this particular syntax, I'd rather wait until we're able to
support more general recursion of the member-of relation on the
left.
It seems to me that this is inherently more difficult than arbitrary
recursion on the right. On the right, it's just a matter of
retrieval, while on the left we have to worry about a possible chain
of modification of objects (although in this particular case there's
no chain, since replacing an element of a matrix doesn't change the
memory address of the matrix, and hence doesn't start any "ripple
effect").
Allin
2937
days inactive
2938
days old
4 comments
2 participants
participants (2)
-
Allin Cottrell -
Sven Schreiber