CS193p Assignment 4

I started working on Assignment 4 of the CS193 fall 2011 course.

• Flickr API - I got the Flickr API working and am able to access the top locations and photos per locations. I did have a bit of trouble figuring out the data structure that Flickr is giving. I got mixed up in Array’s and Dictionaries. Why does the flickrFetch API give an NSArray and not an NSDictionary?
• Storyboard - I had a lot of trouble getting a good storyboard. However after seeing Lecture 10, I decided to delete everything and restart from scratch. Just as Paul Hegarty did during the Lecture. And then everything went pretty smooth;
• Place Photolist - Getting the Photlist for a specifc place working got me bogged down for a while. Until I realised that I did not check the Segue identifier in the right way. I used ‘==’ and not ‘isEqual:’. After that it worked well;
• Spinner - I copied the Spinner idea from teh Lecture, but nothing happens. Do not know why;
• Description dictionary - I was not able to get the information on the description through the ‘description._content’-key. So I had to take the long way to retrieve it;
• Title and description length - the lenghts of these two items is much longer than the screen width. What is the best way to present them?
• Photo location list segue - I do not understand how this segue works. You do not have to set something up. Just add the segue to a table view controller seem to be enough to have it respond to a row selection? From where should I setup the segue? The window? the table? the cell? The window as anchor works with a performSegue: in didSelectRow:, but why?)
• Titles - I have been playing with the window titles a bit in order to display city name and or photo title. I would like to limit the number of characters and append a ‘...’ at the end. If I use a minimum size that is to large I get an error message. So I must take into account the maximum allowed length. Still have to work on that;
• Photo display - I got the photo displaying working, but I am not able to set it to fill with UIContentMode. Do not know what is wrong;
• iPad - I had to rewatch the course on the iPad to see how it worked again. Setting up the storyboard was reasonable straightforward. I had to remember to setup the photoViewController as detailedView. And to not use segue to present photo’s. It seems to be working. I have now to address the details;

 

Categories: Computing • cs193p
PermaLink • Comments

CS193p Post Assignment 3 thoughts

I finished assignment 3 now, apart from the content scaling thing.

In course 9 the TableViewController was introduced. I added the instructions as given during the course. It all worked like a charm. I did however a few things a bit different: all buttons were added to the toolbar in the iPad storyboard.

Paul Hegarty was not able to all the relevant things in the course, so extra code was posted on the website. I folded all the posted code into my code. I used a slightly different approach to the iPhone storyboard: I added a toolbar at the bottom of the GraphView and put the formula, switch and add to favorites in there.

I am however left with one problem: the swipe gesture does not work. I still have to find a way to debug this. At the moment I am lost. It seems that the swipe-gesture is not recognized.

 

Categories:
PermaLink • Comments

CS193p fall 2011 resources

This post gathers interesting resources I found for the fall 2011 course.

The official material can be found on the course website at Stanford and on iTunesU. These lectures are based on Xcode 4 and iOS 5, so the older solutions are no longer applicable. There can be some help found in a corresponding Google Group.

There are multiple people that I are following the course:

• DJ Chung - explicit info on assignment 2;
• Adam Lung

I found various solutions on the web, which work as inspiration.

Assignment 1 (Simple Calculator)

• Implementing pi discussion
• maxkostow - combined code for assignment 1-3;
• macuenca - assignment 1 only;
• floating point - some solutions;

Assignment 2 (Programmable Calculator):

• Geekapproach - looks like an interesting solution to evaluate the expression;
• maxkostow - combined code for assignment 1-3;

Assignment 3 (Graphing Calculator):

• maxkostow - combined code for assignment 1-3;
• Jeffrey Lam - solution does not seem to use a datasource;

 

Categories: Computing • cs193p
PermaLink • Comments

CS193p Assignment 2 thoughts

In this post I gather some thoughts on the assignment 2:

• protocols - for the iPad application to work one has to define a protocol in a separate-file. I just followed the directions in the lecture, but I am still at a loss how this works;
• error handling - in one of the earlier assignments one had to implement some error handling (division by zero). This should also propagate to the Graphing Calculator, which I did not implement;
• Points vs. pixels - the assignment asks to use this conversion in order to have the app working on retina displays. So I added this scale factor and thus doubled the number of calculations. However it does not seem to make any difference. So I am lost here;
• drawing mode - I had some problems implementing the drawing mode (line vs points). I added a segmented switch to the iPhone and iPad GraphController views. These call a method drawingModeChanged in the GraphController, which in turn changes the corresponding instance variable in Graph. But I was not sure in what method to set the drawing mode. After some experimenting I found the right one (tell you later which one);
• Xcode crash - I experienced a heavy Xcode crash. The application would no longer star with my project. I tried to use Time Machine to get a valid version back, but that did not work. So I recreated the project and pulled in the old files one by one. I was able to pull them all in without any problems. So I guess one of the project-files got corrupted;
• Profile - the final part of this assignment involved optimizing the code for the pinching gesture. I did not finish this, as it seemed to involved a lot of rewriting. I guess that one has to use a CGContextScaleCTM to change the scale;

Categories: Computing • cs193p
PermaLink • Comments

IOS programming

And again I started learning IOS-programming. The last time I did finish the book by LaMarche for beginners. However I did not feel confident enough to work on my own. I started with the CS193p course that was then available, but got bogged down in mismatching courses and materials.

So a new year seem to be a good start to begin. I found out that in the mean time Xcode was heavily changed and IOS moved to version 5. This implied that I really had to start from the beginning. I am now up to course 7 and finished assignment 2.

 

Categories: Computing • cs193p
PermaLink • Comments

Bundle time

It seems that it is the time of the year for all sorts of bundles.

The bundle of Productive Macs looks at productivity apps, such as Fantasical, BusyCal, Home Inventory, NotBook, Folder X, LaunchBar, Cashculator and Tags. They offer also some prize. Anyway the bundle is not for me, I have already enough related apps. I like the prizes though, such as Hype.

The MacUpdate bundle seems more interesting with TechTool Pro, IconBox, TotalFinder, Postbox 3, FontPack pro Master, Labels&Adresses;, Mac DVDRipper Pro 3, Back in Focus, NeverWinter Nights, Hear, iClip 5 and FolderSynchronizer. I like TechTool as I have not really something comparable. TotalFinder looks interesting. A DVDRipper useful (Handbrake?). Back in Focus and iClip (have an old version).

Categories: Computing
PermaLink

Effect of eccentricity

Simultaneous fitting two transits of an eclipsing binary is not evident. It is not allways clear how the various parameters interact. For SPH10003247 I used this approach:

• start fitting the secondary (shallowest) transit by changing the relative luminosity of the stars. A luminosity ratio of 0.55 matches the secondary transit. And also the primary transit can be matched (black lines in figure). A further increase (say 0.52) of the luminosity difference will make the secondary transit to shallow. A decrease (0.6) will make the primary transit not deep enough.
• A shallow secondary transit can also be produced by having a size difference between the two stars. Increasing the size of the secondary star to 1.26, will produce the right secondary depth. However this will not produce the right depth of the primary transit. The advantage of a size ratio is also that we will have a flat transit as we have in the data.
• Using a luminosity difference seems to be the preferred explanation. The next thing we need to explain is the shape of the bottom of the transits. Unfortunately any change to the size ratio will make the depths shallower, so a correction to the luminosity ratio must be applied as well. Thus we need to increase the size of the secondary star whilst decreasing the luminosity ratio. Unfortunately at a size ratio of 1.15 and brightness ratio of 0.72, the primary transit is no longer deep enough.
• It is also possible to move in the other direction: decreasing size ratio and increasing the luminosity ratio. It is not possible to go below a luminosity ratio of 0.52. At this ratio the secondary star is fully occulted by the primary, and thus the depth of the secondary transit defines this luminosity ratio.
• In order to explain the transits, I need to work with a third parameter: the linear limb brightening coefficient. Standard this is set at 0.6, but in practive it can vary wildly depending on the star. By decreasing this factor to 0, I can increase the lumiosity ratio to 0.46 and decrease the size ratio to 0.88. This still does not explain the observations: the secondary transit is to narrow and the primary transit is to shallow. The size ratio must be as small has 0.77 to explain the width of the secondary transit (red lines in figure).

Thus my current model does not work to explain these observations. I need to have other parameters that I can tune. There seems to be one assumption to many in my model.

This eclipsing binary has an eccenctric orbit as can be seen from the centers of the transits (0.0985 and 0.7561). Thus my assumption of a circular orbit does not hold. There might be a difference in apparent radii due to the orbit. A change from 0.95 to 0.77 is then needed, to explain the observations.

The difference in transit timings reveals at least a minimal eccentricity of 0.25, which corresponds to a relative distance variation between the two stars of 1.6. This might thus explain why my circular orbit does not work. So I need to refine my model to incorporate eccentricity. (Literature used Russell (1912) and Sterne (1939).

Categories: Science
PermaLink • (1) Comments

Tatooine star analysis

This a very interesting object: a double star with a planet circling around it. The excellent analysis of the previous posters seems to be the best solution. I wondered however if I would be able to expand on that by adding some numbers. Unfortunately most of the published formulae do not work here, as they all assume that the occulted star is stationary, which is certainly not the case here. So I had to invent some stuff to get to an extended explanation.

The first step involves the double star. As the transits have equal depth and are close to 50%, so both stars are assumed to be equal in size and the orbital plane (circular) has an inclination angle of 90 degrees. Thus we see the orbit edge on. The orbital period can be determined from two transits (i and i+1 - the two green transits) and is 2.976 days. Normally the width of a transitcan be used to calculate the half-major axis of the orbit. However formula 3 of Seager&Mallen;-Ornelas (2002) assumes however that the occulted star does not move, which it does in this case. Thus the observed width (0.13 days) must be doubled to get the correct one. From this the hal-major axis can be determined as 11.3 stellar radii.

To determine the movement of the planet, better timings of the transits are needed. In order to make the three extra transits more clear I subtracted the LC of the double star. This was done by shifting and overlaying an adjacent LC and then subtracting the two. The blue and green lines show where the transits were. The dots shows the results of the subtraction. And you as well that the subtraction did not succeed 100%.

Then these three transits were fitted to determine the transit times. The dermined values, such as the width (T) and impact parameter (b) have not much significance, as the formulae assume a static object. Using the start of the ingress of the first transit (day 55023.31) and the end of the egress of the third transit (day 55024.94), we can determined the speed of the planet. The model of the double star indicates where the stars are and by putting the planet next to the star, we set the position of the planet. I used the configuration indicated by @kianjin in his last animation as starting point.

This resulted in the following animation, which confirms @kianjin’s results. The first transit happens just as star 1 is turning prograde. The planet starts the transit and then star 1 speeds up and moves out under the planet. Transit 2 is when the planet passes in front of star 2. Star 2 is then retrograde, which results in a small transit width. Transit 3 happens when star 2 is retrograde.

Interestingly in the animation a fourth transit happens, when the planet transits star 2 again. This fourth transit really isn’t in the data. I checked whether there isn’t any small grazing one. It turns out that this transit only occurs due to the position of the viewer in this 3D-animation. I am not able to undo this perspective (yet) and hence the animation does not allow to read the transit times.

I have a 2D-animation as well, which allows me to put the observer at infinity. In this animation the blue line represents the planet and viewing direction. I can not determine the distance of the planet, as we have no period as yet.

To be continued…

 

Categories: Science
PermaLink • Comments

Transit fit evaluation

This object is known under the identification of Kepler ID 6850504, SPH 21522290 and KOI 70. Four planets have been detected around this planet. This is a good object to check my algorithms against the official ones. The official data of the objects found here are:

ID	duration	depth	t0	period	a/R	r/R*	b
	(hr)	(ppm)	(day)
KOI 70.01	3.798	1027	71.609	10.854042	20.000	0.030	0.49
KOI 70.02	2.478	375	67.501	3.696125	6.200	0.021	0.85
KOI 70.03	7.238	793	97.729	77.609000	83.390	0.026	0.198
KOI 70.04	2.770	74	68.930	6.09852	16.000	0.008	0.40

My data (algorithm 8):

ID	duration	depth	t0	period	a/R	r/R*	b
	(hr)	(ppm)	(day)
KOI 70.01	4.69	990	-	10.8545	-	0.041	0.93
KOI 70.02	2.98	368	-	3.6962	-	0.025	0.95
KOI 70.03	8.753	869	-	77.60	-	0.039	0.94
KOI 70.04	2.93	83	-	6.09852	-	0.012	0.94

The periods founds are similar to 4 decimal accuracy. Adding 7 quarters of data leads to a better accuracy of 2 extra decimals. The other basic parameter of a transit is its depth. The depth difference is -4%, -2%, 10% and -10%. I regard this as OK for the data that I have.

The other three parameters: r/R*, b and duration are all related, so have to be viewed together. The most remarkable is that my detected radii are systematically to large (37%, 19%, 50% and 50%). But also my values for the impact parameter b are much larger. In fact the radii matches best, where the impact parameters do match (KOI 70.02). Thus the impact parameters seem to be the culprit of this difference. When I use the published impact parameters to calculate the radii, I get much smaller differences (9%, -10%, 12% and 12%). These errors seem reasonable as they are comparable to the related errors in depth.

The problem seems to be related to the impact parameter that I determined and the limb darkening model that I used. For small impact parameters (<0.4), the results are similar. The impact parameter influences the slope of the ingress and egress. This effect is mostly seen at the start and end of the ingress: for low impact parameters the descent starts quickly and is done within 0.2 hours. Limb darkening influences this slope as well, but most of all the roundness of the bottom of a transit. This does not influence the rate of descent/ascent.

So the slope of the model seems to steep compared to the data. For KOI 70.01 however the relation between flat and total duration is 99.9% (using Seager&Mallen;-Ornelas formula 2). Thus the steep parts of the transit seem correct.

Then the culprit must lie in the rounding effects due to the limb darkening model. A linear model with parameters varying from 0 to 1 do not provide the right slope. One can improve the situation somehat with a quadratic limb darkening model, but still the right slope is not reached.

In addition any linear limb darkening model in combination with a large impact parameter requires the size of a planet to be larger in order to get the right depth of the transit. This is logic: as the transit occurs further away from the center of the stellar disk, even at maximum transit, the depth is less deep due to limb darkening

In conclusion, I seem to have reached the limit of the model I used in my calculations. The model can not explain the observed slope without reverting to a large impact parameter. The solution seems to lie in the limb darkeing model that have been used.

A more detailed discussion of the individual transits follows.

This is a very interesting lightcurve as transits of 4 different objects have been discovered. The figure shows part of the light curve where all these transits can be seen. The yellow lines are for an object with a period of 77.6 days, the green have a period of 10.8545 days, the red lines have a period of 6.09852 days and finally the lilac lines have a period of 6.09852 days. The transits of this last object are very difficult to see on the light curve (I’m not sure whether I plotted them right). If you see the transit fit later, you’l see why. I took the period from the one that was published by the Kepler team. The other ones I derived myself.

The Q1-Q3 data was folded on 10.8545 days. The transit can be fitted with a relative radius of 0.041, an impact parameter of 0.93 and a linar limb darkeing factor of 0.65.

The Q1-Q3 data was folded with a period of 77.6 days. In the Q1-Q3 period there are only 3 transits. The transit can be fitted with a relative planet radius of 0.039, impact parameter 0.94 and limb darkening factor of 0.65.

The Q1-Q3 data was folded with a period of 3.6962 days. Fit (red line) with a relative planet radius of 0.025, an impact parameter of 0.95 and a limb darkening factor of 0.6. Green line is a 21-point smooth.

The Q1-Q3 data was folded with a published period of 6.09852 days. The fit was made with a relative radius of 0.012. I kept the other parameters the same as the other transits. Total transit time is 2.93 hours.

Categories: Science
PermaLink

Hunting planets

A few ways back I started playing with the Zooniverse websites: doing astronomy at home. I started with hunting for ice planets and then moved to hunting for planet in the Kepler data (planethunters). And I am still working on that.

I like this site, as it allows me to download the corrresponding data and playing with it. I downloaded the Plot application and started writing macro’s in perl for my needs. This results in images such as this one:

This images shows a folded lightcurve, thus showing the passage of planet.

 

Categories: Science
PermaLink

Visiting Copernic

Last tuesday I visited the Copernic observatory. Every tuesday in july and august they have an open evening when people from the public can use the telescopes and get some xplanation about the heavens. It was some time ago I went, so it ws very to see that they now have a 52 cm reflector.

I used it to look at some open clusters and a globular cluster. Also M51 was nice, but even with such a telescope there is just some fluff. The small telescope was used to look at the the Dumbbell nebula and some close binaries (epsilon Lyrae and gamma (arrow)). I tried gamma later at home and was able to distinguish the two stars at 8 arcsec separation. I did not try epsilon lyrae as it was in the zenith, which is very awkward with my telescope.

Now I have to return to view the comet.

 

Categories: Science
PermaLink

Moving to Lion?

Now that a new version of MacOSX is coming, I have to wonder whether I want to upgrade again. This is unfortunately just a theoretical question as I’m still on PowerPC and I was left behind on Leopard. I use this article by Alex Layne (hmm Leene?) as a guidance to have a look at Lion.

Mission Control / Exposé - I am a big user of Exposé, so I would probably like the subtle changes in Lion.

Mission Control / Dashboard - I use it everyday to check the weather, the activity browser or access the dictionary, but that is it. I never add new widgets. So the addition to Mission Control is not a big deal for me.

MissionControl / Spaces - another feature that I use a lot. I do not get the impression that the changes impact my usage.

MissionControl Launchpad - I do not see that I will use this. Normally I start apps through the Dock or through Spotlight. If I do not remember the name of an app I descend into Finder. Here Launchpad could be a replacement. It reminds me as Finder with an icon view. I guess it comes all down to gesture support, which I do not have anyway.

I do not see how the integration into Mission Control works out. Just a question of gestures as well?

Autosave, versions - sounds like a very interesting development. There were already some applications (Sandvox comes to mind) that had this idea implemented and I liked that.

Resume - sounds like a good idea as well. An application like Omniweb had this already.

All in all this does not sound like an impressive update. The OS just evolves slowly. I will keep up, but I am not under pressure to update.

 

Categories: Computing
PermaLink

Learning iOS

I restarted my activity learing iOS. I bought the book “Beginning iPhone 3 development” by Dave Mark and Jeff LaMarche. This is much easier to follow than the CS193 course. I might pick-up that course once I got some more experience. Current book is mainly geared towards learning the interface libraries for iOS (iPhone). And I miss the library changes for the iPad.

I follow the corresponding forum for the book and created a FAQ for each chapter. So I can more easily see what kind of changes and suggestions have been made.

I am now at Chapter 9, so I am progressing well. Every day I work for several hours. Still some pages to go.

I already notice however that I miss some Objective-C basics. So I might also get a more basic book, before I start on my won project.

 

Categories: Computing
PermaLink • Comments

Financial App requirements

After trying several financial applications, I realised that I should formulate my requirements more formally. Several applications seemed to fit my needs, but failed after using them for a while. So with this post I will define my requirements. I might edit this post when I get more details.

• Import - this is one of the most important requirements. The applications should be able to import the files, that I get from my banks. Thus it should be able read OFX-files, which I get from Credit Agricole. It should be able to read CSV-files, which I get from the ING Bank. Latter demand seems to be a bit to much. I can convert CSV-files to QIF-format with QIF-Master, so as a third option QIF is really required. Control over number and date format is desirable (although fiddling with the international settings can help);
• Create/Edit - it should be easy to create and edit new transactions. I prefer inline editing;
• Export - the application should be able to export all data, either into OFX, QIF or CSV. As I have multiple accounts in a single set, I like to export as a single file. QIF seems to support only a single account per file. It seems that I must have control over the date and number formats, both for exporting and importing. Several apps introduced errors here;
• Document-based - I am not sure whether I use the correct terminology here. I want to save multiple sets of financial accounts as separate documents. I have to manage four different of such sets. Hiding those all those sets in a single document can be very difficult when creating reports;
• Filter - I would like to easily zoom in on a set of transactions by specifying a string. This can be to search for a certain amount or transaction made by a person. This is a like search, but then easier;
• Splits - support for splits is desirable. I do not have much experience yet with it, but I found it already useful, just for noting down some details;
• Categories - I would like to set a category (or tag) for each transaction, so that I can see what happens per category. I would also like to have subcategories, although there might be a way around it;
• Reporting - this requirement is the most difficult as it has many subsets that I need;
• Time-ranges - I would like to see what happens in certain times ranges, i.e. per month, per year (this, previous) or a range specified by me. I need the monthly reporting for a specific category for my taxes;
• Across accounts - I like to see what happens to all transactions (or in specific categories) summed over all accounts. Many applications do not support this kind of summation;
• MacOSX adherence - an application should adhere to MacOSX-standards as much as possible. Clear ports will only annoy me.

Categories: Computing
PermaLink

WebCam Monitor

One of the first experiments is to seen what can be done with the camera through the WebCam Monitor application. The application allows you to record audio and/or video through the menu-bar of the application Also the size of the video can be set in the menu (full, half, quarter size). This menu must also be used to record the video. My settings here are to disable audio and to use full size.

An addition there is a preferences window with multiple sub-screens.

The first screen is the Adjustments-screen, which allows to change the hue, saturation, brightness, contrast and sharpness. The problem is to know what these sliders do as there is no documentation. Normally hue and saturation refer to colors on a color wheel. I would not want to fiddle with these settings and take what I get as raw input. Brightness is related to the amount of white versus black. As I want to detect weak object, a large brightness seems logic without overexposing the image. I guess that contrast relates to the difference between dark and light. This seems import to see the weaker objects. I am not sure what sharpness exactly is. It gives the impression of smoothing over multiple pixels. I guess I have to experiment with these sliders to see what they do exactly and what are my best settings. I have the impression that this screen relates to the software of the WebCam Monitor application.

The second screen is the Compression screen. For some reason this screen a bit damaged. I might have to do a reinstall.

This screen seems to relate to the output. Whether the video is compressed and how. In fact I do not want any compression and I need only a few frames per second.

The third screen is called the SN9C102 screen, so I guess this is the interface with the chip itself.

This seems to be the more interesting screen, but still it is unclear what it does. Gamma is about the color, but what is the best setting? Exposure time sounds interesting, but what does it do in context to movie frames. Anyway more seems better. White Balance must be set thuis that there is no difference between colors. Gain must be low for bright objects and high for weak objects. The video format chosen will be close to native, thus CIF (352x288). I have also the possibility to chose VGA or Mpeg, but I rather take the most raw data. I do not know what Flicker frequency does. Rotate 180 is checked as the telescope creates upside-down images.

The SN9C102 Digital Zoom setting is simple. I do not want any.

Finally there is the sources screen. I set this one to the TAS5110D WebCam/Camera setting. The macam #0 does not seem to work.

In conclusion there are many unknowns and I must experiment. I would like to find a way to calibrate things.

 

Categories: Science
PermaLink