A database architecture and algorithm to support querying for availability over a week - iphone

I have an iPhone app where a user can set his availability for different times of the day, for each day of the week. Having just three availability periods per day (morning/afternoon/evening) will work for the time being, but I'd want to implement times in the future. A user will try to search for other users based on the availability. What is a good database architecture and search algorithm to implement this? I use stackmob as my backend. If some body can give me some hints or point me to an algorithm that will be able to search for an availability match, I'd really appreciate it. I have a crude way to do it currently - 21 variables (boolean each for 7 days * 3 time periods). I want to find a smarter way.

I would do the following:
Store availability using date/times in the database. One record for each slot they are available. It is arbitrary what time you use to represent each slot. E.g. maybe morning is 9am, afternoon is 1pm and evening is 5pm. But by using date/time you are setting yourself up to change this to something more precise later (e.g. a start-time, end-time).
Query each users availability within the required time frame (e.g. between now and 1 week time). Lets calling the resulting arrays A & B.
Now run the following algorithm...
NSUInteger a = 0;
NSUInteger b = 0;
BOOL foundMatch = NO;
while(a < A.count && b < B.count) {
NSComparisonResult result = [A[a] compare:B[b]];
if(result == NSOrderedSame) {
foundMatch = YES;
break;
} else if(result == NSOrderedDescending) { //a>b
b++;
} else {
a++;
}
}

Related

How can I tell if DateTime.Now() is on a day AFTER a different DateTime

I'm running this on flutter, but I guess this could be a more general issue.
I am saving a DateTime in the preferences. I want to be able to then tell if DateTime.now() is on at least a day after the last saved DateTime, i.e.
(pseudocode)
lastDailyCheck = 2020.04.10
now = 2020.04.11
=> now is a day after the lastDailyCheck.
This should already work if it is 00:01 on the new day, even if the lastDailyCheck was on 23:58 the day before, meaning the difference can be as low as minutes between the 2 DateTimes.
Turns out this is really complicated!
Here's what doesn't work:
DateTime.Now().isAfter(lastDailyCheck)
This only checks if now is after the last one, it also return true after a second, and on the same day.
DateTime.Now().isAfter(lastDailyCheck) && lastDailyCheck.day != DateTime.Now().day
I thought this was clever. If the day is different and it is after the last then it does work in recognizing it is a day later - but then I realized it would bug out when both days are say on the 15th of the month - then lastDailyCheck.day would equal DateTime.Now().day.
What do you think would be possible here?
I don't know flutter, but my approach would be to not store the last check, but store the date at which the next check should occur. So when you perform a check you calculate the next midnight and store that. Now you can use isAfter.
In javascript this would look something like this:
const now = new Date();
//this also handles overflow into the next month
const nextCheck = new Date(now.getYear(), now.getMonth(), now.getDate() + 1)
//store nextCheck somewhere
//in js there is no isAfter, you just use >
if(new Date() > nextCheck) {
//do the thing
}
of course you could also calculate nextCheck every time you want to compare it, but I dislike performing the same calculation over and over if I can avoid it.
A thing to mention here is timezones, depending on your date library and if your system and user timezones align, you may need to shift the date.
I cannot write a complete code for now but this is what it would look like:
(pseudocode)
expirationDay = lastDailyCheck.add(oneDayDuration);
isOneDayAfter = DateTime.now().isAfter(expirationDay);
You give an expiration date and compare the DateTime to that. You have to use isAfter for reliability, instead of .day check.
I would compute the difference between midnight of the day of the last timestamp and midnight of the current timestamp. That is, consider only the date portion of a DateTime and ignore the time.
DateTime date(DateTime dateTime) =>
DateTime(dateTime.year, dateTime.month, dateTime.day);
// Intentionally check for a positive difference in hours instead of days
// so we don't need to worry about 23-hour days from DST. Any non-zero
// number of hours here means a difference of at least a "day".
if (date(DateTime.now()).difference(date(lastDailyCheck)).inHours > 0) {
// "One day" after.
}
If you're using UTC timestamps and don't care about when midnight is in whatever the local time is, the comparison could more intuitively use .inDays >= 1.
Figured out another potential solution!
In addition to checking if the day is different (which by itself won't work) you can also check the month and year. Only 1 of those needs to differ for it be true :)
if (now.isAfter(lastDailyCheck)) {
if (now.day != lastDailyCheck.day ||
now.month != lastDailyCheck.month ||
now.year != lastDailyCheck.year) {
return true;
}
}
this is the way I prefer to do some logics based on the comparison between two different times:
var now = DateTime.now();
var myDate = new DateTime.utc(2022, 1, 1);
if(myDate.compareTo(now)>0) //positive value means myDate is greater than DateTime.now()
{
// here is your logic based on the comparison between two times
} else {
//your logic if DateTime.now() pass myDate
}
You can use the difference method to get the difference between 2 dates and check whether those differs in hours with at-least 24 hours. So your if condition becomes:
if (now.isAfter(lastDailyCheck) &&
(lastDailyCheck.day != now.day ||
now.difference(lastDailyCheck).inHours > 24)) {
print('After');
}
Here's an attempt to a succint answer. Simply export this extension and use it. With it you can say if a date is at least one day after the current day.
extension DateExt on DateTime {
bool isAtLeastOneDayAfterToday() {
final now = DateTime.now();
return (isAfter(now) &&
(day != now.day || month != now.month || year != now.year));
}
}
Use it like so:
final isAfter = myDay.isAtLeastOneDayAfterToday(); //will be true or false

pseudocode about registers and clients

I have projects that requires to simulate a market with 3 registers. Every second an amount of clients come to the registers and we assume that each clients takes 4 seconds to the register before he leaves. Now lets suppose that we get an input of all the customers and their arriving time: e.x: 0001122334455 which means that 3 customers enter at second 0, 2 at second 1 etc. What i need to find is the total time which need to serve all the customers now matter how many they are and also to find the average waiting time at the store.
Can someone come up with a pseudocode for this problem?
while(flag){
while(i<A.length-1){
if(fifo[tail].isEmpty()) fifo[tail].put(A[i] +4);
else{
temp= fifo[tail].peek();
fifo[tail].put(A[i]-temp+4);
i++;
}
if(tail == a-1){
tail=0;
}else tail++;
if(i>3){
for(int q =0; q<a; q++){
temp = fifo[q].peek();
if(temp==i){
fifo[q].get();
}
}
}
}
}
where A is the array which contains all the customers as numbers as required from the input, and fifo is the array of the registers with the get , put and peek(get the tail but not remove it) methods. I have no clue though how to find the total time an the average waiting time

Which costs more while looping; assignment or an if-statement?

Consider the following 2 scenarios:
boolean b = false;
int i = 0;
while(i++ < 5) {
b = true;
}
OR
boolean b = false;
int i = 0;
while(i++ < 5) {
if(!b) {
b = true;
}
}
Which is more "costly" to do? If the answer depends on used language/compiler, please provide. My main programming language is Java.
Please do not ask questions like why would I want to do either.. They're just barebone examples that point out the relevant: should a variable be set the same value in a loop over and over again or should it be tested on every loop that it holds a value needed to change?
Please do not forget the rules of Optimization Club.
The first rule of Optimization Club is, you do not Optimize.
The second rule of Optimization Club is, you do not Optimize without measuring.
If your app is running faster than the underlying transport protocol, the optimization is over.
One factor at a time.
No marketroids, no marketroid schedules.
Testing will go on as long as it has to.
If this is your first night at Optimization Club, you have to write a test case.
It seems that you have broken rule 2. You have no measurement. If you really want to know, you'll answer the question yourself by setting up a test that runs scenario A against scenario B and finds the answer. There are so many differences between different environments, we can't answer.
Have you tested this? Working on a Linux system, I put your first example in a file called LoopTestNoIf.java and your second in a file called LoopTestWithIf.java, wrapped a main function and class around each of them, compiled, and then ran with this bash script:
#!/bin/bash
function run_test {
iter=0
while [ $iter -lt 100 ]
do
java $1
let iter=iter+1
done
}
time run_test LoopTestNoIf
time run_test LoopTestWithIf
The results were:
real 0m10.358s
user 0m4.349s
sys 0m1.159s
real 0m10.339s
user 0m4.299s
sys 0m1.178s
Showing that having the if makes it slight faster on my system.
Are you trying to find out if doing the assignment each loop is faster in total run time than doing a check each loop and only assigning once on satisfaction of the test condition?
In the above example I would guess that the first is faster. You perform 5 assignments. In the latter you perform 5 test and then an assignment.
But you'll need to up the iteration count and throw in some stopwatch timers to know for sure.
Actually, this is the question I was interested in… (I hoped that I’ll find the answer somewhere to avoid own testing. Well, I didn’t…)
To be sure that your (mine) test is valid, you (I) have to do enough iterations to get enough data. Each iteration must be “long” enough (I mean the time scale) to show the true difference. I’ve found out that even one billion iterations are not enough to fit to time interval that would be long enough… So I wrote this test:
for (int k = 0; k < 1000; ++k)
{
{
long stopwatch = System.nanoTime();
boolean b = false;
int i = 0, j = 0;
while (i++ < 1000000)
while (j++ < 1000000)
{
int a = i * j; // to slow down a bit
b = true;
a /= 2; // to slow down a bit more
}
long time = System.nanoTime() - stopwatch;
System.out.println("\\tasgn\t" + time);
}
{
long stopwatch = System.nanoTime();
boolean b = false;
int i = 0, j = 0;
while (i++ < 1000000)
while (j++ < 1000000)
{
int a = i * j; // the same thing as above
if (!b)
{
b = true;
}
a /= 2;
}
long time = System.nanoTime() - stopwatch;
System.out.println("\\tif\t" + time);
}
}
I ran the test three times storing the data in Excel, then I swapped the first (‘asgn’) and second (‘if’) case and ran it three times again… And the result? Four times “won” the ‘if’ case and two times the ‘asgn’ appeared to be the better case. This shows how sensitive the execution might be. But in general, I hope that this has also proven that the ‘if’ case is better choice.
Thanks, anyway…
Any compiler (except, perhaps, in debug) will optimize both these statements to
bool b = true;
But generally, relative speed of assignment and branch depend on processor architecture, and not on compiler. A modern, super-scalar processor perform horribly on branches. A simple micro-controller uses roughly the same number of cycles per any instruction.
Relative to your barebones example (and perhaps your real application):
boolean b = false;
// .. other stuff, might change b
int i = 0;
// .. other stuff, might change i
b |= i < 5;
while(i++ < 5) {
// .. stuff with i, possibly stuff with b, but no assignment to b
}
problem solved?
But really - it's going to be a question of the cost of your test (generally more than just if (boolean)) and the cost of your assignment (generally more than just primitive = x). If the test/assignment is expensive or your loop is long enough or you have high enough performance demands, you might want to break it into two parts - but all of those criteria require that you test how things perform. Of course, if your requirements are more demanding (say, b can flip back and forth), you might require a more complex solution.

Performance issue finding weekdays over a given period

I have some methods that return the number of weekdays between two given dates. Since calling these methods become very expensive to call when the two dates lie years apart, I'm wondering how these methods could be refactored in a more efficient way.
The returned result is correct but I feel that the iphone processor is struggling to keep up and consequently freezes up the application when I would call these methods over a period of say 10years.
Any suggestions ?
//daysList contains all weekdays that need to be found between the two dates
-(NSInteger) numberOfWeekdaysFromDaysList:(NSMutableArray*) daysList
startingFromDate:(NSDate*)startDate
toDate:(NSDate*)endDate
{
NSInteger retNumdays = 0;
for (Day *dayObject in [daysList objectEnumerator])
{
if ([dayObject isChecked])
{
retNumdays += [self numberOfWeekday:[dayObject weekdayNr] startingFromDate:startDate toDate:endDate];
}
}
return retNumdays;
}
-(NSInteger) numberOfWeekday:(NSInteger)day
startingFromDate:(NSDate*)startDate
toDate:(NSDate*)endDate
{
NSInteger numWeekdays = 0;
NSDate *nextDate = startDate;
NSComparisonResult result = [endDate compare:nextDate];
//Do while nextDate is in the past
while (result == NSOrderedDescending || result == NSOrderedSame)
{
if ([NSDate weekdayFromDate:nextDate] == day)
{
numWeekdays++;
}
nextDate = [nextDate dateByAddingDays:1];
result = [endDate compare:nextDate];
}
return numWeekdays;
}
You need to create an formula to calculate the number of weekdays rather than loop thru each day and count them.
Something like this (this is a rough approximation), where startJD and endJD are the Julian Dates:
nWeekdays = (endJD - startJD) * 5 / 7;
Of course that's close but not exact since it doesn't take into account what day of the week it starts and ends on. But that's the general idea, you need a formula, not a loop.
You can also find quite a bit on this topic by searching.
Why not look at the core foundation classes that handle dates?
CFAbsoluteTimeGetDayOfWeek
Returns an integer representing the day of the week indicated by the specified absolute time.
SInt32 CFAbsoluteTimeGetDayOfWeek (
CFAbsoluteTime at,
CFTimeZoneRef tz
);
Parameters
at : The absolute time to convert.
tz : The time zone to use for time correction. Pass NULL for GMT.
Return Value :
An integer (1-7) representing the day of the week specified by at. Per ISO-8601, Monday is represented by 1, Tuesday by 2, and so on.
Availability
Available in iOS 2.0 and later.
Declared In
CFDate.h
More can be found at: http://developer.apple.com/library/ios/#documentation/CoreFoundation/Conceptual/CFDatesAndTimes/

Is sscanf thread-safe on iPhone OS 3.1.2?

I was just spending my whole day debugging a random bug when i finally realized the Problem was sscanf being called from multiple threads.
I confirmed by running the following code which works as expected on Snow Leopard but produces very strange results on my iphone with os 3.1.2. It also works fine in the Simulator.
On the iPhone the parsed number will be a somewhat random combination of the digits used in the strings.
It would be very helpfull if anyone could check if this is a general Problem or if it's a mistake on my side.
- (void)testIt
{
[NSThread detachNewThreadSelector:#selector(scanfTest) toTarget:self withObject:nil];
[NSThread detachNewThreadSelector:#selector(scanfTest) toTarget:self withObject:nil];
}
- (void)scanfTest
{
while (true)
{
float value = 0.0f;
sscanf("456", "%f", &value);
sscanf( "1.63", "%f", &value);
if (value != 1.63f)
NSLog(#"strange value is %f", value);
}
}
I did some further checking and it appears only floating point numbers are an issue.
This code works
- (void)scanfTest4
{
while (true)
{
int year = 0;
int month = 0;
int day = 0;
sscanf("20090131", "%4d%2d%2d", &year, &month, &day);
sscanf("19840715", "%4d%2d%2d", &year, &month, &day);
if (year != 1984 || month != 7 || day != 15)
NSLog(#"bla");
}
}
And this code fails with the same random digit issues
- (void)scanfTest4
{
while (true)
{
int year = 0;
int month = 0;
float day = 0.0f;
sscanf("20090131", "%4d%2d%2f", &year, &month, &day);
sscanf("19840715", "%4d%2d%2f", &year, &month, &day);
if (year != 1984 || month != 7 || day != 15.0f)
NSLog(#"bla");
}
}
SUSv2 says (Threads):
All interfaces defined by this
specification will be thread-safe,
except that the following interfaces
need not be thread-safe
sscanf() is not on the list of interfaces which need not be thread-safe.
This is not to say that the iPhone is SUSv2-compliant, but I think at least it explains why your code should be expected to work on Snow Leopard. Also I don't have a more recent POSIX spec to hand, so I'm taking a bit of a risk in assuming it hasn't changed since 1997.
sscanf is not thread safe PERIOD. it was written before threads existed its design requires it to use internal static temp variables. the same is true for sprintf.
I your case, sscanf is overkill anyway. just use atof instead.
Thank you John and Stephen!
I can confirm that both atof and strtof are safe to use in this situation.
If I may ask, why do you need to use sscanf/atof when you can use the NSString numeric conversions?