Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

learning java



On Thu, Apr 29, 2004 at 10:20:23PM -0400, Duane Morin wrote:
[bit counting]
> > I'm also curious about what some of the other suggested solutions were...  
> 
> Mostly variations on the bit mask idea.  It's interesting to see how 
> people try to make a bitmask.  Somebody recently tried to use logarithms
> to do it.  Some folks shrug and say that since the primitive is of a 
> fixed length then don't even bother with a loop, just unroll it and have
> 32  "if (x & (1<<y) != 0) total+=1;" lines, changing Y.

In C at least, this is a little silly.  It's a lot of typing, and you
can just tell your compiler to unroll loops for you.  But I suppose it
counts...

> Some folks create bit masks of size N which allow you to count the bits
> at in M/N passes, instead of M, which is neat.  For instance if I said
> that the problem was to count bits in a byte array then a good solution
> might be to just create a 256 entry bitmask table of all the 8 bit
> combinations, then just look up each byte's value in the table.

I see.  Speed/memory tradeoff.

> > > creating several million Integer objects when it can be done by only 
> > > creating 100k.
> > Not knowing Java, I couldn't write the code to do it; but the obvious
> > solution seems to be to create a hash with the string as a key, and
> > the frequency would be the value.
> 
> The trick is that you can't store primitives in collections in Java, so 
> people end up having to create a new Integer object just to increment the 
> value they already stored.  Thus, a new Integer for every entry in the
> original array, rather than just a new integer  only when you create a new
> entry in the hash table.

That seems... limiting.  I guess then, I would probably define my own
class to solve this problem.  Or use some other (currently unknown to
me) feature of Java to solve it.  Interesting.

> > > * Crawl all the HREFs out of a given HTML file.
> > Here I would definitely apply the Google defense...  ;-)
> 
> Aw come on, a little Perl and it wouldn't be that hard.  Actually when 
> this question is asked the real interesting bit is to ask how long the 
> candidate thinks it would take.  If they say 2 weeks, hmmmm.....

What I meant was that Java probably has some clever classes and
methods for doing this very easily, and I don't know what they are.
But maybe it doesn't.  And it's trickier than it might at first seem
to someone who doesn't work with URLs very often.  For example, to do
it right, you need to be able to deal with encoded URLs, and URLs that
contain spaces...

> > LRU caches seem particularly of interest to people writing
> > database code or operating system code, and not much else.  
> 
> And, truthfully, I haven't asked this question, another one of the guys 
> here has.  It's quite common to ask programming questions using real 
> problems that the team is dealing with.  We have an admitted bias toward
> candidates with a formal CS education, for good or bad.  So somebody
> should at least know what LRU means, for instance, and be able to take a
> stab and how you'd implement one.  It by no means has to be perfect.  It's
> more of a "Let me listen to how you think...." problem.

That seems reasonable enough...  :)

-- 
Derek D. Martin    http://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail.  Sorry for the inconvenience.  Thank the spammers.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.blu.org/pipermail/discuss/attachments/20040430/51908abe/attachment.sig>



BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org