5:01 p.m.
Hi,
I get errors with lines such as these:
b.mS = b.mYS * b.S'
that go away when I write this instead:
b.mS = b.mYS * transp(b.S)
(Here "b" is a bundle and the elements are matrices.)
This is with the latest snapshot on Windows. There are several funny
things about this:
First I (think I) had run this code several weeks ago without errors,
but I have to admit I cannot reproduce with which gretl version that
would have worked. In any case I think we discussed before that the
transposition/apostrophe operator should be legal in this case.
Secondly these code lines are inside an if-block where the condition
fails, so they are not executed; is it normal that the gretl interpreter
also checks these code parts?
thanks,
sven
5:36 p.m.
On Tue, 15 Mar 2016, Sven Schreiber wrote:
Hi,
I get errors with lines such as these:
b.mS = b.mYS * b.S'
that go away when I write this instead:
b.mS = b.mYS * transp(b.S)
(Here "b" is a bundle and the elements are matrices.)
I suspect there's some unrelated error in the embedding script, or
perhaps the embedding script triggers a basically unrelated bug, that
is messing things up. In a simple, minimal context the above works
fine, as in
<hansl>
bundle b
b.myS = ones(3,2)
b.S = ones(3,2)
b.mS = b.myS * b.S'
printf "\n%4d\n", b.mS
</hansl>
which works just as expected.
This is with the latest snapshot on Windows. There are several funny
things
about this:
First I (think I) had run this code several weeks ago without errors, but I
have to admit I cannot reproduce with which gretl version that would have
worked. In any case I think we discussed before that the
transposition/apostrophe operator should be legal in this case.
It should be, yes. Seems to me it is.
Secondly these code lines are inside an if-block where the condition
fails, so they are not executed; is it normal that the gretl
interpreter also checks these code parts?
No, you have something very odd going on. If I modify the little
script above thus:
<hansl>
bundle b
b.myS = ones(3,2) * undef
b.S = ones(3,2)
b.mS = b.myS * b.S'
</hansl>
then naturally it fails with the error message "The symbol 'undef' is
undefined". However, the following
<hansl>
bundle b
if 0
b.myS = ones(3,2) * undef
b.S = ones(3,2)
b.mS = b.myS * b.S'
endif
</hansl>
runs OK, because the use of "undef" is not reached.
Allin
5:51 p.m.
On Tue, 15 Mar 2016, Sven Schreiber wrote:
I get errors with lines such as these:
b.mS = b.mYS * b.S'
One more thought: are you sure there's no non-ASCII junk in the
script? For a gretl script the unix "file" command should say either
filename: ASCII text
or
filename: UTF-8 Unicode text
(non-ASCII UTF-8 characters are permitted, but only within string
literals or comments, so getting the second result does not
necessarily mean the script is "clean").
Allin
9:15 p.m.
Am 15.03.2016 um 18:51 schrieb Allin Cottrell:
On Tue, 15 Mar 2016, Sven Schreiber wrote:
> I get errors with lines such as these:
>
> b.mS = b.mYS * b.S'
One more thought: are you sure there's no non-ASCII junk in the script?
I don't think so, but see for yourself, I managed to strip the thing
down to this:
<hansl>
function void heyhey (void)
if 0
print "we shouldn't get here if jack==0"
matrix ba.V = ba.U' # does not cause error
genr bb.V = bb.U' # does not cause error
bc.V = transp(bc.U) # does not cause error
boo.V = boo.U' # but this does
endif
print "we probably don't get here because of the error"
end function
heyhey()
</hansl>
Ok, I admit I didn't mention before it seems to have to do with function
calls...
Curious what you will find!
cheers,
sven
9:27 p.m.
On Tue, 15 Mar 2016, Sven Schreiber wrote:
Am 15.03.2016 um 18:51 schrieb Allin Cottrell:
> On Tue, 15 Mar 2016, Sven Schreiber wrote:
>
>> I get errors with lines such as these:
>>
>> b.mS = b.mYS * b.S'
>
> One more thought: are you sure there's no non-ASCII junk in the script?
I don't think so, but see for yourself, I managed to strip the thing down to
this:
<hansl>
function void heyhey (void)
if 0
print "we shouldn't get here if jack==0"
matrix ba.V = ba.U' # does not cause error
genr bb.V = bb.U' # does not cause error
bc.V = transp(bc.U) # does not cause error
boo.V = boo.U' # but this does
endif
print "we probably don't get here because of the error"
end function
heyhey()
</hansl>
Ok, I admit I didn't mention before it seems to have to do with function
calls...
Curious what you will find!
Well, dang me: "Unexpected symbol '''".
Time to put on my bug-hunting boots.
Allin
10:14 p.m.
On Tue, 15 Mar 2016, Sven Schreiber wrote:
<hansl>
function void heyhey (void)
if 0
print "we shouldn't get here if jack==0"
matrix ba.V = ba.U' # does not cause error
genr bb.V = bb.U' # does not cause error
bc.V = transp(bc.U) # does not cause error
boo.V = boo.U' # but this does
endif
print "we probably don't get here because of the error"
end function
heyhey()
</hansl>
Ok, I admit I didn't mention before it seems to have to do with
function calls...
Actually, putting the relevant code inside a function is not
necessary to trigger this bug. Here's the minimal "offending"
script:
<hansl>
if 0
b.V = b.U'
endif
</hansl>
When execution is masked by "if <false condition>" we still have to
do _some_ parsing of the statements, to discover if we've hit an
"else", "elif" or "endif". But the way things stand,
we're taking
that parsing too far. A fix will not be long in coming, but I need
to figure the best way of preventing the parsing from going too
deep.
Allin
8:49 a.m.
Am 15.03.2016 um 23:14 schrieb Allin Cottrell:
When execution is masked by "if <false condition>" we still have to do
_some_ parsing of the statements, to discover if we've hit an "else",
"elif" or "endif". But the way things stand, we're taking that
parsing
too far.
Now I also understand why I didn't see this bug before, because I had
been running the code with the if-switch on instead of off.
In any case I'm happy that (since version 2016a?) I can put my "matrix"
keyword before the assignment of bundle members, it's really much better
style, readability and apart from avoiding subtle user bugs, in this
case it also is a workaround for this particular bug.
thanks,
sven
11:35 p.m.
On Wed, 16 Mar 2016, Sven Schreiber wrote:
Am 15.03.2016 um 23:14 schrieb Allin Cottrell:
>
> When execution is masked by "if <false condition>" we still have to
do
> _some_ parsing of the statements, to discover if we've hit an "else",
> "elif" or "endif". But the way things stand, we're taking
that parsing
> too far.
Now I also understand why I didn't see this bug before, because I had been
running the code with the if-switch on instead of off.
In any case I'm happy that (since version 2016a?) I can put my "matrix"
keyword before the assignment of bundle members, it's really much better
style, readability and apart from avoiding subtle user bugs, in this case it
also is a workaround for this particular bug.
Yes, that's right. Meanwhile, I believe the bug in question is fixed
in current git and snapshots. Since I'm thinking that we should put
out a new release soon, I'd be grateful if people could try running
their favorite scripts and report on any problems.
Allin
3516
days inactive
3517
days old
7 comments
2 participants
participants (2)
-
Allin Cottrell -
Sven Schreiber