>>1
they smell good and you can pick fruits and stuff of them.
you should go more outside.
Name:
Anonymous2010-05-28 15:08
They're good for making paper, for one thing.
Name:
Anonymous2010-05-28 15:10
trees are used to group data for fast lookup.
*b-trees are used in sql databases to make greater than less than lookups work quickly.
*r-trees are used for spatial indexing.
*distributed hash tables can provide fast lookup of peers in a decentralized network by organizing nodes into a tree.
Name:
Anonymous2010-05-28 15:18
>>5
And how are those better than basic hash tables?
Trees are useful in very special circumstances, you never need to know them for general tasks and when you need them you'll find an implementation easily.
Numbers are useful in very special circumstances, you never need to know them for general tasks and when you need them you'll find an implementation easily.
>>13
If you are using strings for that instead of an array/list of numbers, then you are a moron (or an erlang user)
Name:
Anonymous2010-05-28 19:06
>>14
if you are using something for strings other than sequences of characters and something for characters other than sequences of bits (which are numbers), then you are a moron (or using a quantum computer, but then you have infinitely many problems).
Name:
Anonymous2010-05-28 19:15
>>1
They helped to make the best hardcover book of all time. SICP.
>>15
I see this has gotten out of hand. >>11 was me taking the piss out of >>1. In >>14 I was talking about the general case of needing a representation of a sequence of numbers (which a string like "12 13 14" is a poor data structure for), and not how strings are implemented in your computer. I hope thats cleared everything up
>>18
the way I interpreted his post was as an answer to the question "what good are strings". Therefor "you've never had to use sequences of numbers?" seemed to me as if he was suggesting, "strings are good for representing sequences of numbers". As for the format, it was an arbitrary decision and could have been represented in a different manner.
And just for the record, I believe that having strings by an array(or list) of numbers a la C (arguably) and erlang, instead of having a separate character type is stupid.
>>30
besides copy-tree and the like, subst/-if/-if-not and related, do let you map over a tree and replace elements selectively.
Mind explaining what kind of functions you'd like to see? Most of the times I needed to work with complex circular lists, I was dealing with graphs and more complex structures, and for those, I needed a full-fledged graph manipulation library (which I did find, altough, the documentation sucked, but was overall easy to use).
I ended up writing a recursive function to do it and just wondered why there isn't something like this built into the language when there are lots of other constructs you could also just reinvent on your own but are useful enough to include. Or maybe I'm just missing something obvious.
>>34
They can be useful if you have a lot of data and need a faster way than iteration to look up an element (and you cannot just use regular indexing because the keys are too large).
>>19
many languages do have a separate character type, but that character type is almost always an integral type.
in haskell this is not the case, until you do something like this: both :: Arrow a => a b c -> a (b, b) (c, c)
both = join (***)
instance Num Char where
fromInteger = chr . fromInteger
(+) = ((chr . flip mod (ord maxBound + 1) . uncurry (+)) .) . curry (both ord)
(*) = ((chr . flip mod (ord maxBound + 1) . uncurry (*)) .) . curry (both ord)
(-) = ((chr . flip mod (ord maxBound + 1) . uncurry (-)) .) . curry (both ord)
negate = chr . (ord maxBound + 1 -) . ord
abs = id
signum = chr . signum . ord
instance Real Char where
toRational = toRational . ord
instance Integral Char where
quotRem = ((both chr . uncurry quotRem) .) . curry (both ord)
toInteger = toInteger . ord
>>36
It's not like Haskells solution is much better, really, since all you are doing is performing a type conversion before each (primitive number) operation and informing the type system that "it's cool bro". If the cost wasn't so minimal, you'd be better off converting once, doing your number operations and then converting back, which is what I'd do in Scheme (Yes, i fully accept it's cheating the type system). If we could agree on a method for doing generic functions, I imagine we could get a solution similar to the Haskell one, but getting Schemers to agree is....yeah.
On a separate note, with that solution can you intermix it with other Numeric types? I was under the impression that you couldn't mix types within a typeclass instance. So, with your solution I imagine that you can't do 'I' + 3 and get 'L'. Or will Haskell "do the right thing" as it does for other cases where you intermix numbers?