Develop Reference

Azure Functions Schedule Timer

It is possible that on Azure functions beta the timer has a bug or did I something wrong?
My cron timer in the application settings was this:
59 23 * * * *
and the last run was on 2018-02-21T17:23:59.0307645+00:00
How should I set the cron timer if I want to have every day at 23:59?

The expression you currently have (59 23 * * * *) means "every hour at 23 minutes and 59 seconds). What you need to use instead is 0 59 23 * * *. Note that by default, this will be treated as UTC time.
Be aware that CRON expressions have lots of dialects, and I don't think the other answer will work. My answer is specifically for Azure Functions, which uses ncrontab (the flavor of it that supports the 'seconds' field).

Everyday at 23:59: 0 59 23 1/1 * ? *
Source

Rounding datetime in c# - why does this solution work?

I want to round datetime objects in C# to the nearest minute. So if the datetime object has 1 minute, 29 seconds and 999 miliseconds it should be rounded to 1 minute. If it has 1 minute, 30 seconds and 0 miliseconds, it should be rounded to 2 minutes.
I implemented this solution which I found from internet:
var timespan = new TimeSpan(0, 0, 1, 0);
//timespan has a value of 1 minute because I want to round to the nearest minute
return new DateTime(((dateTime.Ticks + timespan.Ticks/2)/ timespan.Ticks)* timespan.Ticks);
I'm not sure about the last line. Why do we divide by 2? Why do we divide with timespan.Ticks and then multiply?

It's a lot used method of rounding to add half of desired precision and then cut the decimals. Examples:
Desired precision: 0.1 ( / 2 -> add 0.05 )
1.44 + 0.05 = 1.49 -> cut last -> 1.4
1.46 + 0.05 = 1.51 -> cut last -> 1.5
Desired precision: 0.01 ( / 2 -> add 0.005 )
1.443 + 0.005 = 1.448 -> cut last -> 1.44
1.465 + 0.005 = 1.470 -> cut last -> 1.47
Desired precision: 1minute -> add 0.5min or 30s or 30000 ticks* (assumed 1s = 1000 ticks). Unit doesn't matter as long as you keep units the same in all calculations.
1min 25s + 30s = 1min 55s -> cut -> 1min
1min 35s + 30s = 2min 05s -> cut -> 2min
So with datetime it's the same. In order to round by minute, you may add half a minute and then cut the rest away.
Ticks are one way of representing time. So just take the tick-count of a minute (new TimeSpan(0, 0, 1, 0)), divide it by two to get the half way and then add it to your time.
Now all you need to do is to cut the rest away and you can do it by diving your time with the precision (tick count of 1 minute). When you divide by 1 minute, everything that's smaller than a minute will be in decimals. Tick is an integer so it "forgets" all the decimals, thus cutting them away. Now all you need to do is make the value valid again by multiplying it with the same value you divided it with. Decimals are already lost at this point, so... TADAA: Rounded by minute.

C# Math.Ceiling rounds up a event double... (500 to 501) (formula)

why rounds C# this calculation up?
500 -> 501
MessageBox.Show(Math.Ceiling(1 / (4 * 1 - 4 * 0.9) * 200).ToString());
Returns.
---------------------------
---------------------------
501
---------------------------
OK
---------------------------
I dont know why.
Excel doesnt do this, too.
I need the ceiling function for the fomula which returns 500 instead 501.
I could use this instead. But i would know if there is another solution and why C# do this.
MessageBox.Show(Math.Ceiling(Math.Floor((1 / (4 * 1 - 4 * 0.9) * 200) * 100) / 100).ToString());

The problem is that 500 is actually not 500 but rather 500.0000000001 (or something similar) due to using floating point operations.
To solve this issue, use decimal instead of double.
MessageBox.Show(Math.Ceiling(1.0M / (4.0M * 1.0M - 4.0M * 0.9M) * 200.0M).ToString());
See What every Computer Scientist should know about Floating-Point Arithmetic for further information, or take a look at this website for a simpler explanation.

Brute force or algorithm

I'm not sure what kind of approach is needed but let me describe the problem:
Given an arbitrary number of workers (2 or more) are scheduled to work in any given month (including weekends).
Only one worker may work that assigned day.
2a. This worker may not work the day before or after.
Workers also work weekends and if possible equally distributed to the number of workers.
3a. Saturdays and Sundays are weighed equally.
Allot for possible vacations taken
4a. No restriction on sequential days
4b. May not take so much vacation that will interfere with rule(s) #2 and #3
What is the most flexible way to sort these criteria.
What is this type of problem called?
Can someone to point me to the right direction so I can read and learn about it. Obviously if this is something that is already been solved with an algorithm, point me to the right paper or book so I can read and understand it.
Clarification: I'm not looking for how many [total] days and weekends each worker would work but a way to [evenly] distribute the days worked in that month.
E.g. Workers A B C; A requested vacation 17 to 20
Obviously there are other permutations than the example I listed below.
M T W Th F Sa Su
====================
October 1 2 3 4 5 6 7
2012 A B C A B C A
8 9 10 11 12 13 14
B C A B C A B
15 16 17 18 19 20 21
C A B C B C A
22 23 24 25 26 27 28
B A C A C B C
29 30 31
A B A

Use the simplex algorithm. You can program constraints as thus:
Each day needs to be filled by exactly one person
For each day and for each worker, they should work at least one out of every three day block
Nobody should work on their vacation days
The max number of weekends a worker has in a month should be no more than 1+floor(weekend shifts/workers)

Increment, decrement by percentage

I'll try to explain this problem the best way i can with code:
double power = 5000;
//picked up 5 power ups, now need to increase power by 10% per powerup
power += 5 * (power * .10);
//later on...ran into 5 power downs need to decrease power back to initial hp
power -= 5 * (power * .10);//7500 - 3750 -- doesn't work
So what i need is a scaleable solution that gets back to the original value using only the count. Any ideas?

The best way to do this is using a function. It doesn't have to look exactly like this, but:
class Whatever
{
private double basePower = 5000;
public int numPowerUps = 5;
public double GetActualPower()
{
return basePower + (numPowerUps * basePower * 0.1);
}
}
Just change numPowerUps back to 0 when they run out. This way, it looks a whole lot neater.
An aside:
The reason it's not working is because of the fact that adding and then subtracting percentages doesn't work. For instance:
1. What is 10% of 100? --> 10
2. Add that to the 100 --> 110
3. What is 10% of 110? --> 11
4. Subtract that from 110 --> 99
You'll always end up with 99% of your original value. If you really want to take a shortcut, you could instead do this:
1. What is 10% of 100? --> 10
2. Add that to the 100 --> 110
3. What is (100/11) = 9.09090909...% of 110? --> 10
4. Subtract that from 110 --> 100
But then you're potentially susceptible to floating point errors. The function way of doing it is not only neater and clearer, but potentially less error-prone.

To reverse a %age increase, you must divide by the original %age, not subtract.
i.e.:
100 + 5% = 100 * 1.05 = 105
to reverse it:
105 / 1.05 = 100
The more usual '5% off' formula would instead give you:
105 - 5% = (105 * 0.95) = 99.75

To power up:
power <- power * (1 + count * percent);
eg: 5000 * (1 + 5 * 0.1)
5000 * 1.5
7500
To power back down:
power <- power / (1 + count * percent)
eg: 7500 / (1 + 5 * 0.1)
7500 / 1.5
5000
Let's take a more complicated example, 17 power ups, each giving 3% to an intial 1234 power:
1234 * (1 + 17 * 0.3)
= 1234 * (1 + 5.1)
= 1234 * 6.1
= 7527.4
7527.4 / (1 + 17 * 0.3)
= 7527.4 / (1 + 5.1)
= 7527.4 / 6.1
= 1234
It actually looks pretty simple when you write it out like that.

This doesn't work because the two percentages are not taken from the same number. They're taken from the same variable, but not the same number.
The first time, power * 0.10 is 500, and 5*500=2500 so the power will be 5000+2500=7500. Now, the power is 7500, so power * 0.10 is 750. 5*750 = 3750 and 7500-3750=3750 and not 5000 like you started out with.
So apparently, what you want is not really to in/decrease by a percentage of the current power. Perhaps it would be better to set a base power (let's say 5000) and an actual power. Then when you in/decrease, you use actualPower = actualPower + 5*0.1*basePower; or something. Or you just accept that five power downs after five power ups does not get you back to initial hp.

I'm going to suspect that what you mean by "doesn't work" is that the value for power does not end up to be exactly 3750.
This is due to floating-point rounding errors, as floating point values such as double and float are not able to be represented exact values.
If exact values are needed, then using decimal or int would be a better solution, as they are designed to handle exact values.
Edit The actual issue here is not a floating-point rounding error, but an issue noted in Smashery's answer.