Of Time and Integers
Hi,
Tonight two things.
Importer time/date
I've had a problem for a while which looked like the Python datetime reporting daylight savings time/summer time for all the LWC timestamps. I thought this was unlikely, but then again the other options looked more unlikely. I tried creating an UTC tzinfo class - but it didn't help. Today I created a new function from scratch to calculate dates from a reference by hand and had to write some unit tests (been using doctest ... very good and quick) - something I was trying to avoid when I used datetime (i.e. thinking). Well, I realised (once my routine was working) I could have used these unit tests to determine how the original actually worked. DOH! Oh well. Anyway, that just leaves LWC and the operating system itself. I'm not sure I'm any better off than an unexpected operation in Python. Email to Stu sent - see what he says... (probably: look in 'this' LWC source file - but we don't do anything ourselves... I say this because I'm pretty sure I looked in the relevant source files a couple of months ago and I'm not sure it does anything apart from call the OS.)
Next up in the importer: Check thousands of conversions by eye. Oh the joy.
MouseRobot
Finished checking over the integer trig. version of the code. I was thinking all the time: 'I wonder how well the ARM7 would run single precision float'. Not sure it would be quicker to code now (after spending the time on the integer version) - but if I have scaling problems, I'm really going to take a look rather than hack the integer routines. 3 significant figures hopefully will be good enough through all the calculations. Now time to run it in the RedExtract test program before moving it to the actual embedded code to check the results. Does it work? Of course it doesn't. Oh well, debug mode, I guess.
Tonight two things.
Importer time/date
I've had a problem for a while which looked like the Python datetime reporting daylight savings time/summer time for all the LWC timestamps. I thought this was unlikely, but then again the other options looked more unlikely. I tried creating an UTC tzinfo class - but it didn't help. Today I created a new function from scratch to calculate dates from a reference by hand and had to write some unit tests (been using doctest ... very good and quick) - something I was trying to avoid when I used datetime (i.e. thinking). Well, I realised (once my routine was working) I could have used these unit tests to determine how the original actually worked. DOH! Oh well. Anyway, that just leaves LWC and the operating system itself. I'm not sure I'm any better off than an unexpected operation in Python. Email to Stu sent - see what he says... (probably: look in 'this' LWC source file - but we don't do anything ourselves... I say this because I'm pretty sure I looked in the relevant source files a couple of months ago and I'm not sure it does anything apart from call the OS.)
Next up in the importer: Check thousands of conversions by eye. Oh the joy.
MouseRobot
Finished checking over the integer trig. version of the code. I was thinking all the time: 'I wonder how well the ARM7 would run single precision float'. Not sure it would be quicker to code now (after spending the time on the integer version) - but if I have scaling problems, I'm really going to take a look rather than hack the integer routines. 3 significant figures hopefully will be good enough through all the calculations. Now time to run it in the RedExtract test program before moving it to the actual embedded code to check the results. Does it work? Of course it doesn't. Oh well, debug mode, I guess.
posted by RobZed at 9:48 pm
0 Comments:
Post a Comment
<< Home