

Hi All,
While implementing all meta methods in some glue code between Lua and
C++ I'd became curious why __bshr and __bshl both exist. For the
compare operators a smart trick is used so you don't need to implement
them all.
To make sure my glue code behaves the same as Lua I simply tried all
operators, e.g.
Lua 5.3.3 Copyright (C) 19942016 Lua.org, PUCRio
> print(2 << 1)
1
> print(2 >> 1)
1
This is legal in Lua, so why not only a __bshr meta method and call
this with a negative shift count for the << operator?
Just curiosity, no complain ;) I really like Lua and its easiness to
embed. (I also experimented with python and v8)
Best regards,
Reinder


On Sat, Apr 7, 2018 at 1:58 PM, Reinder Feenstra
< [hidden email]> wrote:
> Hi All,
>
> While implementing all meta methods in some glue code between Lua and
> C++ I'd became curious why __bshr and __bshl both exist. For the
> compare operators a smart trick is used so you don't need to implement
> them all.
>
> To make sure my glue code behaves the same as Lua I simply tried all
> operators, e.g.
>
> Lua 5.3.3 Copyright (C) 19942016 Lua.org, PUCRio
>> print(2 << 1)
> 1
>> print(2 >> 1)
> 1
>
> This is legal in Lua, so why not only a __bshr meta method and call
> this with a negative shift count for the << operator?
>
> Just curiosity, no complain ;) I really like Lua and its easiness to
> embed. (I also experimented with python and v8)
>
> Best regards,
> Reinder
>
Not everything that uses << or >> is performing something analogous to
a symmetric bit shift.
C++ developers, for example, use it to mean insertion and extraction.
I don't know off the top of my head if there are any popular Lua
libraries that use the operators for asymmetric behaviors, but it
wouldn't surprise me if LPeg were among them. (I haven't actually used
it!)
/s/ Adam


> On Apr 7, 2018, at 2:58 PM, Reinder Feenstra < [hidden email]> wrote:
>
> Hi All,
>
> While implementing all meta methods in some glue code between Lua and
> C++ I'd became curious why __bshr and __bshl both exist. For the
> compare operators a smart trick is used so you don't need to implement
> them all.
>
> To make sure my glue code behaves the same as Lua I simply tried all
> operators, e.g.
>
> Lua 5.3.3 Copyright (C) 19942016 Lua.org, PUCRio
>> print(2 << 1)
> 1
>> print(2 >> 1)
> 1
>
> This is legal in Lua, so why not only a __bshr meta method and call
> this with a negative shift count for the << operator?
Same reason we have __sub operator (for convenience):
A  B = A + (B)
A + (B) is legal in Lua, so why not ...


On 20180407 05:34 PM, Albert Chan wrote:
>> On Apr 7, 2018, at 2:58 PM, Reinder Feenstra < [hidden email]> wrote:
>>
>> Hi All,
>>
>> While implementing all meta methods in some glue code between Lua and
>> C++ I'd became curious why __bshr and __bshl both exist. For the
>> compare operators a smart trick is used so you don't need to implement
>> them all.
>>
>> To make sure my glue code behaves the same as Lua I simply tried all
>> operators, e.g.
>>
>> Lua 5.3.3 Copyright (C) 19942016 Lua.org, PUCRio
>>> print(2 << 1)
>> 1
>>> print(2 >> 1)
>> 1
>>
>> This is legal in Lua, so why not only a __bshr meta method and call
>> this with a negative shift count for the << operator?
> Same reason we have __sub operator (for convenience):
>
> A  B = A + (B)
>
> A + (B) is legal in Lua, so why not ...
>
>
>
>
Why have __add or __unm at all anyway
A + B == A  (0  B)
A == (0  A)
Also why have __mul
A * B == A / (1 / B)
And so on.

Disclaimer: these emails may be made public at any given time, with or without reason. If you don't agree with this, DO NOT REPLY.


> On Apr 7, 2018, at 5:18 PM, Soni They/Them L. < [hidden email]> wrote:
>
> Why have __add or __unm at all anyway
>
> A + B == A  (0  B)
> A == (0  A)
Killing two birds with one stone ?
Nice shot
> Also why have __mul
>
> A * B == A / (1 / B)
>
No, you cannot remove __mul like that,
Example:
1 * 49 = 49.0
1 / (1/49) = 1 / 0.02040816326530612 = 49.00000000000001


On 20180407 07:17 PM, Albert Chan wrote:
>> On Apr 7, 2018, at 5:18 PM, Soni They/Them L. < [hidden email]> wrote:
>>
>> Why have __add or __unm at all anyway
>>
>> A + B == A  (0  B)
>> A == (0  A)
> Killing two birds with one stone ?
> Nice shot
>
>> Also why have __mul
>>
>> A * B == A / (1 / B)
>>
> No, you cannot remove __mul like that,
> Example:
>
> 1 * 49 = 49.0
> 1 / (1/49) = 1 / 0.02040816326530612 = 49.00000000000001
>
>
Ah, right, we only have floats. The math is correct tho.

Disclaimer: these emails may be made public at any given time, with or without reason. If you don't agree with this, DO NOT REPLY.


> Not everything that uses << or >> is performing something analogous to
> a symmetric bit shift.
>
> C++ developers, for example, use it to mean insertion and extraction.
>
> I don't know off the top of my head if there are any popular Lua
> libraries that use the operators for asymmetric behaviors, but it
> wouldn't surprise me if LPeg were among them. (I haven't actually used
> it!)
When implementing Set functionality you can reuse operators nicely
[1,2,3,4]  [5,6,2,3] = [1,2,3,4,5,6] (union)
[1,2,3,4] & [5,6,2,3] = [2,3] (intersection)
If you take the metamethods out of math context it's really nice that all
of them are available.
tobbik


On 04/08/2018 09:41 AM, Egor Skriptunoff wrote:
> Why we have
> __band, __bxor, __bor, __bnot
> when we could simply have the only boolean operation
> __bnand (Sheffer stroke) ?
>
> :)
>
.. or using __bnor (Peirce arrow)?
 Martin


20180409 14:58 GMT+02:00 dyngeccetor8 < [hidden email]>:
> On 04/08/2018 09:41 AM, Egor Skriptunoff wrote:
>> Why we have
>> __band, __bxor, __bor, __bnot
>> when we could simply have the only boolean operation
>> __bnand (Sheffer stroke) ?
>>
>> :)
>>
> .. or using __bnor (Peirce arrow)?
In fact, why have Lua at all since a Turing machine can do everything?


On Mon, Apr 9, 2018 at 3:08 PM, Dirk Laurie < [hidden email]> wrote:
...
> In fact, why have Lua at all since a Turing machine can do everything?
Because you cannot implement a Turing Machine in a normal computer?
Francisco Olarte.


On Mon, Apr 9, 2018 at 12:19 PM, Francisco Olarte
< [hidden email]> wrote:
> On Mon, Apr 9, 2018 at 3:08 PM, Dirk Laurie < [hidden email]> wrote:
> ...
>> In fact, why have Lua at all since a Turing machine can do everything?
>
> Because you cannot implement a Turing Machine in a normal computer?
>
> Francisco Olarte.
You can implement a sufficiently large finite approximation of a Turing Machine.
On the other hand, a Turing Machine (even a finite one) is a
ridiculously inefficient beast, and you can't implement a Turing
Machine optimizer in a Turing Machine. (You CAN implement one that
optimizes for the capabilities of a given hardware implementation, but
you by definition cannot make a Turing Machine whose purpose is to
make another Turing Machine that is capable of violating the rules of
a Turing Machine.) So where the rubber meets the road, you're gonna
need a programming language that isn't a Turing Machine. :P
/s/ Adam


On Mon, Apr 9, 2018 at 7:32 PM, Coda Highland < [hidden email]> wrote:
> On Mon, Apr 9, 2018 at 12:19 PM, Francisco Olarte
> < [hidden email]> wrote:
>> On Mon, Apr 9, 2018 at 3:08 PM, Dirk Laurie < [hidden email]> wrote:
>> ...
>>> In fact, why have Lua at all since a Turing machine can do everything?
>> Because you cannot implement a Turing Machine in a normal computer?
...
> You can implement a sufficiently large finite approximation of a Turing Machine.
You cannot do everything with that. I knew that, and I suspect the OP
knows both my previous line and yours. I did not suspect you would
fall for that.
> On the other hand, a Turing Machine (even a finite one) is a
> ridiculously inefficient beast, and you can't implement a Turing
> Machine optimizer in a Turing Machine. (You CAN implement one that
> optimizes for the capabilities of a given hardware implementation, but
> you by definition cannot make a Turing Machine whose purpose is to
> make another Turing Machine that is capable of violating the rules of
> a Turing Machine.) So where the rubber meets the road, you're gonna
> need a programming language that isn't a Turing Machine. :P
Which other hand? You cannot implement a turing machine in a normal
computer, you cannot do everything ( meaning compute everything ) with
a finite turing machine ( or with any finite machine, someone is going
to find a problem which overflows, in fact I'm nearly sure that has
already been done ).
What I was trying to point is that we should not slide into that level
of abstraction. Clearly not successful.
Also, you say "you cannot implement an optimizer" followed by "(You
CAN implement one", contradiction? Did you forgot some qualifier? ( an
optimizer does not need to violate any rule )....
See, sliding away, that's why I disliked the TM direction, stopping now.
Francisco Olarte.


> On Apr 9, 2018, at 9:08 AM, Dirk Laurie < [hidden email]> wrote:
>
> 20180409 14:58 GMT+02:00 dyngeccetor8 < [hidden email]>:
>>> On 04/08/2018 09:41 AM, Egor Skriptunoff wrote:
>>> Why we have
>>> __band, __bxor, __bor, __bnot
>>> when we could simply have the only boolean operation
>>> __bnand (Sheffer stroke) ?
>>>
>>> :)
>> .. or using __bnor (Peirce arrow)?
>
> In fact, why have Lua at all since a Turing machine can do everything?
>
It is amazing that a comment to remove left shift operator turn
into removing Lua altogether !
I recently got a warning email by posting in another mailing list
on an issue slightly offtopic. Lua mailing list is much better.
Good ideas will come if you let it run wild.


On Mon, Apr 9, 2018 at 1:00 PM, Francisco Olarte < [hidden email]> wrote:
> On Mon, Apr 9, 2018 at 7:32 PM, Coda Highland < [hidden email]> wrote:
>> On Mon, Apr 9, 2018 at 12:19 PM, Francisco Olarte
>> < [hidden email]> wrote:
>>> On Mon, Apr 9, 2018 at 3:08 PM, Dirk Laurie < [hidden email]> wrote:
>>> ...
>>>> In fact, why have Lua at all since a Turing machine can do everything?
>>> Because you cannot implement a Turing Machine in a normal computer?
> ...
>> You can implement a sufficiently large finite approximation of a Turing Machine.
>
> You cannot do everything with that. I knew that, and I suspect the OP
> knows both my previous line and yours. I did not suspect you would
> fall for that.
Of course you can't do everything, but you can do everything you can
do with a finite computer with a finite Turing Machine. If an
algorithm can't be run on a finite Turing Machine, it can't be run on
a finite computer. But the Turing Machine would be ridiculously huge
and unusably slow (regardless of finite or infinite), which is why the
next part comes into the picture.
>> On the other hand, a Turing Machine (even a finite one) is a
>> ridiculously inefficient beast, and you can't implement a Turing
>> Machine optimizer in a Turing Machine. (You CAN implement one that
>> optimizes for the capabilities of a given hardware implementation, but
>> you by definition cannot make a Turing Machine whose purpose is to
>> make another Turing Machine that is capable of violating the rules of
>> a Turing Machine.) So where the rubber meets the road, you're gonna
>> need a programming language that isn't a Turing Machine. :P
>
> Which other hand? You cannot implement a turing machine in a normal
> computer, you cannot do everything ( meaning compute everything ) with
> a finite turing machine ( or with any finite machine, someone is going
> to find a problem which overflows, in fact I'm nearly sure that has
> already been done ).
>
> What I was trying to point is that we should not slide into that level
> of abstraction. Clearly not successful.
The other hand in this case is saying "just because you could build a
finite Turing Machine doesn't mean it's a good idea"  in other
words, you WEREN'T unsuccessful; we agree.
> Also, you say "you cannot implement an optimizer" followed by "(You
> CAN implement one", contradiction? Did you forgot some qualifier? ( an
> optimizer does not need to violate any rule )....
I didn't forget the qualifier; it's there. The qualifier is "for the
capabilities of a given hardware implementation." Meaning, you can
build an optimizer that takes a Turing Machine and creates a
representation that can run efficiently given a specified physical
implementation.
What you can't do is create an optimizer that will take a Turing
Machine and translate it into another Turing Machine that can run the
algorithm in fewer steps than an optimal equivalent Turing Machine can
run it in. That would be a contradiction. (Nothing prohibits you from
creating a Turing Machine optimizer that can identify suboptimal
machines and create a better, equivalent machine. However, that output
is still subject to the constraints of the Turing Machine formalism.)
/s/ Adam


Coda:
On Mon, Apr 9, 2018 at 10:04 PM, Coda Highland < [hidden email]> wrote:
> On Mon, Apr 9, 2018 at 1:00 PM, Francisco Olarte < [hidden email]> wrote:
....
>> You cannot do everything with that. I knew that, and I suspect the OP
>> knows both my previous line and yours. I did not suspect you would
>> fall for that.
>
> Of course you can't do everything, but you can do everything you can
> do with a finite computer with a finite Turing Machine. If an
> algorithm can't be run on a finite Turing Machine, it can't be run on
> a finite computer. But the Turing Machine would be ridiculously huge
> and unusably slow (regardless of finite or infinite), which is why the
> next part comes into the picture.
I know all of this. I think it should have been obvious from what I've
been writing. What I was trying to point is that if we start talking
about math things, like turing machines and the like, we should be
very precise in what we write, as minor omissions totally change the
subject in this kind of stuff.
....
>> Also, you say "you cannot implement an optimizer" followed by "(You
>> CAN implement one", contradiction? Did you forgot some qualifier? ( an
>> optimizer does not need to violate any rule )....
> I didn't forget the qualifier; it's there. The qualifier is "for the
> capabilities of a given hardware implementation." Meaning, you can
> build an optimizer that takes a Turing Machine and creates a
> representation that can run efficiently given a specified physical
> implementation.
Sory, english is not my first language and I must have written
something badly. I meant if you forgot to put a qualifier to the first
ocurrence of the optimizer word in the paragraph.
> What you can't do is create an optimizer that will take a Turing
> Machine and translate it into another Turing Machine that can run the
> algorithm in fewer steps than an optimal equivalent Turing Machine can
> run it in.
This sentence is some kind of logic trap ? A tatutology or something
like this, sorry but my logic vocabulary is decades rusty, and was not
learnt in English.
If you have an optimal you cannot have anything better, you can at
best equal it with another optimal, for any problem with any means. If
you manage to best it then you didn't had one to start with.
> That would be a contradiction. (Nothing prohibits you from
> creating a Turing Machine optimizer that can identify suboptimal
> machines and create a better, equivalent machine. However, that output
> is still subject to the constraints of the Turing Machine formalism.)
We all know this, but this proves what?
BTW, "the optimal equivalent..." was, IIRC, first mentioned in this message.
And what is this "Turing machine formalism", I've never heard of it.
Also, to discuss around a TM optimizer you have first to define an
scale of "goodness". What are you optimizing for, tape consumption for
a given problem, number of states in the machine, run time, a function
of these, other thing?
Francisco Olarte.


20180410 9:43 GMT+02:00 Francisco Olarte < [hidden email]>:
>> Of course you can't do everything, but you can do everything you can
>> do with a finite computer with a finite Turing Machine. If an
>> algorithm can't be run on a finite Turing Machine, it can't be run on
>> a finite computer. But the Turing Machine would be ridiculously huge
>> and unusably slow (regardless of finite or infinite), which is why the
>> next part comes into the picture.
>
> I know all of this. I think it should have been obvious from what I've
> been writing. What I was trying to point is that if we start talking
> about math things, like turing machines and the like, we should be
> very precise in what we write, as minor omissions totally change the
> subject in this kind of stuff.
We know your views on precise terminology :)
Let me recap the thread.
1. OP asks why __bshr and __bshl both exist.
2. Good answer that metamethods << and >> need not mean shift anymore.
3. Offtopic digressions to the effect that you can do all of __bor,
__band, __bxor and __bnot with just __bnand or with just __bnor.
4. Since the thread had already strayed off into logicians'
minimalism, I threw in the Turing machine red herring.
5. The big fish are fighting about it :)
Sorry, it was naughty of me.
Dirk


It could help a bit if you could use the word "recap" on the subject line.
For instance I missed that one (later for this both).
For the others, I know what Dirk is trying to do here. I do it in another
environment, adjusted for that environment.
To all of us. Mailing lists is a very very very serious matter to get it
slightly. If used wisely, it can result to rapid development.
Here, Dirk is lucky. This list is full by this conscience.
Dirk, curently I'm working in a tag system by using specific keywords on
the subject lines, here are some so far:
Concl[usion], recap, ignore, closed, clar[ification], commit, destroy,
orry.
Now to all of us:
please go back to the matter that really matters really, which is about
"Turing Machines". Special thanks to both of you by all of us!
@Adam, you are using (lyrically i would dare to say) your obvious advantage
over the English language. I could bet you are/was a teacher sometime in time!
But do not wait from us to bite by your red herrings :). And for the
record, its not that much i can understand yet like the others here do, but
even me was able to understand your despairous unsuccesfull try to cheat :).
(how in hell you've managed to squeeze three times the phrase "Turing Machines"
in one sentence?)
Now Dirk, i do not know about you, but I do not like to loose my time.
And to the others, you should also probably do the same ( if, if you ask my
opinion ).
Here are some thought about the .mailing lists.
Evolution never stops. If stops one time which this time is far far away to
be even visible, then either will be in our paradise, or else (better) to
explode all these fbombs at once, but by letting us to know the specific
date so that we could make enough love and dance before tied by our hands
to jump to the eternity :) ocean together ( but that's my opinion ).
So, i start now this discussion with you here right now (be aware that
i'm mostly work outside planting and do farming mostly, ( It's wonderfull
up here. i wish you was here to share the beauty ) so give me some time
to answer.
Dirk: if you want my opinion pall, start right now.
To the others:
You see that subject line:
Subject: @Dirk (and about mailing lists)
@Dirk
I hope you got it.
see ya
ag
IMPORTAND and for my fragile feelings but and to our duty to the justice also.
My own son Dimitris ( aka dim ) helped me a lot in this writting and he
deserves the mention.
love you

