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
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------------
_______________________________________________ Chapel-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/chapel-users
