<bitbasher>
does not matter how many bits you use .. 4 to 64 .. if you flip the bits you have bit wise negation
<JordanBrown1>
Yes.
<bitbasher>
we seem to be agreeing very Very hard here Jordan
<JordanBrown1>
And if you flip the sign bit... which happens when you do a *signed* bitwise NOT, you end up with a negative number.
<JordanBrown1>
(Or, contrariwise, if you started with a negative number you end up with a positive number.
<JordanBrown1>
)
<bitbasher>
and that is why the scad bitwise NOT is not correct
<JordanBrown1>
tRY IT IN c.
<bitbasher>
at least compared to C and other langs
<JordanBrown1>
Try it in C.
<JordanBrown1>
Or Python:
<JordanBrown1>
$ python
<JordanBrown1>
Python 3.12.10 (main, Apr 18 2025, 06:12:01) [GCC 14.2.0 64 bit (AMD64)] on win32
<JordanBrown1>
>>> print(~4)
<JordanBrown1>
Type "help", "copyright", "credits" or "license" for more information.
<JordanBrown1>
-5
<bitbasher>
i am not set up for C on this puter
<JordanBrown1>
>>> ^Z
<bitbasher>
yep .. also not correct bitwise .. still two comp
<bitbasher>
anyway .. all i was concerned with was the accuracy of my description of the bitwise operators and i am now content
<JordanBrown1>
Or in JavaScript
<JordanBrown1>
$ python
<JordanBrown1>
Python 3.12.10 (main, Apr 18 2025, 06:12:01) [GCC 14.2.0 64 bit (AMD64)] on win32
<JordanBrown1>
Type "help", "copyright", "credits" or "license" for more information.
<JordanBrown1>
-5
<JordanBrown1>
>>> print(~4)
<JordanBrown1>
>>> ^Z
<JordanBrown1>
Oops...
<JordanBrown1>
Welcome to Node.js v14.18.0.
<JordanBrown1>
Type ".help" for more information.
<JordanBrown1>
> console.log(~4)
<JordanBrown1>
-5
<JordanBrown1>
undefined
<bitbasher>
still not bitwise
<JordanBrown1>
You keep saying that, and you keep being wrong :-)
<bitbasher>
the scad bitwise & and | work correctly so masking and so on works
<JordanBrown1>
printf("%d\n", ~4)
<JordanBrown1>
will print -5.
<bitbasher>
LOL
<JordanBrown1>
You are just used to thinking in unsigned.
<JordanBrown1>
OpenSCAD numbers are always signed. There is no unsigned.
<bitbasher>
yes indeed .. for the bitwise ops that is the One True Platform
<JordanBrown1>
If you ignore signed :-)
<JordanBrown1>
But OpenSCAD bitwise operators behave exactly the same as C bitwise operators *on signed values*.
<bitbasher>
the ~ could be "fixed" to undo the flipping of the sign and give correct UNSIGNED bitwise result .. but i dont insist on it .. such a rare thing to need
<JordanBrown1>
... because that is how they are implemented :-)
<bitbasher>
yep .. i get that .. never do bitwise on signed ints .. that was always my rule
<JordanBrown1>
For a while I had them be based on unsigned, and I think it was specifically ~0 that was the reason for making them signed.
<bitbasher>
but then, i rarely did math in C .. my early days were in machine control and UI stuff
<JordanBrown1>
For one thing, it nicely hides how wide the arithmetic is.
<JordanBrown1>
In signed arithmetic, ~0 is -1 no matter how wide your arithmetic is.
<bitbasher>
and isn't that a pain trying to flip bits in a port register !!!
<JordanBrown1>
And ~1 is -2 as long as you have at least two bits.
<JordanBrown1>
If you have only one bit, you only get -1 and 0.
<bitbasher>
i think i have captured all the notes you made in the forum and github pages
<JordanBrown1>
In the initial section "Built-in Object Creators"... do the sections on numbers, strings, and vectors similarly have a list of the built-in mechanisms that create them?
<bitbasher>
there is still a bit of work to be done, more examples and images
<JordanBrown1>
You list textmetrics() and fontmetrics() as just the function, but you say 'data = import()".
<bitbasher>
and i would ask you permission to publish that nice example animation as an example
<bitbasher>
yeah .. that is one of the parts that needs correction and fleshing out
<JordanBrown1>
I'm happy to have it used, but it's way too big to be an example for a reference manual.
<JordanBrown1>
One place it will probably end up published is in the advent calendar.
<bitbasher>
it will be added to the examples page .. not lang ref
<JordanBrown1>
And of course object() is an object creator.
<JordanBrown1>
The "Objects are currently experimental" sentence is sort of correct. All of the current object-creating functions are experimental and must be enabled.
<bitbasher>
i want to collect all the example scripts in the lang ref and make them visible in the app .. the file menu > Examples and the splash panel
<JordanBrown1>
"are used interchangeably" is a yellow flag. Pick one nomenclature or the other, and stick with it.
<JordanBrown1>
/ ECHO: Fred = { name = "Fred"; spouse = "wilma"; friend = ["barney"]; }
<JordanBrown1>
s/friend/friends/
<JordanBrown1>
When the value is the result of an expression or function call but is undef the member is still added:
<JordanBrown1>
That's just normal OpenSCAD semantics.
<JordanBrown1>
undef is a value, and can be used in any context where a value can be used.
<bitbasher>
i would normally .. but it is like array = vector = list .. the terminology comes from diff backgrounds and there is a good bit of tradition to follow in nomenclature .. well, IMHO
<JordanBrown1>
But in any new material you should be consistent.
<JordanBrown1>
Note: a later setting for a particular member will replace any earlier definition. This attribute of the language can give unexpected results with member definitions.
<JordanBrown1>
This is not relevant to objects, and has no special interaction with objects.
<JordanBrown1>
Oh, wait, I misread.
<JordanBrown1>
The first half of that sentence is correct.
<JordanBrown1>
The second half, not so much. It's a deliberate feature.
<JordanBrown1>
Or, rather, the first sentence is correct, and the second sentence not so much.
<bitbasher>
you will see some of the Unexpected Effects in later examples
<JordanBrown1>
It is very deliberate that o=object(a=1,b=2); o2 = object(o, a=3); yields { a=3, b=2 }.
<JordanBrown1>
Where the <name> is any expression resulting in a string and the value is any valid expression, specifically including object.
<bitbasher>
i do not say it is a bug .. it is a feature of the language .. but combining objects gives some .. odd results
<bitbasher>
and i may have found some bugs as well .. not sure yet
<JordanBrown1>
I expect that it works exactly as designed. I'll keep looking.
<JordanBrown1>
Where the <name> is any expression resulting in a string and the value is any valid expression, specifically including object.
<JordanBrown1>
that last phrase is unnecessary and I wouldn't include it.
<JordanBrown1>
"any expression" includes any expression, period. If you start saying "including FOO", then people may start to think that anyplace that doesn't say "including FOO" doesn't include FOO.
<bitbasher>
i will make the point about assigning undef clearer .. when a member's value should be calculated by a function but it fails and returns undef .. that is the situation i was trying to cover .. the object is created with no warnings so it is programmer beware
<JordanBrown1>
... and there's nothing special about objects there.
<JordanBrown1>
Indeed, there are a few cases where expressions will yield undef, and that undef may cause problems downstream.
<JordanBrown1>
But it is more correct to say that a list argument is for performing bulk editing
<JordanBrown1>
No. Or, rather, all of the variations perform editing.
<JordanBrown1>
Vector-style is the only way to do a deletion.
<JordanBrown1>
But you can use any of the three styles to do an addition/replacement.
<bitbasher>
huummm .. i take ur point .. but the arg list of object() is very diff than normal functions in that you can have objects as argments .. err .. but vector data structures are just as complex .. yeah . need to change that
<JordanBrown1>
What vector-style is *really* good for is in conjunction with list comprehensions, to build up an object definition.
<bitbasher>
that is why i call out the vector form as "being for" editing
<bitbasher>
and .. $this is not yet implemented in a snapshit is it?
<JordanBrown1>
takes an object, and produces a new object with all of the names having an "x" prepended.
<bitbasher>
oh right .. but then they are not related anymore
<JordanBrown1>
They aren't no matter what, but indeed they are not related.
<JordanBrown1>
o2 = object(o1) makes a copy of o1; it is not related.
<JordanBrown1>
Though because OpenSCAD values are immutable you can't actually tell.
<JordanBrown1>
but we want the spouse to be an object, not just the name as as string, so later we remove it:
califax has quit [Remote host closed the connection]
<JordanBrown1>
I don't understand this sentence, and in particular I don't understand the part about "be an object".
<bitbasher>
you can tell .. playing with Fred, Wilma, Barney and Betty showed me that putting object references as members is never going to work
<JordanBrown1>
It always works.
<JordanBrown1>
Why do you think it doesn't?
<JordanBrown1>
Fred = object( name="Fred", spouse="Wilma", friend=["Barney"] );
<bitbasher>
ah .. so Fred and Wilma should both have spouse=(object) for each other
<JordanBrown1>
s/friend/friends.
<bitbasher>
but it can't be done
<JordanBrown1>
OpenSCAD has no references.
califax has joined #openscad
<bitbasher>
if does not work because when u define Fred, then Wilma .. Wilma can have spouse=Fred the object . .. but Fred is forever spouse="wilma"
<JordanBrown1>
So you can easily make it so that Fred.spouse.name is "Wilma", but you can't infinitely follow references to Fred.spouse.spouse.spouse...
<bitbasher>
one can replace spouse="name" with an object so
<JordanBrown1>
use
<JordanBrown1>
yes
<bitbasher>
Wilma.spouse.spouse == Fred can be true
<bitbasher>
err ... wrong
<bitbasher>
Wilma.spouse == Fred can happen
<JordanBrown1>
Yes. But Wilma.spouse.spouse == Wilma can never happen.
<bitbasher>
but WIlma.spose.spouse is still going to be "WIlma" the string
<JordanBrown1>
That depends on how you construct them. But there are no references.
<JordanBrown1>
There are only copies.
<JordanBrown1>
You *cannot* have a circular structure, because there are no references.
<bitbasher>
exactly .. so even if you make Fred2=obejct( Fred, spouse=WIlma)
<bitbasher>
you cannot get to the object spouse in WIlma to update it with the Fred2 object
<JordanBrown1>
Fred2 is an object that looks a lot like Fred, and that includes a *copy* of Wilma.
<bitbasher>
i tried real hard to get that to go :(
<bitbasher>
yep .. and wilma is still thinking that Fred only know about the string "wilma"
<JordanBrown1>
I think your Fred/Wilma example gets too complicated.
<bitbasher>
it is .. i am going to chop down .. a lot
<bitbasher>
the full example code is about 50 lines
<JordanBrown1>
No, Wilma is an object that has a member "spouse" which in turn is an object that has a member "name" with value "Fred" and a member "spouse" with value "wilma".
<JordanBrown1>
Fred, per se, is not in there. It is a copy of Fred.
snaked has joined #openscad
<bitbasher>
so .. no references means shorter examples
<JordanBrown1>
Giving an object as an argument preforms an implicit assignment of itself to the new object, it does not add the original's members individually.
<JordanBrown1>
absolutely it does. If it doesn't, it's a bug.
<JordanBrown1>
And it does.
<JordanBrown1>
o1 = object(a=1, b=2);
<JordanBrown1>
o2 = object(c=3, d=4);
<JordanBrown1>
echo(object(o1,o2));
<JordanBrown1>
ECHO: { a = 1; b = 2; c = 3; d = 4; }
<bitbasher>
let me find my example
<JordanBrown1>
In your object(Fred, Wilma) example what you are not understanding is that the members of Wilma individually replace the members of Fred.
<JordanBrown1>
Since Wilma has the same members, the results is a copy of Wilma.
<JordanBrown1>
Fred = object(name="Fred", spouse="Wilma", dog="Dino");
<JordanBrown1>
ECHO: { name = "Wilma"; spouse = "Fred"; dog = "Dino"; }
<JordanBrown1>
The explanation looks correct.
<JordanBrown1>
Sorry, the explanation of the "later in list overrides" example looks correct.
<JordanBrown1>
There is a good argument that we should *not* have made objects maintain order, because they really aren't intended as an ordered mechanism.
<JordanBrown1>
But the output looks so much better if they are ordered.
<JordanBrown1>
The rule that object() uses is that replacements replace the member in its original location.
<JordanBrown1>
But it is better to say that although objects are displayed and enumerated in the order that the members were originally added, order is not guaranteed.
<bitbasher>
little hard to parse out but that looks like a correct clone of Betty
<JordanBrown1>
I believe it is, just being reported incorrectly.
<bitbasher>
anyway .. i need to get to sleep
<bitbasher>
thx again for your help .. umm did u see the forum posts .. i had questions there too .. render() is back in the Dark Mystery group for me after TPaul got upset with me