New feature in 2025.07.11: the object() function
I agree that I would not be likely to use len() with an object(), but something I would be possibly worried about (which I'm guessing is part of what "define the length" means) is when updating my code. Not so much updating the values, but I would not be surprised if I (and many others) occasionally added (especially for libraries) functions as members, which would ask the question of whether functions were included when determining len()
Nathan Sokalski
njsokalski@hotmail.commailto:njsokalski@hotmail.com
From: Jordan Brown via Discuss discuss@lists.openscad.org
Sent: Friday, August 8, 2025 3:59 AM
To: OpenSCAD general discussion Mailing-list discuss@lists.openscad.org
Cc: Steve Lelievre steve.lelievre.canada@gmail.com; Jordan Brown openscad@jordan.maileater.net
Subject: [OpenSCAD] Re: New feature in 2025.07.11: the object() function
On 8/7/2025 11:33 PM, Steve Lelievre via Discuss wrote:
Revar’s suggestion returning the length of a vector of one object,
which isn’t quite the same thing as the length of the object per se.
First, you need to define the length of an object. Revar's definition,
and the one that I would think of would be "the number of elements in
the object", along the same lines as len(vector). I'm not immediately
coming up with a different definition that would be more useful. (Heck,
I'm not immediately coming up with a different definition that would be
useful at all.)
For comparison, what does len do for any other non-vector, non-string
variable? (I’m away from home so can’t check)
It's an error.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
function funcless_len=len([for(x=obj)if(!is_function(x))x]);
-Revar
On Aug 8, 2025, at 12:08 PM, Nathan Sokalski via Discuss <discuss@lists.openscad.org> wrote:
I agree that I would not be likely to use len() with an object(), but something I would be possibly worried about (which I'm guessing is part of what "define the length" means) is when updating my code. Not so much updating the values, but I would not be surprised if I (and many others) occasionally added (especially for libraries) functions as members, which would ask the question of whether functions were included when determining len()
Nathan Sokalski
njsokalski@hotmail.com
From: Jordan Brown via Discuss <discuss@lists.openscad.org>
Sent: Friday, August 8, 2025 3:59 AM
To: OpenSCAD general discussion Mailing-list <discuss@lists.openscad.org>
Cc: Steve Lelievre <steve.lelievre.canada@gmail.com>; Jordan Brown <openscad@jordan.maileater.net>
Subject: [OpenSCAD] Re: New feature in 2025.07.11: the object() functionOn 8/7/2025 11:33 PM, Steve Lelievre via Discuss wrote:
> Revar’s suggestion returning the length of a vector of one object,
> which isn’t quite the same thing as the length of the object per se.First, you need to define the length of an object. Revar's definition,
and the one that I would think of would be "the number of elements in
the object", along the same lines as len(vector). I'm not immediately
coming up with a different definition that would be more useful. (Heck,
I'm not immediately coming up with a different definition that would be
useful at all.)> For comparison, what does len do for any other non-vector, non-string
> variable? (I’m away from home so can’t check)It's an error.
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
On 8/8/2025 12:07 PM, Nathan Sokalski via Discuss wrote:
I agree that I would not be likely to use len() with an object(), but
something I would be possibly worried about (which I'm guessing is
part of what "define the length" means) is when updating my code. Not
so much updating the values, but I would not be surprised if I (and
many others) occasionally added (especially for libraries) functions
as members, which would ask the question of whether functions were
included when determining len()
[ Note: len() for objects merged a few hours ago. ]
len() counts members. Members are members. There is nothing special
about a member that happens to be a function reference.
For the record, I just implemented an experimental object() based version of the vnf_merge_points() function, an an initial test with a VNF of an octa style spheroid with $fn=144 had about an 18x speedup.
- Revar
That sounds very good, but not sure I understand where the speed up comes from?
Peter
On 25 Aug 2025, at 14:42, Revar Desmera via Discuss discuss@lists.openscad.org wrote:
For the record, I just implemented an experimental object() based version of the vnf_merge_points() function, an an initial test with a VNF of an octa style spheroid with $fn=144 had about an 18x speedup.
- Revar
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
This is what happens when you replace an O(n^2) algorithm with an O(n) one, enabled by an O(1) hash table.
-Revar
On Aug 25, 2025, at 6:05 AM, Peter Kriens peter.kriens@aqute.biz wrote:
That sounds very good, but not sure I understand where the speed up comes from?
Peter
On 25 Aug 2025, at 14:42, Revar Desmera via Discuss discuss@lists.openscad.org wrote:
For the record, I just implemented an experimental
object()based version of thevnf_merge_points()function, an an initial test with a VNF of an octa style spheroid with$fn=144had about an 18x speedup.
- Revar
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
On 25 Aug 2025, at 15:20, Revar Desmera revarbat@gmail.com wrote:
This is what happens when you replace an O(n^2) algorithm with an O(n) one, enabled by an O(1) hash table.
Hadn't thought of that!
But did this require you to create string proxy keys for non string values?
Peter
-Revar
On Aug 25, 2025, at 6:05 AM, Peter Kriens peter.kriens@aqute.biz wrote:
That sounds very good, but not sure I understand where the speed up comes from?
Peter
On 25 Aug 2025, at 14:42, Revar Desmera via Discuss discuss@lists.openscad.org wrote:
For the record, I just implemented an experimental object() based version of the vnf_merge_points() function, an an initial test with a VNF of an octa style spheroid with $fn=144 had about an 18x speedup.
- Revar
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
Yes in Revar’s code he has to convert 3d vectors into strings to use as the
keys.
On Wed, Aug 27, 2025 at 04:14 Peter Kriens via Discuss <
discuss@lists.openscad.org> wrote:
On 25 Aug 2025, at 15:20, Revar Desmera revarbat@gmail.com wrote:
This is what happens when you replace an O(n^2) algorithm with an O(n)
one, enabled by an O(1) hash table.
Hadn't thought of that!
But did this require you to create string proxy keys for non string values?
Peter
wrote:
That sounds very good, but not sure I understand where the speed up
comes from?
Peter
On 25 Aug 2025, at 14:42, Revar Desmera via Discuss <
discuss@lists.openscad.org> wrote:
For the record, I just implemented an experimental object() based
version of the vnf_merge_points() function, an an initial test with a VNF
of an octa style spheroid with $fn=144 had about an 18x speedup.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
On 27 Aug 2025, at 14:26, Adrian Mariano via Discuss discuss@lists.openscad.org wrote:
Yes in Revar’s code he has to convert 3d vectors into strings to use as the keys.
That's a pity, so it might even be faster.
The current object treats objects as a list of strings. I.e. the comprehension is over strings and you need to look up the value by string. I wonder if we should make it a list of values instead. This gives us less API breakage if we start supporting maps with other types of keys then strings.
It wouldn't be too hard to hash other objects in C++ I notice.
Peter
On Wed, Aug 27, 2025 at 04:14 Peter Kriens via Discuss <discuss@lists.openscad.org mailto:discuss@lists.openscad.org> wrote:
On 25 Aug 2025, at 15:20, Revar Desmera <revarbat@gmail.com mailto:revarbat@gmail.com> wrote:
This is what happens when you replace an O(n^2) algorithm with an O(n) one, enabled by an O(1) hash table.
Hadn't thought of that!
But did this require you to create string proxy keys for non string values?
Peter
-Revar
On Aug 25, 2025, at 6:05 AM, Peter Kriens <peter.kriens@aqute.biz mailto:peter.kriens@aqute.biz> wrote:
That sounds very good, but not sure I understand where the speed up comes from?
Peter
On 25 Aug 2025, at 14:42, Revar Desmera via Discuss <discuss@lists.openscad.org mailto:discuss@lists.openscad.org> wrote:
For the record, I just implemented an experimental object() based version of the vnf_merge_points() function, an an initial test with a VNF of an octa style spheroid with $fn=144 had about an 18x speedup.
- Revar
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org mailto:discuss-leave@lists.openscad.org
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org mailto:discuss-leave@lists.openscad.org_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
On 8/27/2025 4:04 PM, Peter Kriens via Discuss wrote:
The current object treats objects as a list of strings. I.e. the
comprehension is over strings and you need to look up the value by
string. I wonder if we should make it a list of values instead. This
gives us less API breakage if we start supporting maps with other
types of keys then strings.
I don't know what the exact status is today, but I intended to make it
reject non-string keys, to allow for arbitrary-type keys in the future.
And indeed object() rejects non-strings as keys.
So while strings are the only thing that you can use today, a future
version could allow other types.