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

[Jordi Gutiérrez Hermoso]

On 4 March 2013 12:03, Yury T. <address@hidden> wrote:
> Jordi Gutiérrez Hermoso-2 wrote
>> Sure, moving material from the FAQ to the manual is fine, with the FAQ
>> pointing to the manual is good. Do you have a suggestion on how to
>> reword the manual?
>
> Yes, but I can't jump in rewriting right now. Generally, on the
> lines of what I'm talking about here.

I'm busy and lazy. ;-)

It's easier if you just write it and make it easy for me to
incorporate your changes.

>  BTW, I have already partly rewritten several manual fragments on
> complex datatypes (as mentioned in the previous discussion). Only
> it's in Russian (but translates adequately with Google), and not
> finished (I remade only the parts of immediate concern to me). I can
> post it as a work-in-progress somewhere.

Sure. Also post the original Russian. Я тоже говорю немножко по-русски.

> Jordi Gutiérrez Hermoso-2 wrote
>>> Also, talking about integers presupposes talking about *limits, not
>>> precision* -- how big are the integer numbers you can use with the help
>>> of
>>> data types: uint32, uint64 etc.
>>
>> That is precision:
>>
>>     http://en.wikipedia.org/wiki/Precision_%28computer_science%29
>
> 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.

> Jordi Gutiérrez Hermoso-2 wrote

>>> If uint64() works by converting its input somehow through the IEEE
>>> floats (16 positions after the decimal point), than it is doing it
>>> wrong, anyway.
>>
>> I suppose the FAQ entry isn't clear. The problem isn't uint64, but
>> that the Octave and Matlab languages don't have integer literals.
>> Any numerical literal is first read by the interpreter as a double.
>> With JITC, sometimes you can optimise this and guess the type, but
>> this is just a transparent optimisation. The semantics of the
>> language do not allow integer literals.
>
> If the function silently rounds the integer (!!), then the
> function's, well, functioning is wrong, wrong and, once again,
> wrong.

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".

> or, better yet, to throw a rounding error in such cases. Definitely
> not silently round the supposedly integer input.

Rounding is the best that can be done, especially if we are to keep
Matlab compatibility. If this bothers you so much, I will welcome a
patch to make the interpreter warn in this case.

- Jordi G. H.