It seems like pyephem should be able to give me your standard human-type names for where we are in a moon cycle, given a date -- "first quarter," "full," "waxing crescent," "waning gibbous," etc.
Am I right that it does not?
Does anyone know of a standard solution for that?
There is not, alas, any standard definition of a term like “Full Moon” beyond its being the moment when the Moon is completely full. This means that, technically, there is only one exact infinitely small moment when the Moon is completely full, and therefore that any real moment about which you could ask PyEphem will be either before or after that perfect moment of fullness.
So unless you can find a standard definition for how “wide” in seconds the moment of Full Moon is, the actual phase at any given second that you ask about will be either waxing or waning. You can consult the USNO definitions for all the details:
http://aa.usno.navy.mil/faq/docs/moon_phases.php
Since the standards there say that the difference in ecliptic longitude is how you determine the phase, you might try something like this:
import ephem
tau = 2.0 * ephem.pi
sun = ephem.Sun()
moon = ephem.Moon()
names = ['Waxing Crescent', 'Waxing Gibbous',
'Waning Gibbous', 'Waning Crescent']
for n in range(1, 31):
s = '2014/%d/11' % n
sun.compute(s)
moon.compute(s)
sunlon = ephem.Ecliptic(sun).lon
moonlon = ephem.Ecliptic(moon).lon
angle = (moonlon - sunlon) % tau
quarter = int(angle * 4.0 // tau)
print n, names[quarter]
Here's my quick and dirty solution to my own problem. It assumes observer is in the same timezone as the system timezone, but that's good enough for my purposes.
Still surprised pyephem doesn't have something like/more refined than this, but maybe there's an astronomical reason that I'm not smart enough to understand.
import ephem
def human_moon(observer):
target_date_utc = observer.date
target_date_local = ephem.localtime( target_date_utc ).date()
next_full = ephem.localtime( ephem.next_full_moon(target_date_utc) ).date()
next_new = ephem.localtime( ephem.next_new_moon(target_date_utc) ).date()
next_last_quarter = ephem.localtime( ephem.next_last_quarter_moon(target_date_utc) ).date()
next_first_quarter = ephem.localtime( ephem.next_first_quarter_moon(target_date_utc) ).date()
previous_full = ephem.localtime( ephem.previous_full_moon(target_date_utc) ).date()
previous_new = ephem.localtime( ephem.previous_new_moon(target_date_utc) ).date()
previous_last_quarter = ephem.localtime( ephem.previous_last_quarter_moon(target_date_utc) ).date()
previous_first_quarter = ephem.localtime( ephem.previous_first_quarter_moon(target_date_utc) ).date()
if target_date_local in (next_full, previous_full):
return 'Full'
elif target_date_local in (next_new, previous_new):
return 'New'
elif target_date_local in (next_first_quarter, previous_first_quarter):
return 'First Quarter'
elif target_date_local in (next_last_quarter, previous_last_quarter):
return 'Last Full Quarter'
elif previous_new < next_first_quarter < next_full < next_last_quarter < next_new:
return 'Waxing Crescent'
elif previous_first_quarter < next_full < next_last_quarter < next_new < next_first_quarter:
return 'Waxing Gibbous'
elif previous_full < next_last_quarter < next_new < next_first_quarter < next_full:
return 'Waning Gibbous'
elif previous_last_quarter < next_new < next_first_quarter < next_full < next_last_quarter:
return 'Waning Crescent'
Related
I want a strategy to Take Profit/Stop Loss to be based on the ATR (plus multiplier). However, I want it to be whatever the readings were at the point of entry, not simply the last candle (which is what it seems to be doing). Weird thing is that I have other strategies that use this approach, and they seem fine, so I'm really stumped by what I'm doing wrong.
Any help would be much appreciated!
// This source code is subject to the terms of the Mozilla Public License 2.0 at https://mozilla.org/MPL/2.0/
// © dave-browning
//#version=5
strategy("Dead-Cat Bounce", overlay = true, initial_capital = 1000, default_qty_value = 100, default_qty_type = strategy.percent_of_equity, currency = currency.GBP, commission_value = 0.05, use_bar_magnifier = true)
trendEMAlength = input.int(130, "Trend EMA Length")
fastSMALength = input.int(14, "Fast SMA Length")
tpATRmultiplyer = input.float(6.2, "Short TP ATR Multiplier")
slATRmultiplier = input.float(4, "Short SL ATR Multiplier")
//Trade Conditions
shortCondition = close > ta.sma(close, fastSMALength) and close < ta.ema(close, length=trendEMAlength)
notInTrade = strategy.position_size <= 0
atr = ta.atr(14)
ema=ta.ema(close, trendEMAlength)
plot(ta.sma(close,length=fastSMALength), color=color.blue, linewidth = 2)
plot(ta.ema(close, length=trendEMAlength), color=color.yellow, linewidth = 4)
plot(low - (atr * tpATRmultiplyer), color=color.green)
plot(high + (atr * slATRmultiplier), color=color.red)
if shortCondition and notInTrade
stopLoss = (high + (atr * slATRmultiplier))
takeProfit = (low - (atr * tpATRmultiplyer))
strategy.entry("Short", strategy.short)
strategy.exit("Short Exit", "Short", limit=takeProfit, stop=stopLoss)
I am implementing this neural network for some classification problem. I initially tried back propagation but it takes longer to converge. So I though of using RPROP. In my test setup RPROP works fine for AND gate simulation but never converges for OR and XOR gate simulation.
How and when should I update bias for RPROP?
Here my weight update logic:
for(int l_index = 1; l_index < _total_layers; l_index++){
Layer* curr_layer = get_layer_at(l_index);
//iterate through each neuron
for (unsigned int n_index = 0; n_index < curr_layer->get_number_of_neurons(); n_index++) {
Neuron* jth_neuron = curr_layer->get_neuron_at(n_index);
double change = jth_neuron->get_change();
double curr_gradient = jth_neuron->get_gradient();
double last_gradient = jth_neuron->get_last_gradient();
int grad_sign = sign(curr_gradient * last_gradient);
//iterate through each weight of the neuron
for(int w_index = 0; w_index < jth_neuron->get_number_of_weights(); w_index++){
double current_weight = jth_neuron->give_weight_at(w_index);
double last_update_value = jth_neuron->give_update_value_at(w_index);
double new_update_value = last_update_value;
if(grad_sign > 0){
new_update_value = min(last_update_value*1.2, 50.0);
change = sign(curr_gradient) * new_update_value;
}else if(grad_sign < 0){
new_update_value = max(last_update_value*0.5, 1e-6);
change = -change;
curr_gradient = 0.0;
}else if(grad_sign == 0){
change = sign(curr_gradient) * new_update_value;
}
//Update neuron values
jth_neuron->set_change(change);
jth_neuron->update_weight_at((current_weight + change), w_index);
jth_neuron->set_last_gradient(curr_gradient);
jth_neuron->update_update_value_at(new_update_value, w_index);
double current_bias = jth_neuron->get_bias();
jth_neuron->set_bias(current_bias + _learning_rate * jth_neuron->get_delta());
}
}
}
In principal you don't treat the bias differently than before when you did backpropagation. It's learning_rate * delta which you seem to be doing.
One source of error may be that the sign of the weight change depends on how you calculate your error. There's different conventions and (t_i-y_i) instead of (y_i - t_i) should result in returning (new_update_value * sgn(grad)) instead of -(new_update_value * sign(grad)) so try switching the sign. I'm also unsure about how you specifically implemented everything since a lot is not shown here. But here's a snippet of mine in a Java implementation that might be of help:
// gradient didn't change sign:
if(weight.previousErrorGradient * errorGradient > 0)
weight.lastUpdateValue = Math.min(weight.lastUpdateValue * step_pos, update_max);
// changed sign:
else if(weight.previousErrorGradient * errorGradient < 0)
{
weight.lastUpdateValue = Math.max(weight.lastUpdateValue * step_neg, update_min);
}
else
weight.lastUpdateValue = weight.lastUpdateValue; // no change
// Depending on language, you should check for NaN here.
// multiply this with -1 depending on your error signal's sign:
return ( weight.lastUpdateValue * Math.signum(errorGradient) );
Also, keep in mind that 50.0, 1e-6 and especially 0.5, 1.2 are empirically gathered values so they might need to be adjusted. You should definitely print out the gradients and weight changes to see if there's something weird going on (e.g. exploding gradients->NaN although you're only testing AND/XOR). Your last_gradient value should also be initialized to 0 at the first timestep.
I am involved in a project that I think you can help me. I have multiple images that you can see here Images to recognize. The goal here is to extract the numbers between the dashed lines. What is the best approach to do that? The idea that I have from the beginning is to find the coordinates of the dash lines and do the crop function, then is just run OCR software. But is not easy to find those coordinates, can you help me? Or if you have a better approach tell me.
Best regards,
Pedro Pimenta
You may start by looking at more obvious (bigger) objects in your images. The dashed lines are way too small in some images. Searching for the "euros milhoes" logo and the barcode will be easier and it will help you have an idea of the scale and rotation involved.
To find these objects without using match template you can binarize your image (watch out for the background texture) and use the Hu moments on the contours/blobs.
Don't expect a good OCR accuracy on images where the numbers are smaller than 8-10 pixels.
You can use python-tesseract https://code.google.com/p/python-tesseract/ ,it works with your image.What you need to do is to split the result string.I use your https://www.dropbox.com/sh/kcybs1i04w3ao97/u33YGH_Kv6#f:euro9.jpg to test.And source code is below.UPDATE
# -*- coding: utf-8 -*-
from PIL import Image
from PIL import ImageEnhance
import tesseract
im = Image.open('test.jpg')
enhancer = ImageEnhance.Contrast(im)
im = enhancer.enhance(4)
im = im.convert('1')
w, h = im.size
im = im.resize((w * (416 / h), 416))
pix = im.load()
LINE_CR = 0.01
WHITE_HEIGHT_CR = int(h * (20 / 416.0))
status = 0
white_line = []
for i in xrange(h):
line = []
for j in xrange(w):
line.append(pix[(j, i)])
p = line.count(0) / float(w)
if not p > LINE_CR:
white_line.append(i)
wp = None
for i in range(10, len(white_line) - WHITE_HEIGHT_CR):
k = white_line[i]
if white_line[i + WHITE_HEIGHT_CR] == k + WHITE_HEIGHT_CR:
wp = k
break
result = []
flag = 0
while 1:
if wp < 0:
result.append(wp)
break
line = []
for i in xrange(w):
line.append(pix[(i, wp)])
p = line.count(0) / float(w)
if flag == 0 and p > LINE_CR:
l = []
for xx in xrange(20):
l.append(pix[(xx, wp)])
if l.count(0) > 5:
break
l = []
for xx in xrange(416-1, 416-100-1, -1):
l.append(pix[(xx, wp)])
if l.count(0) > 17:
break
result.append(wp)
wp -= 1
flag = 1
continue
if flag == 1 and p < LINE_CR:
result.append(wp)
wp -= 1
flag = 0
continue
wp -= 1
result.reverse()
for i in range(1, len(result)):
if result[i] - result[i - 1] < 15:
result[i - 1] = -1
result = filter(lambda x: x >= 0, result)
im = im.crop((0, result[0], w, result[-1]))
im.save('test_converted.jpg')
api = tesseract.TessBaseAPI()
api.Init(".","eng",tesseract.OEM_DEFAULT)
api.SetVariable("tessedit_char_whitelist", "0123456789abcdefghijklmnopqrstuvwxyz")
api.SetPageSegMode(tesseract.PSM_AUTO)
mImgFile = "test_converted.jpg"
mBuffer=open(mImgFile,"rb").read()
result = tesseract.ProcessPagesBuffer(mBuffer,len(mBuffer),api)
print "result(ProcessPagesBuffer)=",result
Depends python 2.7 python-tesseract-win32 python-opencv numpy PIL,and be sure to follow python-tesseract's remember to .
I have built a tricopter from scratch based on a .NET Micro Framework board from TinyCLR.com. I used the FEZ Mini which runs at 72 MHz. Read more about my project at: http://bit.ly/TriRot.
So after a pre-flight check where I initialise and test each component, like calibrating the IMU and spinning each motor, checking that I get receiver data, etc., it enters a permanent loop which then calls the flight controller method on each loop.
I'm trying to tune my PID controller now using the Ziegler-Nichols method, but I am always getting a progressively larger overshoot. I was eventually able to get a [mostly] stable oscillation using proportional control only (setting Ki and Kd = 0); timing the period K with a stopwatch averaged out to 3.198 seconds.
I came across the answer (by Rex Logan) on a similar question by chris12892.
I was initially using the "Duration" variable in milliseconds which made my copter highly aggressive, obviously because I was multiplying the running integrator error by thousands on each loop. I then divided it by another thousand to bring it to seconds, but I'm still battling...
What I don't understand from Rex's answer is:
Why does he ignore the time variable in the integral and differential parts of the equations? Is that right or is it a typo?
What he means by the remark
In a normal sampled system the delta term would be one...
One what? Should this be one second under normal circumstances? What
if this value fluctuates?
My flight controller method is below:
private static Single[] FlightController(Single[] imuData, Single[] ReceiverData)
{
Int64 TicksPerMillisecond = TimeSpan.TicksPerMillisecond;
Int64 CurrentTicks = DateTime.Now.Ticks;
Int64 TickCount = CurrentTicks - PreviousTicks;
PreviousTicks = CurrentTicks;
Single Duration = (TickCount / TicksPerMillisecond) / 1000F;
const Single Kp = 0.117F; //Proportional Gain (Instantaneou offset)
const Single Ki = 0.073170732F; //Integral Gain (Permanent offset)
const Single Kd = 0.001070122F; //Differential Gain (Change in offset)
Single RollE = 0;
Single RollPout = 0;
Single RollIout = 0;
Single RollDout = 0;
Single RollOut = 0;
Single PitchE = 0;
Single PitchPout = 0;
Single PitchIout = 0;
Single PitchDout = 0;
Single PitchOut = 0;
Single rxThrottle = ReceiverData[(int)Channel.Throttle];
Single rxRoll = ReceiverData[(int)Channel.Roll];
Single rxPitch = ReceiverData[(int)Channel.Pitch];
Single rxYaw = ReceiverData[(int)Channel.Yaw];
Single[] TargetMotorSpeed = new Single[] { rxThrottle, rxThrottle, rxThrottle };
Single ServoAngle = 0;
if (!FirstRun)
{
Single imuRoll = imuData[1] + 7;
Single imuPitch = imuData[0];
//Roll ----- Start
RollE = rxRoll - imuRoll;
//Proportional
RollPout = Kp * RollE;
//Integral
Single InstanceRollIntegrator = RollE * Duration;
RollIntegrator += InstanceRollIntegrator;
RollIout = RollIntegrator * Ki;
//Differential
RollDout = ((RollE - PreviousRollE) / Duration) * Kd;
//Sum
RollOut = RollPout + RollIout + RollDout;
//Roll ----- End
//Pitch ---- Start
PitchE = rxPitch - imuPitch;
//Proportional
PitchPout = Kp * PitchE;
//Integral
Single InstancePitchIntegrator = PitchE * Duration;
PitchIntegrator += InstancePitchIntegrator;
PitchIout = PitchIntegrator * Ki;
//Differential
PitchDout = ((PitchE - PreviousPitchE) / Duration) * Kd;
//Sum
PitchOut = PitchPout + PitchIout + PitchDout;
//Pitch ---- End
TargetMotorSpeed[(int)Motors.Motor.Left] += RollOut;
TargetMotorSpeed[(int)Motors.Motor.Right] -= RollOut;
TargetMotorSpeed[(int)Motors.Motor.Left] += PitchOut;// / 2;
TargetMotorSpeed[(int)Motors.Motor.Right] += PitchOut;// / 2;
TargetMotorSpeed[(int)Motors.Motor.Rear] -= PitchOut;
ServoAngle = rxYaw + 15;
PreviousRollE = imuRoll;
PreviousPitchE = imuPitch;
}
FirstRun = false;
return new Single[] {
(Single)TargetMotorSpeed[(int)TriRot.LeftMotor],
(Single)TargetMotorSpeed[(int)TriRot.RightMotor],
(Single)TargetMotorSpeed[(int)TriRot.RearMotor],
(Single)ServoAngle
};
}
Edit: I found that I had two bugs in my code above (fixed now). I was integrating and differentiating with the last IMU values as opposed to the last error values. That got rid of the runaway sitation completely. The only problem now is that it seems to be a bit slow. When I perturb the system, it responds very quickly and stop it from continuing, but it takes a long time to get back to the setpoint (0), about 10 seconds or more. Is this now just down to tuning the PID? I'll give the suggestions below a go, and let you know if any of them make a difference.
One question I have is:
being a .NET board, I don't want to bank on any kind of accurate timing, so instead of trying to work out at what frequency I am executing that method, surely if I calculate the actual time and factor that into the equations, it should be better, or am I misunderstanding something?
I have some code that is taking a long time to run(several hours) and I think it is because it is doing a lot of comparisons in the if statement. I would like it to run faster, does anyone have any helpful suggestions to improve the runtime? If anyone has a different idea of what is slowing the code down so I could try and fix that it would be appreciated.
xPI = zeros(1,1783);
argList2 = zeros(1,1783);
aspList2 = zeros(1,1783);
cysList2 = zeros(1,1783);
gluList2 = zeros(1,1783);
hisList2 = zeros(1,1783);
lysList2 = zeros(1,1783);
tyrList2 = zeros(1,1783);
minList= xlsread('20110627.xls','CM19:CM25');
maxList= xlsread('20110627.xls','CN19:CN25');
N = length(pIList);
for i = 1:N
if (argList(i)>= minList(1) && argList(i) <= maxList(1)) ...
&& (aspList(i)>= minList(2) && aspList(i) <= maxList(2)) ...
&& (cysList(i)>= minList(3) && cysList(i) <= maxList(3)) ...
&& (gluList(i)>= minList(4) && gluList(i) <= maxList(4)) ...
&& (hisList(i)>= minList(5) && hisList(i) <= maxList(5)) ...
&& (lysList(i)>= minList(6) && lysList(i) <= maxList(6)) ...
&& (tyrList(i)>= minList(7) && tyrList(i) <= maxList(7))
xPI(i) = pIList(i);
argList2(i) = argList(i);
aspList2(i) = aspList(i);
cysList2(i) = cysList(i);
gluList2(i) = gluList(i);
hisList2(i) = hisList(i);
lysList2(i) = lysList(i);
tyrList2(i) = tyrList(i);
disp('passed test');
end
end
You can try vectorising the code; I have made up some sample data sets and duplicated some of the operations you're performing below.
matA1 = floor(rand(10)*1000);
matB1 = floor(rand(10)*1000);
matA2 = zeros(10);
matB2 = zeros(10);
minList = [10, 20];
maxList = [100, 200];
indicesToCopy = ( matA1 >= minList(1) ) & ( matA1 <= maxList(1) ) & ( matB1 >= minList(2) ) & ( matB1 <= maxList(2) );
matA2(indicesToCopy) = matA1(indicesToCopy);
matB2(indicesToCopy) = matB1(indicesToCopy);
No idea whether this is any faster, you'll have to try it out.
EDIT:
This doesn't matter too much since you're only making two calls, but xlsread is horribly slow. You can speed up those calls by using this variant syntax of the function.
num = xlsread(filename, sheet, 'range', 'basic')
The catch is that the range argument is ignored and the entire sheet is read, so you'll have to mess with indexing the result correctly.
Use the profiler to see which lines or functions are using the most execution time.
You can probably get a huge increase in execution speed by vectorizing your code. This means using operations which operate on an entire vector at once, instead of using a for-loop to iterate through it. Something like:
% make a logical vector indicating what you want to include
ii = (argList >= minList(1) & argList <= maxList(1)) & ...
% use it
argList2(ii) = arglist(ii); % copies over every element where the corresponding ii is 1
...