Re: Updated floating point patch
Bill McCarthy wrote: (2) does this LC_NUMERIC actually work on Windows - I recall having problems with LC_ALL using the unix sort of GNU coreutils - is this an environment variable we need to set? I haven't tried it. So please set your environment so that a comma is used for a decimal point and then run Vim to try out the floating point stuff. The patch applied flawlessly. Both Vim and Gvim makes were without warnings. Without setting any environment variables,all of my tests are working as expected. Also, commas don't work as expected. Here's what I get from: :echo 1,2 1 E15: Invalid expression: ,2 E15: Invalid expression: ,2 Eh, I think you mean that this doesn't work, and that this is expected. We don't want to have Vim recognize 1.2 in one environment and 1,2 in another. 1,2 is not backwards compatible anyway (think of function arguments, list initializers, etc.) Otherwise Vim scripts would not be portable. -- hundred-and-one symptoms of being an internet addict: 19. All of your friends have an @ in their names. /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Updated floating point patch
On Mon 9-Jun-08 2:01am -0600, Tony Mechelynck wrote: On 09/06/08 03:43, Bill McCarthy wrote: On Sun 8-Jun-08 4:25pm -0600, Bram Moolenaar wrote: Bill McCarthy wrote: (2) does this LC_NUMERIC actually work on Windows - I recall having problems with LC_ALL using the unix sort of GNU coreutils - is this an environment variable we need to set? I haven't tried it. So please set your environment so that a comma is used for a decimal point and then run Vim to try out the floating point stuff. The patch applied flawlessly. Both Vim and Gvim makes were without warnings. Without setting any environment variables,all of my tests are working as expected. Also, commas don't work as expected. Here's what I get from: :echo 1,2 1 E15: Invalid expression: ,2 E15: Invalid expression: ,2 I get the same but I think it's expected -- at least with my locale Yes, I was trying to say commas don't work pause as expected :-( :lang Current language: LC_CTYPE=en_US.UTF-8;LC_NUMERIC=C;LC_TIME=C;LC_COLLATE=C;LC_MONETARY=C;LC_MESSAGES=C;LC_PAPER=C;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=C;LC_IDENTIFICATION=C When I was on Windows, it didn't accept C as a locale but it did accept en so, since I wanted menus and messages in English and not in the French or Dutch of my Windows locale, I started my vimrc with if has(unix) language messages C else language messages en endif runtime vimrc_example.vim etc. Since Vim has no separate :language numeric setting, I suppose it should be set with :language en or similar. If you want to keep messages and/or ctype and/or time in your default locale, you'll need to save and restore them, for instance: let save_messages = v:lang let save_time = v:lc_time let save_ctype = v:ctype if has(unix) lang C else lang en endif exe lang mess save_messages exe lang time save_time exe lang cty save_ctype Thanks for the explanation. If you know of a way of setting a locale that accepts commas as decimal points, see if it causes Vim to accept 1,2 as 1.2 - that's what I think Bram was asking in his release of the latest floating point patch. -- Best regards, Bill --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Updated floating point patch
On Mon 9-Jun-08 3:41am -0600, Bram Moolenaar wrote: Bill McCarthy wrote: Also, commas don't work as expected. Here's what I get from: :echo 1,2 1 E15: Invalid expression: ,2 E15: Invalid expression: ,2 Eh, I think you mean that this doesn't work, and that this is expected. You didn't hear my pause between work and as :-) Yes, that should have been written: Also, as expected, commas don't work. -- Best regards, Bill --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
RE: Updated floating point patch
Bram Moolenaar wrote:
Attached you will find the latest floating point patch.
Thanks Bram. I have patched and compiled without incident. A few tests, and a
superficial look at the code changes, make me believe that the new float patch
is
good. As discussed, using strtod() is much more robust.
One query: In file doc/eval.txt we see:
These are INVALID:
1e40 missing .{M}
Perhaps in str2float() help, mention that following IS valid:
str2float('1e40')
John
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: Updated floating point patch
On Mon, Jun 9, 2008 at 12:06 PM, Tony Mechelynck wrote: On 09/06/08 11:52, Bill McCarthy wrote: [...] Thanks for the explanation. If you know of a way of setting a locale that accepts commas as decimal points, see if it causes Vim to accept 1,2 as 1.2 - that's what I think Bram was asking in his release of the latest floating point patch. I think French normally uses a comma as decimal point Most countries in Europe, use comma rather than dot as decimal separator. The links below gives the list of countries that use dot, comma or momayyez as decimal separator (if that can help testing): http://en.wikipedia.org/wiki/Decimal_separator#Comma_countries http://en.wikipedia.org/wiki/Image:DecimalSeparator.png The thousand separator can also be different with the locale (space in France, dot in the Netherlands, comma in the UK): France: 1 234 567,89 Netherlands: 1.234.567,89 UK: 1,234,567.89 -- Dominique --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Patch 7.1.312
Patch 7.1.312
Problem:The .po files have mistakes in error numbers.
Solution: Search for these mistakes in the check script. (Dominique Pelle)
Files: src/po/check.vim
*** ../vim-7.1.311/src/po/check.vim Wed Nov 23 22:10:37 2005
--- src/po/check.vimSun May 25 13:47:59 2008
***
*** 1,7
Vim script for checking .po files.
! Go through the file and verify that all %...s items in msgid are identical
! to the ones in msgstr.
if 1 Only execute this if the eval feature is available.
--- 1,8
Vim script for checking .po files.
! Go through the file and verify that:
! - All %...s items in msgid are identical to the ones in msgstr.
! - An error or warning code in msgid matches the one in msgstr.
if 1 Only execute this if the eval feature is available.
***
*** 56,61
--- 57,76
endif
endwhile
+ Check that error code in msgid matches the one in msgstr.
+
+ Examples of mismatches found with msgid E123: ...
+ - msgstr E321: ...error code mismatch
+ - msgstr W123: ...warning instead of error
+ - msgstr E123 ... missing colon
+ - msgstr ... missing error code
+
+ 1
+ if search('msgid \(\n\)\?\([EW][0-9]\+:\).*\nmsgstr \(\n\)\?[^[EMAIL
PROTECTED]@!') 0
+ echo 'Mismatching error/warning code in line ' . line('.')
+ let error = 1
+ endif
+
if error == 0
echo OK
endif
*** ../vim-7.1.311/src/version.cWed Jun 4 21:34:51 2008
--- src/version.c Mon Jun 9 14:43:59 2008
***
*** 668,669
--- 673,676
{ /* Add new patch number below this line */
+ /**/
+ 312,
/**/
--
hundred-and-one symptoms of being an internet addict:
24. You realize there is not a sound in the house and you have no idea where
your children are.
/// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\download, build and distribute -- http://www.A-A-P.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Patch 7.1.314
Patch 7.1.314
Problem:The value of 'pastetoggle' is written to the session file without
any escaping. (Randall Hansen)
Solution: Use put_escstr(). (Ben Schmidt)
Files: src/option.c
*** ../vim-7.1.313/src/option.c Wed Mar 12 17:37:53 2008
--- src/option.cWed Jun 4 19:32:02 2008
***
*** 243,249
/* WV_ and BV_ values get typecasted to this for the indir field */
typedef enum
{
! PV_NONE = 0
} idopt_T;
/*
--- 243,250
/* WV_ and BV_ values get typecasted to this for the indir field */
typedef enum
{
! PV_NONE = 0,
! PV_MAXVAL = 0x/* to avoid warnings for value out of range */
} idopt_T;
/*
***
*** 8713,8719
{
s = *valuep;
while (*s != NUL)
! if (fputs((char *)str2special(s, FALSE), fd) 0)
return FAIL;
}
else if (expand)
--- 8714,8720
{
s = *valuep;
while (*s != NUL)
! if (put_escstr(fd, str2special(s, FALSE), 2) == FAIL)
return FAIL;
}
else if (expand)
*** ../vim-7.1.313/src/version.cMon Jun 9 15:10:07 2008
--- src/version.c Mon Jun 9 17:05:40 2008
***
*** 668,669
--- 673,676
{ /* Add new patch number below this line */
+ /**/
+ 314,
/**/
--
hundred-and-one symptoms of being an internet addict:
26. You check your mail. It says no new messages. So you check it again.
/// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\download, build and distribute -- http://www.A-A-P.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
BUG: Partially reversed strings with long entered ex command
Hello VIM developers,
I'd like to report a bug that occurs when a very long ex command is entered, so
that the GUI / console screen space isn't sufficient to display the complete
command.
I have an external VBScript that uses the VIM OLE SendKeys() function (or
WshShell.SendKeys() as a fallback) to open a list of files in VIM via:
:drop file1 file2 C:/Program\ Files/this_is_a_very_very_very_long_filename
If the list of files is longer than the available space for the ex command, the
characters that didn't fit in are appended in reversed order:
:args
[file1] file2 C:/Program\ Fiemanelif_gnol_yrev_yrev_yrev_a_si_siht/sel
^ BUG: reversed string!!!^
This happens:
- both in GVIM and console VIM
- on Windows and Linux
- through OLE SendKeys(), VIM's feedkeys(string,'t'), or by manually typing
the string
- in VIM 7.1.311 until back to VIM 6.0
Probably, this is due to some bad pointer increment, which is hopefully easy to
fix.
Steps to reproduce:
---
vim -N -u NONE
Limit window size to minimize typing until overflow :-)
:set columns=20 lines=4
:drop 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890
1234567890 1234567890
Enlarge again to better see the output (optional).
:set columns=80
:args
[1234567890] 1234567890 1234567890 1234567890 1234567890 1234567890
12345670987654321 098
Note the garbled strings at the end!
You can also reproduce without resizing via feedkeys():
gvim -N -u NONE
call feedkeys(':drop ', 't') | for i in range(1,500) | call
feedkeys('1234567890
', 't') | endfor | call feedkeys(\CR, 't')
:args
-- kind regards, ingo
/^-- Ingo Karkat -- /^-- /^-- /^-- /^-- /^-- /^-- http://ingo-karkat.de/ --
Me? A skeptic? I trust you have proof.
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: Improve vim's keyboard input subsystem
On Mon, 09 Jun 2008 17:41:00 +0200 Bram Moolenaar [EMAIL PROTECTED] wrote: In that case, I'd like to hear your suggestion on how I may use combinations of Shift/Ctrl/Alt with keypresses in a normal vim. Nothing special, most of them can be recognized already. Especially if you are using an xterm. Try :set term=xterm and then :set termcap. The entries which contain ;* recognize modifier keys. For other terminals you will need to add the termcap entries somehow. Yes; that works on real vim-in-xterm. But what of e.g. screen? When I'm editing an email in mutt, running via screen, this uses vim. vim starts up with $TERM=screen, not xterm, so doesn't know to do that. Perhaps to handle this case, vim ought always to recognise the ;* entries? Currently, the only way I find that works at all is to keep a giant list of :map and :map! commands, which recognise the sequences. See the attached file. This sortof works; it's enough to get things like Ctrl-LR to be move word left/right, Alt+arrow to be move focus to window, and Alt+[number] to be :b1 to :b10. It doesn't work in paste mode, and it upsets the ttytime settings. Also, it breaks UTF-8 input if I try to map Alt+letter. Alt-letter is supposed to work to get the letter with the 8th bit set. Then converted to whatever encoding you are using. This is how vi traditionally works, in combination with traditional terminals (and terminal emulators). Also note that things like Esc0 should never be produced by a single key, since it should mean Esc (leave Insert mode), and zero (go to first column). Relying on timing is not a good idea. I'm aware of the problems with timing :) Seems we're stuck though, ultimately.. we can't make all three of Escletter, Alt-letter and UTF-8 work. If you know of a better way to make all these things possible, I would very much like to hear it. It appears you need to read :help xterm-modifier-keys Again, I'm aware of it. I'm aware that it doesn't apply during screen. How would you recommend I make vim-in-screen work, then? Just set TERM=xterm or some vim-specific fiddling if it notices $TERM == screen ? I still think ultimately a rethink of the bottom input layer is best here... I can make it not break anything that currently works... Read terminfo just as before - it'll still JustWork on your 1970s glass teletype that sends Weird Sequences. It'll just happen to work better on a modern xterm. And as a side-effect, GDK and other input layers will work better. I'm still failing to understand your hostility toward it. -- Paul LeoNerd Evans [EMAIL PROTECTED] ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: PGP signature
Re: Updated floating point patch
Mikolaj Machowski wrote: Things works, thanks :) Few things I'd like to see explained (fixed, implemented?): 1. Once a float, always a float. Don't see way to make float other type of data - string, integer. At least one can convert floats to strings: :let x=1.3 :echo type(string(x)) Regards, Chip Campbell --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: BUG: Partially reversed strings with long entered ex command
Ingo Karkat wrote:
I'd like to report a bug that occurs when a very long ex command is
entered, so that the GUI / console screen space isn't sufficient to
display the complete command.
I have an external VBScript that uses the VIM OLE SendKeys() function
(or WshShell.SendKeys() as a fallback) to open a list of files in VIM
via:
:drop file1 file2 C:/Program\
Files/this_is_a_very_very_very_long_filename
If the list of files is longer than the available space for the ex
command, the characters that didn't fit in are appended in reversed
order:
:args
[file1] file2 C:/Program\ Fiemanelif_gnol_yrev_yrev_yrev_a_si_siht/sel
^ BUG: reversed string!!!^
This happens:
- both in GVIM and console VIM
- on Windows and Linux
- through OLE SendKeys(), VIM's feedkeys(string,'t'), or by manually
typing the string
- in VIM 7.1.311 until back to VIM 6.0
Probably, this is due to some bad pointer increment, which is
hopefully easy to fix.
Steps to reproduce:
---
vim -N -u NONE
Limit window size to minimize typing until overflow :-)
:set columns=20 lines=4
:drop 1234567890 1234567890 1234567890 1234567890 1234567890
1234567890 1234567890 1234567890
Enlarge again to better see the output (optional).
:set columns=80
:args
[1234567890] 1234567890 1234567890 1234567890 1234567890 1234567890
12345670987654321 098
Note the garbled strings at the end!
You can also reproduce without resizing via feedkeys():
gvim -N -u NONE
call feedkeys(':drop ', 't') | for i in range(1,500) | call
feedkeys('1234567890
', 't') | endfor | call feedkeys(\CR, 't')
:args
I see the problem. I think the patch below fixes it properly.
*** ../vim-7.1.314/src/ex_getln.c Thu May 29 15:33:13 2008
--- src/ex_getln.c Mon Jun 9 20:10:51 2008
***
*** 2829,2838
if (has_mbyte)
correct_cmdspos(ccline.cmdpos, c);
#endif
! /* Stop cursor at the end of the screen */
! if (ccline.cmdspos + c = m)
! break;
! ccline.cmdspos += c;
#ifdef FEAT_MBYTE
if (has_mbyte)
{
--- 2829,2839
if (has_mbyte)
correct_cmdspos(ccline.cmdpos, c);
#endif
! /* Stop cursor at the end of the screen, but do increment the
!* insert position, so that entering a very long command
!* works, even though you can't see it. */
! if (ccline.cmdspos + c m)
! ccline.cmdspos += c;
#ifdef FEAT_MBYTE
if (has_mbyte)
{
--
Bypasses are devices that allow some people to dash from point A to
point B very fast while other people dash from point B to point A very
fast. People living at point C, being a point directly in between, are
often given to wonder what's so great about point A that so many people
from point B are so keen to get there and what's so great about point B
that so many people from point A are so keen to get there. They often
wish that people would just once and for all work out where the hell
they wanted to be.
-- Douglas Adams, The Hitchhiker's Guide to the Galaxy
/// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\download, build and distribute -- http://www.A-A-P.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: Updated floating point patch
Mikolaj Machowski wrote: Things works, thanks :) Few things I'd like to see explained (fixed, implemented?): 1. Once a float, always a float. Don't see way to make float other type of data - string, integer. String - Float with str2float() Float - String with printf() When would you need Float - Int? You can actually use printf(.0f, float), and rely on automatic String to Int conversion, but it's clumsy. 2. This is not strictly related to floating point, just noticed: :echo 1/0 2147483647 :echo 1.0/0 2.147484e+09 Shouldn't divide by 0 throw error? The number you see is the largest int value or a special value for floats which is INFINITY. It has always worked this way for Ints, don't know if it is such a good idea to do differently for floats. Although I would rather get the maximum value, INFINITY doesn't appear to be close to infinity :-). I suppose I should use MAXFLOAT instead. 3. floor(), ceil(), trunc() ? And round()? 4. Cosmetic thing but truncating of 0s in floating numbers would be user friendly (eg. store and display 0.5 instead of 0.50) I don't see an argument to printf() to get this. -- For a moment, nothing happened. Then, after a second or so, nothing continued to happen. -- Douglas Adams, The Hitchhiker's Guide to the Galaxy /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Improve vim's keyboard input subsystem
On Mon, 09 Jun 2008 21:04:51 +0200 Bram Moolenaar [EMAIL PROTECTED] wrote: No, because only a few terminals send these codes. Instead, add the entries in the termcap/terminfo. That might break other programs though. You can also use a Vim script to set them. Or a shell wrapper around Vim. All that works but isn't nice. So, do you suggest that screen's termcap/terminfo DBs ought to contain these items? I know the current termcap/terminfo system is outdated and insufficient for modern terminal emulaters. The solution should be changing termcap/terminfo into some better library. The actual escape sequences used can remain the same. And that is exactly what I propose. My libtermkey library already understands the byte sequences that xterm _already_ throws. I made a whole load of suggestions on how to extend these byte seq.s to fix a few problems with the current encoding, but that was more of a side interest... Nothing stops libtermkey from simply abstracting out what termcap/terminfo already provide. It's an extension of, not a replacement. -- Paul LeoNerd Evans [EMAIL PROTECTED] ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: PGP signature
RE: Updated floating point patch
Mikolaj Machowski wrote: echo printf(%.0f, 0.4) E807: expected Float argument for printf() You mean (argument not a string): :echo printf(%.0f, 0.4) echo printf(%d, 4-2) Same glitch. It's 4-2 not 4-2. user friendly (eg. store and display 0.5 instead of 0.50) Here is a workaround: :let f=1.0/2.0 :echo f :echo substitute(string(f),'0\+$','','') John --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Updated floating point patch
Ben Schmidt wrote:
When would you need Float - Int? You can actually use
printf(.0f, float), and rely on automatic String to Int conversion,
but it's clumsy.
Float - Int can be very handy, using floats as intermediate
calculations in scripts and then converting to ints for some kind of
display or condition, but usually in combination with a well-defined way
of converting between...i.e. a ceil, floor, round function. It would be
good if some of these could be implemented. How about a single round
function with a second parameter to specify the type of rounding, and
return an int? The second argument could be 'floor|down|int' (round
down), 'ceil|up' (round up), 'trunc|zero' (towards zero), 'away' (away
from zero), 'nearest|round' (towards nearest integer, round away from
zero if half way), 'even' (towards nearest integer, round to the even
number if half way).
2. This is not strictly related to floating point, just noticed:
:echo 1/0
2147483647
:echo 1.0/0
2.147484e+09
Shouldn't divide by 0 throw error?
The number you see is the largest int value or a special value for
floats which is INFINITY.
Something is wrong there, because it's not anywhere near the largest
value for floats, it is simply the largest value for a 32 bit int
converted to a float. Looks like some integer code has interfered with
the float code. Only on your system though. My system correctly reports
'inf', the special IEEE floating point representation of 'infinity'.
There is still a bug there, though:
:echo -1/0 gives 2147483647, see below
:echo 0/0 gives 2147483647, see below
:echo -1.0/0 gives inf, should give -inf
:echo 0.0/0 gives inf, should give nan
It may also be worth noting that 0.0 and -0.0 are (or should be)
different floats, so, for instance 1/-0.0 should give -inf.
For the integer ones, the negative should report, if the 'maximum value'
philosophy is followed, -2147483648 (==-2^31, the smallest value a
32-bit int can represent). Though in Vim, a case could be made for
actually returning -2147483647 (i.e. one unit 'too high') since in Vim
-(-2147483648) == -2147483648 due to overflow, which isn't very
desirable! In practice, using -2147483647 and having a sign change work
as expected would be more useful. Care would have to be taken to have
things that work on 64 bit systems, too, I guess (and systems with
smaller words if we still compile for those!). However, this whole idea
isn't all that useful with ints anyway. It is useful with floats,
though, In most environments, integer division by zero chucks an error
and float division reports inf, -inf or nan as appropriate.
Apart from various types rounding, which I can definitely imagine being
useful, are there any mathematical functions that could be handy in a
text processing environment? So far I can only think of 'toy'
applications for them! Perhaps to minimise disruption but allow
flexibility they could all be wrapped in a 'math' function, where the
first argument is the function, and the second and optionally third
arguments are the parameters?
math('sqrt',argument)
math('exp',exponent[,base=e])
math('log',argument[,base=e])
math('sin',argument[,degrees (bool)=0])
math('cos',argument[,degrees (bool)=0])
math('tan',argument[,degrees (bool)=0])
math('atan',argument[,degrees (bool)=0])
I think that covers all the basics in an extensible and inobtrusive way.
4. Cosmetic thing but truncating of 0s in floating numbers would be user
friendly (eg. store and display 0.5 instead of 0.50)
I don't see an argument to printf() to get this.
Yeah, that'd be a good improvement.
Are floats or doubles being used? They are definitely being displayed
with float, not double, precision at present. I would vastly prefer
double precision. 7 significant figures is barely worth it, and wouldn't
cut it for a lot of data files where having floating points in a text
editor would actually be useful! 15 significant figures gives you a lot
of power, and would allow you to interact with the floating points just
as accurately as most other software that would be reading your data
files.
Ben.
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: Updated floating point patch
Gary Johnson wrote: On 2008-06-10, Ben Schmidt [EMAIL PROTECTED] wrote: Out of curiosity, why the preference for a few functions with parameters, e.g., To be honest, I probably prefer the 'many functions' approach. I was just thinking in terms of not cluttering the Vim function namespace with functions for a feature that isn't really core to a text editor. Though for the rounding, there are so many different types and different names for the different types, that I thought a single function to group them together made sense. Still, the chances of an actual name clash are small--if we called a function by one of those names with a different purpose, it would cause plenty of confusion, and I guess just another section of :help function-list is needed. abs(argument) That's a good thought. Vim should have that one, for ints and floats. sgn() wouldn't go astray either. Another that could conceivably be useful would be a random number function. A low quality PRNG would do just fine. This could be used in Vim for editing data files for testing purposes, etc. Ben. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Updated floating point patch
On Tue, Jun 10, 2008 at 01:55:04PM +1000, John Beckett wrote: It would be a pointless waste of development time to do much more with floats in Vim, IMHO. I *strongly* agree! Apart from the basic operations, the rest can be left to vim-perl/python/ruby/etc. Please don't bloat Vim. GI -- 'Impatience' -- Waiting in a hurry. pgp4FrFt8TWb4.pgp Description: PGP signature
Re: Updated floating point patch
John Beckett wrote:
Ben Schmidt wrote:
math('sqrt',argument)
math('exp',exponent[,base=e])
math('log',argument[,base=e])
math('sin',argument[,degrees (bool)=0])
math('cos',argument[,degrees (bool)=0])
math('tan',argument[,degrees (bool)=0])
math('atan',argument[,degrees (bool)=0])
Considering the functions, not the syntax to call them, I would have
to suggest that it would be better to use Python-in-Vim for this sort
of thing (and get complex numbers as well, plus heaps more).
You can leverage that argument about the entire floating point patch.
That said, the only functions I can imagine being truly useful in a text
editing setting, as opposed to an application that truly does require
something more numerically oriented, like a scripting language or
spreadsheet, are:
- rounding functions
- absolute value function
- sign function
- random number function
- power function (either exp() with variable base or pow() with
arguments in the reverse order)
Not the rest of the mathematical functions, the majority of which you
noted above. As I said, I can only think of 'toy' applications for them.
It would be a pointless waste of development time to do much more with
floats in Vim, IMHO.
Despite my comments above, I don't think writing a wrapper around a C
library function is long or hard work, which is basically all this
requires. If you're going to do one or two, which I think could be very
useful, you might as well do all ten while you're at it. Saves having to
do it later when someone discovers they need it!
But that said, yes, there are other Vim features I would much rather see
than this: variable tab stops, for instance, which are useful for many
more (most tab separated) data files than floating point computation is.
Are floats or doubles being used? They are definitely being
displayed with float, not double, precision at present.
Vim's float code is using doubles.
I haven't done anything serious with floats for years, but my vague
recollection is that you would have to use something like
printf('%.20f',myfloat) to see lots of precision (i.e. I think what
you are seeing in Vim is just standard behaviour).
Yes, this works (well, 20 doesn't work, because they don't have that
much precision, so it just prints additional rubbish digits, but that is
as expected)!
Ben.
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
