General discuss

[tst2005]

Hello,

I would like to said BIG THANKS for your work. For years, I'm searching a way to go outside of native limitations for numbers and bitwise operations with interpreted code (without lib/compilation stuff)

I tried by myself, I tried with very old thirdparty code. Your lua-nums is the first one with all features, both big int and bitwise operation.

Your code is very well documented. I think you like your project/code and hardly follow your own rules. I see some coding style that is unusual for me.

• Do you comes from C world ? I read lot of local variable, one per line at the beginning of each functions. It is unusual for Lua code. Usualy I use local near the first use.

You'll have guessed it, I have a big interest on lua-nums.

Are you open to alternative implementation to compare some function one by one. In some case the generated bytecode is very different and performance can be also different...

I would like to know if you are interested to discuss of possible changes more complexe than minor change that I made for now.

I think also about spliting the tostring_int to 2 parts :

• the convertion code needed to change base (returning a BN or a table of digits)
• the need to convert a table of digits to a string with the sign The previous bug of len_digits can fixed by getting the ._digits table size directly, without string convertion (without dealing with the sign).

I think also about the use of expand + reduce, I think there is other way to do.

Best Regards,

[user-none]

You’re welcome. I had hoped when I wrote the library it would be useful to other people.

Do you comes from C world ?

Yes. You are correct that a lot of people write Lua with variable declaration at first use. Using C style at the top is partly habit, and partly because it makes variables used in the function clearer. Which leads into 3.

3, 4

Are you open to alternative implementation to compare some function one by one. In some case the generated bytecode is very different and performance can be also different... I would like to know if you are interested to discuss of possible changes more complexe than minor change that I made for now.

No and yes. Not in BN specifically but I’m open to writing a second BN module that’s optimized. I specifically kept the optimizations to a minimum and only optimized when absolutely necessary. For example, the division function. That is slightly optimized over the much similar division by subtraction method.

I wrote it with little optimization so it would be somewhat of a reference implementation. The design is efficient enough to be useful but still easy to understand what’s happening. This allows auditing to be easier as well as learning. Also, coming back to this in the future to fix bugs and what not it’s easier for me to get back into.

So, optimizing BN is a no but a new optimized version would be nice to have. uintb could easily be changed to use the optimized version since I’d keep the API for BN and BN_fast the same. They could be used interchangeably.

I think also about spliting the tostring_int to 2 parts :

• the convertion code needed to change base (returning a BN or a table of digits)

I’m not sure I follow this. You’re saying tostring_int would return a BN with a different base where each digit in _digits would represent one number in the given base. Essentially tostring_int(132) in base 10 would have: _digits = { 1, 3, 2 }? This isn’t much what it’s doing now but it returns them concatenated into a string.

• the need to convert a table of digits to a string with the sign The previous bug of len_digits can fixed by getting the ._digits table size directly, without string convertion (without dealing with the sign).

I see what you mean where if the table from tostring_int was returned directly you could take the size of the table instead of the length of the returned string. I’m not sure if this is really a worthwhile optimization….

[tst2005]

Thanks for your answer.

I will go step by step. I'm continuing to make some "small" PR. Let me know if it is ok for you or not. My code is probably closer than usual Lua style than C.

My final goal is to be able to port lua-nums for lua 5.1/5.2, and make bitwise stuff on big register (performance improvement probably needed).

Regards,

[user-none]

My final goal is to be able to port lua-nums for lua 5.1/5.2, and make bitwise stuff on big register (performance improvement probably needed).> My final goal is to be able to port lua-nums for lua 5.1/5.2, and make bitwise stuff on big register (performance improvement probably needed).

Good Luck!

[Hexastar]

I have some questions

1. Does this library supports Roblox?
2. Can you make instruction file too?

[user-none]

1. Does this library supports Roblox?

No idea if it works with Roblox. It was written to work with Lua 5.3. If Roblox supports Lua 5.3 then it should.

2. Can you make instruction file too?

Can you be more specific?