AM
Adrian Mariano
Tue, Feb 15, 2022 9:21 PM
To add a little bit more to what Ronaldo wrote, the problem is being
robust and avoiding unexpected outcomes. I am a library author and am
not in control of what a user does. So no, it is not entirely up to
me that the data is valid. I have to assume the user may do something
stupid. Also, accidents happen. You think p is a value but it's a
vector. You made a mistake. One can question what the right outcome
is in this case. Ideally perhaps an error, but the behavior shouldn't
be puzzling and surprising, which unfortunately the behavior of
search() is.
The design of search() is bad because what is arguably the most basic
case is impossible to perform. You can only do it though fussy
workarounds that compromise the performance. I would say it's much
more important to fix this than the warning message.
On Tue, Feb 15, 2022 at 7:51 AM MichaelAtOz oz.at.michael@gmail.com wrote:
"Goal", "normal search", "actually match".
You use the tools available, don't blame the hammer because you want to use a screw.
You miss my point, IF you use appropriate data structures, it works.
If you have garbage structures you get garbage, it is entirely up to you.
search() does as advertised, it is not inherently wrong, use it the right way, it works.
[and you get warnings...just because your choice of haystack is a vector of vectors, does not mean
a non-match is a warning...I argued on GitHub...]
-----Original Message-----
From: Adrian Mariano [mailto:avm4@cornell.edu]
Sent: Tue, 15 Feb 2022 22:26
To: OpenSCAD general discussion
Subject: [OpenSCAD] Re: search function is broken
If your goal is to write a normal search that returns the items that
actually match, then it's wrong. The code you show chooses the
option of finding all matches and then looking through that result for
the desired output. What if your list has a million entries and the
desired result is in position 8, and there are half a million positive
results. Then maybe that's not an efficient way to do it. So it it
better to write that method the way you did? Or is it better to write
it as a recursive function that calls search repeatedly---in principle
a quadratic algorithm. Or is it better to just write a recursion
that walks the list and looks for the first match and doesn't use
search()? The point I'm getting at is that the whole benefit of using
search() with the option to return only N hits is that it presumably
can save time vs searching the entire list, and you give up that
advantage if you want actual matches instead of the quirky type
matches it returns.
On Tue, Feb 15, 2022 at 2:12 AM MichaelAtOz oz.at.michael@gmail.com wrote:
Search returns the index 2
referring to [5,6] which is wrong.
It's not wrong, it's what it does.
If you have a data in a wrong structure, you will get wrong results. GIGO
So if you only want to operate on atomic entries in an unknown structure of course it is
more work.
list=[3,4,[5,6],3,5,7,9,5,4,3];
// 0,1,2 ,3,4,5,6,7,8,9
function searchAtomic(needle,haystack,nth=0) =[
for (i = search([needle], haystack , 1e12) )
for (r = i)
if (!is_list(haystack[r]))
r ][nth];
echo(searchAtomic(5, list)); // 4
echo(searchAtomic(5, list,1)); // 7
echo(searchAtomic(5, list,9)); // undef
-----Original Message-----
From: Adrian Mariano [mailto:avm4@cornell.edu]
Sent: Tue, 15 Feb 2022 16:17
To: OpenSCAD general discussion
Subject: [OpenSCAD] Re: search function is broken
Yeah, that is surely the way to go. The trouble is that it's harder
to do than it appears. Suppose you want to find the first match. So
you do search([5], [3,4,[5,6],3,5]). Search returns the index 2
referring to [5,6] which is wrong. So how do you find the first
match? You need to look for the second match now? Or find all
matches from the beginning? There's not really a good solution. I
mean, you could assume that this case is rare and just recurse,
looking for the 2nd match if it fails. But it's complicated.
On Tue, Feb 15, 2022 at 12:10 AM A. Craig West acraigwest@gmail.com wrote:
I feel certain that I fell into this rabbit hole the first time I tried to use
search
for something. I believe my solution then was to wrap it in more meaningful functions
On Mon, 14 Feb 2022, 11:45 nop head, nop.head@gmail.com wrote:
The warning itself seems broken because no matter what the string key is it only
warns
about the second letter. Or perhaps I don't understand search. I have never used it
because it is pretty incomprehensible to me.
On Mon, 14 Feb 2022 at 16:36, Jordan Brown openscad@jordan.maileater.net wrote:
On 2/13/2022 3:14 PM, Adrian Mariano wrote:
I can't imagine why anybody thought issuing a warning when you don't find
something
was a good idea.
Nor can I. But removing a warning is a compatible change...
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
--
This email has been checked for viruses by AVG.
https://www.avg.com
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
--
This email has been checked for viruses by AVG.
https://www.avg.com
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
To add a little bit more to what Ronaldo wrote, the problem is being
robust and avoiding unexpected outcomes. I am a library author and am
not in control of what a user does. So no, it is *not* entirely up to
me that the data is valid. I have to assume the user may do something
stupid. Also, accidents happen. You think p is a value but it's a
vector. You made a mistake. One can question what the right outcome
is in this case. Ideally perhaps an error, but the behavior shouldn't
be puzzling and surprising, which unfortunately the behavior of
search() is.
The design of search() is bad because what is arguably the most basic
case is impossible to perform. You can only do it though fussy
workarounds that compromise the performance. I would say it's much
more important to fix this than the warning message.
On Tue, Feb 15, 2022 at 7:51 AM MichaelAtOz <oz.at.michael@gmail.com> wrote:
>
> "Goal", "normal search", "actually match".
> You use the tools available, don't blame the hammer because you want to use a screw.
>
> You miss my point, IF you use appropriate data structures, it works.
> If you have garbage structures you get garbage, it is entirely up to you.
>
> search() does as advertised, it is not inherently wrong, use it the right way, it works.
>
> [and you get warnings...just because your choice of haystack is a vector of vectors, does not mean
> a non-match is a warning...I argued on GitHub...]
>
> > -----Original Message-----
> > From: Adrian Mariano [mailto:avm4@cornell.edu]
> > Sent: Tue, 15 Feb 2022 22:26
> > To: OpenSCAD general discussion
> > Subject: [OpenSCAD] Re: search function is broken
> >
> > If your goal is to write a normal search that returns the items that
> > actually match, then it's wrong. The code you show chooses the
> > option of finding all matches and then looking through that result for
> > the desired output. What if your list has a million entries and the
> > desired result is in position 8, and there are half a million positive
> > results. Then maybe that's not an efficient way to do it. So it it
> > better to write that method the way you did? Or is it better to write
> > it as a recursive function that calls search repeatedly---in principle
> > a quadratic algorithm. Or is it better to just write a recursion
> > that walks the list and looks for the first match and doesn't use
> > search()? The point I'm getting at is that the whole benefit of using
> > search() with the option to return only N hits is that it presumably
> > can save time vs searching the entire list, and you give up that
> > advantage if you want actual matches instead of the quirky type
> > matches it returns.
> >
> > On Tue, Feb 15, 2022 at 2:12 AM MichaelAtOz <oz.at.michael@gmail.com> wrote:
> > >
> > > > Search returns the index 2
> > > > referring to [5,6] which is wrong.
> > >
> > > It's not wrong, it's what it does.
> > > If you have a data in a wrong structure, you will get wrong results. GIGO
> > > So if you only want to operate on atomic entries in an unknown structure of course it is
> > more work.
> > >
> > > list=[3,4,[5,6],3,5,7,9,5,4,3];
> > > // 0,1,2 ,3,4,5,6,7,8,9
> > > function searchAtomic(needle,haystack,nth=0) =[
> > > for (i = search([needle], haystack , 1e12) )
> > > for (r = i)
> > > if (!is_list(haystack[r]))
> > > r ][nth];
> > > echo(searchAtomic(5, list)); // 4
> > > echo(searchAtomic(5, list,1)); // 7
> > > echo(searchAtomic(5, list,9)); // undef
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Adrian Mariano [mailto:avm4@cornell.edu]
> > > > Sent: Tue, 15 Feb 2022 16:17
> > > > To: OpenSCAD general discussion
> > > > Subject: [OpenSCAD] Re: search function is broken
> > > >
> > > > Yeah, that is surely the way to go. The trouble is that it's harder
> > > > to do than it appears. Suppose you want to find the first match. So
> > > > you do search([5], [3,4,[5,6],3,5]). Search returns the index 2
> > > > referring to [5,6] which is wrong. So how do you find the first
> > > > match? You need to look for the second match now? Or find all
> > > > matches from the beginning? There's not really a good solution. I
> > > > mean, you could assume that this case is rare and just recurse,
> > > > looking for the 2nd match if it fails. But it's complicated.
> > > >
> > > >
> > > >
> > > > On Tue, Feb 15, 2022 at 12:10 AM A. Craig West <acraigwest@gmail.com> wrote:
> > > > >
> > > > > I feel certain that I fell into this rabbit hole the first time I tried to use
> > search
> > > > for something. I believe my solution then was to wrap it in more meaningful functions
> > > > >
> > > > > On Mon, 14 Feb 2022, 11:45 nop head, <nop.head@gmail.com> wrote:
> > > > >>
> > > > >> The warning itself seems broken because no matter what the string key is it only
> > warns
> > > > about the second letter. Or perhaps I don't understand search. I have never used it
> > > > because it is pretty incomprehensible to me.
> > > > >>
> > > > >> On Mon, 14 Feb 2022 at 16:36, Jordan Brown <openscad@jordan.maileater.net> wrote:
> > > > >>>
> > > > >>> On 2/13/2022 3:14 PM, Adrian Mariano wrote:
> > > > >>>
> > > > >>> I can't imagine why anybody thought issuing a warning when you don't find
> > something
> > > > was a good idea.
> > > > >>>
> > > > >>>
> > > > >>> Nor can I. But removing a warning is a compatible change...
> > > > >>>
> > > > >>> _______________________________________________
> > > > >>> OpenSCAD mailing list
> > > > >>> To unsubscribe send an email to discuss-leave@lists.openscad.org
> > > > >>
> > > > >> _______________________________________________
> > > > >> OpenSCAD mailing list
> > > > >> To unsubscribe send an email to discuss-leave@lists.openscad.org
> > > > >
> > > > > _______________________________________________
> > > > > OpenSCAD mailing list
> > > > > To unsubscribe send an email to discuss-leave@lists.openscad.org
> > > > _______________________________________________
> > > > OpenSCAD mailing list
> > > > To unsubscribe send an email to discuss-leave@lists.openscad.org
> > >
> > >
> > > --
> > > This email has been checked for viruses by AVG.
> > > https://www.avg.com
> > > _______________________________________________
> > > OpenSCAD mailing list
> > > To unsubscribe send an email to discuss-leave@lists.openscad.org
> > _______________________________________________
> > OpenSCAD mailing list
> > To unsubscribe send an email to discuss-leave@lists.openscad.org
>
>
> --
> This email has been checked for viruses by AVG.
> https://www.avg.com
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
JB
Jordan Brown
Tue, Feb 15, 2022 10:11 PM
I think we could get rid of the warning message, and call it
compatible. Changing the search logic is much harder to do compatibly.
It seems to me that there are three options:
- Find a way to make the current arguments yield results that are more
useful and understandable. (I'm dubious that this can be done
compatibly.)
- Add new arguments, or new semantics for old arguments, that yield
results that are more useful and understandable. (Documentation
will be difficult, since it will need to cover both old and new
semantics.)
- Create a new function or functions that does the desired thing.
Ideally it/they could cover all existing search() use cases, so that
search itself can be relegated to legacy.
I'm inclined toward that last option. Other thoughts?
I think we could get rid of the warning message, and call it
compatible. Changing the search logic is much harder to do compatibly.
It seems to me that there are three options:
* Find a way to make the current arguments yield results that are more
useful and understandable. (I'm dubious that this can be done
compatibly.)
* Add new arguments, or new semantics for old arguments, that yield
results that are more useful and understandable. (Documentation
will be difficult, since it will need to cover both old and new
semantics.)
* Create a new function or functions that does the desired thing.
Ideally it/they could cover all existing search() use cases, so that
search itself can be relegated to legacy.
I'm inclined toward that last option. Other thoughts?
TP
Torsten Paul
Tue, Feb 15, 2022 10:35 PM
On 15.02.22 23:11, Jordan Brown wrote:
I'm inclined toward that last option. Other thoughts?
I'd call the last one the only option.
ciao,
Torsten.
On 15.02.22 23:11, Jordan Brown wrote:
> I'm inclined toward that last option. Other thoughts?
I'd call the last one the only option.
ciao,
Torsten.
PC
Patrick Callahan
Tue, Feb 15, 2022 11:02 PM
To add a little bit more to what Ronaldo wrote, the problem is being
robust and avoiding unexpected outcomes. I am a library author and am
not in control of what a user does. So no, it is not entirely up to
me that the data is valid. I have to assume the user may do something
stupid. Also, accidents happen. You think p is a value but it's a
vector. You made a mistake. One can question what the right outcome
is in this case. Ideally perhaps an error, but the behavior shouldn't
be puzzling and surprising, which unfortunately the behavior of
search() is.
The design of search() is bad because what is arguably the most basic
case is impossible to perform. You can only do it though fussy
workarounds that compromise the performance. I would say it's much
more important to fix this than the warning message.
It might be instructive to determine when the search facility was added to
OpenSCAD and look at any discussion around it at that time. Things like
this have a history, and that might explain some things.
If you believe the documentation on search, it’s intent is to be some kind
of generalized facilty for searching. On reading that, my BS detector went
off. Was it a False Alarm?
It’s treatment of strings as inputs seems at first glance to be somewhat
arcane. If a single input string results in the matching of the individual
characters of the input string as separate matches, one has to ask why. If
that’s the intent, aren’t there much better syntactic ways to express such
an idea?.
I’m guessing but the right question to ask about this might be: Is this a
bug, a design error or something else. If it’s something else, somebody
needs to explain it better than the present documentation. It’s confusing
some pretty smart people.
-Pat
On Tue, Feb 15, 2022, at 5:21 PM, Adrian Mariano <avm4@cornell.edu> wrote:
> To add a little bit more to what Ronaldo wrote, the problem is being
> robust and avoiding unexpected outcomes. I am a library author and am
> not in control of what a user does. So no, it is *not* entirely up to
> me that the data is valid. I have to assume the user may do something
> stupid. Also, accidents happen. You think p is a value but it's a
> vector. You made a mistake. One can question what the right outcome
> is in this case. Ideally perhaps an error, but the behavior shouldn't
> be puzzling and surprising, which unfortunately the behavior of
> search() is.
>
> The design of search() is bad because what is arguably the most basic
> case is impossible to perform. You can only do it though fussy
> workarounds that compromise the performance. I would say it's much
> more important to fix this than the warning message.
>
It might be instructive to determine when the search facility was added to
OpenSCAD and look at any discussion around it at that time. Things like
this have a history, and that might explain some things.
If you believe the documentation on search, it’s intent is to be some kind
of generalized facilty for searching. On reading that, my BS detector went
off. Was it a False Alarm?
It’s treatment of strings as inputs seems at first glance to be somewhat
arcane. If a single input string results in the matching of the individual
characters of the input string as separate matches, one has to ask why. If
that’s the intent, aren’t there much better syntactic ways to express such
an idea?.
I’m guessing but the right question to ask about this might be: Is this a
bug, a design error or something else. If it’s something else, somebody
needs to explain it better than the present documentation. It’s confusing
some pretty smart people.
-Pat
M
MichaelAtOz
Tue, Feb 15, 2022 11:13 PM
It depends on how many issues there are, if there are one/few it would be expeditious to improve search.
Disregarding warnings, the single v vector v mixed haystack and how it handles that seems to be one issue.
Ronaldo suggests
Function search() should not have a default value for index_col_num. If the argument is missing (undef), search() should look just for matching full list entries (either a singleton or a vector). And if index_col_num is given, it should look only at the prescribed column of vectors that have that column.
It's unclear what 'matching full list entries' means. Presumably matching by type, where needle is a non-vector don't search inside vectors, if it is a vector then only search vectors in the haystack.
We shouldn't do it based on index_col_num=undef, as that may break existing use.
If that is it, then a search match type parameter could be used, defaults to the current behaviour, match_type=true perhaps.
I'm inclined toward that last option. Other thoughts?
--
This email has been checked for viruses by AVG.
https://www.avg.com
It depends on how many issues there are, if there are one/few it would be expeditious to improve search.
Disregarding warnings, the single v vector v mixed haystack and how it handles that seems to be one issue.
Ronaldo suggests
Function search() should not have a default value for index_col_num. If the argument is missing (undef), search() should look just for matching full list entries (either a singleton or a vector). And if index_col_num is given, it should look only at the prescribed column of vectors that have that column.
It's unclear what 'matching full list entries' means. Presumably matching by type, where needle is a non-vector don't search inside vectors, if it is a vector then only search vectors in the haystack.
We shouldn't do it based on index_col_num=undef, as that may break existing use.
If that is it, then a search match type parameter could be used, defaults to the current behaviour, match_type=true perhaps.
I'm inclined toward that last option. Other thoughts?
--
This email has been checked for viruses by AVG.
https://www.avg.com
TP
Torsten Paul
Tue, Feb 15, 2022 11:20 PM
On 16.02.22 00:02, Patrick Callahan wrote:
It might be instructive to determine when the search
facility was added to OpenSCAD and look at any discussion
around it at that time. Things like this have a history,
and that might explain some things.
What a perfect time to ask that question :-)
The answer is: exactly 10 years ago to the day!
(+/- timezones, clock just rolled over to Feb, 16th here)
For the historians:
https://github.com/openscad/openscad/pull/90
And maybe some more recent discussion here:
https://github.com/openscad/openscad/pull/1318
I'm not sure there's much more use in digging into this
than curiosity.
A more interesting question seems to be what a future
replacement could look like.
ciao,
Torsten.
On 16.02.22 00:02, Patrick Callahan wrote:
> It might be instructive to determine when the search
> facility was added to OpenSCAD and look at any discussion
> around it at that time. Things like this have a history,
> and that might explain some things.
What a perfect time to ask that question :-)
The answer is: exactly 10 years ago to the day!
(+/- timezones, clock just rolled over to Feb, 16th here)
For the historians:
https://github.com/openscad/openscad/pull/90
And maybe some more recent discussion here:
https://github.com/openscad/openscad/pull/1318
I'm not sure there's much more use in digging into this
than curiosity.
A more interesting question seems to be what a future
replacement could look like.
ciao,
Torsten.
AM
Adrian Mariano
Tue, Feb 15, 2022 11:46 PM
I would say that the basic search behavior would be that search([x],list)
returns exactly those indices, i, such that list[i]==x is true. I think
that's what Ronaldo meant by "matching full list entries". No special
behaviors relating types or whether things are or are not vectors or
lists. You never search inside vectors. You just perform a simple
equality test. If you search for 5 and an entry in list is [5,5] then
they are different, so it is not a match. If you search for [5,5] then
[5,5] would be a match in a larger list that might be
[[1,1],[2,2],[3,3,3,3,3],4,5,[5,5]].
On Tue, Feb 15, 2022 at 6:14 PM MichaelAtOz oz.at.michael@gmail.com wrote:
It depends on how many issues there are, if there are one/few it would be
expeditious to improve search.
Disregarding warnings, the single v vector v mixed haystack and how it
handles that seems to be one issue.
Ronaldo suggests
Function search() should not have a default value for index_col_num. If
the argument is missing (undef), search() should look just for matching
full list entries (either a singleton or a vector). And if index_col_num is
given, it should look only at the prescribed column of vectors that have
that column.
It's unclear what 'matching full list entries' means. Presumably matching
by type, where needle is a non-vector don't search inside vectors, if it is
a vector then only search vectors in the haystack.
We shouldn't do it based on index_col_num=undef, as that may break
existing use.
If that is it, then a search match type parameter could be used, defaults
to the current behaviour, match_type=true perhaps.
I'm inclined toward that last option. Other thoughts?
http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient Virus-free.
www.avg.com
http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient
<#m_5567020748495808241_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
I would say that the basic search behavior would be that search([x],list)
returns exactly those indices, i, such that list[i]==x is true. I think
that's what Ronaldo meant by "matching full list entries". No special
behaviors relating types or whether things are or are not vectors or
lists. You *never* search inside vectors. You just perform a simple
equality test. If you search for 5 and an entry in list is [5,5] then
they are different, so it is not a match. If you search for [5,5] then
[5,5] would be a match in a larger list that might be
[[1,1],[2,2],[3,3,3,3,3],4,5,[5,5]].
On Tue, Feb 15, 2022 at 6:14 PM MichaelAtOz <oz.at.michael@gmail.com> wrote:
> It depends on how many issues there are, if there are one/few it would be
> expeditious to improve search.
>
>
>
> Disregarding warnings, the single v vector v mixed haystack and how it
> handles that seems to be one issue.
>
> Ronaldo suggests
>
> Function search() should not have a default value for *index_col_num*. If
> the argument is missing (undef), search() should look just for matching
> full list entries (either a singleton or a vector). And if *index_col_num* is
> given, it should look only at the prescribed column of vectors that have
> that column.
>
> It's unclear what 'matching full list entries' means. Presumably matching
> by type, where needle is a non-vector don't search inside vectors, if it is
> a vector then only search vectors in the haystack.
>
> We shouldn't do it based on *index_col_num=undef*, as that may break
> existing use.
>
> If that is it, then a search match type parameter could be used, defaults
> to the current behaviour, *match_type=true* perhaps.
>
>
>
> I'm inclined toward that last option. Other thoughts?
>
>
> <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> Virus-free.
> www.avg.com
> <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
> <#m_5567020748495808241_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
>
PC
Patrick Callahan
Wed, Feb 16, 2022 12:03 AM
I'm not sure there's much more use in digging into this
than curiosity.
History’s important. I read through it and found it worthwhile.
A more interesting question seems to be what a future —!
replacement could look like.
Replacement or perhaps renaming. Several have suggested that there are
valid use cases for the search function as written. The thread contains at
least one example of this from Oz. It might be worth taking a look at
specific examples where it’s used, especially if it’s used in any library.
I’d take a look at the claim of generality in the documentation. I think
that’s a problem. Also, the documentation focuses on what the search
does. Perhaps a bit more about how it might be useful would clarify the
current situation. Certainly those who proposed it and worked on it 10
years ago found it useful.
Note that they also found it buggy and confusing. Perhaps a move away from
an attempt at generality might help. Specific language features for
specific types. More than one kind of search. Maybe more than one
matching engine and different ways to return the result of the search.
Specific issue I’d take with the current search , . design are the
equivalence of “abc” with [“a”, “b”, “c”]. I’m sure that’s a source of a
whole bunch of confusion. If it’s needed functionality to re-interpret a
string this way, it should be an option, not a default. "
-pat
Thanks Torsten!
On Tue, Feb 15, 2022 at 7:21 PM Torsten Paul <Torsten.Paul@gmx.de> wrote:
>
>
> For the historians:
> https://github.com/o penscad/openscad/pull/90
> <https://github.com/openscad/openscad/pull/90>
>
> And maybe some more recent discussion here:
> https://github.com/openscad/openscad/pull/1318
> I'm not sure there's much more use in digging into this
> than curiosity.
History’s important. I read through it and found it worthwhile.
>
>
> A more interesting question seems to be what a future —!
> replacement could look like.
>
>
Replacement or perhaps renaming. Several have suggested that there are
valid use cases for the search function as written. The thread contains at
least one example of this from Oz. It might be worth taking a look at
specific examples where it’s used, especially if it’s used in any library.
I’d take a look at the claim of generality in the documentation. I think
that’s a problem. Also, the documentation focuses on what the search
does. Perhaps a bit more about how it might be useful would clarify the
current situation. Certainly those who proposed it and worked on it 10
years ago found it useful.
Note that they also found it buggy and confusing. Perhaps a move away from
an attempt at generality might help. Specific language features for
specific types. More than one kind of search. Maybe more than one
matching engine and different ways to return the result of the search.
Specific issue I’d take with the current search , . design are the
equivalence of “abc” with [“a”, “b”, “c”]. I’m sure that’s a source of a
whole bunch of confusion. If it’s needed functionality to re-interpret a
string this way, it should be an option, not a default. "
-pat
>
>
JB
Jordan Brown
Wed, Feb 16, 2022 12:29 AM
On 2/15/2022 4:03 PM, Patrick Callahan wrote:
Specific issue I’d take with the current search , . design are the
equivalence of “abc” with [“a”, “b”, “c”]. I’m sure that’s a source
of a whole bunch of confusion. If it’s needed functionality to
re-interpret a string this way, it should be an option, not a default. "
I assume (without looking at the implementation or historical record)
that the string behavior derives from the fact that OpenSCAD strings
look a lot like arrays.
Consider:
v[3]
len(v)
for (i = v) ...;
which all work on both arrays and strings.
I don't feel like writing one right now, but I suspect that an obvious
implementation of "find the elements of array b that are in array a",
that does not attempt to handle strings, would work with strings exactly
as search() works.
search([1,2,3], [6,4,3,5,2,1])
search("abc", "fdceba")
produce the same result: [5,4,2].
Obvious? Perhaps not. But at least sort of consistent.
On 2/15/2022 4:03 PM, Patrick Callahan wrote:
> Specific issue I’d take with the current search , . design are the
> equivalence of “abc” with [“a”, “b”, “c”]. I’m sure that’s a source
> of a whole bunch of confusion. If it’s needed functionality to
> re-interpret a string this way, it should be an option, not a default. "
I assume (without looking at the implementation or historical record)
that the string behavior derives from the fact that OpenSCAD strings
look a lot like arrays.
Consider:
*
v[3]
*
len(v)
*
for (i = v) ...;
which all work on both arrays and strings.
I don't feel like writing one right now, but I suspect that an obvious
implementation of "find the elements of array b that are in array a",
that does not attempt to handle strings, would work with strings exactly
as search() works.
*
search([1,2,3], [6,4,3,5,2,1])
*
search("abc", "fdceba")
produce the same result: [5,4,2].
Obvious? Perhaps not. But at least sort of consistent.
TP
Torsten Paul
Wed, Feb 16, 2022 12:38 AM
On 16.02.22 01:03, Patrick Callahan wrote:
Replacement or perhaps renaming. Several have suggested
that there are valid use cases for the search function as
written.
Right, maybe it will stay forever, it certainly has seen
lots of interesting uses and made feature possible that
would not have worked otherwise.
But we also need to consider, there's new features that
maybe just need to be made easier to use, e.g. some of
the "search in array" cases can be done without any new
core feature:
find_index = function(v, pred)
[ for (i = 0;i < len(v);i = i + 1) if (pred(v[i])) i];
first_in_vector = function(v) function(e) e[0] == v;
last_in_vector = function(v) function(e) e[len(e) - 1] == v;
a = [["M3", 3, false], ["M4", 4, true], ["M5", 5, "x", false]];
echo(find_index(a, first_in_vector("M4")));
// ECHO: [1]
echo(find_index(a, last_in_vector(false)));
// ECHO: [0, 2]
ciao,
Torsten.
On 16.02.22 01:03, Patrick Callahan wrote:
> Replacement or perhaps renaming. Several have suggested
> that there are valid use cases for the search function as
> written.
Right, maybe it will stay forever, it certainly has seen
lots of interesting uses and made feature possible that
would not have worked otherwise.
But we also need to consider, there's new features that
maybe just need to be made easier to use, e.g. some of
the "search in array" cases can be done without any new
core feature:
find_index = function(v, pred)
[ for (i = 0;i < len(v);i = i + 1) if (pred(v[i])) i];
first_in_vector = function(v) function(e) e[0] == v;
last_in_vector = function(v) function(e) e[len(e) - 1] == v;
a = [["M3", 3, false], ["M4", 4, true], ["M5", 5, "x", false]];
echo(find_index(a, first_in_vector("M4")));
// ECHO: [1]
echo(find_index(a, last_in_vector(false)));
// ECHO: [0, 2]
ciao,
Torsten.
