teepee changed the topic of #openscad to: OpenSCAD - The Programmers Solid 3D CAD Modeller | This channel is logged! | Website: http://www.openscad.org/ | FAQ: https://goo.gl/pcT7y3 | Request features / report bugs: https://goo.gl/lj0JRI | Tutorial: https://bit.ly/37P6z0B | Books: https://bit.ly/3xlLcQq | FOSDEM 2020: https://bit.ly/35xZGy6 | Logs: https://bit.ly/32MfbH5
bitbasher has quit [Ping timeout: 260 seconds]
ccox_ has quit [Ping timeout: 260 seconds]
<JordanBrown1> bitbasher, teepee: the expression forms of let, assert, and echo are precisely low-precedence unary operators.
<JordanBrown1> Though it is kind of weird that 1 + assert(true)2 is not legal. Abstractly I think it's clear what it means and how it should be parsed, but ‎with the current syntax it's illegal because the RHS of "+" is a multiplication, and multiplication doesn't include those.
<JordanBrown1> There aren't any other examples of low-precedence operators.
<JordanBrown1> Though I guess that 2 * assert(true) 1 + 2 would be ambiguous-ish.
ccox has joined #openscad
<JordanBrown1> Correction: there aren't any other examples of low-precedence +unary+ operators.
mmu_man has quit [Ping timeout: 272 seconds]
guso78k has quit [Ping timeout: 272 seconds]
J25k55 has joined #openscad
J25k has quit [Ping timeout: 272 seconds]
ToAruShiroiNeko has quit [Ping timeout: 260 seconds]
ToAruShiroiNeko has joined #openscad
_whitelogger has joined #openscad
L29Ah has quit [Ping timeout: 240 seconds]
snaked has quit [Quit: Leaving]
sculptor has joined #openscad
sculptor has quit [Changing host]
sculptor has joined #openscad
GNUmoon has quit [Ping timeout: 244 seconds]
GNUmoon has joined #openscad
guso78k has joined #openscad
sculptor has quit [Ping timeout: 272 seconds]
germ_ has quit [Read error: Connection reset by peer]
germ_ has joined #openscad
mmu_man has joined #openscad
guso78k has quit [Quit: Client closed]
splud has quit [Ping timeout: 276 seconds]
mmu_man has quit [Ping timeout: 252 seconds]
mmu_man has joined #openscad
bitbasher has joined #openscad
mmu_man has quit [Ping timeout: 240 seconds]
guso78k has joined #openscad
teepee_ has joined #openscad
teepee has quit [Ping timeout: 244 seconds]
teepee_ is now known as teepee
bitbasher has quit [Ping timeout: 276 seconds]
TheAssassin has quit [Ping timeout: 244 seconds]
TheAssassin has joined #openscad
guso78k has quit [Quit: Client closed]
bitbasher has joined #openscad
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #openscad
mmu_man has joined #openscad
castawayc has quit [Server closed connection]
castawayc has joined #openscad
J25k55 has quit [Quit: Client closed]
J25k55 has joined #openscad
L29Ah has joined #openscad
aiyion has quit [Quit: aiyion]
splud has joined #openscad
bitbasher has quit [Ping timeout: 276 seconds]
mmu_man has quit [Ping timeout: 276 seconds]
mmu_man has joined #openscad
howiemnt has quit [Ping timeout: 276 seconds]
howiemnt has joined #openscad
muesli has quit [Server closed connection]
muesli has joined #openscad
mmu_man has quit [Ping timeout: 245 seconds]
bitbasher has joined #openscad
howiemnt has quit [Remote host closed the connection]
howiemnt has joined #openscad
krushia_ has joined #openscad
Guest15 has joined #openscad
bitbasher has quit [Ping timeout: 276 seconds]
krushia has quit [Read error: Connection reset by peer]
krushia_ has quit [Client Quit]
Guest15 has quit [Client Quit]
mmu_man has joined #openscad
mmu_man has quit [Ping timeout: 245 seconds]
mmu_man has joined #openscad
mmu_man has quit [Ping timeout: 244 seconds]
mmu_man has joined #openscad
lostapathy has quit [Quit: WeeChat 4.1.1]
lostapathy has joined #openscad
bitbasher has joined #openscad
bitbasher has quit [Changing host]
bitbasher has joined #openscad
bozo16 has quit [Ping timeout: 260 seconds]
sculptor has joined #openscad
mwette has joined #openscad
J25k55 has quit [Ping timeout: 272 seconds]
<mwette> Did you try "1 + (assert(true) 2)"
<mwette> The assert() operator has lower precedence than `+' while unary - has higher precedence.
<bitbasher> yep .. teepee educated me on assert() as a low precedence operator yesterday .. i will be updating the docs .. perhaps not this evening, but soon
<teepee> 👍
<mwette> good
teepee_ has joined #openscad
teepee has quit [Ping timeout: 244 seconds]
teepee_ is now known as teepee
bitbasher has quit [Ping timeout: 276 seconds]
bitbasher has joined #openscad
bozo16 has joined #openscad
bozo16 has quit [Ping timeout: 252 seconds]
mwette has left #openscad [ERC 5.6.0.30.1 (IRC client for GNU Emacs 30.1)]
pie_ has quit []
<JordanBrown1> mwette I was trying to understand and explore the particular syntax, without the parentheses. I understand that you can use parentheses to force particular grouping.
<JordanBrown1> But the question was around the precedence behavior of the operators without parentheses.
<bitbasher> yep .. just like math (2+4)/2 != 2+4/2
<JordanBrown1> This is the only case that I can think of where you can't just throw together operators and operands in any order, and end up with a legal and well-defined result.
<bitbasher> ah . we do need an operator precedence list
<bitbasher> ah .. no, the C language op precedence list is a tangled web of deceit and should be kept in childproof containers
<bitbasher> that said .. it would be a useful starting point
<JordanBrown1> I don't think it's there in a table form, but I think it's implied in the text.
<JordanBrown1> We certainly *know* what the precedence is; it's in the parser syntax description.
<bitbasher> oh right .. do you know where that is in the code?
<JordanBrown1> src/core/parser.y
<JordanBrown1> I think it's the same as C, except that when I added binary-and and binary-or I made them be *above* comparison operators.
<JordanBrown1> (In C, I think they originally had binary-and and binary-or, and didn't have `&&` and `||`, and they used binary-and and binary-or to combine the results from comparisons.
<bitbasher> you mean the bitwise & and | yes?
<JordanBrown1> )
<JordanBrown1> yes
<JordanBrown1> In C, 1 & 1 == 2 & 2 binds as 1 & (1 = 2) & 2.
<JordanBrown1> In OpenSCAD, it binds as (1 & 1) == (2 & 2)
<JordanBrown1> excuse me, of course I mean that in C it binds as 1 & (1 == 2) & 2.
<bitbasher> i dont think that was the case .. i am pretty sure that C already had && || right from the start .. i was working with it in the 70's .. but memory is fuzzy on the fine points
<bitbasher> no worries .. i got that
<bitbasher> oh .. then, can u confirm for me that bitwise not is doing twos complement and not bit inversion?
<JordanBrown1> C did. But did B and BCPL?
<JordanBrown1> What distinction are you trying to draw?
<bitbasher> that i do not know .. i never used the B languages
<JordanBrown1> Nor I. But it's the history that makes the precedence make sense.
<bitbasher> i was documenting details for the bitwise operators and found that ...
<JordanBrown1> What distinction are you trying to draw between "twos complement" and "bit inversion"?
<bitbasher> not 000001 was not giving me 1111110
<JordanBrown1> Of course not.
<JordanBrown1> There are an infinite number of ones on the left side of ~1.
<bitbasher> the not operator is taking the twos complement of a binary value
<JordanBrown1> "two's complement" is a method for representing negative numbers.
<bitbasher> well .. actually only 52 in a 64bit floating value no?
<bitbasher> of course it is
<JordanBrown1> I believe it's actually infinite.
<JordanBrown1> Well, out to maybe 2^1024 or something like that.
<JordanBrown1> Conceptually, it's infinite.
<JordanBrown1> Just like 1 has an infinite number of zeroes to the left.
<bitbasher> sure .. but binary encoding limits
<JordanBrown1> ~1 is 111111111111111111...1111111110.
<JordanBrown1> With an infinite number of 1s.
<JordanBrown1> That bit pattern is, because it's treated as a signed number and we (and basically everybody) use two's complement, is -2.
<JordanBrown1> So I guess the formal answer is that ~ does bit inversion, and the resulting bit pattern is interpreted as a signed two's complement number.
<JordanBrown1> ... which is exactly what C does when you ~ a signed int.
<bitbasher> in C this is how bitwise operators work
<bitbasher> Then, the corresponding binary logic operators are applied bitwise; that is, each bit of the result is set or cleared according to the logic operation (NOT, AND, OR, or XOR), applied to the corresponding bits of the operands. Note: bitwise operators are commonly used to manipulate bit sets and bit masks.
<JordanBrown1> In OpenSCAD they work the same as in C when operating on a signed int.
<JordanBrown1> or a bit more generally, when operating on a signed integer.
<bitbasher> um no .. in C doing unary minus is arithmetic and ~0001 is 1110
<JordanBrown1> You think that in C ~0001 is 1110?
<JordanBrown1> It is, on a machine with 4-bit ints.
<bitbasher> yep .. i used to use that to make bit masks
<JordanBrown1> (Which nobody has.)
<JordanBrown1> In C with 32-bit ints, ~1 is 11111111111111111111111111111110.
<bitbasher> just an example byte .. the operation is the same on a byte / int etc
<JordanBrown1> C never does arithmetic on bytes.
<bitbasher> yep there u go
<bitbasher> C converts anything to everything based on the declared type
<JordanBrown1> It has very complex conversion rules.
<JordanBrown1> But the first one is "take anything that's smaller than an int, and turn it into an int".
<JordanBrown1> Ignoring for the moment unsigned variants.
<bitbasher> and C can do byte arithmetic on platforms that support it
<JordanBrown1> Nope.
<JordanBrown1> Never.
<bitbasher> ok ..
<bitbasher> any way .. the scad bitwise operators all work like the C equivalents except for ~ .. the binary NOT
<JordanBrown1> Not true.
<bitbasher> i was just trying to confirm what my testing showed me
<JordanBrown1> With respect to the "can C do byte arithmetic", try https://bpa.st/L54Q
<JordanBrown1> OpenSCAD ~ is the same as C ~, as applied to signed integers.
<bitbasher> in scad echo( ~4 ); // -5
<JordanBrown1> Sure. And in C?
<bitbasher> which is the value one would expect from twos comp
<JordanBrown1> And what does C give you for that expression?
<bitbasher> in C ~0100 would be 1011 or 0xB
<JordanBrown1> Either you aren't speaking C, or no, it's not.
<JordanBrown1> Because in C, 0100 is 64 decimal.
<JordanBrown1> Because the leading zero makes it octal.
<bitbasher> oh good grief
<JordanBrown1> But assuming that you really mean ~0x04...
<JordanBrown1> actually, assuming that you really mean ~4...
<JordanBrown1> printf("%d\n", ~4); will print -5.
<JordanBrown1> Go try it.
<JordanBrown1> (I had no real doubt, but checked it anyway.)
<bitbasher> fine then decimal 4 == 0x0100 == 0x04 .. all of which flip bits so the third bit from the right is a 0 and all the others are 1s
<JordanBrown1> Yes. *All* of the others, including the sign bit.
<JordanBrown1> With 32-bit int, the bit pattern is 0xfffffffb.
<bitbasher> not also the sign .. if that was the case ~4 would give a large negative value, not -5
<JordanBrown1> the bit pattern for ~r, that is.
<JordanBrown1> No... -1 as a 32-bit signed int is 0xffffffff.
<JordanBrown1> *That* is the two's complement part, that 0xffffffff is treated as -1.
<bitbasher> sure .. now switched to unsigned .. doing bitwise ops on signed ints seldom goes well
<JordanBrown1> But signed ints is what OpenSCAD bitwise operators as defined as.
<bitbasher> i finally got reminded to say ones complement negation
<bitbasher> as oppsed to twos comp
<JordanBrown1> And yes, that is exactly what it does.
<bitbasher> yes .. so then ~x is in fact doing twos comp inversion, which is not the bitwise negation .. and my write up is correct
<JordanBrown1> Nope.
<JordanBrown1> Two's complement of 1 is -1, not -2.
<bitbasher> what i learned way back when is the twos comp NOT x = -x-1 so NOT 1 = -1-1 = -2
howiemnt has quit [Remote host closed the connection]
<bitbasher> and scad agrees with me echo( ~1 ); // -2
howiemnt has joined #openscad
<JordanBrown1> I think you're doing all of the arithmetic right, but using the wrong words.
<bitbasher> yes .. that is the ref on my screen RN
<JordanBrown1> The result [of the bitwise NOT ]is equal to the two's complement of the value minus one. If two's complement arithmetic is used, then NOT x = -x − 1.
<bitbasher> The bitwise NOT, or bitwise complement, is a unary operation that performs logical negation on each bit, forming the ones' complement of the given binary value. Bits that are 0 become 1, and those that are 1 become 0
<JordanBrown1> Sure.
<bitbasher> and
<bitbasher> NOT 0111 (decimal 7) = 1000 (decimal 8)