I have a problem with calculations using the CAPM model (I have to do a finance project using this formula)
When calculating the Rf for 10 year bonds, what time period do I have to use? I stumbled across a video where some guy is using a 3 month time period, is that okay? If not, what time period should I use for my calculations?
Related
dears
I want to calculate the price rate of change by dividing the today's price with price 12 periods ago
"df.close" is the my data where I want to calculate the rate of change.
please guide me
I was unable to try anything because I felt it is the window of 12 days but not a continuous window
I see some similar replies but those are some big codes not relevant to me. I simply need one line to call the price 12 days ago and divide it
thank you.
I am working on a calculator to track my (and my coworkers may use it) overtime at work. We have a bunch written in excel, but I am trying to do one in access. There is probably a simple solution, but having searched for a couple days for using a variable in a date has only given me how to use the date as a variable. So our pay periods are defined 1/1/yyyy to 1/15/yyyy etc. Hour pay is calculated on the number of days we have in a pay period which varies every year by days off. I have it calculating the proper number of days using VBA, but I am having difficulty getting it to use the combo box year which defaults to current year.
I have tried setting the control source to = 01/01/[cmbYearselect]
using variables, creating a string in vba and format date
Any help would be appreciated as I am going to have to use the variable in both the control sources and vba code.
Thank you
01/01/[cmbYearSelect] results in 12/30/1899 on my form
everything else has resulted in a type mismatch for the variables etc.
Use CDate with no year:
=CDate(#01/01#)
or:
=CDate("01/01")
to have primo of the current year.
I’m a data analyst in the insurance industry and we currently have a program in SAS EG that tracks catastrophe development week by week since the start of the event for all of the catastrophic events that are reported.
(I.E week 1 is catastrophe start date + 7 days, week 2 would be end of week 1 + 7 days and so on) then all transaction amounts (dollars) for the specific catastrophes would be grouped into the respective weeks based on the date each transaction was made.
Problem that we’re faced with is we are moving away from SAS EG to GCP big query and the current process of calculating those weeks is a manually read in list which isn’t very efficient and not easily translated to BigQuery.
Curious if anybody has an idea that would allow me to calculate each week number in periods of 7 days since the start of an event in SQL or has an idea specific for BigQuery? There would be different start dates for each event.
It is complex, I know and I’m willing to give more explanation as needed. Open to any ideas for this as I haven’t been able to find anything.
I have the dataset consisting of energy demand per each of the user profiles, sampled on every half an hour during different days (for example Weekday in Summer or Saturday in Winter). What I would like to do is to extend this for each day of a year using existing data with some randomness here and there.
What methods do you recommend for time series extrapolation?
The dataset I'm working on is here:
https://data.ukedc.rl.ac.uk/browse/edc/efficiency/residential/LoadProfile/data
You may use imputeTS or pandas interpolate for filling missing values in betweens the days (i.e., imputation/interpolation) and forecast for filling future values (forecast/extrapolation).
I've started thinking about an employee shift management application to handle the shifts (who works when, trading, etc) at my current workplace (that uses pen and paper and hasn't got anyway for us employees to communicate about changes without going through the boss and be on site).
Currently the shifts are modeled loosely as:
There is a recurring 4 week period (from Monday week 1 to Sunday week 4)
There is a template for placing employees in this 4 week period
Every 4 months (ie 3 times a year) the 4 week template is projected over the next 4 month period
The shifts have been the same for a long time and it seems many employees would prefer to have them changed (I can say this by the requests for change that come in every time a new 4 month is set).
What I'm aiming at are the models:
Shift_group_tpl (the 4 week period above)
Shift_tpl (a single shift in the 4 week period, including info on who defaults to work this shift)
Shift_group (a set period of time whit actual shifts)
Shift (a set shift whit a real time period and an employee - and the possibility to be changed both in start_time, end_time and employee)
I've thought of a way to do this with recurring iCalendar events: Creating RRULE's (without an endtime) and then calculate (using temporary start and end times) if that specific Shift_group_tpl could be used within a real Shift_group. (The problem with this approach is that I can't figure out how to trim the Shift_group_tpl's to fit into the start or end of a Shift_group.)
What I'm looking for are some other perspectives or ways of doing it or even just a pat on the shoulder letting me know that I'm on the right track (and then giving advice on the trimming problem).
/iole1
What I'm aiming at are the models:
Shift_group_tpl (the 4 week period above)
Shift_tpl (a single shift in the 4 week period, including info on who defaults to work this shift)
Shift_group (a set period of time whit actual shifts)
Shift (a set shift whit a real time period and an employee - and the possibility to be changed both in start_time, end_time and employee)
You have "sql" as a tag for this post? So im guessing you want these as SQL tables?
By the sounds, the problem is that your considering the data you have, rather than the abstract concepts you need to store that data. Which is what you'd need to do to create an application. (Most likely a "Shifts" table, rather than the four tables above).
There is little information here to help, Consider refining your thoughts and ask another question.