 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Please, this is not a troll. It's a serious question that isn't meant to
imply the answer is "no."
What are some other cool open-source projects that didn't take their design
from existing products? I.e., ones where the open source software was the
first thing to do things that way?
The ones I can think of offhand are Ruby, Python, CouchDB, maybe VFS file
system, Singularity (if you count that as open source)... I think there was
another cool large-scale database system I'm forgetting, and probably a PL
or two...
I don't count the Linux kernel, GNOME or KDE, Emacs, GCC, MySQL, Hadoop,
etc., because all these things look and act (from the outside) significantly
like that which they're based on. While some of the stuff the "cloud" folks
are doing is very cool, I don't think it counts as Open Source.
Any other innovative languages, databases, etc? Something that one could
learn cool new ideas from by just reading the documentation (assuming
documentation exists ;-)?
--
Darren New, San Diego CA, USA (PST)
There's no CD like OCD, there's no CD I knoooow!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 03 Apr 2009 09:40:45 -0700, Darren New wrote:
> Any other innovative languages, databases, etc? Something that one could
> learn cool new ideas from by just reading the documentation (assuming
> documentation exists ;-)?
Well, it didn't start as open source, but now under the GPL (well, dual-
licensed) is Novell's FLAIM database. I don't know of any other database
like it.
http://forge.novell.com/modules/xfmod/project/?flaim
The successor, x-flaim is something of a hybrid of XML and the older
FLAIM engine. Very high scalability and fast searches; it's used as the
backend data store for eDirectory, GroupWise, and iFolder (iFolder being
open sourced is why FLAIM was).
There aren't many people who understand it very thoroughly (and I'm not
one of them).
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New escreveu:
> Please, this is not a troll. It's a serious question that isn't meant to
> imply the answer is "no."
Yes, I know.
> What are some other cool open-source projects that didn't take their
> design from existing products?
Not many I can think of. Certainly a lot of cool ideas come from
academic research projects, like in language design. But truthfully,
most open-source contributors are really more interested in
reimplementing existing ideas. You know, it's much easier when people
already elaborated and a design and thought out all the details.
I think it'll never stop. It's like the wine and mono guys trying
desperately to implement Microsoft things, always one step behind.
> Any other innovative languages, databases, etc? Something that one could
> learn cool new ideas from by just reading the documentation (assuming
> documentation exists ;-)?
Man, slow down on the coffee. You're trying to learn
C++/Haskell/Lisp/Tcl all at the same time! I won't give you more rope... ;)
--
a game sig: http://tinyurl.com/d3rxz9
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim Henderson wrote:
> Well, it didn't start as open source, but now under the GPL (well, dual-
> licensed) is Novell's FLAIM database. I don't know of any other database
> like it.
There was one a few years ago for doing XML searches. Called Verity or
something, I think. Sounds like this:
http://livedocs.adobe.com/coldfusion/6.1/htmldocs/mkvdk22.htm
but maybe I'm seeing something else called verity.
Used it for giant XML databases (like, all the US patents, all the SEC
filings, etc). FLAIM looks much nicer. I'd have to study it closely to see
if it has surprisingly new features or something, but it's good to know it's
out there.
> There aren't many people who understand it very thoroughly (and I'm not
> one of them).
Looks useful to know about, yes. Thanks!
--
Darren New, San Diego CA, USA (PST)
There's no CD like OCD, there's no CD I knoooow!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis wrote:
> C++/Haskell/Lisp/Tcl all at the same time!
I know Tcl. I'm trying to learn Python. ;-)
--
Darren New, San Diego CA, USA (PST)
There's no CD like OCD, there's no CD I knoooow!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> What are some other cool open-source projects that didn't take their
> design from existing products? I.e., ones where the open source
> software was the first thing to do things that way?
>
> The ones I can think of offhand are Ruby, Python, CouchDB.
>
> I don't count the Linux kernel, GNOME or KDE, Emacs, GCC, MySQL, Hadoop,
> etc., because all these things look and act (from the outside)
> significantly like that which they're based on.
And you don't count Haskell as open-source because it's vaguely based on
Miranda (plus four-dozen other proprietry pure-functional languages)?
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 03 Apr 2009 11:21:38 -0700, Darren New wrote:
> Jim Henderson wrote:
>> Well, it didn't start as open source, but now under the GPL (well,
>> dual- licensed) is Novell's FLAIM database. I don't know of any other
>> database like it.
>
> There was one a few years ago for doing XML searches. Called Verity or
> something, I think. Sounds like this:
> http://livedocs.adobe.com/coldfusion/6.1/htmldocs/mkvdk22.htm but maybe
> I'm seeing something else called verity.
Interesting.
> Used it for giant XML databases (like, all the US patents, all the SEC
> filings, etc). FLAIM looks much nicer. I'd have to study it closely to
> see if it has surprisingly new features or something, but it's good to
> know it's out there.
At Novell, marketing isn't exactly our strong point - even the coolest
technology we have is virtually unknown. :-)
The history of FLAIM goes back to the LDS Church as I understand it; it
was originally developed for genealogical database structures, so it
scales extremely well with structured hierarchical data.
That it moved into the directory service space was almost a totally
natural thing for it. The technology came to Novell when we acquired
WordPerfect.
>> There aren't many people who understand it very thoroughly (and I'm not
>> one of them).
>
> Looks useful to know about, yes. Thanks!
No problem. :-)
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 03 Apr 2009 14:16:44 -0300, nemesis wrote:
> Not many I can think of. Certainly a lot of cool ideas come from
> academic research projects, like in language design. But truthfully,
> most open-source contributors are really more interested in
> reimplementing existing ideas. You know, it's much easier when people
> already elaborated and a design and thought out all the details.
>
> I think it'll never stop. It's like the wine and mono guys trying
> desperately to implement Microsoft things, always one step behind.
Well, reimplementation of ideas is a cyclic theme in IT and software
development - period.
I think what you describe isn't "most open-source contributors" but most
developers.
There has been some really innovative work done in the OSS development
circles around virtualization, but the idea of virtualization goes back
to mainframes and systems like VMS. That doesn't mean there's no
innovation going on in XEN or KVM in Linux, for example.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
> And you don't count Haskell as open-source because it's vaguely based on
> Miranda (plus four-dozen other proprietry pure-functional languages)?
After I posted, I realized I'd left out Haskell. :)
--
Darren New, San Diego CA, USA (PST)
There's no CD like OCD, there's no CD I knoooow!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 3-4-2009 18:40, Darren New wrote:
> Please, this is not a troll. It's a serious question that isn't meant to
> imply the answer is "no."
'No' would be a strange answer to your question anyway.
> What are some other cool open-source projects that didn't take their
> design from existing products? I.e., ones where the open source
> software was the first thing to do things that way?
POV and Blender?
> The ones I can think of offhand are Ruby, Python, CouchDB, maybe VFS
> file system, Singularity (if you count that as open source)... I think
> there was another cool large-scale database system I'm forgetting, and
> probably a PL or two...
>
> I don't count the Linux kernel, GNOME or KDE, Emacs, GCC, MySQL, Hadoop,
> etc., because all these things look and act (from the outside)
> significantly like that which they're based on. While some of the stuff
> the "cloud" folks are doing is very cool, I don't think it counts as
> Open Source.
>
> Any other innovative languages, databases, etc? Something that one could
> learn cool new ideas from by just reading the documentation (assuming
> documentation exists ;-)?
Check out the works of Don Knuth. E.g. TeX and Metafont are fully
documented and source is available as books.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
andrel wrote:
> POV and Blender?
POV, certainly, yes. I don't know enough about Maya and those others to know
if Blender is particularly innovative. I suspect not, since it was developed
initially by experienced animators. Thanks for the suggestion, tho.
> Check out the works of Don Knuth. E.g. TeX and Metafont are fully
> documented and source is available as books.
Yep. Read them 15 years ago or so. :-) Good stuff. Thanks!
--
Darren New, San Diego CA, USA (PST)
There's no CD like OCD, there's no CD I knoooow!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
andrel escreveu:
> On 3-4-2009 18:40, Darren New wrote:
>> Please, this is not a troll. It's a serious question that isn't meant
>> to imply the answer is "no."
>
> 'No' would be a strange answer to your question anyway.
>
>> What are some other cool open-source projects that didn't take their
>> design from existing products? I.e., ones where the open source
>> software was the first thing to do things that way?
>
> POV and Blender?
Blender started life as an in-house, proprietary tool. When the company
was closing doors, they realized the tool was quite complete and good
enough perhaps not for going commercial, but at least to serve as the
basis for an open-source project. And so they realized an online
auction and when a certain ammount was gathered, they did release the
source under the GPL.
The community literally bought a former proprietary product and
open-sourced it. Even Stallman gone hurrah. :)
--
a game sig: http://tinyurl.com/d3rxz9
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 03 Apr 2009 18:08:30 -0300, nemesis wrote:
> When the company
> was closing doors, they realized the tool was quite complete and good
> enough perhaps not for going commercial
I understood that it used to be commercially available....
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis wrote:
> The community literally bought a former proprietary product and
> open-sourced it. Even Stallman gone hurrah. :)
I'd read about the first part, but not the auction. That's pretty clever.
--
Darren New, San Diego CA, USA (PST)
There's no CD like OCD, there's no CD I knoooow!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] san rrcom> wrote:
> nemesis wrote:
> > C++/Haskell/Lisp/Tcl all at the same time!
>
> I know Tcl. I'm trying to learn Python. ;-)
Hey, me too. I'm in love already. With numpy and scipy too, I can control the
hardware, collect data, and process it efficiently in the same language! It's
really a great compromise. And dictionaries? Outstanding.
- Ricky
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
triple_r wrote:
> And dictionaries? Outstanding.
Actually, python dictionaries are pretty lame compared to dictionaries in
some other languages, like PHP. Lots of good uses for them, but they're
really nothing more than a hashtable.
--
Darren New, San Diego CA, USA (PST)
There's no CD like OCD, there's no CD I knoooow!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> nemesis wrote:
>> The community literally bought a former proprietary product and
>> open-sourced it. Even Stallman gone hurrah. :)
>
> I'd read about the first part, but not the auction. That's pretty clever.
Pretty much like the ones you spot from time to time in the headers of
wikipedia. It was an amazing event in any way.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim Henderson wrote:
> On Fri, 03 Apr 2009 18:08:30 -0300, nemesis wrote:
>
>> When the company
>> was closing doors, they realized the tool was quite complete and good
>> enough perhaps not for going commercial
>
> I understood that it used to be commercially available....
Not quite sure about that. But the company was definitely closing doors
and seemingly not interested in maintaining it though they saw its value.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> Actually, python dictionaries are pretty lame compared to dictionaries
> in some other languages, like PHP.
I don't know PHP, so I'm curious if you could elaborate a bit, since I'm
used to viewing "dictionary" as more of less a synonym for "hashtable"
in this context.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> Actually, python dictionaries are pretty lame compared to dictionaries in
> some other languages, like PHP.
Really? Interesting, but perhaps I should clarify. The only other languages I
know are C/C++, Fortran, Matlab, and... let's see... POV-Ray? I'm sure they're
perfectly capable, but having it built in is really great.
- Ricky
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Kevin Wampler <wam### [at] uwashingtonedu> wrote:
> Darren New wrote:
> > Actually, python dictionaries are pretty lame compared to dictionaries
> > in some other languages, like PHP.
>
> I don't know PHP, so I'm curious if you could elaborate a bit, since I'm
> used to viewing "dictionary" as more of less a synonym for "hashtable"
> in this context.
Yeah, me too. What is it lacking exactly? Specially compared to an aberration
like PHP?
Python 2.5.2 (r252:60911, Jul 31 2008, 17:28:52)
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> d = {}
>>> type( d )
<type 'dict'>
>>> d['foo'] ="bar"
>>> d
{'foo': 'bar'}
>>> dir( d )
['__class__', '__cmp__', '__contains__', '__delattr__', '__delitem__',
'__doc__', '__eq__', '__ge__', '__getattribute__', '__getitem__', '__gt__',
'__hash__', '__init__', '__iter__', '__le__', '__len__', '__lt__', '__ne__',
'__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__',
'__setitem__', '__str__', 'clear', 'copy', 'fromkeys', 'get', 'has_key',
'items', 'iteritems', 'iterkeys', 'itervalues', 'keys', 'pop', 'popitem',
'setdefault', 'update', 'values']
>>> d.items()
[('foo', 'bar')]
>>> d[1] = 2
>>> d[1]
2
>>> d[2]=lambda x:x+1
>>> d
{1: 2, 2: <function <lambda> at 0x8198fb4>, 'foo': 'bar'}
>>> d[2](3)
4
>>> for k,v in d.items():
.... print k, " => ", v
....
1 => 2
2 => <function <lambda> at 0x8198fb4>
foo => bar
>>>
It can take arbitrary objects as keys and has a wealth of good methods to choose
from. Perhaps it's time for some friday night troll? ;)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Kevin Wampler wrote:
> I don't know PHP, so I'm curious if you could elaborate a bit, since I'm
> used to viewing "dictionary" as more of less a synonym for "hashtable"
> in this context.
Hmmm... A dictionary in PHP is more like an array of key/value pairs. So
they preserve the order in which you inserted elements, they have integer
indecies, but they also act as hash tables. Plus, you can say things like
x[] = 27
to append 27 to the end of the array, whatever size it is. So they work as
both dictionaries, arrays, and ordered maps.
http://us3.php.net/manual/en/language.types.array.php
Honestly, I don't think I've ever *used* the fact that the keys maintain an
order even when they're not integers.
Lua dictionaries (called "tables") are also kind of odd, in that they are
apparently hashtables with special rules for entries with integer keys as
well as an independent "size", but I didn't follow it far enough to
understand what was going on exactly there. It was kind of funky mixing
integer and non-integer indecies, in the tutorials I was reading.
--
Darren New, San Diego CA, USA (PST)
There's no CD like OCD, there's no CD I knoooow!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> Kevin Wampler wrote:
>> I don't know PHP, so I'm curious if you could elaborate a bit, since
>> I'm used to viewing "dictionary" as more of less a synonym for
>> "hashtable" in this context.
>
> Hmmm... A dictionary in PHP is more like an array of key/value pairs. So
> they preserve the order in which you inserted elements
Interesting. So, to make sure I understand correctly if dicts in python
were to operate like this then:
D = dict()
d["a"] = "foo"
d["b"] = "bar"
d["c"] = "baz"
would give me {"a":"foo", "b":"bar", "c":"baz"} where the order matters
so D[1] gives "bar"?
If so, then what happens in the following case:
D = dict()
d[3] = "foo"
d[2] = "bar"
d[1] = "baz"
or:
D = dict()
D[2000000000] = "foo"
I think any implementation which tries to behave both like a list and a
hashtable is going to have some inconsistencies when using ints as keys,
so I actually prefer the approach of keeping the two separate. That
said I do sometimes like the C++ stl approach of maintaining an ordering
in a map based on the natural order of its elements.
> Honestly, I don't think I've ever *used* the fact that the keys maintain
> an order even when they're not integers.
I actually have used this in python a few times, using a custom class
rather than a straight dict of course. Unfortunately I can't remember
why I needed it. I suspect it was so that I could pack the dict into a
vector, perform some computations on it, and then put the results back
into the dict.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Kevin Wampler <wam### [at] uwashingtonedu> wrote:
> I think any implementation which tries to behave both like a list and a
> hashtable is going to have some inconsistencies when using ints as keys,
> so I actually prefer the approach of keeping the two separate.
Exactly, order shouldn't matter in a dictionary: it's a set. There are lists
if one needs order or you can always base a class on dict and replace
__setitem__ and __getitem__.
What matters in Python though is case and D is not the same as d. :P
PHP and Perl are full of inconsistencies.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Kevin Wampler wrote:
> would give me {"a":"foo", "b":"bar", "c":"baz"} where the order matters
> so D[1] gives "bar"?
It has been a while, but I think so, yes.
> If so, then what happens in the following case:
IIRC, if you use integer keys, you get what you'd expect.
Note that you can iterate over a list without giving specific indexes, so it
might work that you say
foreach key, value in D {print key,value}
and you get
3 foo / 2 bar / 1 baz
or something like that. It has been too long for me to remember.
> said I do sometimes like the C++ stl approach of maintaining an ordering
> in a map based on the natural order of its elements.
That's another way to do it. Or at least make hashes with equal contents
iterate in identical order.
> I actually have used this in python a few times, using a custom class
> rather than a straight dict of course. Unfortunately I can't remember
> why I needed it.
If you're making a dict (in particular a class namespace) that you're going
to translate into (for example) SOAP or a COM interface or something, I can
see where it would be helpful. That's what some of the Python 3.0
extensions were about.
--
Darren New, San Diego CA, USA (PST)
There's no CD like OCD, there's no CD I knoooow!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis wrote:
> Exactly, order shouldn't matter in a dictionary: it's a set.
But that's kind of the point. Why do you think that? Saying "order
shouldn't matter because it's a set" is begging the question.
Why does order matter in argument lists, if the arguments all need distinct
names anyway? :-)
> PHP and Perl are full of inconsistencies.
No argument there.
--
Darren New, San Diego CA, USA (PST)
There's no CD like OCD, there's no CD I knoooow!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> But that's kind of the point. Why do you think that? Saying "order
> shouldn't matter because it's a set" is begging the question.
A set in the mathematical sense has no order. If the guy wants order, he goes
for a list. PHP only got array, so it has to play many roles.
> Why does order matter in argument lists, if the arguments all need distinct
> names anyway? :-)
I think it has to do with pragmatism: it's just simpler to go with a list than
a hash.
In math, you have a function over domains and you have to make sure each
argument belongs to each domain and the simplest way to notate this is to give
the order of the domains and pass the arguments to the function in that order.
Had they opted for a named argument notation, you'd not need order, but on the
other hand you'd need a lot more typing. Programming language designers were
conscious of that and just stacking them as they come is much easier than
unwrapping hash values.
Named arguments is a thing of a hip generation used to lots of cheap computing
power and general resources. It's not as costly anymore to be verbose when
your tools happily churn it out for you.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> Why does order matter in argument lists, if the arguments all need
> distinct names anyway? :-)
So you can call the function without explicitly naming the parameters,
thus reducing the amount of typing required.
Personally, I like the style where arguments can be passed in order (in
which case the names don't matter) or by name (in which case the order
doesn't matter). Python sort does this, with a few restrictions, and
it's seemed pretty intuitive and useful to me.
Thinking back, didn't objective-C use named parameters only for calling
object methods? Did the order matter there? I can't really remember.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> IIRC, if you use integer keys, you get what you'd expect.
I'm actually not sure what to expect here. For instance:
D = dict()
D[1] = "foo"
try:
if D[0] == D[1]:
print "maybe this makes sense?"
else:
print "ok, this is odd"
except:
print "maybe this also makes sense?"
I think the issue is that this sort of structure has two types of
indices, and when both are ints there's no way to properly distinguish
them, so I can't think of what behavior would be appropriate.
On the other hand, it's probably not a very big issue in practice, since
at worst the behavior (whatever it is) would be just another one of
those language quirks that you have to memorize, and there's certainly
no shortage of those in most languages.
> Note that you can iterate over a list without giving specific indexes,
This is a different matter, and I don't think it has any of the problems
that using integers as direct indices does. I might imagine that such
a structure tightly integrated into a language might have uses which
outweighed it's somewhat higher inefficiency, although I can't think of
just what those uses might be. As a matter of taste, however, I tend to
prefer have the basic structures at my disposal be closely related to
basic classes of algorithms and to build more complicated assemblages as
I need from those parts. Hence my preference for hashtable or
ordered-tree backed dicts types.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 3-4-2009 23:08, nemesis wrote:
> andrel escreveu:
>> On 3-4-2009 18:40, Darren New wrote:
>>> Please, this is not a troll. It's a serious question that isn't meant
>>> to imply the answer is "no."
>>
>> 'No' would be a strange answer to your question anyway.
>>
>>> What are some other cool open-source projects that didn't take their
>>> design from existing products? I.e., ones where the open source
>>> software was the first thing to do things that way?
>>
>> POV and Blender?
>
> Blender started life as an in-house, proprietary tool. When the company
> was closing doors, they realized the tool was quite complete and good
> enough perhaps not for going commercial, but at least to serve as the
> basis for an open-source project. And so they realized an online
> auction and when a certain ammount was gathered, they did release the
> source under the GPL.
>
> The community literally bought a former proprietary product and
> open-sourced it. Even Stallman gone hurrah. :)
What I remember is that it started as a research project (at which stage
it may have been available for others, so that is why I though it might
qualify as an answer), was then tried commercially and when that did not
work converted to open source by the main developer.
The reason that it did not work may be related to being forced to do
(more than) full time 'maintenance' and 'support' because people were
paying.
That danger is why our software is available to fellow researchers for
free. We would like to do some research ourselves too.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis wrote:
> It can take arbitrary objects as keys and has a wealth of good methods to choose
> from. Perhaps it's time for some friday night troll? ;)
Unless they made changes, that's not correct. It can only take strings,
numbers, and immutable types as keys (so no lists, but yes tuples).
--
It's not hard to meet expenses, they're everywhere.
/\ /\ /\ /
/ \/ \ u e e n / \/ a w a z
>>>>>>mue### [at] nawazorg<<<<<<
anl
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
andrel <a_l### [at] hotmailcom> wrote:
> On 3-4-2009 23:08, nemesis wrote:
> > andrel escreveu:
> >> On 3-4-2009 18:40, Darren New wrote:
> >>> Please, this is not a troll. It's a serious question that isn't meant
> >>> to imply the answer is "no."
> >>
> >> 'No' would be a strange answer to your question anyway.
> >>
> >>> What are some other cool open-source projects that didn't take their
> >>> design from existing products? I.e., ones where the open source
> >>> software was the first thing to do things that way?
> >>
> >> POV and Blender?
> >
> > Blender started life as an in-house, proprietary tool. When the company
> > was closing doors, they realized the tool was quite complete and good
> > enough perhaps not for going commercial, but at least to serve as the
> > basis for an open-source project. And so they realized an online
> > auction and when a certain ammount was gathered, they did release the
> > source under the GPL.
> >
> > The community literally bought a former proprietary product and
> > open-sourced it. Even Stallman gone hurrah. :)
>
> What I remember is that it started as a research project (at which stage
> it may have been available for others, so that is why I though it might
> qualify as an answer), was then tried commercially and when that did not
> work converted to open source by the main developer.
> The reason that it did not work may be related to being forced to do
> (more than) full time 'maintenance' and 'support' because people were
> paying.
> That danger is why our software is available to fellow researchers for
> free. We would like to do some research ourselves too.
First time I hear of such research history. Are you sure you are talking about
Blender?
http://en.wikipedia.org/wiki/Blender_(software)#History
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> But that's kind of the point. Why do you think that? Saying "order
>> shouldn't matter because it's a set" is begging the question.
>
> A set in the mathematical sense has no order.
I'm asking you why a dictionary shouldn't have order. You're saying "A
dictionary is a set, so it shouldn't have order." But what makes a
dictionary a set?
> If the guy wants order, he goes for a list.
And now you're telling me how to work around the problem of sets not having
order. See? :-)
Not that it's worth arguing. I'm just pointing out the logic is flawed.
> PHP only got array, so it has to play many roles.
Or, I could say "Python dictionaries are broken, so you need something else
to substitute for when you want ordered pairs." Considering there are
occasions when you want an order-maintaining dictionary, it would seem to be
of benefit to have such built in.
>> Why does order matter in argument lists, if the arguments all need distinct
>> names anyway? :-)
>
> I think it has to do with pragmatism: it's just simpler to go with a list than
> a hash.
You're answering a rhetorical question. :-) I don't think you can argue that
it's pragmatic to order argument lists but not pragmatic to order dictionaries.
> Named arguments is a thing of a hip generation used to lots of cheap computing
> power and general resources.
Errrrr... math generally doesn't use named arguments, even back when
"computer" was a job title.
Anyway, I was trying to make a point, not especially to say one way is
better than the other, but that both are equally valid approaches, modulo
efficiency.
--
Darren New, San Diego CA, USA (PST)
There's no CD like OCD, there's no CD I knoooow!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Kevin Wampler wrote:
> Darren New wrote:
>> Why does order matter in argument lists, if the arguments all need
>> distinct names anyway? :-)
>
> So you can call the function without explicitly naming the parameters,
> thus reducing the amount of typing required.
It was a rhetorical question to show that the argument "dictionaries are
sets and hence have no order" is an invalid comparison.
> Personally, I like the style where arguments can be passed in order (in
> which case the names don't matter) or by name (in which case the order
> doesn't matter). Python sort does this, with a few restrictions, and
> it's seemed pretty intuitive and useful to me.
Agreed.
> Thinking back, didn't objective-C use named parameters only for calling
> object methods? Did the order matter there? I can't really remember.
Yes. Because they took it from Smalltalk.
--
Darren New, San Diego CA, USA (PST)
There's no CD like OCD, there's no CD I knoooow!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mueen Nawaz <m.n### [at] ieeeorg> wrote:
> nemesis wrote:
> > It can take arbitrary objects as keys and has a wealth of good methods to choose
> > from. Perhaps it's time for some friday night troll? ;)
>
> Unless they made changes, that's not correct. It can only take strings,
> numbers, and immutable types as keys (so no lists, but yes tuples).
Python 2.5.2 (r252:60911, Jul 31 2008, 17:28:52)
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> ls = dir()
>>> ls
['__builtins__', '__doc__', '__name__']
>>> d = {}
>>> d[ls]=1
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: list objects are unhashable
>>> str
<type 'str'>
>>> d[str]="string class"
>>> d
{<type 'str'>: 'string class'}
>>> d[lambda x:x+1]="function object as key"
>>> d
{<type 'str'>: 'string class', <function <lambda> at 0x838aa3c>: 'function
object as key'}
True, lists can't be used as key. But classes, objects and even functions can.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Kevin Wampler wrote:
> I'm actually not sure what to expect here.
Note that the "First Text" and "Second Text" keys stay in order, for
example. I think it's pretty useful for things like representing stuff like
XML, where you might want keys for the "id" field, but you also want to know
what order the tags were in in the source file.
It looks like inserting something without an index puts it at the end of the
array with an index one higher than the biggest integer index. Inserting
something with an index overwrites what's at that index, or adds it to the
end if the index doesn't already exist.
--
Darren New, San Diego CA, USA (PST)
There's no CD like OCD, there's no CD I knoooow!
Post a reply to this message
Attachments:
Download 'xyz.php.txt' (1 KB)
Download 'xyz.txt' (1 KB)
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> nemesis wrote:
> > Darren New <dne### [at] sanrrcom> wrote:
> >> But that's kind of the point. Why do you think that? Saying "order
> >> shouldn't matter because it's a set" is begging the question.
> >
> > A set in the mathematical sense has no order.
>
> I'm asking you why a dictionary shouldn't have order. You're saying "A
> dictionary is a set, so it shouldn't have order." But what makes a
> dictionary a set?
>
> > If the guy wants order, he goes for a list.
>
> And now you're telling me how to work around the problem of sets not having
> order. See? :-)
>
> Not that it's worth arguing. I'm just pointing out the logic is flawed.
>
> > PHP only got array, so it has to play many roles.
>
> Or, I could say "Python dictionaries are broken, so you need something else
> to substitute for when you want ordered pairs."
You could say math is broken.
The primary function of a hash table is for lookup. Looking up individual
registers associated with a given key. No one said anything about order.
If you want order, append the keys to a list as they are inserted into the hash
and implement a display_hash function that will display hash items by iterating
over items from the list.
> Considering there are
> occasions when you want an order-maintaining dictionary, it would seem to be
> of benefit to have such built in.
Sure. There's also plenty of practical benefits from having a language
automatically parse numbers out of strings such as v = "24"+1, as Perl and its
bastard son PHP do.
> > Named arguments is a thing of a hip generation used to lots of cheap computing
> > power and general resources.
>
> Errrrr... math generally doesn't use named arguments, even back when
> "computer" was a job title.
All the worse as mathematicians would need to write down far too much more
symbols on paper, rather than resorting to the simpler approach of following a
given order. Lists are always simpler than sets.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis wrote:
> The primary function of a hash table is for lookup. Looking up individual
> registers associated with a given key. No one said anything about order.
Yes. So... why is a "dict" a hashtable instead of something else?
Again, you're begging the question. You're asserting that the way Python
does it is right, then justifying it based on the fact that Python decided
to implement it that way. See?
You're saying "a hastable is for lookups. It doesn't have an order.
Therefore, Python is right to base its data structures on hash tables."
> If you want order, append the keys to a list as they are inserted into the hash
> and implement a display_hash function that will display hash items by iterating
> over items from the list.
Well, there ya go. So why isn't that built in, like it is in PHP, since it
allows both random and sequential lookups? :-)
> All the worse as mathematicians would need to write down far too much more
> symbols on paper, rather than resorting to the simpler approach of following a
> given order. Lists are always simpler than sets.
So, it's OK for a mathematical set to maintain order when it's simpler, but
it's not logical to make the data structures in your language have the same
simplicity? I'm not following. :-)
--
Darren New, San Diego CA, USA (PST)
There's no CD like OCD, there's no CD I knoooow!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 4-4-2009 18:45, nemesis wrote:
> andrel <a_l### [at] hotmailcom> wrote:
>> On 3-4-2009 23:08, nemesis wrote:
>>> andrel escreveu:
>>>> On 3-4-2009 18:40, Darren New wrote:
>>>>> Please, this is not a troll. It's a serious question that isn't meant
>>>>> to imply the answer is "no."
>>>> 'No' would be a strange answer to your question anyway.
>>>>
>>>>> What are some other cool open-source projects that didn't take their
>>>>> design from existing products? I.e., ones where the open source
>>>>> software was the first thing to do things that way?
>>>> POV and Blender?
>>> Blender started life as an in-house, proprietary tool. When the company
>>> was closing doors, they realized the tool was quite complete and good
>>> enough perhaps not for going commercial, but at least to serve as the
>>> basis for an open-source project. And so they realized an online
>>> auction and when a certain ammount was gathered, they did release the
>>> source under the GPL.
>>>
>>> The community literally bought a former proprietary product and
>>> open-sourced it. Even Stallman gone hurrah. :)
>> What I remember is that it started as a research project (at which stage
>> it may have been available for others, so that is why I though it might
>> qualify as an answer), was then tried commercially and when that did not
>> work converted to open source by the main developer.
>> The reason that it did not work may be related to being forced to do
>> (more than) full time 'maintenance' and 'support' because people were
>> paying.
>> That danger is why our software is available to fellow researchers for
>> free. We would like to do some research ourselves too.
>
> First time I hear of such research history. Are you sure you are talking about
> Blender?
I am sure I meant Blender, I am not sure if I am confusing some stories
or filling in gaps. ;)
Memory is based on something someone that I worked with for some time
told me some years ago.
He worked later in a group where one of the developers of Blender also
ended up after NaN stopped. That was a group that was closely linked to
a university, so I assumed he (not Ton Roosendaal) had a university
background. So I just assumed it all started there.
> http://en.wikipedia.org/wiki/Blender_(software)#History
Given that my memory is not that good and it was mentioned in passing
that is probably more accurate.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> You're saying "a hastable is for lookups. It doesn't have an order.
> Therefore, Python is right to base its data structures on hash tables."
It's supposed to be a hashtable. If you don't want a hashtable, you shouldn't
use it.
> Well, there ya go. So why isn't that built in, like it is in PHP, since it
> allows both random and sequential lookups? :-)
Because Python, Scheme and Haskell attempt to use the correct approaches. Form
follows function.
> So, it's OK for a mathematical set to maintain order when it's simpler,
A math set has no order. I was saying the notation of functions over set
domains employs the convention of lists of arguments because it's simpler to
notate than named arguments out of order.
> it's not logical to make the data structures in your language have the same
> simplicity? I'm not following. :-)
Sure, just use a list if you want simplicity. If you're using a hashtable,
you're stating order is not important. Say:
x from XS, y from YS:
f(x, y) = x*x+y
You could call it, ordered:
f(1,2)
or unordered:
f(y=3,x=4)
They just crammed the 2 behaviours into a single multipurpose data
structure(less) in PHP. Other languages have specialized data structures for
specific needs and that ought to be a good thing.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> Kevin Wampler wrote:
>> Darren New wrote:
>>> Why does order matter in argument lists, if the arguments all need
>>> distinct names anyway? :-)
>>
>> So you can call the function without explicitly naming the parameters,
>> thus reducing the amount of typing required.
>
> It was a rhetorical question to show that the argument "dictionaries are
> sets and hence have no order" is an invalid comparison.
I should have guessed that. It certainly seemed like an odd question
for you to be asking in earnest.
>> Thinking back, didn't objective-C use named parameters only for
>> calling object methods? Did the order matter there? I can't really
>> remember.
>
> Yes. Because they took it from Smalltalk.
That makes sense. One of these days I'd like to get around to learning
smalltalk.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> Kevin Wampler wrote:
>> I'm actually not sure what to expect here.
>
> Note that the "First Text" and "Second Text" keys stay in order, for
> example. I think it's pretty useful for things like representing stuff
> like XML, where you might want keys for the "id" field, but you also
> want to know what order the tags were in in the source file.
Ahh, yeah, that's exactly the sort of use case I was looking for.
> It looks like inserting something without an index puts it at the end of
> the array with an index one higher than the biggest integer index.
> Inserting something with an index overwrites what's at that index, or
> adds it to the end if the index doesn't already exist.
Good to know. Thanks!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> You're saying "a hastable is for lookups. It doesn't have an order.
>> Therefore, Python is right to base its data structures on hash tables."
>
> It's supposed to be a hashtable.
What is "supposed" to be a hashtable? And why do you say it's "supposed" to
be a hashtable?
> If you don't want a hashtable, you shouldn't use it.
Of course not. Because it *is* a hashtable, whether that's what you want or
not.
>> Well, there ya go. So why isn't that built in, like it is in PHP, since it
>> allows both random and sequential lookups? :-)
>
> Because Python, Scheme and Haskell attempt to use the correct approaches. Form
> follows function.
And what is incorrect about PHP's approach? Why is Python more "correct"
than PHP? (Note: "because it uses hashtables" is a circular argument.)
>> So, it's OK for a mathematical set to maintain order when it's simpler,
>
> A math set has no order. I was saying the notation of functions over set
> domains employs the convention of lists of arguments because it's simpler to
> notate than named arguments out of order.
I understand that. You're missing my point. You're arguing that keyed data
structures in a programming language should not preserve insertion order.
I'm asking you why that is the case, and you're answering "Because!"
I'm just trying to figure out why you think a structure with a superset of
the functionality that a hashtable provides is a bad thing.
> and that ought to be a good thing.
Why? Do you actually *have* a reason beyond "because"? Or is this a
faith-based argument?
If you need a hashtable, PHP's arrays give that to you. If you need a list,
PHP's arrays give that to you. If you need order-preserving keyed-access
data structures, PHP's arrays gives that to you, and Python doesn't. If you
need order-preserving keyed-access data structures in Python, you have to
implement it yourself. I'd say that's a bad thing, for all the same reasons
that having non-standardized implementations of any application-independent
data structures in any language is a bad thing.
--
Darren New, San Diego CA, USA (PST)
There's no CD like OCD, there's no CD I knoooow!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Kevin Wampler wrote:
> Ahh, yeah, that's exactly the sort of use case I was looking for.
It took me a bit of thinking. That, and getting rows back from a SQL server
indexed by primary key but sorted by something else, for example.
> Good to know. Thanks!
It looks like it just keeps the order even for integer indecies:
$pdq[10] = "Ten";
$pdq[20] = "Twenty";
$pdq[15] = "Fifteen";
$pdq[12] = "Twelve";
print_r($pdq);
Array
(
[10] => Ten
[20] => Twenty
[15] => Fifteen
[12] => Twelve
)
Weird, but understandable. It looks like a list of pairs. :-)
--
Darren New, San Diego CA, USA (PST)
There's no CD like OCD, there's no CD I knoooow!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Just to throw in two cents of mine:
Darren New <dne### [at] sanrrcom> wrote:
> I'm just trying to figure out why you think a structure with a superset of
> the functionality that a hashtable provides is a bad thing.
I think there's nothing wrong about it - if that structure also provides the
same performance as a true hashtable (which, as a quick guess, it probably
doesn't). Or if performance is not an issue.
Added features typically come with added execution time. So added features you
don't need for a certain job typically come with wasted execution time.
As stated before: No problem if you have enough time to waste.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Kevin Wampler wrote:
> outweighed it's somewhat higher inefficiency,
Actually, thinking on it, it doesn't need to be noticeably less efficient.
You can just implement it as a regular hashtable except have a head and tail
pointer in the top-level structure, and a couple of pointers in each entry.
Adding a new index also links it to the tail of the linked list, deleting an
entry takes it out of the linked list and the hashtable, etc. So there
doesn't seem to be more than a handful of machine instructions on an insert
or delete to maintain this extra information, and it's certainly not wasting
a lot of space compared to keeping a hashtable sufficiently below full that
you avoid too many collisions.
--
Darren New, San Diego CA, USA (PST)
There's no CD like OCD, there's no CD I knoooow!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka wrote:
> I think there's nothing wrong about it
That's why I was confused. You were characterizing it as "incorrect" and
"not a good thing", rather than "inefficient", and talking about
mathematical constructs rather than computational elements.
> if that structure also provides the
> same performance as a true hashtable (which, as a quick guess, it probably
> doesn't). Or if performance is not an issue.
I think if you're using Python or PHP, you're not too worried about the
performance issues. If you're using PHP and your program runs more than five
seconds CPU time, you're probably doing something wrong and ought to be
using a different language anyway.
> Added features typically come with added execution time. So added features you
> don't need for a certain job typically come with wasted execution time.
It adds a handful of instructions to inserts and deletes, and no overhead to
lookups, and probably *saves* time iterating over the array.
In other words, it's all O(1) with a constant on the order of a dozen
machine instructions amortized (not counting hashing the key), regardless of
whether you preserve order or not.
5 million integer key array inserts in PHP: 3.3 seconds
5 million dict inserts in Python: 2.3 seconds
5 million list appends in Python: 1.9 seconds
5 million integer key inserts then lookups in PHP: 4.2 seconds
5 million dict inserts and then lookups in python: 4.3 seconds
5 million list element appends then lookups in Python: 3.4 seconds
5 million inserts and iterate-over-values in PHP: 9.5 seconds
5 million inserts and iterate-over-values in python: 133 seconds
(Each is 5 cycles of a million entries each, lest we run out of RAM
in the VM. :-)
I guess it depends what you want to do. If you often iterate over the
values, clearly you should go with PHP. If you often work with more than
five million entries in one PHP page, you're probably doing something wrong.
> As stated before: No problem if you have enough time to waste.
Given the languages are interpreted to start with, if four machine
instructions per insert into your dictionary is breaking the bank, you
probably shouldn't be using hashtables to start with. You should be using
interned strings and modulus operators on the addresses.
If you want to use PHP or Python and have trouble with how slow the built-in
data structures are, chances are you should be using PHP anyway.
--
Darren New, San Diego CA, USA (PST)
There's no CD like OCD, there's no CD I knoooow!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> clipka wrote:
>> I think there's nothing wrong about it
>
> That's why I was confused. You were characterizing it as "incorrect" and
No he (clipka) wasn't. nemesis was :)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Kevin Wampler wrote:
> Thinking back, didn't objective-C use named parameters only for calling
> object methods? Did the order matter there? I can't really remember.
Order matters, because method:param1:param2 is the function signature.
method:param2:param1 would be a different function.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Kevin Wampler wrote:
> Interesting. So, to make sure I understand correctly if dicts in python
> were to operate like this then:
>
> D = dict()
> d["a"] = "foo"
> d["b"] = "bar"
> d["c"] = "baz"
>
> would give me {"a":"foo", "b":"bar", "c":"baz"} where the order matters
> so D[1] gives "bar"?
No, because key 1 isn't set to any value. However, if you iterate over the
array, you'll get items a, b, c, in that order.
> If so, then what happens in the following case:
>
> D = dict()
> d[3] = "foo"
> d[2] = "bar"
> d[1] = "baz"
Then d[3] is "foo", but if you iterate, it will be the first item to show
up.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
