type of number/float in vim script

[mattn]

Hi, all

I'm thinking, type of 'number' in vim script must be 64bit. Also 'float' should be 'double' in 2013/2014 or later.
`getfsize()` can't return size of big file over 32bit. And localtime() return 32bit.

I suggest to let us convert types in vim script.

How do you think?

Thanks.

[Christian Brabandt]

Hi mattn!

Good idea, if this is possible on all architectures where Vim runs.

regards,
Christian
--
Der Kl�gere gibt nach, solange, bis er der dumme ist.

[mattn]

Bram, How about to start implement?
At the first, re-define int64_t or _int64 for vimnumber_T?

[mattn]

https://gist.github.com/mattn/8278843

This is in progress.

[Andre Sihera]

-
-#if SIZEOF_INT <= 3 /* use long if int is smaller than 32 bits */
-typedef long varnumber_T;
-#else
-typedef int varnumber_T;
-#endif
+typedef int64_t varnumber_T;


In my opinion, this type of change is not acceptable.

If VIM is to be targetted for 32-bit platforms, it should have the option to
run with 32-bit wide types on those platforms for optimal performance.

64-bit wide types on 32-bit platforms cause 64-bit arithmetic emulation
to be performed on ALL integer-based calculations, impacting the speed
of such calculations, be it in-script variable access, loop control, etc.

The typedef should look like this:

#if sizeof(size_t) > 4 /* ANSI C only. need to change to cross-standard
64-bit test */
typedef int64_t varnumber_T;
#else
#if SIZEOF_INT<= 3 /* use long if int is smaller than 32 bits */
typedef long varnumber_T;
#else
typedef int varnumber_T;
#endif
#endif


Use of size_t is the best way in ANSI C to know the width of the system
bus as size_t must be able to reflect the size of the largest possible
addressable memory object (as returned by "malloc()").

[Ken Takata]

Hi mattn and all,

I think that supporting 64-bit Number (even on 32-bit systems) is very useful.
One of the best examples is getfsize() as mattn said. 32-bit Number is too
small to represent a filesize nowadays.

2014/1/6 Mon 15:34:44 UTC+9 mattn wrote:
> https://gist.github.com/mattn/8278843
>
> This is in progress.

I have updated mattn's patch:
https://bitbucket.org/k_takata/vim-ktakata-mq/src/fd966d51f56b69e02d9ebb984355f692b73b2260/num64.patch?at=default&fileviewer=file-view-default

Changes are:

* Sync with the latest codebase.
* VC9 or earlier doesn't have stdint.h, int64_t and uint64_t.
Use __int64 for old Windows compilers.
* Define FEAT_NUM64 in feature.h.
(If someone doesn't like this feature, s/he can disable this by editing
feature.h.)
* Display +/-num64 in :version.
* Add has('num64').
* Adjust the behaviour when dividing by 0. (:help expr-/)
* Adjust the behaviour of float2nr().

I confirmed that getfsize() returned a right value even if the filesize was
over 2 GiB. (My largefile patches are also needed.)
I also confirmed that all existing tests passed.

Of cause, more tests are needed, and documents should be updated.

(See also: [patch] Always use long for vimscript Numbers
https://groups.google.com/d/topic/vim_dev/Ju0DDCqeuMc/discussion )

Regards,
Ken Takata

[Tony Mechelynck]

Vim differs from some editors such as sed in that it loads the whole
editfile in memory. In a 64-bit Vim, a Number is a 64-bit integer so
no change is required. In a 32-bit Vim, if the filesize doesn't fit in
a 32-bit integer, or even in 'maxmem' (which cannot be more than half
the available system memory), we know that the file won't fit in
memory: we won't be able to edit it. If we need better precision,
which IMHO won't be often, we can get it by parsing a directory
listing (on Unix: let str = system('ls -l ' . expand('filename.ext',
':p')) or similar).

For other purposes, we can exceed 32-bit integer precision in 32-bit
code by using the FPU ("pretending" that our integers are
floating-point numbers). In that case, of course we have to know how
many bits of mantissa are available before we start losing lower-end
digits (lower-end binary digits, for the purists among you).

IIUC, Vim's Float format uses what C calls "double" which on Intel
i686 processors means a 64-bit data item including 53 significant
bits. The "long double" format (maximum hardware precision, with 64
bits _plus_ exponent) is not used by Vim to store data (though the
floating-point hardware uses it for computations, even in Vim). This
"double" format is better than 32-bit but does not reach 64-bit
integers.

Best regards,
Tony.

[Ken Takata]

Hi,

I have updated the patch and divided it into two:
https://bitbucket.org/k_takata/vim-ktakata-mq/src/ec8fa710e76975724c30d0f84c02e1460e5bb705/num64.patch?at=default&fileviewer=file-view-default
https://bitbucket.org/k_takata/vim-ktakata-mq/src/ec8fa710e76975724c30d0f84c02e1460e5bb705/incdec64.patch?at=default&fileviewer=file-view-default

If incdec64.patch is applied, incrementing/decrementing with <C-A>/<C-X> uses
64-bit integer on supported platforms. (Currently, 64-bit int is used on 64-bit
Linux but not on 64-bit Windows.)

Regards,
Ken Takata

[Ken Takata]

Hi,

I have updated the paches:
https://bitbucket.org/k_takata/vim-ktakata-mq/src/d1b6fe7c1f38ffc8d7fda03fda31d0dec6a5cbd1/num64.patch?fileviewer=file-view-default
https://bitbucket.org/k_takata/vim-ktakata-mq/src/d1b6fe7c1f38ffc8d7fda03fda31d0dec6a5cbd1/incdec64.patch?fileviewer=file-view-default

Now, vim_snprintf() supports 64-bit formats (%lld, etc.).

Regards,
Ken Takata

[Ken Takata]

Hi,

Here are the updated num64 patches for 7.4.1202 (including docs).
Also available on my bitbucket repository:
https://bitbucket.org/k_takata/vim-ktakata-mq/src

Regards,
Ken Takata

[Bram Moolenaar]

Thanks. I'm going to change the function declarations today, this
probably means it's going to change again... After that everything will
be better!

--
hundred-and-one symptoms of being an internet addict:
84. Books in your bookcase bear the names Bongo, WinSock and Inside OLE

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

[Ken Takata]

Hi,

Here are the updated num64 patches.

Regards,
Ken Takata

[Ken Takata]

Hi,

I have updated the num64 patch. I have merged the three patches into one again.
This includes the fix of the g<C-G> problem:
https://groups.google.com/d/msg/vim_dev/8epHlRuIAHc/j5I9x9eHEQAJ

Regards,
Ken Takata

[Ken Takata]

Hi,

2016/2/24 Wed 22:10:33 UTC+9 Ken Takata wrote:
> I have updated the num64 patch. I have merged the three patches into one again.
> This includes the fix of the g<C-G> problem:
> https://groups.google.com/d/msg/vim_dev/8epHlRuIAHc/j5I9x9eHEQAJ

I have updated the num64 patch for 7.4.1665.
Please check the attached patch.

Bram, I'm afraid that you are mistaking some of my patches.
Attached patch is related to the following item from the todo.txt:

L175-176
> Patch to support 64 bit ints for Number. (Ken Takata, 2016 Jan 21)
> Also in update of Feb 24?

The num64 patch is also available from the following URL:
https://bitbucket.org/k_takata/vim-ktakata-mq/src/tip/num64.patch
(I will keep it up to date in the same URL.)

Regards,
Ken Takata

[Bram Moolenaar]

Thanks. Hopefully I get to including it one of these days.

--
We are the Borg of GNU GPL. We will assimilate your source code.
Resistance is futile.

[Ken Takata]

Hi,

2016/3/29 Tue 2:27:40 UTC+9 Bram Moolenaar wrote:
> Ken Takata wrote:
>
> > 2016/2/24 Wed 22:10:33 UTC+9 Ken Takata wrote:
> > > I have updated the num64 patch. I have merged the three patches into one again.
> > > This includes the fix of the g<C-G> problem:
> > > https://groups.google.com/d/msg/vim_dev/8epHlRuIAHc/j5I9x9eHEQAJ
> >
> > I have updated the num64 patch for 7.4.1665.
> > Please check the attached patch.
> >
> > Bram, I'm afraid that you are mistaking some of my patches.
> > Attached patch is related to the following item from the todo.txt:
> >
> > L175-176
> > > Patch to support 64 bit ints for Number. (Ken Takata, 2016 Jan 21)
> > > Also in update of Feb 24?
> >
> > The num64 patch is also available from the following URL:
> > https://bitbucket.org/k_takata/vim-ktakata-mq/src/tip/num64.patch
> > (I will keep it up to date in the same URL.)
>
> Thanks. Hopefully I get to including it one of these days.

I have slightly updated the num64 patch.
I changed to use vim_snprintf() instead of sprintf() when a 64-bit number is
used, and removed VARNUMBER_FMT. I think this makes the source codes a bit
easier to understand. E.g.:

Before:
sprintf((char *)buf, "%"VARNUMBER_FMT"d",
(varnumber_T)varp->vval.v_number);
After:
vim_snprintf((char *)buf, NUMBUFLEN, "%lld",
(varnumber_T)varp->vval.v_number);

Regards,
Ken Takata

[Ken Takata]

Hi,

I have updated the num64 patch. Now it includes some tests.
While I wrote the tests, I found some bugs, but they are already fixed.
I also added type casts to suppress warnings.
Please check the attached patch. The same patch is also available at:
https://bitbucket.org/k_takata/vim-ktakata-mq/src/tip/num64.patch

Regards,
Ken Takata