hi Russel --
Resurrecting an old thread (and one that you suggested may not actually be
all that important to you, but still...), I've just gotten my first bigint
range test compiling and running, as enabled by some refactoring that I
did to the range module this past month. Hope to get this onto master in
some form over the next few weeks:
---
use BigInteger;
var lo: bigint = 1;
var hi: bigint = 10;
for i in 1..10 do
lo *= 1000;
hi += lo;
const r = lo..hi;
for i in r do
writeln(i);
----
1000000000000000000000000000000
1000000000000000000000000000001
1000000000000000000000000000002
1000000000000000000000000000003
1000000000000000000000000000004
1000000000000000000000000000005
1000000000000000000000000000006
1000000000000000000000000000007
1000000000000000000000000000008
1000000000000000000000000000009
-Brad
On Wed, 7 Sep 2016, Russel Winder wrote:
On Tue, 2016-09-06 at 15:57 +0000, Michael Ferguson wrote:
Hi Russel -
However, GMP integers are not integers according to the Chapel
compiler.
That's right; and they wouldn't be in C++ either... Nonetheless
I'd like to mention two things:
Nor in Fortran, Java, Kotlin, etc. However nice languages, like Kotlin,
have language structures that allow them to become so. I'd have
thought the idea for Chapel was not to be bound by the constraints of
C++. :-)
1) The BigInt support has recently been revamped
and we're working on getting that in to master. The 1st draft is
here:
https://github.com/chapel-lang/chapel/pull/4243
I am guessing the main thrust here is to have the values be on the
stack rather than on the heap. Will the new type be a value type or as
currently a reference type? Operator overloads a great idea. Working
with BigInteger and BigDecimal is a joy in Groovy and Kotlin, whereas
it is a right pain using Java.
2) We've talked about supporting arbitrary precision integers
at a more native level. We've talked about using some
syntax like int(_) or int(big) or something so that
the arbitrary precision would fit in with int(16)/int(64) etc.
If we did that, it would seem to be more apparent that
it should be possible to make a range over arbitrary precision
integers.
Having distinct but interworkable arbitrary size integers and arbitrary
precision floats makes for an easier life, if it is possible. Python
ints seem to get this mostly right – though losing the type distinction
between hardware and software integers has a real downside.
3) It seems to me that getting the range type to support arbitrary
precision integers is a reasonable TODO that could be taken on
once the recent BigInt improvements land. I don't think that
having other/better syntax for BigInt that makes it look more
like an integer really matters here. Also, I can't predict
(without trying it) if this is an easy change or a hard one.
In Groovy we went with postfix letters to distinguish the type of a
literal. I think all language that have literal types do this.
Languages that have abstract type literals, e.g. Go, don't have to
worry.
So, I have two questions for you:
1) Would you be able to make a .future test that works with our
start_test testing system? In test/modules//standard/gmp ?
I don't know if you've done this before but we can help if
you need some pointers. Creating the .future file will help
us to track the feature request. (Of course, you or somebody
else in the community could go on to implement the improvements
necessary to the range type).
I'll certainly look into this. But not in the next few days I'm afraid.
Travel and PyCon UK then JAX London. Not to mention a couple of paying
gigs in between.
2) Is making a range of BigInts obviously important to some
Chapel program you are working on? If you can convince somebody
why it's important to work on that right away (vs other
priorities) it might get resolved sooner. I'm guessing it's
a "nice to have" and a TODO to record somewhere.
To be honest arbitrary precision floats are more commercially
important. Various people do need arbitrary size integers. Experience
from Groovy is that having BigDecimal as the default floating point
type was a very good choice for take up and usage. Kotlin has taken
over a bit from Groovy now in many ways, but there were some doubts in
some finance sectors till they had the BigDecimal story analogous to
Groovy.
I'd guess the cryptography folk are the most obvious group that needs
arbitrary size integers. However there are some bioinformatics and
finance people who also rely on them, and use Python because of it's
story on integers.
So I'd say this is "current usage" versus "traction and future usage".
Clearly those currently using Chapel are happy with constrained integer
and errorful float hardware numbers. But to get traction in the
finance, and some areas of data science and bioinformatics, arbitrary
size integers and arbitrary accuracy floats will be essential. The
balance is cost versus opportunity. And missing the opportunity. C++17
and Java 9 is a good timescale on which to have a better story that
C++.
But then I am just an analyst these days… :-)
--
Russel.
=============================================================================
Dr Russel Winder t: +44 20 7585 2200 voip: sip:[email protected]
41 Buckmaster Road m: +44 7770 465 077 xmpp: [email protected]
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Chapel-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-users
