OpenEuphoria

1. Interpreter erroneously reading some numbers

• Posted by SDPringle Jan 23, 2015
• 1511 views

Forked from Re: POLL: What should value do with underscores?

I have forked because my last post was off topic and I realized that I may have caused some confusion. See ticket 877. Some numbers are read wrong and although the same problems with 4.0.5 may not be there, there are new problems that were previously not there. In the HEAD of 4.0, some numbers cause the computer to hang a long time, some numbers are just interpreted wrong, so the interpreter doesn't see the original number it sees instead an erroneous value. Now, arguably it should parse correctly if the string is inside the range of a double. This number I have given as an example isn't. So, what should we do with this? Should we make these numbers read as inf or should we error out and notify the user?

Shawn

3. Re: Interpreter erroneously reading some numbers

• Posted by petelomax Jan 24, 2015
• 1483 views

That exact problem is on my radar, not sure how to proceed. When a 32-bit compiler is trying to construct a 64-bit executable, I'd like #8000000000000001 to yield {#80000000,#00000001} (or {lo_dword,hi_dword}) and something similar for 80-bit floats, and when a 32-bit compiler is constructing a 32-bit executable, I'd like ^warning: precision loss messages for such values. Of course, #8000000000000000 is fine as-is, it is not so much a matter of counting digits but explicitly testing for precision loss.

For what it is worth, which is probably not very much at all, and this is bytes->value not source->bytes, in my filedump.exw program I resorted to this:

constant atom h8a = allocate(8), 
         integer h8i = floor(h8a/4)     -- (easier for ilASM) 
 
function reconstitute_int64(sequence s8) 
-- While 64-bit apps use 80-bit floats, which have 64 bits of precision, 
--  32-bit apps use 64-bit floats, which only have 53 bits of precision. 
-- This retrieves "normal" numbers as "normal" values (eg 0,1,-1,237), 
--  but eg #8000000000000001 (or more accurately {1,0,0,0,0,0,0,#80}), 
--  rather than minus the 1, as {#80000000,1}, ie {hi_dword,lo_dword}. 
-- (If invoked on 64-bit, does a pointless peek and returns an atom.) 
object res 
    poke(h8a,s8) 
    #ilASM{  
        [32] 
            mov eax,[h8i] 
            lea edi,[res] 
            fild qword[ebx+eax*4] 
            call %opMovbi               -- call StoreFlt ([edi]:=ST0) 
            mov eax,[res] 
            mov edi,[h8i] 
            cmp eax,h4 
            jl %opRetf 
            fld qword[ebx+eax*4] 
            fistp qword[ebx+edi*4] 
        [64] 
            mov rax,[h8i] 
            lea rdi,[res] 
            fild qword[rbx+rax*4] 
            call %opMovbi               -- call StoreFlt ([rdi]:=ST0) 
        [] 
          } 
    if peek({h8a,8})=s8 then 
        return res 
    end if 
    poke(h8a,s8) 
    return reverse(peek4u({h8a,2})) 
end function 

Pete

5. Re: Interpreter erroneously reading some numbers

• Posted by petelomax Jan 25, 2015
• 1345 views

It's a fairly low priority thing, but one I'd like to solve properly one day. Pointers aren't an issue, it's arbitrary literal values - and most executables are well below 1GB anyway! The 2^55 (2^53?) thing is a bit of a red herring as #8000000000000000 (2^63) is perfectly fine, on a 32-bit system using 64-bit floats, but #8000000000000001 is not. I think I can see a way to count digits and reconstruct 64-bit integers in the range 0..#FFFFFFFFFFFFFFFF, it is probably more that accurately crafting 80-bit floats using only 64-bit floats that may prove the tougher issue. Any kind of type check seems unlikely to help unless you have the actual value you were expecting (where from and held how though?) vs. the value you actually got, and as type checking routines only accept the one value, I believe that rules them out completely, or at least makes a standard function a more logical choice. Maybe reconstructing a string representation to see if it matches the program source is the only way it can be done.

All I am really saying here is that I too am interested in determining precisely when 53/64 bits of precision (not value) are exceeded. My interests may differ, but probably share some common ground.

Pete