3:13 p.m.
Dear all, Is there a possibility to set defaults values for matrix input vars for hansl
user-written functions? If no, Is there a chance for it to go into the wishlist? Oleh
7:07 p.m.
Am 18.12.2015 um 16:13 schrieb oleg_komashko(a)ukr.net:
Dear all,
Is there a possibility to set
defaults values for matrix input vars
for hansl user-written functions?
If no, Is there a chance for it to go
into the wishlist?
If you want to use a default matrix content, make "null" the default
value in the argument and set the matrix to your wanted default inside
the function, after checking with exists() or isnull() or whatever.
cheers,
sven
7:15 p.m.
Dear Sven, I have tried function void mmaa (matrix m[null])
x=1
print x
end function
and got Syntax error
My git is outdated by ~5 day's In fact, this is why I asked it on the list Oleh
18 грудня 2015, 21:07:33, від "Sven Schreiber" < svetosch(a)gmx.net >:
Am 18.12.2015 um 16:13 schrieb oleg_komashko(a)ukr.net :
Dear all,
Is there a possibility to set
defaults values for matrix input vars
for hansl user-written functions?
If no, Is there a chance for it to go
into the wishlist?
If you want to use a default matrix content, make "null" the default
value in the argument and set the matrix to your wanted default inside
the function, after checking with exists() or isnull() or whatever.
cheers,
sven
_______________________________________________
Gretl-devel mailing list
Gretl-devel(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-devel
7:18 p.m.
Am 18.12.2015 um 20:15 schrieb oleg_komashko(a)ukr.net:
Dear Sven,
I have tried
function void mmaa (matrix m[null])
x=1
print x
end function
and got
Syntax error
IIRC this only works in pointer form: matrix *m[null]
I don't know (or remember) why, but at least it's in the manual I think.
cheers,
sven
7:37 p.m.
Thank you, Sven It works with *matrices. Unfortunately, it seems, there are no (yet?)
defaults for [usual] matrices. Of course, it has a way around, but many function calls in
many situations would have looked much shorter Oleh
18 грудня 2015, 21:18:44, від "Sven Schreiber" < svetosch(a)gmx.net >:
Am 18.12.2015 um 20:15 schrieb oleg_komashko(a)ukr.net :
Dear Sven,
I have tried
function void mmaa (matrix m[null])
x=1
print x
end function
and got
Syntax error
IIRC this only works in pointer form: matrix *m[null]
I don't know (or remember) why, but at least it's in the manual I think.
cheers,
sven
_______________________________________________
Gretl-devel mailing list
Gretl-devel(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-devel
8:59 p.m.
On Fri, 18 Dec 2015, oleg_komashko(a)ukr.net wrote:
Thank you, Sven It works with *matrices. Unfortunately, it seems,
there are no (yet?) defaults for [usual] matrices. Of course, it
has a way around, but many function calls in many situations would
have looked much shorter
Can you give us an idea of contexts in which you'd like to be able
to define a default matrix argument, and where the pointer form is
somehow unsuitable?
Allin
9:04 a.m.
Dear Allin, Of course, I may be wrong, but I think like that: 1) *matrices are certainly
better for big matrices, e.g. quantiles for surface responses 2) for small matrices,
it's a matter of convenience for an user: with *matrices we can't input
fun({1,2,3},...)
only b = {1,2,3} fun(&b,....) 3) Of course I can't make cost-benefit analysis,
since costs in coding time is not on me
Oleh
18 грудня 2015, 23:00:00, від "Allin Cottrell" < cottrell(a)wfu.edu >:
On Fri, 18 Dec 2015, oleg_komashko(a)ukr.net wrote:
Thank you, Sven It works with *matrices. Unfortunately, it seems,
there are no (yet?) defaults for [usual] matrices. Of course, it
has a way around, but many function calls in many situations would
have looked much shorter
Can you give us an idea of contexts in which you'd like to be able
to define a default matrix argument, and where the pointer form is
somehow unsuitable?
Allin
_______________________________________________
Gretl-devel mailing list
Gretl-devel(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-devel
3:43 p.m.
On Sat, 19 Dec 2015, oleg_komashko(a)ukr.net wrote:
Dear Allin, Of course, I may be wrong, but I think like that: 1)
*matrices are certainly better for big matrices, e.g. quantiles
for surface responses 2) for small matrices, it's a matter of
convenience for an user: with *matrices we can't input
fun({1,2,3},...)
only
b = {1,2,3}
fun(&b,....)
OK, I take your point. I suppose we could enable a default of "null"
for non-pointer matrix arguments, though I think it might be more in
keeping with our type system to enable "{}" instead.
Allin
3:20 p.m.
Am 18.12.2015 um 21:59 schrieb Allin Cottrell:
On Fri, 18 Dec 2015, oleg_komashko(a)ukr.net wrote:
> Thank you, Sven It works with *matrices. Unfortunately, it seems,
> there are no (yet?) defaults for [usual] matrices. Of course, it has a
> way around, but many function calls in many situations would have
> looked much shorter
Can you give us an idea of contexts in which you'd like to be able to
define a default matrix argument, and where the pointer form is somehow
unsuitable?
While personally I'm not much concerned with a default matrix, I would
like to use this discussion to ask about the necessity of the pointer
form for marking the argument optional. And it may well be that it has
been discussed before.
To be concrete, why would it be problematic to have something like this:
<hansl-not-correct-right-now>
function void example(matrix m[null])
if !isnull(m)
print m
endif
end function
example(I(3))
</hansl-not-correct-right-now>
Changing the function signature to "matrix *m[null]" is easy enough, but
then of course you need an extra line before the call:
marg = I(3)
example(&marg)
Basically it's this extra and kind of unnecessary line that is bothering
me (and Oleh I guess) because it "contaminates" the script.
thanks,
sven
3:33 p.m.
Isn't this more a question of scope? If the pointer from is mandatory, then the
variable is forced to have a larger scope then perhaps the script writer intends? Not that
a poiter doesn't have advantages, but why should the compiler force a larger scope?
That seems in conflict with the argument against global variables.
Sent from Outlook Mobile<https://aka.ms/blhgte>
On Sat, Dec 19, 2015 at 7:21 AM -0800, "Sven Schreiber"
<svetosch@gmx.net<mailto:svetosch@gmx.net>> wrote:
Am 18.12.2015 um 21:59 schrieb Allin Cottrell:
On Fri, 18 Dec 2015, oleg_komashko(a)ukr.net wrote:
> Thank you, Sven It works with *matrices. Unfortunately, it seems,
> there are no (yet?) defaults for [usual] matrices. Of course, it has a
> way around, but many function calls in many situations would have
> looked much shorter
Can you give us an idea of contexts in which you'd like to be able to
define a default matrix argument, and where the pointer form is somehow
unsuitable?
While personally I'm not much concerned with a default matrix, I would
like to use this discussion to ask about the necessity of the pointer
form for marking the argument optional. And it may well be that it has
been discussed before.
To be concrete, why would it be problematic to have something like this:
<hansl-not-correct-right-now>
function void example(matrix m[null])
if !isnull(m)
print m
endif
end function
example(I(3))
</hansl-not-correct-right-now>
Changing the function signature to "matrix *m[null]" is easy enough, but
then of course you need an extra line before the call:
marg = I(3)
example(&marg)
Basically it's this extra and kind of unnecessary line that is bothering
me (and Oleh I guess) because it "contaminates" the script.
thanks,
sven
_______________________________________________
Gretl-devel mailing list
Gretl-devel(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-devel
3:39 p.m.
Am 19.12.2015 um 16:33 schrieb Logan Kelly:
Isn't this more a question of scope? If the pointer from is
mandatory,
then the variable is forced to have a larger scope then perhaps the
script writer intends? Not that a poiter doesn't have advantages, but
why should the compiler force a larger scope? That seems in conflict
with the argument against global variables.
No I don't think so. The names of the variables are in general different
inside and outside of the function, even though in pointer form they
point to the same memory. You could also do "delete marg" right after
completing the function call if you want to free that chunk of memory (I
think). Which adds yet another line of code of course, which is my main
mini-worry.
cheers,
sven
3:53 p.m.
Sven,
I don't follow you. In pointer form, the function can change the value of the variable
in the larger scope. Protecting the value of the variable in the larger scope is the only
reason I'm aware of for not always using pointer as the are much faster.
Please don't take my response as antagonistic. I may be misunderstanding the point of
scoping?
Cheers,
Logan
Sent from Outlook Mobile<https://aka.ms/blhgte>
From: Sven Schreiber
Sent: Saturday, December 19, 9:39 AM
Subject: Re: [Gretl-devel] default values for matrices?
To: Gretl development
Am 19.12.2015 um 16:33 schrieb Logan Kelly: > Isn't this more a question of scope?
If the pointer from is mandatory, > then the variable is forced to have a larger scope
then perhaps the > script writer intends? Not that a poiter doesn't have
advantages, but > why should the compiler force a larger scope? That seems in conflict
> with the argument against global variables. > No I don't think so. The names
of the variables are in general different inside and outside of the function, even though
in pointer form they point to the same memory. You could also do "delete marg"
right after completing the function call if you want to free that chunk of memory (I
think). Which adds yet another line of code of course, which is my main mini-worry.
cheers, sven _______________________________________________ Gretl-devel mailing list
Gretl-devel(a)lists.wfu.edu http://lists.wfu.edu/mailman/listinfo/gretl-devel
4:54 p.m.
Dear Sven, You got the point of my second message absolutely exactly! Oleh
19 грудня 2015, 17:21:08, від "Sven Schreiber" < svetosch(a)gmx.net >:
Am 18.12.2015 um 21:59 schrieb Allin Cottrell:
On Fri, 18 Dec 2015, oleg_komashko(a)ukr.net wrote:
> Thank you, Sven It works with *matrices. Unfortunately, it seems,
> there are no (yet?) defaults for [usual] matrices. Of course, it has a
> way around, but many function calls in many situations would have
> looked much shorter
Can you give us an idea of contexts in which you'd like to be able to
define a default matrix argument, and where the pointer form is somehow
unsuitable?
While personally I'm not much concerned with a default matrix, I would
like to use this discussion to ask about the necessity of the pointer
form for marking the argument optional. And it may well be that it has
been discussed before.
To be concrete, why would it be problematic to have something like this:
<hansl-not-correct-right-now>
function void example(matrix m[null])
if !isnull(m)
print m
endif
end function
example(I(3))
</hansl-not-correct-right-now>
Changing the function signature to "matrix *m[null]" is easy enough, but
then of course you need an extra line before the call:
marg = I(3)
example(&marg)
Basically it's this extra and kind of unnecessary line that is bothering
me (and Oleh I guess) because it "contaminates" the script.
thanks,
sven
_______________________________________________
Gretl-devel mailing list
Gretl-devel(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-devel
3292
days inactive
3293
days old
12 comments
4 participants
participants (4)
-
Allin Cottrell -
Logan Kelly -
oleg_komashko＠ukr.net -
Sven Schreiber