Poly/ML October 2015

polyml@lists.polyml.org

8 participants
14 discussions

New Foreign Function Interface
by artella.coding＠googlemail.com 12 Oct '15

12 Oct '15

Hi, I was trying out the new foreign function interface that was committed today, and I find that if one tries to load a symbol that does not exist no error message is returned. For example in https://github.com/polyml/polyml/blob/598ff7841e5e155c1fff89bf75cd2a91ee779… if I do val sumTree2 = call1 ( getSymbol mylib "SumTreeDoesNotExist" ) cTree cInt; then no error message is reported. Then upon the call to sumTree aTree; an error is encountered and the program just terminates. Thanks

2 8

InternalError: AllocStore found but last allocation not complete
by phil.clayton＠lineone.net 08 Oct '15

08 Oct '15

After integrating the new Finalizable module in a library, I am getting an internal error from the compiler: Exception- InternalError: AllocStore found but last allocation not complete raised while compiling This affects Poly/ML 5.5.2 and the very latest commit with the compiler rebuilt (twice). An example is attached showing this. I have reduced this as far as I can but still a few small library files are required. The file 'polyml.sml' is the top-level file that uses the other files. Regards, Phil

2 3

Weak references
by ramana＠member.fsf.org 08 Oct '15

08 Oct '15

Hello, I am interested in using Poly/ML's Weak structure ( http://polyml.org/documentation/Reference/Weak.html) for hash-consing. The documentation would perhaps suggest that this is not an intended use of Weak, so I'd like to ask the list whether it is suitable and, if not, whether there are alternatives. An abstract of the problem is as follows. For a certain datatype, t, we want there to be at most one copy of any value of type t created by applying a constructor to unique arguments. To achieve this, we implement "hash-consing" constructors for t, which check whether the desired value exists already and return it if so, and only otherwise create a new value. To be able to check which values exist already, we maintain a hash table of all existing values. To allow values to be garbage collected when they are no longer needed, we make the hash table store only weak references to the values. The Weak structure allows weak references to be made to other references, but not to other non-reference values. Thus, the values in the hash table can be of type (t ref option ref), as produced by Weak.weak, but not of type (t option ref). Thus, on the face of it, it seems like using Poly/ML's Weak implementation will require unnecessary references and indirections. Is that indeed the case, or is Poly/ML smart about avoiding unnecessary indirections somehow? For hash-consing, we are not using Weak in the way described in its documentation, wherein the contents of the reference don't matter and the reference itself is only used as a token to track an external resource. Is there, perhaps, an alternative interface to Poly/ML's garbage collector more suitable for hash-consing? Cheers, Ramana

2 5

type real in polyml
by David.Matthews＠prolingua.co.uk 07 Oct '15

07 Oct '15

Hi Fabian, This was a bit bizarre particularly as when I tried it on Windows there didn't seem to be a problem. It is a problem with the precision and when rounding occurs. Poly/ML uses the old x87 floating point unit on both X86/32 and X86/64. As far as I'm aware all x86/64 machines support the SSE2 instructions so other compilers use SSE2 instructions on 64-bit but, by default use the x87 instructions on 32-bit. The x87 instructions use 80-bit registers internally and only round to 64-bits when the registers are stored to double-precision values. The SSE2 instructions are 64-bit so all the results are the same whether values are stored to memory or not. The x87 has bits in the control word that can allow it to compute intermediate results to 80-bit, 64-bit or 32-bit precision. The question is whether this should be set to 80-bit or 64-bits? Currently Poly/ML sets it to 80-bit precision at the start. As far as I've been able to ascertain that is what other x86/32 compilers do. The idea is, I suppose, to compute intermediate results to the best precision available. It does, though, produce the strange results that you've encountered. I think the reason for the difference in results is whether the function can be computed at compile-time or not. I'm coming round to the view that it should instead set the FPU to 64-bits so that intermediate results are the same whether they remain in the register or are written out to memory and reloaded. It looks as though the libraries in Visual C set that anyway which is why I only saw the problem when I tested on Linux. This would also mean that results would not change when, as I plan, I change to using the SSE2 instructions on x86/64. Best regards, David On 07/10/2015 14:07, Fabian Immler wrote: > Hi David, > > Perhaps I should rephrase my enquiry to: "Do I get any guarantees from the implementation of type real in PolyML"? > Naively, I would have expected, that every subexpression is evaluated according to the IEEE-754 standard (in double precision). > > I skimmed the implementation in libpolyml/reals.cpp, it looks like all intermediate results are stored in and retrieved from memory (real_arg, real_result). Is that sufficient to comply to IEEE-754? I.e., can there not occur "double rounding" (as in [1, section 3.3.1])? Or isn't there the need to use something like FLT_EVAL_METHOD=1 [2,3]? > > [1] http://www.springer.com/us/book/9780817647049 > [2] https://en.wikipedia.org/wiki/C99#IEEE.C2.A0754_floating_point_support > [3] http://www.cplusplus.com/reference/cfloat/ > > Best regards, > Fabian > > >> Am 07.10.2015 um 12:26 schrieb Fabian Immler <immler at in.tum.de>: >> >> Hi David, >> >> I noticed some strange behavior when working with type real in PolyML: >> In the following example, where I have "testres = twosum a", depending on whether I call >> "testres" or "twosum a" I get different results. >> >> If I take the definitions out of the structure Test, the results are the same. They are also the same if e.g. print-statements are inserted in between the assignments to b, s, sb and r. The results are also the same when evaluating inside Isabelle with the debugger turned on. >> >> Do you have an idea what is going on there? >> Is it possible that some intermediate results are kept in higher precision in the FPU? >> Does the compiler perform some "optimizations" on expressions of type real? >> >> Best regards, >> Fabian >> >> >> structure Test = struct >> >> fun one n = (if n = 0 then 100.0 else one (n - 1)); >> >> val a : real = one 1; >> >> fun twosum a = >> let >> val b = 1.0/1243313.0; >> val s = a + b >> val sb = s - b >> val r = s - sb >> in >> r >> end; >> >> val testres = twosum a; >> end; >> >> open Test; >> val a = twosum a >> val b = testres >> >> >>

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Poly/ML October 2015