This morning, I noticed a new entry on Flickr's blog saying that they have added 'Collections', i.e. sets of sets. Although I haven't played with it yet (it requires paying for Flickr Pro... which I probably won't do any time soon as I have my own server and software that hosts my pictures), they say that it supports 5 levels of nested collections (I suppose this is reasonable, although it seems a bit arbitrary). This has to be the single most blatantly missing feature that would be required by any power user. At this point, I have my collection of approximately 37,000 digital photos is organized using over 2,100 folders. If I don't have multiple levels of folder organization, it's basically rendered useless for browsing.
In the process of playing with Flickr today, I discovered that the Geo-tagging map search supports Japanese place names (I did a search for 京都), but the map resolution for Japan (both satellite and roads) is so poor that it's basically useless for tagging much below the city level. Google Maps is clearly ahead of Yahoo Maps in this regard. I also discovered that Flickr supports unicode search, but mostly treats Japanese text as a single word, so a group search for "源氏" would not return a group containing "源氏物語" in the title. Didn't do an extensive test, so I don't know if they are at least breaking words at Kana/Kanji boundaries or not.
Wednesday, March 14, 2007
Thursday, March 01, 2007
What other development system could get away with this?
Last semester, I did a class project where I compared a couple of approximate matrix decomposition methods for their ability to restore removed photo annotations. Since I already had an experimental frame created for this purpose in Matlab, I decided to continue developing implementations of the additional methods I was interested in comparing in Matlab as well. One of the methods I wanted to compare was Mor Naaman's neighboring time context, which of course requires date comparisons (rank annotations by the number of photos associated with them among pictures taken with X seconds of a candidate photo). This should be a simple built-in function call and, although somewhat annoying to deal with due to complexities of the Gregorian calendar, has been done in many other languages/frameworks (Java, C#, etc.). Looking around the Matlab documentation, I find the following 'Limitations' section of the etime() function:
"As currently implemented, the etime function fails across month and year boundaries. Since etime is an M-file, you can modify the code to work across these boundaries if needed."
What the heck? Not only is it not implemented correctly, they laugh in your face and just tell you to do it yourself. Further investigation reveals a copy of the docs with a 1994 copyright date containing a similar cop out! They've been sitting on this fix for 13 years! Searching around the web, I failed to find someone who had bothered to do this and share the library. "Great," I say to myself and proceed to add the value of C#'s DateTime.GetFileTime()'s function (which returns a long with the number of 100 nanoseconds since 1601). Granted, I only have second resolution on my photos anyway. Having look through Matlab's data types previously,
I know it has int64's, so there should be no problem. That is until I actually try to run it and I get the following error:
"As currently implemented, the etime function fails across month and year boundaries. Since etime is an M-file, you can modify the code to work across these boundaries if needed."
What the heck? Not only is it not implemented correctly, they laugh in your face and just tell you to do it yourself. Further investigation reveals a copy of the docs with a 1994 copyright date containing a similar cop out! They've been sitting on this fix for 13 years! Searching around the web, I failed to find someone who had bothered to do this and share the library. "Great," I say to myself and proceed to add the value of C#'s DateTime.GetFileTime()'s function (which returns a long with the number of 100 nanoseconds since 1601). Granted, I only have second resolution on my photos anyway. Having look through Matlab's data types previously,
I know it has int64's, so there should be no problem. That is until I actually try to run it and I get the following error:
"Function 'minus' is not defined for values of class 'int64'."
What??? Further reading of the docs reveal the following:
"Note The arithmetic operators do not support operations on the data types int64 or uint64. Except for the unary operators +A and A.', the arithmetic operators do not support operations on complex arrays of any integer data type."
Who the heck doesn't bother to implement long arithmetic? In version 7.2 of a product? That is sold for hundreds of dollars? And why do they even support loading data into int64's if you can't do anything with them once they are loaded? To be fair, I found some docs from version 6 that had just announced the support for int64 comparison operators. Wonderful.
Fortunately, for my implementation, I realized that I was only using 12 digits of precision for my data's time values... so I just had to stick my 'long' data into a double and that was good enough to get my experiment working (although making me feel dirty in the process). I do have to wonder what the engineers at MathWorks are actually doing, if they haven't bothered implementing such basic things.
What??? Further reading of the docs reveal the following:
"Note The arithmetic operators do not support operations on the data types int64 or uint64. Except for the unary operators +A and A.', the arithmetic operators do not support operations on complex arrays of any integer data type."
Who the heck doesn't bother to implement long arithmetic? In version 7.2 of a product? That is sold for hundreds of dollars? And why do they even support loading data into int64's if you can't do anything with them once they are loaded? To be fair, I found some docs from version 6 that had just announced the support for int64 comparison operators. Wonderful.
Fortunately, for my implementation, I realized that I was only using 12 digits of precision for my data's time values... so I just had to stick my 'long' data into a double and that was good enough to get my experiment working (although making me feel dirty in the process). I do have to wonder what the engineers at MathWorks are actually doing, if they haven't bothered implementing such basic things.
Subscribe to:
Comments (Atom)