7:02 a.m.
Hi,
in the GUI it is easy to get a plot of estimated VAR residuals.
But it seems surprisingly difficult to do the same thing via scripting.
I can save the residuals by $uhat, but that gives me a matrix (not a
variable list), and converting the columns in that matrix to series
fails because of length mismatch.
I know I _could_ adjust the workfile sample to match the effective
sample of the VAR and then the conversion to series would work, but that
feels quite clumsy. (And have to reset the workfile sample afterwards.)
Any recommendations how to achieve that quick and easy?
thanks
sven
10:32 a.m.
On Fri, 23 Aug 2019, Sven Schreiber wrote:
Hi,
in the GUI it is easy to get a plot of estimated VAR residuals.
But it seems surprisingly difficult to do the same thing via scripting.
I can save the residuals by $uhat, but that gives me a matrix (not a
variable list), and converting the columns in that matrix to series
fails because of length mismatch.
I know I _could_ adjust the workfile sample to match the effective
sample of the VAR and then the conversion to series would work, but that
feels quite clumsy. (And have to reset the workfile sample afterwards.)
Any recommendations how to achieve that quick and easy?
This should do it:
<hansl>
set verbose off
open denmark.gdt --quiet
list X = LRM LRY IBO IDE
var 4 X --silent
matrix U = $uhat
cnameset(U, varnames(X))
gnuplot --matrix=U --with-lines --time-series --output=display
</hansl>
this could be made nicer with a column for time; unfortunately, I can't
think of any easy automatic way to construct this, other than introducing
a couple of new functions to retrieve the "t1" and "t2" integers that
are
contained in the matrix info.
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
10:49 a.m.
On Fri, 23 Aug 2019, Riccardo (Jack) Lucchetti wrote:
On Fri, 23 Aug 2019, Sven Schreiber wrote:
> Hi,
>
> in the GUI it is easy to get a plot of estimated VAR residuals.
> But it seems surprisingly difficult to do the same thing via scripting.
> I can save the residuals by $uhat, but that gives me a matrix (not a
> variable list), and converting the columns in that matrix to series
> fails because of length mismatch.
>
> I know I _could_ adjust the workfile sample to match the effective
> sample of the VAR and then the conversion to series would work, but that
> feels quite clumsy. (And have to reset the workfile sample afterwards.)
>
> Any recommendations how to achieve that quick and easy?
This should do it:
<hansl>
set verbose off
open denmark.gdt --quiet
list X = LRM LRY IBO IDE
var 4 X --silent
matrix U = $uhat
cnameset(U, varnames(X))
gnuplot --matrix=U --with-lines --time-series --output=display
</hansl>
this could be made nicer with a column for time; unfortunately, I can't think
of any easy automatic way to construct this, other than introducing a couple
of new functions to retrieve the "t1" and "t2" integers that are
contained in
the matrix info.
Or perhaps, something like this (but it's not pretty)
<hansl>
set verbose off
open AWM18.gdt --quiet
list Y = YER PCR GCR ITR
list X = logs(Y)
scalar p = 4
var p X --silent --seasonals
tt = seq(0, $t2 - $t1 - p)/$pd
t0 = $obsmajor[$t1+p-1] + $obsminor[$t1+p-1]/$pd
tt = t0' + tt'
matrix U = $uhat ~ tt
cnameset(U, varnames(X)+ defarray("Time"))
gnuplot --matrix=U --with-lines --output=display
</hansl>
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
11:14 a.m.
On 23.08.19 12:49, Riccardo (Jack) Lucchetti wrote:
On Fri, 23 Aug 2019, Riccardo (Jack) Lucchetti wrote:
> On Fri, 23 Aug 2019, Sven Schreiber wrote:
>>
>> Any recommendations how to achieve that quick and easy?
>
> This should do it:
>
> <hansl>
> set verbose off
> open denmark.gdt --quiet
> list X = LRM LRY IBO IDE
> var 4 X --silent
> matrix U = $uhat
> cnameset(U, varnames(X))
> gnuplot --matrix=U --with-lines --time-series --output=display
> </hansl>
>
> this could be made nicer with a column for time; unfortunately, I
> can't think of any easy automatic way to construct this, other than
> introducing a couple of new functions to retrieve the "t1" and
"t2"
> integers that are contained in the matrix info.
OK now that Allin has fixed the $system.t1 (and t2) bug, we can get
those numbers. However, it's not clear to me how these can be used to
get the associated time period labels showing up on the x-axis. (Side
question: How to inject such t1 and t2 info into an existing matrix?)
Obviously you get the time labeling for free if you work with series and
lists. So here's a little function that does it that way. (Current git
is needed because of the bug fixed just recently.)
<hansl>
function void plotsysres(bundle sys)
start = sys.t1 # requires 2019d / current git
stop = sys.t2
smpl start stop
strings nn = varnames(sys.ylist)
list L
loop i=1..cols(sys.uhat) -q
L += genseries(nn[i], sys.uhat[,i])
endloop
gnuplot L --with-lines --time-series --output=display
end function
open denmark.gdt --quiet
list X = LRM LRY IBO IDE
var 4 X --silent
plotsysres($system)
</hansl>
But I repeat, all this is quite clumsy IMHO. My proposal would be that
the data in $uhat (or $system.uhat) should also be retrievable as a
list, with automatic names in the pattern <var1>_res or something like
that, similar to how lags and differences and other pre-defined name
patterns are handled.
thanks
sven
12:30 p.m.
On Mon, 26 Aug 2019, Sven S wrote:
But I repeat, all this is quite clumsy IMHO.
I agree.
My proposal would be that the data in $uhat (or $system.uhat) should
also be retrievable as a list, with automatic names in the pattern
<var1>_res or something like that, similar to how lags and differences
and other pre-defined name patterns are handled.
I have another idea: at present, we allow
<hansl>
series x = matrix
</hansl>
provided the matrix in question has the right number of rows and one
column. In many cases, it'd be very useful to have a parallel
"multivariate" construct, such as
<pseudo-hansl>
list X = matrix
</pseudo-hansl>
which would generate the series X_01, X_02, etc (of course, if
rows(matrix) == $nobs). The identifiers could be taken from the column
labels, if present, or the list name by default as in my example. This
would be quite handy, I think.
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
1:18 p.m.
On 26.08.19 14:30, Riccardo (Jack) Lucchetti wrote:
provided the matrix in question has the right number of rows and one
column. In many cases, it'd be very useful to have a parallel
"multivariate" construct, such as
<pseudo-hansl>
list X = matrix
</pseudo-hansl>
which would generate the series X_01, X_02, etc (of course, if
rows(matrix) == $nobs). The identifiers could be taken from the column
labels, if present, or the list name by default as in my example. This
would be quite handy, I think.
In principle I like the idea. However, in the case of residuals in
dynamic equations typically rows(mat) != $nobs. So it seems to me this
wouldn't solve the present use case.
Perhaps the t1 and t2 infos of the matrix could be used to align the
generated series properly. Which also brings me back to the question how
to inject this information into a matrix.
(BTW, we're essentially trying to create a synthesis of matrix and list
here it seems to me. In a sense we're trying to emulate something like
dataframes...)
cheers
sven
1:43 p.m.
On Mon, 26 Aug 2019, Sven S wrote:
On 26.08.19 14:30, Riccardo (Jack) Lucchetti wrote:
> provided the matrix in question has the right number of rows and one
> column. In many cases, it'd be very useful to have a parallel
> "multivariate" construct, such as
>
> <pseudo-hansl>
> list X = matrix
> </pseudo-hansl>
>
> which would generate the series X_01, X_02, etc (of course, if
> rows(matrix) == $nobs). The identifiers could be taken from the column
> labels, if present, or the list name by default as in my example. This
> would be quite handy, I think.
In principle I like the idea. However, in the case of residuals in
dynamic equations typically rows(mat) != $nobs. So it seems to me this
wouldn't solve the present use case.
Perhaps the t1 and t2 infos of the matrix could be used to align the
generated series properly.
This is an excellent idea.
Which also brings me back to the question how to inject this
information
into a matrix.
Having a dedicated function like cnameset() would make perfect sense to
me. limitset(), perhaps, or something like that?
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
1:55 p.m.
On 26.08.19 15:43, Riccardo (Jack) Lucchetti wrote:
On Mon, 26 Aug 2019, Sven S wrote:
> Which also brings me back to the question how to inject this
> information into a matrix.
Having a dedicated function like cnameset() would make perfect sense
to me. limitset(), perhaps, or something like that?
Either that, or since we have the convention that time periods in a
matrix will be in rows, perhaps exend the existing rnameset() function?
In any case, extending rnameget() would also be useful then: If the rows
of a matrix refer to time periods, I would guess that no proper "names"
will ever be specified. So using rnameget(M) on a matrix M which has the
t1 and t2 info set (and no other rownames) could give an array of
strings with the associated time period labels, e.g. from "1974Q1",
"1974Q2", through "1990Q4" or whatever.
thanks
sven
2:30 p.m.
On Mon, 26 Aug 2019, Sven S wrote:
On 26.08.19 14:30, Riccardo (Jack) Lucchetti wrote:
> provided the matrix in question has the right number of rows and one
> column. In many cases, it'd be very useful to have a parallel
> "multivariate" construct, such as
>
> <pseudo-hansl>
> list X = matrix
> </pseudo-hansl>
>
> which would generate the series X_01, X_02, etc (of course, if
> rows(matrix) == $nobs). The identifiers could be taken from the column
> labels, if present, or the list name by default as in my example. This
> would be quite handy, I think.
In principle I like the idea. However, in the case of residuals in
dynamic equations typically rows(mat) != $nobs. So it seems to me this
wouldn't solve the present use case.
Perhaps the t1 and t2 infos of the matrix could be used to align the
generated series properly.
Yes, that's what happens in the single-series case and it would be
natural to do it for the list case too.
Which also brings me back to the question how to inject this
information into a matrix.
Sorry, I haven't been following this very closely, but what's the case
where you'd need to inject such information (I mean, where it wouldn't
already be attached by gretl)?
Allin
2:55 p.m.
On Mon, 26 Aug 2019, Allin Cottrell wrote:
Sorry, I haven't been following this very closely, but what's
the case
where you'd need to inject such information (I mean, where it wouldn't
already be attached by gretl)?
Well, suppose you want to inject a matrix with 98 rows you created somehow
into a 100-obs dataset, leaving the first and last observations missing.
Now you can use either "smpl 2 99" and do a "smpl full" afterwards, or
perhaps also something like "matrix X = NA | X | NA", but it'd also be
cool to have the opportunity of using something like "limitset(X, 2, 99)".
At least, that's what I had in mind.
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
5:54 p.m.
Am 26.08.2019 um 16:55 schrieb Riccardo (Jack) Lucchetti:
On Mon, 26 Aug 2019, Allin Cottrell wrote:
> Sorry, I haven't been following this very closely, but what's the case
> where you'd need to inject such information (I mean, where it wouldn't
> already be attached by gretl)?
Well, suppose you want to inject a matrix with 98 rows you created
somehow into a 100-obs dataset, leaving the first and last observations
missing.
Now you can use either "smpl 2 99" and do a "smpl full" afterwards,
or
perhaps also something like "matrix X = NA | X | NA", but it'd also be
cool to have the opportunity of using something like "limitset(X, 2,
99)".
Yes; however, I have to admit that I had lost track of the fact that
$uhat already has the t1 and t2 infos, which was the original issue here.
cheers
sven
10:07 p.m.
On Mon, 26 Aug 2019, Sven Schreiber wrote:
Am 26.08.2019 um 16:55 schrieb Riccardo (Jack) Lucchetti:
> On Mon, 26 Aug 2019, Allin Cottrell wrote:
>
>> Sorry, I haven't been following this very closely, but what's the case
>> where you'd need to inject such information (I mean, where it wouldn't
>> already be attached by gretl)?
>
> Well, suppose you want to inject a matrix with 98 rows you created
> somehow into a 100-obs dataset, leaving the first and last observations
> missing.
>
> Now you can use either "smpl 2 99" and do a "smpl full"
afterwards, or
> perhaps also something like "matrix X = NA | X | NA", but it'd also be
> cool to have the opportunity of using something like "limitset(X, 2,
> 99)".
Yes; however, I have to admit that I had lost track of the fact that
$uhat already has the t1 and t2 infos, which was the original issue here.
OK, now I understand. Jack's "limitset()" idea might be cool but IMO
it's not a priority since smpl does the job OK. (Also, I'm not
totally enthusiastic about having m->t1 and m->t2 user-settable: one
more thing to worry about being possibly wrong!)
Allin
3:20 a.m.
On Mon, 26 Aug 2019, Riccardo (Jack) Lucchetti wrote:
I have another idea: at present, we allow
<hansl>
series x = matrix
</hansl>
provided the matrix in question has the right number of rows and one column.
In many cases, it'd be very useful to have a parallel "multivariate"
construct, such as
<pseudo-hansl>
list X = matrix
</pseudo-hansl>
which would generate the series X_01, X_02, etc (of course, if rows(matrix)
== $nobs). The identifiers could be taken from the column labels, if present,
or the list name by default as in my example. This would be quite handy, I
think.
I agree. But several policies have to be decided in the
implementation of this. Here's what's in current git on the
"newcomplex" branch.
1) As with other "genr" things, the current sample range is
respected in creating or modifying series: we will not write outside
of that range.
2) We have to able to match rows of the matrix to observations in
the dataset. We do this by using the t1 and t2 tags attached to the
matrix, if present (in which case it's an error if there's no
overlap between the matrix t1 to t2 range and the current sample
range). Otherwise we match if the number of rows equals the number
of observations (a) in the dataset as a whole or (b) in the current
sample range. Otherwise error.
3) We need valid series names. If the matrix has column names we use
them. It's then an error if any of them are not valid identifiers,
or if there are any duplicates among them. If the source matrix
doesn't have column names we use the name of the matrix itself (if
it's named), or failing that the name of the list to which the new
series are being assigned. We append column numbers for uniqueness
and it's an error if the matrix or list name is too long to
accomodate the suffix.
4) If any of the names thus constructed are names of existing
non-series objects, an error is flagged and no list is produced. If
any of them are names of pre-existing series, the original series
are over-written over the current sample range.
Allin
6:32 a.m.
Am 27.08.2019 um 05:20 schrieb Allin Cottrell:
On Mon, 26 Aug 2019, Riccardo (Jack) Lucchetti wrote:
>
> <pseudo-hansl>
> list X = matrix
> </pseudo-hansl>
>
> which would generate the series X_01, X_02, etc (of course, if
> rows(matrix) == $nobs). The identifiers could be taken from the column
> labels, if present, or the list name by default as in my example. This
> would be quite handy, I think.
I agree. But several policies have to be decided in the implementation
of this. Here's what's in current git on the "newcomplex" branch.
(As long as this is still fresh in your mind: Do you know which commits
are related to this? More than one? Perhaps other people -me- could
experiment with applying only those commits without the rest of the branch.)
...
This all sounds good. Just one question: What actually happens in
cross-section and panel datasets? Cross-section is not such a problem
because of no lags, but panel? Does t1 and t2 also exist there?
thanks
sven
1:34 p.m.
On Tue, 27 Aug 2019, Sven Schreiber wrote:
Am 27.08.2019 um 05:20 schrieb Allin Cottrell:
> On Mon, 26 Aug 2019, Riccardo (Jack) Lucchetti wrote:
> >
> > <pseudo-hansl>
> > list X = matrix
> > </pseudo-hansl>
> >
> > which would generate the series X_01, X_02, etc (of course, if
> > rows(matrix) == $nobs). The identifiers could be taken from the column
> > labels, if present, or the list name by default as in my example. This
> > would be quite handy, I think.
>
> I agree. But several policies have to be decided in the implementation
> of this. Here's what's in current git on the "newcomplex" branch.
(As long as this is still fresh in your mind: Do you know which commits
are related to this? More than one? Perhaps other people -me- could
experiment with applying only those commits without the rest of the branch.)
...
This all sounds good. Just one question: What actually happens in
cross-section and panel datasets? Cross-section is not such a problem
because of no lags, but panel? Does t1 and t2 also exist there?
Good question. I need to do a little investigation on the panel case.
Allin
1:37 p.m.
On Tue, 27 Aug 2019, Sven Schreiber wrote:
Am 27.08.2019 um 05:20 schrieb Allin Cottrell:
> On Mon, 26 Aug 2019, Riccardo (Jack) Lucchetti wrote:
> >
> > <pseudo-hansl>
> > list X = matrix
> > </pseudo-hansl>
> >
> > which would generate the series X_01, X_02, etc (of course, if
> > rows(matrix) == $nobs). The identifiers could be taken from the column
> > labels, if present, or the list name by default as in my example. This
> > would be quite handy, I think.
>
> I agree. But several policies have to be decided in the implementation
> of this. Here's what's in current git on the "newcomplex" branch.
(As long as this is still fresh in your mind: Do you know which commits
are related to this? More than one? Perhaps other people -me- could
experiment with applying only those commits without the rest of the branch.)
The relevant commits were
b17d7aebf03b548e8a024f692a7937281a3678d0
bc6a18041eca1fafda1ec186cf6e6850dbf0fc0f
8e1cbad8ad740a2bf0a00fd2b604efb5557c948f
But pretty soon newcomplex will be merged into master then retired.
Allin
11:12 p.m.
On Tue, 27 Aug 2019, Sven Schreiber wrote:
Am 27.08.2019 um 05:20 schrieb Allin Cottrell:
> On Mon, 26 Aug 2019, Riccardo (Jack) Lucchetti wrote:
>> <pseudo-hansl>
>> list X = matrix
>> </pseudo-hansl>
>>
>> which would generate the series X_01, X_02, etc (of course, if
>> rows(matrix) == $nobs). The identifiers could be taken from the column
>> labels, if present, or the list name by default as in my example. This
>> would be quite handy, I think.
>
> I agree. But several policies have to be decided in the implementation
> of this. Here's what's in current git on the "newcomplex" branch.
(As long as this is still fresh in your mind: Do you know which commits
are related to this? More than one? Perhaps other people -me- could
experiment with applying only those commits without the rest of the branch.)
...
This all sounds good. Just one question: What actually happens in
cross-section and panel datasets? Cross-section is not such a problem
because of no lags, but panel? Does t1 and t2 also exist there?
Yes, they do exist for panel data -- when estimation is performed
for a specification that involves multiple sets of residuals or
fitted values represented in matrix form, such as "system" -- but
they refer to starting and ending points that must line up with
"individuals", not to the time-series dimension as such.
It's good you raised this question: my testing on panel data
revealed a bug in the new code that I think would equally apply to
time-series data, namely an incorrect notion of what exactly the
matrix t1- and t2-values imply for alignment with dataset
observations. That's now fixed in git and snapshots. Test script
follows (please ignore the highly questionable system
specification!):
<hansl>
open nc_crime.gdt -q
smpl 5:1 50:7 # use a subset of counties
system method=OLS
equation crmrte 0 prbarr
equation prbarr 0 polpc
end system
U = $uhat
print U
list L = U
smpl full
# check alignment of system residuals
print L -o
</hansl>
Allin
6:15 a.m.
On Tue, 27 Aug 2019, Allin Cottrell wrote:
That's now fixed in git and snapshots. Test script follows
(please
ignore the highly questionable system specification!):
[...]
This is very nice, thanks Allin, but I must admit I'm getting a bit lost
here: to go back to the original point, I would have expected the
following to work (but it doesn't). What am I missing?
<hansl>
set verbose off
open denmark.gdt --quiet
list X = LRM LRY IBO IDE
var 4 X --silent
matrix U = $uhat
list L = U
</hansl>
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
12:04 p.m.
On Wed, 28 Aug 2019, Riccardo (Jack) Lucchetti wrote:
On Tue, 27 Aug 2019, Allin Cottrell wrote:
> That's now fixed in git and snapshots. Test script follows (please ignore
> the highly questionable system specification!):
[...]
This is very nice, thanks Allin, but I must admit I'm getting a bit lost here:
to go back to the original point, I would have expected the following to work
(but it doesn't). What am I missing?
<hansl>
set verbose off
open denmark.gdt --quiet
list X = LRM LRY IBO IDE
var 4 X --silent
matrix U = $uhat
list L = U
</hansl>
Yes, the above obviously ought to work. The bug that stopped it from
working is now fixed in git.
Allin
3:54 p.m.
Am 28.08.2019 um 01:12 schrieb Allin Cottrell:
On Tue, 27 Aug 2019, Sven Schreiber wrote:
> This all sounds good. Just one question: What actually happens
in
> cross-section and panel datasets? Cross-section is not such a problem
> because of no lags, but panel? Does t1 and t2 also exist there?
Yes, they do exist for panel data -- when estimation is performed for a
specification that involves multiple sets of residuals or fitted values
represented in matrix form, such as "system" -- but they refer to
starting and ending points that must line up with "individuals", not to
the time-series dimension as such.
I'm afraid I don't really understand this description.
In general I have to say that transferring terminology from the
time-series case to panel data and then partly changing the meaning has
confused me in the past. One example is this documentation snippet from
the setobs command:
"..In the case of panel data the periodicity means the number of lines
per data block: this corresponds to the number of cross-sectional units
in the case of stacked cross-sections..."
The good thing about this is that the documentation is clear and
complete. The downside is that I really wouldn't associate a term like
"periodicity" with number of countries or people.
cheers
sven
12:42 p.m.
Am 23.08.2019 um 12:32 schrieb Riccardo (Jack) Lucchetti:
this could be made nicer with a column for time; unfortunately, I
can't
think of any easy automatic way to construct this, other than
introducing a couple of new functions to retrieve the "t1" and "t2"
integers that are contained in the matrix info.
Good idea. But doesn't the following look like a off-by-one bug:
<hansl>
open denmark.gdt --quiet
list X = LRM LRY IBO IDE
var 4 X --silent
eval $system.t1 # 4
eval $system.t2 # 54
U = $uhat
print U # says t1=5, t2=55
</hansl>
thanks
sven
4:22 p.m.
On Fri, 23 Aug 2019, Sven Schreiber wrote:
Am 23.08.2019 um 12:32 schrieb Riccardo (Jack) Lucchetti:
> this could be made nicer with a column for time; unfortunately, I can't
> think of any easy automatic way to construct this, other than
> introducing a couple of new functions to retrieve the "t1" and
"t2"
> integers that are contained in the matrix info.
Good idea. But doesn't the following look like a off-by-one bug:
<hansl>
open denmark.gdt --quiet
list X = LRM LRY IBO IDE
var 4 X --silent
eval $system.t1 # 4
eval $system.t2 # 54
U = $uhat
print U # says t1=5, t2=55
</hansl>
Yes, it does. The $system t1 and t2 values are given "raw" (0-based),
but for consumption by users they should be adjusted to 1-based.
That's now done in git.
Allin
1696
days inactive
1701
days old
22 comments
4 participants
participants (4)
-
Allin Cottrell -
Riccardo (Jack) Lucchetti -
Sven S -
Sven Schreiber