I have upgraded quantstrat package from 0.7.7(installed on Jan 7th 2013) to 0.7.8, however old code does not work properly. looks like we can not put any entry orders niether buy or sell, and only exit orders are executed. Here is the detail. Someone knows major changes in add.rule or applyStrategy function or same issue has been reported?
We set up trading rule by add.rule()
add.rule(f,'ruleSignal',arguments=list(sigcol="DoSell",sigval=TRUE,orderqty=(-1*tradeSize),osFUN='osSUS',ordertype='market',TxnFees="calcTxnFee",prefer='Open'),type='enter',label=gExitLabel)
add.rule(f,'ruleSignal',arguments=list(sigcol="DoBuy", sigval=TRUE,orderqty=tradeSize,osFUN='osBuy',ordertype='market',TxnFees="calcTxnFee",prefer='Price'),type='enter',label=gEnterLabel)
add.rule(f,'ruleSignal',arguments=list(sigcol="DoStop", sigval=TRUE,orderqty=-1*tradeSize,osFUN='osStop',ordertype='stoplimit',threshold='StopLevel',TxnFees="calcTxnFee"),type='risk',label='Stop')
The problem we had is we don't get entry signal when we run applyStrategy ...... It seems that getOrderbook has "Buy" and "Sell" .....
applyStrategy(rs, rs) only applied sell signal ........(not buy)
[1] "2010-11-18 09:00:00 ABC -65660 # 4.6"
[1] "2010-12-07 09:00:00 ABC -37509 # 5.17"
However getOrderBook() recorded "Buy", and "Sell" in order .....
at the same time order.prices were set "0", order.status "replaced" and Prefer "Price" by the system
It is hard to understand what is your problem exactly: "no entry signal", "orderbook has Buy and Sell" (whatever that means), "order.prices were set to 0" ...
I see that you are using your own order sizing functions, could it have something to do with that? You may try dropping your order sizing functions for a test, just to check if your entry orders are being executed.
Otherwise I suggest that you provide a complete example so I can run it and check.
Please be aware that quantstrat is under heavy development and that the code is patched almost on a daily basis, although the version number may not always be bumped up. So make sure that you always download the latest code.
HTH,
Jan Humme.
Related
I was making a package in R and would like it to make it as a trial version for a period of 30 days .
Well my question is how to make a code self destructive depends on number of days ??
I had played with time and date package for a while where i came to know ,
Sys.Date() could give todays date , so i get forard with something below
today=Sys.Date()
a=today
b=a+1
if(a==today)
{
print(paste("today is sunday"))
if(b==today){
print(paste("today is monday"))
}
I know it is stupid work whatever i had done , my sole idea was to fix the 1st use of package as starting day ,and every day it will increment till 30 days ,when it will reach the limit it will automatically destroy using
file.remove () <- through which I can remove some file ........
May be I am clear with my ideas .
Sorry for the novice question .
Add this condition to the license. ("30 days for free, after that you'll have to pay".) and expect users to comply with this.
There is really nothing else you can do.
Well, actually you can. For example, on the first occasion your code is run, save the current date to a file in a certain location (say, "~/.datetocheck"). Then every time your code is run, check for the existence of this file, and if it exists, compare the dates. If more than 30 days have passed, give an error message:
stop("Time is over! You have to pay!")
The problem is that nothing prevents the user from simply deleting this file.
It is difficult for me to catch with the eye a boundary between test runs.
Is it possible to clear console for each run of Testacular/Karma + Jasmine or at least put there something easily catched by the eye, for example a series of newlines?
Note
Currently it is an abandoned question because I am no longer trying to perform tasks described in it. Please do not ask for additional info. Write only if you know for sure what to do. It will help other people.
Write your own reporter, and do whatever you want with it.
Also, if you're on a Mac and use Growl, take a look at karma-growl-reporter
I am not sure to fully understand your need but karma-spec-reporter can give you a detailed review of your test execution. Output example from karma-spec-reporter-example:
array:
push:
PASSED - should add an element
PASSED - should remove an element
FAILED - should do magic (this test will fail) expected [] to include 'magic'
at /home/michael/development/codecentric/karma-spec-reporter-example/node_modules/chai/chai.js:401
...
PhantomJS 1.8.1 (Linux): Executed 3 of 3 (1 FAILED) (0.086 secs / NaN secs)
There's now a reporter available for this: https://github.com/arthurc/karma-clear-screen-reporter
It's working for me on OSX.
Im scrapping the price of some products from a website . In Python I used the urllib2 without problems, but when I tried using RCurl in R I couldn't donwload the source code.
I have to paste the source code with the product code, then I catch the price. The path of a product is: http://www.americanas.com.br/produto/code_of_product.
Actually, I can't download the source code of a product with RCurl. When I try for example getURL('http://www.americanas.com.br/produto/111467594') it returns "".
I tried using getURL('.../produtos/111467594') and I could download the source, but in this way I'm unable to get the price. :(
Anyone know how could I get the price of the products?
Thanks.
Ps.: Sorry for my bad english. :)
welcome to StackOverflow.
It's hard to say for me why it doesn't work, could you include a verbose=TRUE in the getURL? Also, I notice there's different prices on the webpage you linked. You want all or just the first? How about this to get the "Por price":
library("stringr")
productwebpage<-readLines("http://www.americanas.com.br/produto/111467594")
pricerow<-productwebpage[grep("p class=\"sale price\"",productwebpage)]
price<-str_extract_all(pricerow,"\\(?[0-9,.]+\\)?")[[1]]
You could also substitute the grep("p class=\"sale price\"",productwebpage) to either grep("<p><span class=\"regular price\">",productwebpage) (to get the "de price" / old price) or grep("<span class=\"p-v interest\">",productwebpage) (which will give you the "sem jouros" price / per month payment). For the last example you will get the months first and the payment after so it will be:
> price
[1] "12" "83,25"
This should hopefully work for other products as well (just tried 5 and seemed to work for all of them).
I'm upgrading from rails 3 to 3.1.8 (and onwards). A couple of my tests are failing, one of which seemed at first glance to be because of the change from mysql2 gem (0.2.x to 0.3.x). However, it gets a little stranger. Here's what's happening.
In my test I am updating attributes on a model, and checking that they've saved:
...
post :create, :advertisement => #advertisement_attributes
assert_equal assigns(:blah).start_date, #blah_attributes[:start_date]
It is failing saying that they are different times.
If I put a binding.pry and jump in just before the assert_equal this is what I get:
a = assigns(:blah).start_date
b = #blah_attributes[:start_date]
a == b #false
a.to_s #"2012-10-17 20:46:12 UTC"
b.to_s #"2012-10-17 20:46:12 UTC"
a.to_i #1350506772
b.to_i #1350506772
a.to_i - b.to_i #0
So far.. I'm still confused as to why the == is returning false. But what is really odd is if I subtract the dates -
a - b #-0.989403009414673
If anyone can explain what's going on here I'd love to know!
Also, this same test was passing fine in rails 3 (no timezone was set for the application), any pointers to what has changed would also be handy!
Is there any way to create a cron expression for not running the job at all?
I though of using this expression :
0 0 0 1 1 ? 3099
...which will practically do the job as it will run on year 3099, but is there a cleaner way to do it?
If you're still looking for something robust even in the far future, try https://stackoverflow.com/a/13938099/1601531, where I suggest the use of February 31st in crontab entries which are never intended to execute.
0 0 5 31 2 ?
I needed a valid cron schedule (? syntax not working in my system) which resolves real dates, but to be effectively "never". My current best solution was to pick the most recent leap year and see what day Feb 29th fell on. Feb 29 2016 was a Monday, so the next Monday Feb 29 is currently furthest away.
0 0 29 2 1 yields the next 5 triggers as:
02/29/2044 00:00:00Z
02/29/2072 00:00:00Z
02/29/2112 00:00:00Z
02/29/2140 00:00:00Z
02/29/2168 00:00:00Z
Not perfect but it'll do.
Pick a date in the past.
That'll never happen again. Unless it's groundhog day. Just don't pick groundhog day.
I created a duplicate (click here to see) for your question, and agree with your initial proposal. After testing, it appears Quartz will never execute a cron expression with a year above 2300.
Opening your crontab file and deleting the entry would be the adequate way. Or you might as well simlink the executable that's called by the cronjob to an empty shell script.
Tell us more about your setup, then we'll see ...
Comment it out — put # sign in front of it. Very useful, especially if you're afraid you'll forget about your changes by the year 3099.
Another possibility is to make it execute dummy command, like true rm -rf /.