There are now a couple versions of math objects that do standard math operations on lists: Frank's list-abs and Cyrille's ds_/datastream. I think that there should be a standard set of math objects that can handle lists of indeterminate length (like the previously mentioned objects).
So it seems that the list handling versions cannot be interchangable with the standard versions, since standard math objects will interpret lists as input to that objects inlets. But it would be nice to have both options. So I propose making a mirror math library for lists, like this:
math/clip math/list/clip
math/* math/list/*
math/min math/list/min
etc. etc.
This would then largely be built from Frank's list-abs and Cyrille's ds_ objects and assembled to make sure that the list versions have the same interface as the standard versions. Then for handling floats, they would be completely interchangable.
.hc
________________________________________________________________________ ____
"The arc of history bends towards justice." - Dr. Martin Luther King, Jr.
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
There are now a couple versions of math objects that do standard math operations on lists: Frank's list-abs and Cyrille's ds_/datastream.
Where can I take a look at ds_?
So it seems that the list handling versions cannot be interchangable with the standard versions, since standard math objects will interpret lists as input to that objects inlets. But it would be nice to have both options. So I propose making a mirror math library for lists, like this:
math/clip math/list/clip
math/* math/list/*
math/min math/list/min
etc. etc.
This would then largely be built from Frank's list-abs and Cyrille's ds_ objects and assembled to make sure that the list versions have the same interface as the standard versions. Then for handling floats, they would be completely interchangable.
One thing that I considered and important convenience feature for all the arithmetics in [list]-abs was, that they should handle lists where float-elements and symbol-elements are mixed as well by just passing through symbol-elements. That is, "list x 1 y 2 z 3" * "float 2" would result in "list x 2 y 4 z 6". So most of my abstractions have a [route float] inside and math is only done at the left outlet of [route]. ([list-makefilename] works the other way around and ignores floats.)
I'm not sure if this can be included in the proposed arithmetics objects, but IMO it is a very useful feature.
Ciao
On Feb 11, 2006, at 4:16 AM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
There are now a couple versions of math objects that do standard math operations on lists: Frank's list-abs and Cyrille's ds_/datastream.
Where can I take a look at ds_?
You can see the mapping library in externals/mapping/, Most of the ds_ objects are checked in there. I attached a tarball of the ds_ collection before being integrated with the hid_ objects into mapping.
So it seems that the list handling versions cannot be interchangable with the standard versions, since standard math objects will interpret lists as input to that objects inlets. But it would be nice to have both options. So I propose making a mirror math library for lists, like this:
math/clip math/list/clip
math/* math/list/*
math/min math/list/min
etc. etc.
This would then largely be built from Frank's list-abs and Cyrille's ds_ objects and assembled to make sure that the list versions have the same interface as the standard versions. Then for handling floats, they would be completely interchangable.
One thing that I considered and important convenience feature for all the arithmetics in [list]-abs was, that they should handle lists where float-elements and symbol-elements are mixed as well by just passing through symbol-elements. That is, "list x 1 y 2 z 3" * "float 2" would result in "list x 2 y 4 z 6". So most of my abstractions have a [route float] inside and math is only done at the left outlet of [route]. ([list-makefilename] works the other way around and ignores floats.)
I'm not sure if this can be included in the proposed arithmetics objects, but IMO it is a very useful feature.
I've never had a situation where I had to use such a feature, but I can't see a problem with it. So unless we come up with a reason against it, sounds fine to me.
.hc ________________________________________________________________________ ____
Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams
Hans-Christoph Steiner a écrit :
There are now a couple versions of math objects that do standard math operations on lists: Frank's list-abs and Cyrille's ds_/datastream. I think that there should be a standard set of math objects that can handle lists of indeterminate length (like the previously mentioned objects).
i don't fear redondancy. some mapping objects can be the same as some list-abs object. having a mapping_clip that whould clip data acording to the mapping standard is great, event if it's the same object as the list_clip 0 1. i don't think it's a problem to have 2 objects with same fonctionality with diferents name.
i think the mapping lib should have all necessary object for mapping. the list-abs should have all necessary objects to deal with list. and it's not a problem if sometimes the same objects have 2 diferents name in both lib.
So it seems that the list handling versions cannot be interchangable with the standard versions, since standard math objects will interpret lists as input to that objects inlets. But it would be nice to have both options. So I propose making a mirror math library for lists, like this:
math/clip math/list/clip
math/* math/list/*
math/min math/list/min
etc. etc.
This would then largely be built from Frank's list-abs and Cyrille's ds_ objects and assembled to make sure that the list versions have the same interface as the standard versions. Then for handling floats, they would be completely interchangable.
.hc
"The arc of history bends towards justice." - Dr. Martin Luther King, Jr.
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
cyrille henry wrote:
i don't fear redondancy.
Hi Cyrille,
Perhaps you don't but anyone who is learning PD should! Without consitancy and a lack of redundancy learning PD becomes a much more complex and confusing proposition.
Wherever possible objects with the same functionality should be unified.
Otherwise things tend towards a state where the dominant (first written) object gets priority in patches and in workshops. Then the users miss the second object, that might be better, and then we end up with different camps of users using different versions of "functionally" the same object, and incompatible patches.
Its my personal opinion that one should never write an object that overlaps more than 60% of the functionality of an already existing object. One should "fix" the existing object to cover the 40% the new object would allow.
If you really want to write your own redundant objects then please don't bother releasing them. It just adds to the chaotic fuzz and it would serve the community much better to integrate rather than "fork" even if its hard and takes longer.
Just an opinion as a PD instructor.
.b.
Hallo, B. Bogart hat gesagt: // B. Bogart wrote:
cyrille henry wrote:
i don't fear redondancy.
Perhaps you don't but anyone who is learning PD should! Without consitancy and a lack of redundancy learning PD becomes a much more complex and confusing proposition.
Wherever possible objects with the same functionality should be unified.
I agree that this should be a goal for externals and built-in objects, however for abstractions I see it slightly different and I would rather support Cyrille's view. Although I abandoned Perl years ago, I may bring up the basic Perl philosophy axiom here: "There's more than one way to do it." I see it as part of the artistic freedom Pd offers to be able to do the same things in different ways - like it's part of artistic freedom to write yet another pop song about a broken heart.
We even have different versions of Pd: msp, devel, desiredata and now pd-extended. That's the way, the world is and thus it's the way, software is. With the Linux-kernel it's even worse than in our tiny Pd world.
Several of the [list]-abs are reimplementations of existing externals. Still I see a place for them, if alone because they are not externals.
Ciao
On Feb 12, 2006, at 11:37 AM, Frank Barknecht wrote:
Hallo, B. Bogart hat gesagt: // B. Bogart wrote:
cyrille henry wrote:
i don't fear redondancy.
Perhaps you don't but anyone who is learning PD should! Without consitancy and a lack of redundancy learning PD becomes a much more complex and confusing proposition.
Wherever possible objects with the same functionality should be unified.
I agree that this should be a goal for externals and built-in objects, however for abstractions I see it slightly different and I would rather support Cyrille's view. Although I abandoned Perl years ago, I may bring up the basic Perl philosophy axiom here: "There's more than one way to do it." I see it as part of the artistic freedom Pd offers to be able to do the same things in different ways - like it's part of artistic freedom to write yet another pop song about a broken heart.
We even have different versions of Pd: msp, devel, desiredata and now pd-extended. That's the way, the world is and thus it's the way, software is. With the Linux-kernel it's even worse than in our tiny Pd world.
Several of the [list]-abs are reimplementations of existing externals. Still I see a place for them, if alone because they are not externals.
The language should be free for people to do things in many different ways, I don't think that anyone really wants to restrict that. But I do not think its a good idea to have redundant objects in the standard libraries. Its good to have different objects that provide similar yet distinct functionality, like [math/clip] and [math/list/clip. But having different clipping objects in the same library with different arguments and inlets that do the same idea would be a bad idea and just add to the confusion.
.hc
________________________________________________________________________ ____
There is no way to peace, peace is the way. -A.J. Muste
hello Ben
B. Bogart a écrit :
cyrille henry wrote:
i don't fear redondancy.
Hi Cyrille,
Perhaps you don't but anyone who is learning PD should! Without consitancy and a lack of redundancy learning PD becomes a much more complex and confusing proposition.
Wherever possible objects with the same functionality should be unified.
yes. i want to unified mapping objects together. and list objects together.
i think mixing list object with mapping objects for a patch is confusing. mapping object should be consistant, and one should not use list object when he's looking for a mapping object.
Otherwise things tend towards a state where the dominant (first written) object gets priority in patches and in workshops. Then the users miss the second object, that might be better, and then we end up with different camps of users using different versions of "functionally" the same object, and incompatible patches.
Its my personal opinion that one should never write an object that overlaps more than 60% of the functionality of an already existing object. One should "fix" the existing object to cover the 40% the new object would allow.
ok. so let's embeded a [list_clip 0 1] in the mapping_clip. what do you think?
If you really want to write your own redundant objects then please don't bother releasing them. It just adds to the chaotic fuzz and it would serve the community much better to integrate rather than "fork" even if its hard and takes longer.
i don't think it's chaotic to have all object need for mapping in a mapping folder, and all object need for list processing in a list folder...
Just an opinion as a PD instructor.
c
.b.
On Feb 12, 2006, at 12:02 PM, cyrille henry wrote:
hello Ben
B. Bogart a écrit :
cyrille henry wrote:
i don't fear redondancy.
Hi Cyrille, Perhaps you don't but anyone who is learning PD should! Without consitancy and a lack of redundancy learning PD becomes a much more complex and confusing proposition. Wherever possible objects with the same functionality should be unified.
yes. i want to unified mapping objects together. and list objects together.
i think mixing list object with mapping objects for a patch is confusing. mapping object should be consistant, and one should not use list object when he's looking for a mapping object.
I don't think this should be a problem at all and its quite common with many programming languages. In C, libc doesn't have any math functions in it, they are in libm. In Java, java.lang.* does not have any GUI classes at all, you have to use java.awt.* or javax.swing.*.
"mapping" should be a library like java.awt, and "math/list" also.
Otherwise things tend towards a state where the dominant (first written) object gets priority in patches and in workshops. Then the users miss the second object, that might be better, and then we end up with different camps of users using different versions of "functionally" the same object, and incompatible patches. Its my personal opinion that one should never write an object that overlaps more than 60% of the functionality of an already existing object. One should "fix" the existing object to cover the 40% the new object would allow.
ok. so let's embeded a [list_clip 0 1] in the mapping_clip. what do you think?
[mapping/clip] object would just be a shortcut, which could also create confusion. If someone imports "math/list" before "mapping", then [clip] would loose its defaults. So I think that it would probably be a better idea to just use [math/list/clip] in the context of mapping. If we start making distinct math objects for the mapping lib, where will it stop? Should we have [mapping/*], [mapping/cos], etc. etc. also?
If you really want to write your own redundant objects then please don't bother releasing them. It just adds to the chaotic fuzz and it would serve the community much better to integrate rather than "fork" even if its hard and takes longer.
i don't think it's chaotic to have all object need for mapping in a mapping folder, and all object need for list processing in a list folder...
This structure worked well when you had to work around Pd's lack of order. But with Pd-extended, the aim is to have a clean, standard library mechanisms. There is much work to be done, but its usable now. And quite frankly, these days all Pd objects I write are organized to work in the structure of Pd-extended. I see little or no reason to do otherwise.
We need to think of Pd as a common platform, not as just a collection of code you find from wherever, and assemble however into some cobbled-together thing that isn't the same as anyone else's install.
.hc
Just an opinion as a PD instructor.
c
.b.
________________________________________________________________________ ____
"The arc of history bends towards justice." - Dr. Martin Luther King, Jr.
On Mon, 13 Feb 2006, Hans-Christoph Steiner wrote:
[mapping/clip] object would just be a shortcut, which could also create confusion. If someone imports "math/list" before "mapping", then [clip] would loose its defaults. So I think that it would probably be a better idea to just use [math/list/clip] in the context of mapping.
Anyone cares about higher-order functions? use a class name as the $1.
I don't want to have 666 more classes just because someone thinks that higher-order functions can be avoided.
I don't think there ought to be more than one [map] class.
And btw, no-one calls that a "mapping" in the real world.
What about generic [zip] [fold] [scan] now?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Alas Cyrille it seems we agree rather than disagree.
I think having list stuff seperate from mapping stuff IS logical, and is not redundant. sorry for misunderstanding.
I think a lister cliper should differ from a float clipper only in the ways that they are different. If we have a patch with a float clipper, we should be able to change it to the list clipper, and the upper/lower limits should be interfaced the same way, so it still works, but would allow you to sent it lists as well at that point.
What do we mean by "mapping" exactly?
If the difference between the list clipper and the float clipper is just being able to use lists, should we just have one clipper that acts as it should based on the type of data it gets? I guess in PD this is not the way we have now, since [clip] and [clip~] are a case, which would argue for paralell list_clip, mtx_clip, etc..
The problem of libs again becomes the problem of objects that belong equally in multiple catagories. In eyesweb we have a giant tree of all the objects. the hypothetical object "myobj" would be located in BOTH these places:
/video/input/myobj
/input/video/myobj
which is pretty confusing rather than liberating...
Add to that you can drag and drop any object anywhere you want in the stucture, and RENAME it to anything you want, and you have one of the ugliest patcher languages I can think of.
The following scenario sounds ok to me:
User searches for "clip range" in the PD help searching tool, and we end up getting a list like:
/math/clip /signal/clip~ /math/list/clip /mapping/clip
ok, I'm done.
b.
cyrille henry wrote:
hello Ben
B. Bogart a écrit :
cyrille henry wrote:
i don't fear redondancy.
Hi Cyrille,
Perhaps you don't but anyone who is learning PD should! Without consitancy and a lack of redundancy learning PD becomes a much more complex and confusing proposition.
Wherever possible objects with the same functionality should be unified.
yes. i want to unified mapping objects together. and list objects together.
i think mixing list object with mapping objects for a patch is confusing. mapping object should be consistant, and one should not use list object when he's looking for a mapping object.
Otherwise things tend towards a state where the dominant (first written) object gets priority in patches and in workshops. Then the users miss the second object, that might be better, and then we end up with different camps of users using different versions of "functionally" the same object, and incompatible patches.
Its my personal opinion that one should never write an object that overlaps more than 60% of the functionality of an already existing object. One should "fix" the existing object to cover the 40% the new object would allow.
ok. so let's embeded a [list_clip 0 1] in the mapping_clip. what do you think?
If you really want to write your own redundant objects then please don't bother releasing them. It just adds to the chaotic fuzz and it would serve the community much better to integrate rather than "fork" even if its hard and takes longer.
i don't think it's chaotic to have all object need for mapping in a mapping folder, and all object need for list processing in a list folder...
Just an opinion as a PD instructor.
c
.b.
Hallo, B. Bogart hat gesagt: // B. Bogart wrote:
If the difference between the list clipper and the float clipper is just being able to use lists, should we just have one clipper that acts as it should based on the type of data it gets?
This is often not possible, unless we want to give up automatic unpacking of lists over inlets. Like many objects [clip] distributes elements of incoming lists as arguments (see attached), so we definitely need two objects to handle floats and lists. Pd is not C++. ;)
Ciao
On Feb 11, 2006, at 1:40 PM, cyrille henry wrote:
Hans-Christoph Steiner a écrit :
There are now a couple versions of math objects that do standard math operations on lists: Frank's list-abs and Cyrille's ds_/datastream. I think that there should be a standard set of math objects that can handle lists of indeterminate length (like the previously mentioned objects).
i don't fear redondancy. some mapping objects can be the same as some list-abs object. having a mapping_clip that whould clip data acording to the mapping standard is great, event if it's the same object as the list_clip 0 1. i don't think it's a problem to have 2 objects with same fonctionality with diferents name.
i think the mapping lib should have all necessary object for mapping. the list-abs should have all necessary objects to deal with list. and it's not a problem if sometimes the same objects have 2 diferents name in both lib.
How about implementing all of the objects in math/list, then the mapping versions would be based on them. Sharing code is always helpful. So [mapping/clip] would just be:
[inlet] [inlet] [inlet] | | | | [float_argument $1 0] [float_argument $2 1] | / / | / /----------------/ [math/list/clip] | [outlet]
That would make it behave exactly like [math/list/clip] but have defaults of 0 and 1. People looking for [math/list/clip] functionality would use [mapping/clip] interchangeably. But some people might get confused the other way around, if they use [math/list/clip], it would clip to 0,0. But that's not such a big deal.
.hc
So it seems that the list handling versions cannot be interchangable with the standard versions, since standard math objects will interpret lists as input to that objects inlets. But it would be nice to have both options. So I propose making a mirror math library for lists, like this: math/clip math/list/clip math/* math/list/* math/min math/list/min etc. etc. This would then largely be built from Frank's list-abs and Cyrille's ds_ objects and assembled to make sure that the list versions have the same interface as the standard versions. Then for handling floats, they would be completely interchangable. .hc ______________________________________________________________________ __ ____ "The arc of history bends towards justice." - Dr. Martin Luther King, Jr. _______________________________________________ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
________________________________________________________________________ ____
"Terrorism is not an enemy. It cannot be defeated. It's a tactic. It's about as sensible to say we declare war on night attacks and expect we're going to win that war. We're not going to win the war on terrorism." - retired U.S. Army general, William Odom
-
B. Bogart -
cyrille henry -
Frank Barknecht -
Hans-Christoph Steiner -
Mathieu Bouchard