Re: uint64 typecast can't be initialised with more than 15 decimal positions

[Yury T.]

Jordi Gutiérrez Hermoso-2 wrote
> It's easier if you just write it and make it easy for me to
> incorporate your changes.
> ...
> Sure. Also post the original Russian. Я тоже говорю немножко по-русски.

Okay, let's try working that way. And as for my draft on datatypes, it's in
OpenOffice, so it WILL be posted in Russian (that is, "as is") :).


Jordi Gutiérrez Hermoso-2 wrote
>> Most definitely it is NOT. Even as wiki-entry says, precision is an
>> amount
>> of detail, and you can't be any more detailed with machine-represented
>> integer, as you already are. One is one. But there are magnitude limits.
> 
> An uint64 has 64 bits of precision, which is the point here. There are
> simply more bits with which to represent quantities, even if these
> quantities have to be integral. This is more precision than the 52
> bits of a double's mantissa. An uint64 thus has more precision than a
> double. A double can represent numbers as large as an uint64, but with
> less precision. The limits are the same, the precision is not.
> 
> But again, if you strongly disagree, go ahead and rewrite the FAQ.

IEEE's double may represent (in 64 bits) roughly +-0.9{times 16}x10+-308.
This limit is way over any integer limit using comparable binary resources.
Representation loses precision for ANY number requiring more than 16
significant figures in mantiss.

Now, integer datatype may represent (in 64 bits) roughly +-8x10^18, but this
representation is, however, *always precise*.

This is fundamental difference, whatever the docs saying otherwise say.

I will just go ahead, then.


Jordi Gutiérrez Hermoso-2 wrote
>>>> If uint64() works by converting its input somehow through the IEEE
>> If the function silently rounds the integer (!!), then the
> The function is doing no such thing. The function is being fed a
> double that has already been rounded by the interpreter, before the
> function ever sees it.
> 
>> The only rational decision would be to limit the interpreter input
>> by number of decimal places (and throw an error)
> 
> This would break compatibility with Matlab, since this works there
> without error. We could warn, if you want, "numeric literal cannot be
> represented with double precision".

Ah, the Matlab compatibility... Please-please, add at least either this
signalling or any other kind of warning. The current situation is
unacceptable. E.g., I would be in a goodly pickle if I didn't check what
actually goes in into uint64.

And I wouldn't try to coax this modification out of competent folks, if I
were competent to do it myself (like previously, with utf8 in plot windows).




--
View this message in context: 
http://octave.1599824.n4.nabble.com/uint64-typecast-can-t-be-initialised-with-more-than-15-decimal-positions-tp4650508p4650526.html
Sent from the Octave - General mailing list archive at Nabble.com.