Proposed concat() improvement
The current concat()
https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/The_OpenSCAD_Language#concat
has the feature when there's only one argument: concat( x ):
(1) x is an arr: do nothing, just return the arr:
concat( [1,2,3] ) => [1,2,3]
(2) x is a str: convert the string to a 1-item array:
concat( "abc" ) => ["abc"]
I can't figure under what situation this is useful, because that one
argument is
not something users can assign programmably but have to hard code it. i.e.,
there seems to be no point when typing concat( [1,2,3] ) is the same as just
[1,2,3].
In the mean time, I found that I have frequent need of joining the
array-items inside an array:
[[1,2],[3,4]] => [ 1,2,3,4 ]
it'd be nice (and make sense ) if concat can take care of this:
Proposed:
concat( [[1,2],[3,4]] ) => [ 1,2,3,4 ]
ps = [ [x1,y1,z1], [x2,y2,z2] ]
qs = [ [x3,y3,z3], [x4,y4,z4] ]
concat( [ps,qs] ) => [ [x1,y1,z1], [x2,y2,z2], [x3,y3,z3], [x4,y4,z4]
]
but the current concat simply throw it back:
concat( [[1,2],[3,4]] ) => [ [1,2],[3,4] ]
concat( [ps,qs] ) => [ps,qs]
Also, concatting multiple string arguments makes no sense to me, either:
concat("a","b","c","d","e","f")=> ["a", "b", "c", "d", "e", "f"]
It falls into the same category that typing concat( s1,s2 ...) is the same
as typing [s1,s2 ...] so there seems to be no need for this feature to
exist.
$ Runsun Pan, PhD
$ -- libs: doctest , faces ( git ), offliner ( git );
ideas: hash ( 1 , 2 ), sweep
$ -- Linux Mint 17.1 Rebecca x64 + OpenSCAD 2015.03.15/2015.04.01.nightly
--
View this message in context: http://forum.openscad.org/Proposed-concat-improvement-tp13283.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Part 1
Runsun proposes that concat([v1,v2,v3]) is equivalent to concat(v1, v2, v3).
I agree with this change. It is useful for the reasons that Runsun
gives. It permits a program to construct the list of vectors to be
concatenated at run time, where the length of the list is determined
dynamically.
It is also consistent with the behaviour of some other functions with
a variable number of arguments, which have already been modified to
work in the same way: you can pass a vector as a single argument. For
example,
min(x,y,z) == min([x,y,z])
max(x,y,z) == max([x,y,z])
chr(x,y,z) == chr([x,y,z])
(I think str() is the only other variable-number-of-arguments function
that doesn't work this way.)
Part 2
I would like to modify concat() so that it can be used to catenate a
list of strings, producing another string. This is part of the
OpenSCAD2 proposal, and the rationale is given here:
https://github.com/doug-moen/openscad2/blob/master/rfc/Sequences.md
So, for example,
concat("a", "b", "c') => "abc"
concat(["a","b","c"]) => "abc"
Doug Moen.
On 23/07/2015, runsun runsun@gmail.com wrote:
The current concat()
https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/The_OpenSCAD_Language#concat
has the feature when there's only one argument: concat( x ):
(1) x is an arr: do nothing, just return the arr:
concat( [1,2,3] ) => [1,2,3]
(2) x is a str: convert the string to a 1-item array:
concat( "abc" ) => ["abc"]
I can't figure under what situation this is useful, because that one
argument is
not something users can assign programmably but have to hard code it. i.e.,
there seems to be no point when typing concat( [1,2,3] ) is the same as
just
[1,2,3].
In the mean time, I found that I have frequent need of joining the
array-items inside an array:
[[1,2],[3,4]] => [ 1,2,3,4 ]
it'd be nice (and make sense ) if concat can take care of this:
*Proposed:*
concat( [[1,2],[3,4]] ) => [ 1,2,3,4 ]
ps = [ [x1,y1,z1], [x2,y2,z2] ]
qs = [ [x3,y3,z3], [x4,y4,z4] ]
concat( [ps,qs] ) => [ [x1,y1,z1], [x2,y2,z2], [x3,y3,z3], [x4,y4,z4]
]
but the current concat simply throw it back:
concat( [[1,2],[3,4]] ) => [ [1,2],[3,4] ]
concat( [ps,qs] ) => [ps,qs]
Also, concatting multiple string arguments makes no sense to me, either:
concat("a","b","c","d","e","f")=> ["a", "b", "c", "d", "e", "f"]
It falls into the same category that typing concat( s1,s2 ...) is the same
as typing [s1,s2 ...] so there seems to be no need for this feature to
exist.
$ Runsun Pan, PhD
$ -- libs: doctest , faces ( git ), offliner ( git );
ideas: hash ( 1 , 2 ), sweep
$ -- Linux Mint 17.1 Rebecca x64 + OpenSCAD 2015.03.15/2015.04.01.nightly
--
View this message in context:
http://forum.openscad.org/Proposed-concat-improvement-tp13283.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
On 07/24/2015 01:25 PM, doug moen wrote:
Part 1
Runsun proposes that concat([v1,v2,v3]) is equivalent to concat(v1, v2, v3).
I agree with this change. It is useful for the reasons that Runsun
gives. It permits a program to construct the list of vectors to be
concatenated at run time, where the length of the list is determined
dynamically.
That's the often cited flatten() in disguise then, at least
when v1,v2,v3 are vectors, right?
I guess it's not really a normal use case to call concat() with
a single value. Using that to implement different behavior seems
a bit strange to me even if that behavior would be useful.
Right now the full behavior is defined as
- create an empty output vector
- for all input values
- if value is a vector add all elements to the output vector
- else add the value to the output vector
Yes, that leaves some cases which are not hugely useful, but why
is that a problem? The same goes for calling min() with a single
number argument.
Maybe it would be better to add some more flexible support for
working with vectors, like splicing and related features which
were mentioned lately?
Part 2
I would like to modify concat() so that it can be used to catenate a
list of strings, producing another string. This is part of the
OpenSCAD2 proposal, and the rationale is given here:
https://github.com/doug-moen/openscad2/blob/master/rfc/Sequences.md
So, for example,
concat("a", "b", "c') => "abc"
concat(["a","b","c"]) => "abc"
Hmm, that produces quite a number of special cases. As soon as there
is one non-string argument, it goes back to the normal behavior?
concat("a", "b", []);
concat("a", "b", undef);
ciao,
Torsten.
The way I see it is:
-- When there are multiple args, loop thru them and do-something;
-- When there's only one arr arg, loop thru its items and do-something;
This is exactly the way max() and min() work, therefore it's consistent.
$ Runsun Pan, PhD
$ -- libs: doctest , faces ( git ), offliner ( git );
ideas: hash ( 1 , 2 ), sweep
$ -- Linux Mint 17.1 Rebecca x64 + OpenSCAD 2015.03.15/2015.04.01.nightly
--
View this message in context: http://forum.openscad.org/Proposed-concat-improvement-tp13283p13291.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
On 07/24/2015 12:35 PM, Torsten Paul wrote:
quite a number of special cases.
Being an OpenSCAD user of Small Brain, I appreciate semantics that
follow the Principle of Least Surprise. When a function does something
/different/ for seemingly similar inputs, I have a hard time remembering
what it /should/ do for any of them.
My favorite screwup is watching translate() silently do nothing when I
forget the square brackets around the vector. That's at least
understandable, because I build my simple models in small steps, and
I've grown accustomed to the lack of an error message.
However, as a silly example, if you folks suddenly decide that giving
translate() a list of scalars should add them all up and translate
along, oh, the XYZ first-quadrant diagonal by their sum, I'd /never/
figure it out after my usual typo.
Please use different names for different operations, so I can read my
code and figure out what's going on. Ideally, my inevitable blunders
won't become impossible to debug when you're finished.
Thanks...
--
Ed
softsolder.com
ednisley wrote
On 07/24/2015 12:35 PM, Torsten Paul wrote:
quite a number of special cases.
...
Please use different names for different operations, so I can read my
code and figure out what's going on. Ideally, my inevitable blunders
won't become impossible to debug when you're finished.
Following your idea, I would prefer concat() leaves strings alone. i.e.,
--- concat( ) handles concatenation of arrays
--- join( ) handles concatenation of strings
concat( [1,2], [3,4]) => [1,2,3,4]
concat( [ [1,2], [3,4] ] ) => [1,2,3,4]
join( ["a","b","c"] )=> "abc"
join( ["a",[1,2],"c"] ) => "a[1, 2]c"
join( ["a",undef,"c"] ) => "aundefc"
join( [ [1,2], [3,4] ] ) => "[1, 2][3, 4]"
Certainly, we don't have join( ), yet.
Note that if a join takes one array argument: join( arr ),
it is then possible to upgrade it :
join( ["a","b","c"], "/" )=> "a/b/c"
This is another benefit of having an array as the single argument:
we can add new argument in the future if needed.
$ Runsun Pan, PhD
$ -- libs: doctest , faces ( git ), offliner ( git );
ideas: hash ( 1 , 2 ), sweep
$ -- Linux Mint 17.1 Rebecca x64 + OpenSCAD 2015.03.15/2015.04.01.nightly
--
View this message in context: http://forum.openscad.org/Proposed-concat-improvement-tp13283p13293.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Torsten wrote:
I guess it's not really a normal use case to call concat() with
a single value. Using that to implement different behavior seems
a bit strange to me even if that behavior would be useful.
It's actually not that strange, because min(), max() and chr() already work
that way.
The changes to min() and max() were done in the 2014 release, according to
the wiki.
So Runsun's proposal is equivalent to making concat() consistent with the
way that min(), max() etc already work.
On 24 July 2015 at 12:35, Torsten Paul Torsten.Paul@gmx.de wrote:
On 07/24/2015 01:25 PM, doug moen wrote:
Part 1
Runsun proposes that concat([v1,v2,v3]) is equivalent to concat(v1, v2,
v3).
I agree with this change. It is useful for the reasons that Runsun
gives. It permits a program to construct the list of vectors to be
concatenated at run time, where the length of the list is determined
dynamically.
That's the often cited flatten() in disguise then, at least
when v1,v2,v3 are vectors, right?
I guess it's not really a normal use case to call concat() with
a single value. Using that to implement different behavior seems
a bit strange to me even if that behavior would be useful.
Right now the full behavior is defined as
- create an empty output vector
- for all input values
- if value is a vector add all elements to the output vector
- else add the value to the output vector
Yes, that leaves some cases which are not hugely useful, but why
is that a problem? The same goes for calling min() with a single
number argument.
Maybe it would be better to add some more flexible support for
working with vectors, like splicing and related features which
were mentioned lately?
Part 2
I would like to modify concat() so that it can be used to catenate a
list of strings, producing another string. This is part of the
OpenSCAD2 proposal, and the rationale is given here:
https://github.com/doug-moen/openscad2/blob/master/rfc/Sequences.md
So, for example,
concat("a", "b", "c') => "abc"
concat(["a","b","c"]) => "abc"
Hmm, that produces quite a number of special cases. As soon as there
is one non-string argument, it goes back to the normal behavior?
concat("a", "b", []);
concat("a", "b", undef);
ciao,
Torsten.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
runsun wrote
--- join( ) handles concatenation of strings
join( ["a","b","c"] )=> "abc"
join( ["a",[1,2],"c"] ) => "a[1, 2]c"
join( ["a",undef,"c"] ) => "aundefc"
join( [ [1,2], [3,4] ] ) => "[1, 2][3, 4]"
Certainly, we don't have join( ), yet.
Note that if a join takes one array argument: join( arr ),
it is then possible to upgrade it :
join( ["a","b","c"], "/" )=> "a/b/c"
This is another benefit of having an array as the single argument:
we can add new argument in the future if needed.
Note str() does the first bunch of examples above.
Unless specifically shown otherwise above, my contribution is in the Public Domain; To the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. This work is published globally via the internet. :) Inclusion of works of previous authors is not included in the above.
The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/
View this message in context: http://forum.openscad.org/Proposed-concat-improvement-tp13283p13301.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
MichaelAtOz wrote
Note str() does the first bunch of examples above.
Not in the OpenSCAD I am using (version 2015.06.21.nightly):
join( ["a","b","c"] )=> "abc"
str( ["a","b","c"] )=> "["a", "b", "c"]"
join( ["a",[1,2],"c"] ) => "a[1, 2]c"
str( ["a",[1,2],"c"] ) => "["a", [1, 2], "c"]"
join( ["a",undef,"c"] ) => "aundefc"
str( ["a",undef,"c"] ) => "["a", undef, "c"]"
join( [ [1,2], [3,4] ] ) => "[1, 2][3, 4]"
str( [ [1,2], [3,4] ] ) => "[[1, 2], [3, 4]]"
Which version are you talking about ?
$ Runsun Pan, PhD
$ -- libs: doctest , faces ( git ), offliner ( git );
ideas: hash ( 1 , 2 ), sweep
$ -- Linux Mint 17.1 Rebecca x64 + OpenSCAD 2015.03.15/2015.04.01.nightly
--
View this message in context: http://forum.openscad.org/Proposed-concat-improvement-tp13283p13302.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
module join(a="",b="",c="") echo(str(a,b,c));
join( "a","b","c" );//=> "abc"
join( "a",[1,2],"c" ); //=> "a[1, 2]c"
join( "a",undef,"c" ); //=> "aundefc"
join( [1,2], [3,4] ); //=> "[1, 2][3, 4]"
Compiling design (CSG Tree generation)...
ECHO: "abc"
ECHO: "a[1, 2]c"
ECHO: "aundefc"
ECHO: "[1, 2][3, 4]"
Compiling design (CSG Products generation)...
Unless specifically shown otherwise above, my contribution is in the Public Domain; To the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. This work is published globally via the internet. :) Inclusion of works of previous authors is not included in the above.
The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/
View this message in context: http://forum.openscad.org/Proposed-concat-improvement-tp13283p13303.html
Sent from the OpenSCAD mailing list archive at Nabble.com.