Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Web site for the containers library

Reply
Thread Tools

Web site for the containers library

 
 
Marcin Grzegorczyk
Guest
Posts: n/a
 
      01-11-2011
Jonathan Leffler wrote:
> On 1/10/11 2:59 AM, jacob navia wrote:
>> Le 10/01/11 09:51, copx a écrit :
>>>[...] I always wanted to try Judy arrays for
>>> example:
>>> http://en.wikipedia.org/wiki/Judy_array

>>
>> Well, the problem is:
>>
>> <quote>
>> Judy was invented at HP's UNIX Software Enablement Laboratory at Fort
>> Collins Colorado. Hewlett-Packard has patents pending on the Judy
>> Technology.
>> <end quote>
>>
>> I do not want to have HP's lawyers knocking at my door.
>> Besides that, it is really a good technology.

>
> http://sourceforge.net/projects/judy/develop
>
> That code is available under the LGPL.


LGPL won't help against a patent claim.

OTOH, that project is 8 years old now, so if HP hasn't shut it down yet,
I guess whatever patents they may have, they do not apply to that
implementation.
--
Marcin Grzegorczyk
 
Reply With Quote
 
 
 
 
Ian Collins
Guest
Posts: n/a
 
      01-11-2011
On 01/12/11 09:28 AM, Marcin Grzegorczyk wrote:
> Jonathan Leffler wrote:
>> On 1/10/11 2:59 AM, jacob navia wrote:
>>> Le 10/01/11 09:51, copx a écrit :
>>>> [...] I always wanted to try Judy arrays for
>>>> example:
>>>> http://en.wikipedia.org/wiki/Judy_array
>>>
>>> Well, the problem is:
>>>
>>> <quote>
>>> Judy was invented at HP's UNIX Software Enablement Laboratory at Fort
>>> Collins Colorado. Hewlett-Packard has patents pending on the Judy
>>> Technology.
>>> <end quote>
>>>
>>> I do not want to have HP's lawyers knocking at my door.
>>> Besides that, it is really a good technology.

>>
>> http://sourceforge.net/projects/judy/develop
>>
>> That code is available under the LGPL.

>
> LGPL won't help against a patent claim.
>
> OTOH, that project is 8 years old now, so if HP hasn't shut it down yet,
> I guess whatever patents they may have, they do not apply to that
> implementation.


See the first paragraph in

http://judy.sourceforge.net/downloads/10minutes.htm

--
Ian Collins
 
Reply With Quote
 
 
 
 
Marcin Grzegorczyk
Guest
Posts: n/a
 
      01-11-2011
Ian Collins wrote:
> On 01/12/11 09:28 AM, Marcin Grzegorczyk wrote:
>> Jonathan Leffler wrote:
>>> On 1/10/11 2:59 AM, jacob navia wrote:
>>>> Le 10/01/11 09:51, copx a écrit :
>>>>> [...] I always wanted to try Judy arrays for
>>>>> example:
>>>>> http://en.wikipedia.org/wiki/Judy_array
>>>>
>>>> Well, the problem is:
>>>>
>>>> <quote>
>>>> Judy was invented at HP's UNIX Software Enablement Laboratory at Fort
>>>> Collins Colorado. Hewlett-Packard has patents pending on the Judy
>>>> Technology.
>>>> <end quote>
>>>>
>>>> I do not want to have HP's lawyers knocking at my door.
>>>> Besides that, it is really a good technology.
>>>
>>> http://sourceforge.net/projects/judy/develop
>>>
>>> That code is available under the LGPL.

>>
>> LGPL won't help against a patent claim.
>>
>> OTOH, that project is 8 years old now, so if HP hasn't shut it down yet,
>> I guess whatever patents they may have, they do not apply to that
>> implementation.

>
> See the first paragraph in
>
> http://judy.sourceforge.net/downloads/10minutes.htm


Well, the inventor of an algorithm needn't be the owner of a patent on
that algorithm (and let's not forget algorithms can be independently
invented and patented). But yes, it is extremely improbable that he
would LGPL the code without HP's knowledge and consent (especially if
one notices that the HP's publication jacob navia quoted above pre-dates
the SourceForge project).
--
Marcin Grzegorczyk
 
Reply With Quote
 
Alan Curry
Guest
Posts: n/a
 
      01-11-2011
In article <igihp8$3ee$(E-Mail Removed)-september.org>,
Marcin Grzegorczyk <(E-Mail Removed)> wrote:
>Well, the inventor of an algorithm needn't be the owner of a patent on
>that algorithm (and let's not forget algorithms can be independently
>invented and patented). But yes, it is extremely improbable that he
>would LGPL the code without HP's knowledge and consent (especially if
>one notices that the HP's publication jacob navia quoted above pre-dates
>the SourceForge project).


Only GPL3 contains an explicit promise not to sue over patents. LGPL is
insufficient. Don't think "they wouldn't do that to me". They wouldn't have
registered a patent without the intent to do it to somebody, and you're
somebody.

Stay away if you want to be safe.

--
Alan Curry
 
Reply With Quote
 
Charles
Guest
Posts: n/a
 
      01-12-2011
Tim Harig wrote:
> On 2011-01-11, Charles <(E-Mail Removed)> wrote:
>> jacob navia wrote:
>>> In Charles' world, requirements never change, everything is known
>>> on advance, etc.
>>>
>>> This is the type of person pontificating (it is very cheap) without
>>> any REAL world experience.

>>
>> Nice try at "turning the tables" little boy. You always get this way
>> when someone calls you on your bullshit.

>
> Don't feed the troll.


He's not one. (Hmm... is he?). He actually might have some potential if
he'd pull his head out of his ass.


 
Reply With Quote
 
Dag-Erling Smørgrav
Guest
Posts: n/a
 
      01-12-2011
"Charles" <(E-Mail Removed)> writes:
> Oh hush. You were trying to make a case for high-level requirements
> changes affecting the very low-level of the implementation. I don't have
> to reiterate how silly that sounds. Get your process under control is all
> I have to say to you.


You are not only an idiot, but an offensive one at that.

Requirements change over time. Programs change over time. For
instance, a client might request an additional feature, either halfway
through development or in a later update, which requires a data
structure to be sorted and / or searchable when it did not previously
need to be. The size of the input set might increase dramatically,
requiring a data structure which is well suited for small data sets (low
overhead but poor scalability) to be replaced with one which is better
suited for larger data sets (high overhead but better scalability). The
nature of the data set might change: some data structures are faster to
access but perform poorly when elements are inserted in order.

This is particularly true in scientific computing, which deals with
ever-increasing data sets and ever-changing requirements.

As a client or a manager, I would be extremely skeptical, to say the
least, of a developer who does not understand that "change happens".

DES
--
Dag-Erling Smørgrav - http://www.velocityreviews.com/forums/(E-Mail Removed)
 
Reply With Quote
 
s5n
Guest
Posts: n/a
 
      01-16-2011
On Jan 10, 7:17*am, "Charles" <(E-Mail Removed)> wrote:
> jacob navia wrote:
> > that some of the assumptions done at
> > design time are no longer valid. Hence it is important
> > to be able to change that.

>
> That's some "hearty" reasoning! Are you high?


i agree wholeheartedly with Jacob's point here. i can't count how
often i swap out underlying list/container implementations. In C++,
with the STL, this is trivial. In C it is normally a lot of work
unless one has gone through the trouble of setting up an interface-
based system which lets us swap out the implementations. As Jacob
wrote in another post, changing implementations is not as uncommon as
it sounds. i'm such a huge fan of implementation-based design in C
that i recently published an article on the topic:

http://www.wanderinghorse.net/computing/papers/#oo_c

 
Reply With Quote
 
Nick
Guest
Posts: n/a
 
      01-16-2011
"Charles" <(E-Mail Removed)> writes:

> Ben Pfaff wrote:
>> jacob navia <(E-Mail Removed)> writes:
>>
>>> All containers share the same vocabulary. It is easy then,
>>> to change the data representation without doing enormous
>>> changes to the code.

>>
>> Developers promoting container libraries often mention this as a
>> feature.

>
> It's a stepping stone. It's where all container library developers start
> out. As experience increases with that design, its limitations and
> "incorrectness" become clear.
>
>> But why is it such a great feature?

>
> It's not.
>
>> Who wants to
>> change data representations often?

>
> Inexperienced and/or unknowledgeable developers or those who won't or
> can't analyze and design before jumping in and coding. I see no reason to
> build a library in a fashion to support that. Indeed, it is GOOD for
> someone to have more tedium when a design change is necessary because of
> inadequate capability or preparation, for learning by making mistakes is
> a powerful teaching process.


But sometimes designing and coding the final solution just isn't the
right way to do it. Take my website, which is entirely programmed by
me, in my spare time.

Over the 10 years it's been live, the data set has increased by an order
of magnitude, and the data has gone from being read from a static file
to loading from a database.

I did have dreams of the final version, but I'd still be programming it
with nothing to use if I'd set out to write it.

So starting off with the places in a linear list, which then became a
tree and is now a hash table - for example - was been the right design
and build methodology for this.

It, quite clearly, wouldn't be for something with a team of developers
and defined clients, but the world isn't like that (who is the "client"
for Google for example?).

I have very little time for people who push paradigms over pragmatism.
--
Online waterways route planner | http://canalplan.eu
Plan trips, see photos, check facilities | http://canalplan.org.uk
 
Reply With Quote
 
Charles
Guest
Posts: n/a
 
      01-16-2011
s5n wrote:
> On Jan 10, 7:17 am, "Charles" <(E-Mail Removed)> wrote:
>> jacob navia wrote:
>>> that some of the assumptions done at
>>> design time are no longer valid. Hence it is important
>>> to be able to change that.

>>
>> That's some "hearty" reasoning! Are you high?

>
> i agree wholeheartedly with Jacob's point here. i can't count how
> often i swap out underlying list/container implementations. In C++,
> with the STL, this is trivial. In C it is normally a lot of work
> unless one has gone through the trouble of setting up an interface-
> based system which lets us swap out the implementations. As Jacob
> wrote in another post, changing implementations is not as uncommon as
> it sounds. i'm such a huge fan of implementation-based design in C
> that i recently published an article on the topic:
>


A lot of people operate primarily in an iterative mode. I prefer
well-thought-out approaches. That is, thinking before doing. An example
of "iterative mode of operation" is the fast typist who at the command
line does not bother to learn the different versions of the commands
because he can easy enough just iterate through them until he achieve the
desired result. Surely everyone has seen someone who uses the computer
that way: it's very frenzied and chaotic. Your statement "I can't count
how often I swap out underlying list/container implementations" may be an
indication of such. But, Jacob was talking about swapping out completely
different ADTs rather than just implementations of the correctly chosen
one. Swapping out one list implementation for another is not relevant for
me as I build my own containers, but even if I did not, such micro-level
substitutions are categorized as optimizations for specialized
applications or use. Finally, I think Jacob considers "design" to be an
implementation thing whereas I see it as independent from implementation
details such as containers/algos or which language to use.


 
Reply With Quote
 
Charles
Guest
Posts: n/a
 
      01-16-2011
Nick wrote:
> "Charles" <(E-Mail Removed)> writes:
>
>> Ben Pfaff wrote:
>>> jacob navia <(E-Mail Removed)> writes:
>>>
>>>> All containers share the same vocabulary. It is easy then,
>>>> to change the data representation without doing enormous
>>>> changes to the code.
>>>
>>> Developers promoting container libraries often mention this as a
>>> feature.

>>
>> It's a stepping stone. It's where all container library developers
>> start out. As experience increases with that design, its limitations
>> and "incorrectness" become clear.
>>
>>> But why is it such a great feature?

>>
>> It's not.
>>
>>> Who wants to
>>> change data representations often?

>>
>> Inexperienced and/or unknowledgeable developers or those who won't or
>> can't analyze and design before jumping in and coding. I see no
>> reason to build a library in a fashion to support that. Indeed, it
>> is GOOD for someone to have more tedium when a design change is
>> necessary because of inadequate capability or preparation, for
>> learning by making mistakes is a powerful teaching process.

>
> But sometimes designing and coding the final solution just isn't the
> right way to do it. Take my website, which is entirely programmed by
> me, in my spare time.


We could go round and round all day on this, and I'm sure JN would
because he is so in love with the idea, which is not novel nor
necessarily even correct, that swapping one type of container for another
is the best thing since sliced bread.

I could say that doing so, even if it was a correct design, is a
compromise in favor of the exceptional case over the mainstream case. I
could volunteer that it is "gold plating", a decidedly negative thing to
do on a project. And then you'd just come back with "well in this case or
that case... yada". YMMV is all I can say.

Bottom-up approaches are good for when it is not known how to do it. It
allows gradual build up of knowledge to incrementally and iteratively get
the job done. It is an inefficient process, but when there is nothing
else available, it's a tool in the process toolbox (note that hiring a
consultant may be much better use of time, money, resources). If you
already know how to do it, then there is no need to seek out compromised
components to help with the iterative/bottom-up approach at all. A list
will look like a list, an array will look like an array and a map will
look like a map. The right thing for the task at hand without compromise.
YMMV.



 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Are sequence containers not a subset of general containers? Sebastian Mach C++ 5 10-06-2012 07:54 PM
Containers of iterators vs. containers of references clark.coleman@att.net C++ 7 01-25-2008 01:37 PM
List of free web site design, web site backgrounds, web site layoutsresources cyber XML 1 12-25-2007 11:48 PM
List of free web site design, web site backgrounds, web site layoutsresources cyber HTML 0 12-21-2007 03:47 PM
List of free web site design, web site backgrounds, web site layoutsweb sites cyber HTML 1 12-19-2007 09:07 AM



Advertisments