Will Erlang have Bignums for math functions? - erlang

Why does Erlang not include arbitrary precision for math functions? I recently had to use math:pow(2,4333), and it throws an error. Why does Erlang not use libraries like GMP? Are there any plans to include it in the standard library? (Haskell uses it, [strike]even Java has bignums[strike]).
Thanks.
Update:
To add more perspective, I understand that it can be done using NIFs. I was solving problems from hackerrank in which the input uses larger numbers. pow/2 can be easily written in Erlang and it worked, but for larger computations, it would be slow.
Java returns double for pow so it does not work for Math.pow(2, 1024) which gives Infinity.

Erlang has bignums for integers but uses 64-bit IEEE standard floating point numbers. So while you can happily compute factorial(10000) with integers by default the math library uses floating point so math:pow(2, 4333) does not work.

Related

Lua operator overloading for numbers

How are operators overloaded for numbers? I need this for replacing the standard floating point numbers in Lua with big floats (384 bit floats from Cephes) that I've added as a library without having to change Lua itself. The reason is that sometimes normal Lua doubles get mixed up with the big floats if you don't convert the Lua doubles to big floats first.
Can it be done with just some Lua code, or does Lua have to be changed (not necessarily a problem, but still undesirable)?

Lua floating point operations

I run Lua on a CPU without dedicated floating point HW, depending on SW emulation.
From luaopt.h I can see that some macros are set to double, but it does not clearly state when floats are used and its a little hard to track it.
If my script does simple stuff like:
a=0
a=a+1
for...
Would that involve a floating point operations at any level?
If no that's fine, but what is then the benefit to change macros to long?
(I tried of course but did not work....)
All numeric operations in Lua are performed (according to the default configuration) in floating point. There is no distinction made between floating point and integer, all values are simply numbers.
The actual C type used to store a Lua number is set in luaconf.h, and it is both allowed and even practical to change that to a suitable integral type. You start by changing LUA_NUMBER from double to int, long, or perhaps ptrdiff_t. Then you will find you need to tweak the related macros that control the conversions between strings and numbers. And, of course, you will likely need to eliminate most or all of the base math library since math.sin() and its friends and neighbors are not particularly useful over integers.
The result will be a Lua interpreter where all numbers are integers. The language will still allow you to type 3.14, but it will be stored as 3. Your code will likely not be completely portable to a Lua interpreter built with the standard configuration since a huge amount of Lua code casually assumes that floating point arithmetic is permitted, and remember that your compiled byte code will definitely not be compatible since byte code will store numbers as LUA_NUMBER.
There is LNUM patch (used, for example, by OpenWrt project which relies heavily on Lua for providing Web UI on hardware without FPU) that allows dual integer/floating point representation of numbers in Lua with conversions happening behind the scenes when required. With it most integer computations will be performed without resorting to FPU. Unfortunately, it's only applicable to Lua 5.1; 5.2 is not supported.

Store and perform operations with huge numbers in iOS

How could I handle operations with a number like:
48534588306961133067968196965257961415756656521818848750723547477673457670019632882524164647651492025728980571833579341743988603191694784406703
Nothing that I've tried worked so far... unsigned long, long long, etc...
What you need is a library that provides support for operations on integers of arbitrary length. However, from what I've been able to find out, there are no such libraries written in Objective-C.
You are nevertheless in luck as Objective-C is a superset of C. That makes it possible for you to use C libraries such as those described in the answers to this somewhat dated SO question.
Also, since the Clang compiler supports C++ and combining Objective-C and C++ code, you can probably use something like big int.
Note that none of the built-in types is even close to being big enough to represent numbers with as many digits as your examples. The biggest available integer type is unsigned long long, if you don't need negative numbers, and its size is 8 bytes/64 bits, which gives you a range of 0-18446744073709551615, or 20 digits max.
You could use JKBigInteger instead, it is a Objective-C wrapper around LibTomMath C library. And really easy to use and understand.
In your case:
JKBigInteger *int = [[JKBigInteger alloc] initWithString:#"48534588306961133067968196965257961415756656521818848750723547477673457670019632882524164647651492025728980571833579341743988603191694784406703"];
You can try here : http://gmplib.org/
GMP is a free library for arbitrary precision arithmetic, operating on signed integers, rational numbers, and floating point numbers. There is no practical limit to the precision except the ones implied by the available memory in the machine GMP runs on. GMP has a rich set of functions, and the functions have a regular interface.

how do i simulate signed 32bit integer in lua

In Java, when I do following left shift operation, I get a negative result due to integer / long overflow:
0xAAAAAAAA << 7 gives me -183251938048
But, In Lua since everything is a Lua number which is 52 bit float; I am not able to trigger overflow upon left shift:
bit_lshift(0xAAAAAAAA,7) gives me 1431655680
How do I simulate 32bit signed integer in Lua??
You write some C functions that handle this and then export them to Lua.
Though generally, Lua code shouldn't be touching things this low-level.
You are looking for bit manipulating libraries in Lua. One such library is bitop from the author of LuaJIT, which directly contains it without the need for installation. You can also install it in standard Lua.
Another library is the bit32 library, which is contained in Lua 5.2.
Both libraries let you manipulate 32-bit numbers. For example with bitop:
local bit = require 'bit
print(bit.lshift(0xAAAAAAAA, 7)) --> 1431655680
I do not know how you got the negative number, since 1431655680 is what I get by doing (0xAAAAAAAA<<7)&0xFFFFFFFF in C (and also doing that in a "programming calculator").
I hope I'm not seen as trolling for saying this, but the best way to simulate Java from Lua would be to use Java from Lua.
If you need to emulate Java, chances are that your Lua is already embedded in it. Just expose Java's binary operations to the Lua program, so it can use them.

Where to handle Parsing of Floating Point Number - Scanner or Parser?

I'm in the process of designing a small domain specific language.
As scanner/parser generators I use Flex/Bisonc++.
Now, the generated DSL-compiler frontend is capable of parsing octal, decimal and hex numbers.
The only thing remaining is the support for floating point numbers (FPN) as notated in C/C++.
There's a RegExp for the floating point number syntax at
http://rosettacode.org/wiki/Literals/Floating_point#C
a) I know that parsing that can be done in the scanner or/and in the parser,
but I don't know what's best - in terms of performance and efficiency.
b) One additional constraint is, that I want to avoid touching each character of the input more than once, i.e. I want to avoid using STL or other string-to-float conversion functions
by implementing an on-the-fly conversion during the parsing process.
Is that possible?
It is perfectly feasible, and normally sensible, to have the scanner (flex code) recognize and convert the floating point numbers, just as it should be recognizing and converting the integers. If you've written the integer recognition code in the grammar (bison code) rather than the scanner, then maybe you write the floating-point recognition there too, but it is not the way it is normally done. You will probably need to use a more sophisticated (read 'complex') data type for the token types; read up on %union.

Resources